Do we need to create local branches for the enhancements we are working on?

Question

We just started implementing the Git source control for our project and the Admin says we should not be creating any new branches for the enhancements that we are working on instead everybody should pull remote master branch into their machine and make changes and push the commits to remote master branch.

I somehow feel this process is wrong and I strongly feel that we should be creating new branch for the each enhancement that we are working on and merge the respective branches into master branch. Something similar to this

I need expert advice on this and which approach do you guys suggest from your past experience.

Answer 1

The commit to master or trunk works as long as you are ok with how it works.

It means that if you have committed a bit of code to master (and haven't pushed it because its not a complete thing) and then realize that you need to work on something else (leaving those commits in an incomplete state) - it becomes very difficult to do that.

Branches exist to separate development efforts and the roles that a given line of code may take.

Consider:

• You are packaging up a release on master, and now everything other than commits for this are frozen. This stops a lot of developers in their tracks.
• You need to commit a hot fix into master and push it to production.
• You need to work on two separate tasks at the same time.
• You need to hold off on committing some features into the master branch until marketing says "ok"
• Oops, that feature was a mess. Don't commit it to master - oh wait, its already there.

These are just some of the issues that come up with everyone committing to the master branch. If you can resolve these in other ways, then, well, you don't need branches. However, branches are exactly the tool that is used by most processes to resolve these issues avoiding code freezes and awkward reversals of specific commits.

I will also point out that none of this prevents you from having local branches. One could easily pull from master, branch local, rebase on top of master, delete the local branch, and then push that back to the remote master and none would be the wiser. Personally I feel that having branches and merges showing more information about the history of the code is useful, but thats me personally. Maybe your admin doesn't like seeing all those branches and just wants to see the master branch - there are people like that. But that doesn't mean don't branch local - it just means don't push the branches back to the remote and clean up everything before doing that push.

Answer 2

See the above-linked question for, I think, a comprehensive Q&A on the role of the master branch.

However, to further answer your question, it's important to understand why feature branches are important. If everyone is developing on and pushing to the same branch, then what happens when someone forgets to check in a file, or checks in the wrong stuff, or messes things up in a rebase?

In our organization we use GitFlow, with the master branch left unused. Develop is the working tip of the current release's efforts, releases are in named branches, and features are all developed on (hopefully short-lived) branches.

With feature branches, we're able to run a complete CI build on each branch before it gets merged to develop. Along with an approved pull request, the branch build must be green before the merge can occur. This ensures that the to-be-merged code compiles and passes all automated tests. This process has been successful for us in catching the simplest sorts of problems as early in the development cycle as possible.

Answer 3

Maybe the admin is simply trying to get you on board with a continuous integration development strategy, to avoid the integration hell usually associated with multiple development branches.