One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Hello, I think you did a good job at describing your git workflow, but also that we should always be careful of avoiding preaching "best practices" without noting what is the context of the project.
Even the best things make sense only in a given context.
For small teams, you could do more complicated than "GitHub pull-requests + squash commits" but YAGNI.
Can you tell us more about your context?
How many developers are working on a single repository?
Is there some reason a clean git history is especially important for you?
etc...
Thank you for your comment. The purpose of the article was not to preach a specific case but to outline a common one from my own experiences.
I don't believe there is a single optimal flow to use for all types of projects, in the same manner, that I don't believe there is a single "best" technology out there. It all drills down to solving a specific problem. Also, I would always pick consistency inside a team, before a "better" flow, as the most important thing is that everybody is efficient and understand what they are doing.
We use different flows inhouse, based on the project, and whether it is a small website, mobile app or a SaaS product. One of the flows that we also use for some cases in contrast to GitFlow is Stable Mainline Branching model: bitsnbites.eu/a-stable-mainline-br...
The only real consistency is that we always use a rebase flow, that doesn't change.
The context is:
Projects are usually 2-5 developers working together. Most are 1dev/1feature as we prefer smaller features that we quickly iterate on, but there are cases when 2-3 people work on a feature if this is not applicable.
I had the unfortunate luck of working on tons of client projects, where there were no, or very lousy git practices. Resolving any type of conflict was a problem, and even "missing code" was sometimes the case. This is one of the reasons why we have a strict pattern in our company. When people get used to it, it becomes second nature. Usually, new developers are actively mentored during the first 2 months on git practices and our code standards to alleviate the overhead of using something that may seem like a complex flow at first.
As stated in the article, nothing is lost if your graph is a bit messy, but this allows the team lead to more easily see the order of merged features, revert or bisect commits or features if a problem was introduced, and quickly pinpoint the issue, leading to faster hotfixes from our experience.
The GitFlow pattern also works great with our CircleCI build setup, where PR-s to specific features are automatically tested and released to test/staging/production servers.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Hello, I think you did a good job at describing your git workflow, but also that we should always be careful of avoiding preaching "best practices" without noting what is the context of the project.
Even the best things make sense only in a given context.
For small teams, you could do more complicated than "GitHub pull-requests + squash commits" but YAGNI.
Can you tell us more about your context?
How many developers are working on a single repository?
Is there some reason a clean git history is especially important for you?
etc...
Hi Jean-Michel,
Thank you for your comment. The purpose of the article was not to preach a specific case but to outline a common one from my own experiences.
I don't believe there is a single optimal flow to use for all types of projects, in the same manner, that I don't believe there is a single "best" technology out there. It all drills down to solving a specific problem. Also, I would always pick consistency inside a team, before a "better" flow, as the most important thing is that everybody is efficient and understand what they are doing.
We use different flows inhouse, based on the project, and whether it is a small website, mobile app or a SaaS product. One of the flows that we also use for some cases in contrast to GitFlow is Stable Mainline Branching model: bitsnbites.eu/a-stable-mainline-br...
The only real consistency is that we always use a rebase flow, that doesn't change.
The context is:
Projects are usually 2-5 developers working together. Most are 1dev/1feature as we prefer smaller features that we quickly iterate on, but there are cases when 2-3 people work on a feature if this is not applicable.
I had the unfortunate luck of working on tons of client projects, where there were no, or very lousy git practices. Resolving any type of conflict was a problem, and even "missing code" was sometimes the case. This is one of the reasons why we have a strict pattern in our company. When people get used to it, it becomes second nature. Usually, new developers are actively mentored during the first 2 months on git practices and our code standards to alleviate the overhead of using something that may seem like a complex flow at first.
As stated in the article, nothing is lost if your graph is a bit messy, but this allows the team lead to more easily see the order of merged features, revert or bisect commits or features if a problem was introduced, and quickly pinpoint the issue, leading to faster hotfixes from our experience.
The GitFlow pattern also works great with our CircleCI build setup, where PR-s to specific features are automatically tested and released to test/staging/production servers.
Thanks a lot, adding context like this makes it insightful : we saw those problems, and here is what we did to mitigate them.