Developer Workflow with Git Branches

Question

I'm reading this article http://nvie.com/posts/a-successful-git-branching-model/

Right now we have a central repository (a source repo). Everyone is cloning down this (creating a fork in technical terms), and then creating their own branches.

I'm used to svn, the old way of doing things where as a good little developer your'e expected to check into master often. However with Git, I'm not as clear on if that is something we should still be doing.

Lets say I have a brach off the origin master, and my collegue also has his own branch for some other feature. I want both of us to commit often so that we get each other's changes.

But does that mean we should both be merging back to master every time we make a commit? Or, should I be pulling from his branch directly and we only merge back to master when it's time to say it's ready for release (or ready for pushing to QA or whatever)?

Also how do you create a developer branch essentially where we can both merge our branches into some kind of developer repository? I don't get how this works, segregating environments with origin master as something you do not modify as well (that's a no brainer)? So for devs, do you create a new branch called 'development' off the origin master and then developers merge their changes back to the development branch and then when time comes we think our development branch is stable, merge back down to master origin and push that off to Jenkins and Jenkins builds and runs automated unit tests? How would you push your development branch to Jenkins? I'm lost.

Answer 1

To answer the first point - merging frequently into master depends on your workflow. There are many different workflows out there with Git; Git Flow is yet another approach. It has its strengths and weaknesses, depending on how your team integrates, tests and deploys code.

Right now, it sounds like you have a master branch and a branch that you develop on personally before it's pushed to master. This may be fine for your workflow, but there are a few things you are going to want to understand:

• The work you're doing should be in isolation from anyone else's work. If you find yourself in a situation where that's often not the case, you need to decompose the work further until it can be reasonably isolated.
• You should only merge to master if your feature is complete. Don't merge incomplete code.
• If you require a place to integrate the work that you and other colleagues have done, then this is more of a communication problem than anything else; if master is the branch to do it on then so be it.

The idea behind Git Flow is that it takes whatever is currently in master and treats that as production-ready code; that is, the code that's on master is what is live in production at that moment in time. Other workflows exist where the use of tagged commits indicate this fact instead, such that only the last tagged commit on master is what's live in production.

Since I don't know anything about your testing environment, I can't say if it'd be easier or harder to create a new branch off of master, exclusively for an integration point. If you don't want a commit in master to represent deployable code, then it's fine to continue merging directly into master (but do tag your releases).

I will say this about separate branches, however: if you do want to do separate branches, then you're going to want to adopt most of the principles behind Git Flow. See how well it works for you and your team.

• master is always deployable
• development is always mergable to master
• Topic branches are always mergable to development (and should be rebased against master)
• Further, as a general rule, all branches should be tested through Jenkins. If you can't test all branches reasonably, then the main integration points should be tested.

Answer 2

You should merge back into master as often as possible. For example, many companies have a workflow where users write code, commit that code locally, then post it for review. If changes need to be made, the author makes the changes, makes another commit, and posts it for review again. When accepted (usually 0-2 revisions are needed), the developer merges it into master.

Infrequent merges to master is a very, very bad thing, because it means there will be an absurd number of merge conflicts. Don't do that.

You ask about "developer branches"; that's what master is for. Instead of using master as your release branch, use master as your development branch, and whenever you need to make a release, create tags. These are like branches, but permanently point to a given repository state.

If you need to share work with another developer that isn't ready yet (i.e. it hasn't been reviewed), you can create another remote branch (in addition to master), and use that.