Managing branches with git and SourceControl

Cristina

Hi!

We’re planning to move from TFS to Git. Currently we use Source Control, with no branches, but we would like to use them and we are not sure about the correct way to do it.

Imagine you have task1, create branch_task1, develop your task and leave it for other people testing. Then, you have task2, create brach_task2, develop the task and leave it for testing. I want both tasks to be available at the same time, but they’re not in the same branch, what should I do: push to develop branch? What if task1 is a long task that implies alter tables, multiple sps modifications, etc and I have to develop in the same database task2, which is a short task. If I change the branch to develop task2, I undo task1, maybe when I return to task1 there could be some kind of order issues executing my scripts, data loss… What is the best way to do it?

I hope somebody can shed some light on this. 

Thanks in advance!

AlexYates

Hi Mary,

Moving from TFS to Git is an excellent choice and your question is a very good one. The short answer to it, however, is "it depends". Everyone has their own views on the best branching strategy and it's a minefield of flame wars.

For example, first read this article by Vincent Driessen. This is probably the most widely respected and referenced blog post about git branching on the internet. This branching model has become known as "gitflow":
https://nvie.com/posts/a-successful-git-branching-model/

However, once you have read it, also read this blog post by Jussi Judin which calls out some of the common problems that some people see with gitflow. Essentially Jussi is arguing for trunk-based development because he feels it's better aligned with the principles of continuous integration and more natural for developers:
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

I'm sorry I don't have a simple answer for you - there is a big gap between theory and practice and ultimately you need to figure out how to bridge it for yourself. However, I would like to leave you with an exercise that I have run with various clients to help them figure out the best strategy for their team.

I believe in two things:

- You should avoid cherry picking changes from one branch or another. Branches should be tested and deployed in their entirety for effective, repeatable testing and simpler deployments.
- Your branching strategy should mirror your project management style.

You can read all the books you like about DevOps, continuous delivery and branching models, but ultimately if the way you manage your code does not match the way you manage your projects, you will forever be cutting corners, breaking your own rules and creating headaches for yourself.

For this exercise, I want you to begin by leaving your theoretical ideas about good and bad branching strategies at the door and consider the reality of the way you manage your development process and map that out as if it were a branching strategy. Since, in a perfect world, your project management style and your branching strategy would be aligned, you should consider whether the diagram you have drawn would be in any way sane if you used it as your git branching strategy.

This gives you a starting point - then you should think about whether you could make any simplifications in your branching or project management strategies to make life simpler - considering everything you know about DevOps, continuous delivery and widely accepted branching good and bad practices - while also considering the preferences and abilities of your team. (E.g. avoid long-running feature branches, break down bigger tasks into smaller chunks, don't ask a developer who has never used git to follow a horribly complicated branching model.)

For more info about my "reality branches" exercise:
http://workingwithdevs.com/branching-reality/

I hope that's useful. Good luck!

AlexYates

However, to answer your question more directly. Consider using a "release branch".

For example, in Vincent's "GitFlow" model feature 1 and 2 would have been merged to develop. Then a release branch could be created and the testers would work on the release branch until they are happy to sign it off. Then they would merge it to master and deploy to production.

Of course, you might prefer to develop your own strategy that does something similar. Or not.