Comments for Git Workflows That Work

[phinjensen]

Comments for https://www.endpointdev.com/blog/2014/05/git-workflows-that-work/ By Spencer Christensen

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: Srđan Šrepfler
date: 2014-05-24T06:46:33-04:00

Scullcandy the headphones company uses git?

[phinjensen]

original author: Spencer Christensen
date: 2014-05-26T12:43:18-04:00

Hi Srđan. Yes, indeed they do! I worked for them managing server architecture and doing release management for their websites.

[phinjensen]

original author: Mark Haller
date: 2014-12-23T13:31:50-05:00

git --help workflows

Why is that never discussed? I actually prefer the naming in git flow, but there are some interesting thoughts in there, like always merge upwards.

I also don't understand how github deals with regression. They can't be merging all these branches and not introducing bugs. I assume their tests are so automated and fast, that they can push so often with such confidence.

[phinjensen]

original author: Spencer Christensen
date: 2014-12-23T15:11:14-05:00

Hi Mark. Thanks for pointing out git --help workflows. I actually wasn't aware of that. I've read through it now and I agree the naming in there is a bit confusing.

One thing that I clearly noticed was that the workflow they describe is used for git itself. So unless you plan to help contribute and work on the git source code, take their recommendations with a grain of salt when applying to some other project. Although, I do think that some of their points are good general guidelines for most projects. For example- create your feature/topic branches off of the oldest branch that you intend to merge back into (meaning, branch off master if you intend for your changes to end up being merged back into master for deployment). I also agree that feature/topic branches should be kept separate from integration branches, and that they are individually merged into testing and release branches (like master)- instead of merging a bunch of features into a common branch and then merging that common branch merged into master. Doing it this way limits the risk of changes being deployed that are not ready.

As for GitHub's workflow- I can't say how they test and deal with regressions. I would certainly hope they do regression testing before merging into master and deploying. However, one of the advantages of their very simple workflow is that it is quite easy to revert the latest change or to quickly deploy a fix.

[phinjensen]

original author: 4SN
date: 2015-03-21T00:09:03-04:00

Hi Mark, In the Git flow, release branch it is branched off from develop. What I don't quite understand is that, develop has lot of on-going development activities. Some of which, for example we want to cut release 1.2, introduce code that is meant for much later release (1.3 and could be 1.4) due to continuous development. Would the release that we are creating 1.2 already be polluted right at the beginning?

I must be missing something very basic here? Thanks 4SN

[phinjensen]

original author: 4SN
date: 2015-03-21T00:11:20-04:00

Sorry, my question above was meant for Spencer :(. However, I appreciate anyone who could shed some light for me as I am fairly new to Git.

Thanks!

[phinjensen]

original author: Spencer Christensen
date: 2015-03-24T11:46:12-04:00

Hello 4SN.

Gitflow does has some good points to it, but as you point out there is certainly the possibility that code that is not yet ready for production gets included in a release accidentally. This can be a major problem or it can be an acceptable risk. It all depends on your project and your release management.

When I worked at Backcountry, we had well known schedules for releases and for code reviews to help reduce the chances of something getting in that wasn't ready to go out. Every feature branch was peer-reviewed and tested and approved by a business owner before it got merged into the development branch and then subsequently included in the next release. So we had processes and expectations of each developer to follow to help solve the problem. But that was no guarantee to stop it from happening, it still did every once in a while- and that was "an acceptable risk" that we all knew could happen.

There are other things you can do to try to solve this problem, but in my opinion they add more process and overhead to a release workflow that is already complicated. Instead of trying to add more safety checks and more reviews and meetings and on and on, I'd recommend looking at something like the Github Flow or the Skullcandy workflow which keeps all branches in isolation until deployment. That way you can test and approve changes individually- and keep out changes that are not ready for release.

As I said in the blog post above, the point of your git workflow should be to help you release your software (safely, timely, etc.). So that is more important than following Git Flow "the right way" or any other recommendation. And if your process is too complicated, then that is a red flag that you should make changes to simplify it.

Best of luck!

[phinjensen]

original author: Marnen Laibow-Koser
date: 2015-05-06T14:36:51-04:00

"GitHub’s own workflow, their internal workflow, is quite different from what everyone else does who uses GitHub."

Really? I've been using this workflow for a long time, on many projects, without knowing that GitHub used it internally.

[phinjensen]

original author: Stijn Herreman
date: 2015-09-02T09:31:08-04:00

Our team is looking to use a workflow similar to the Skullcandy workflow. The major difference is that we'd have 3 QA branches and they are to be permanent; after a feature branch was merged to the first QA branch and approved, the feature can be merged to the second QA branch, and so on, until they are approved for merging to master.

Ideally, when all feature branches have gone to all QA branches and to master, the QA branches and master branch are identical. However, mistakes could happen during merge conflicts, for example. Should we periodically merge master to the QA branches, as a safeguard/verification?

[shoosah]

In Skullcandy workflow, I was wondering how do we keep track of all the feature branches that are merged into QA. Shall we go through commits and figure it out or there is a better way?