Git development→production workflow – how to set up repo?

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

In git it is easy to just create a new branch for every type of change that you want to do. Then when the change is done, you can first merge it with the unstable branch (and eventually to the stable branch).

When you want only some of the changes to merge into the stable branch, you can select the functionalities that you need by selecting the right branches.

Answer 2

We use the following workflow :

1. All changes/features/improvements bugs enter in JIRA
2. We create a branch in JIRA with the name of the ticket e.g. TKT-1234
3. Work-Work-Green-Commit-Push to central (github in our case but not important) on branch TKT-1234
4. Hudson (CI server) polls central repo, sees new branches, merges them on master, compile, test, push to central if tests pass
5. Developers pull from central regularly

If this circle runs fast enough there are almost no conflicts. All branches are relatively short lived. Everybody stays close to the master.

For moving to prod, we make manually a branch in a UAT repository after validation this is deployed.

Answer 3

read http://nvie.com/git-model and use hxxp://github.com/nvie/gitflow

Answer 4

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).