Question

I’m working on a relatively small, but fast-changing project (a web application) with a few other developers. We’re using Git for source control.

We started out creating a stable branch which is what is deployed to the live production web server. The master branch is what is deployed to a secondary “unstable” server for testing purposes. Whenever we felt that the master branch was ready to go live, we merged it into stable.

However, we came to a point where we wanted one of the later master commits, but not some of the commits before it, so we used cherry-pick to pull that change into stable. This creates a new commit with the same change as the one in master, and it feels as if we’re losing the nice history that Git otherwise provides.

Are there better ways of handling this type of unstable/stable deployment model?

One solution I thought of was using feature branches, and only ever merging a feature branch into master once we want it to go live. Then we’ll tag every deployment instead of having a stable branch.

Answer 1

You’re correct in saying that this undermines the history git keeps by cherry-picking. The thing to think about here is, why do you not want the preceding commits on stable?

(nb. if its some following commits that you aren’t ready to port yet, you can of course use git merge <commit-id> rather than cherry-pick to retain the history cleanly – future merges are also smart about not duplicating commits/changesets)

If you don’t want them because they aren’t ready for mainline, or fully tested, what makes you confident that the desired commit (which depends on them and their state) is ready?

If its because they aren’t ready for stable, and the commit that you want doesn’t depend on them, then you aren’t branching as effectively as you could be: that commit could have been on a seperate topic branch (which contains only the commits required for the feature you’re interested), then once you’ve determined that its good to hit stable, just merge that branch. You can then either rebase your other branches that need this feature onto stable, or just merge the feature-branch into them (once again, git is pretty smart here about future merges).

It takes a little more discipline to think about the impact of your commits as you are working (since you’re already committing early and often ;), but it makes the branching/merging workflow much simpler – git checkout -b new-feature is your friend to quickly add a commit with other, unrelated changes in the middle of working in a topic-branch (or git checkout -b new-feature master if you are particularly well-disciplined and don’t have extra changes hanging around your work tree).