Git workflow for a new dev project

Question

I am starting a new Project and it has been decided that we shall use git for our version control.

It is a project which involves development of multiple components / Microservices from scratch.

To address the complexities in our organisation where we have junior developers, senior developers, dev leads, architects etc., I was looking to use a git workflow based more or less on gitflow, so that we can ensure that developers can work on feature branches and before moving on to the develop branch, we have some code review process in place. I want to have master branch which corresponds to the production / production ready code and release branches to signify the current release in progress.

It is an agile project so my idea is to have develop branch corresponding to the sprint code (unit tested and reviewed) and the release branch corresponding to the release (=3 sprints).

The only issue I am facing is how to define the master branch and the relationship between master and develop at the beginning.

Since it is a new dev project, we begin with no production code and everything would basically start from feature branches, move to develop, release and then the master when we have the production ready code.

Any suggestions on how to handle this in a good way and also, is this a good idea

Thanks in advance

Answer 1

First create a master branch and then from the master branch create other branches. For your reference, I find this gitflow branching model diagram helpful and have successfully in multiple projects.

Don't over do it. First start off with the simplest branching strategy and then depending upon the complexity and need you may create or adapt to more complex branching strategy.

Answer 2

I think gitflow is just fine for a project as you describe it.

If you just start, I would create the master but leave it empty. The develop can be filled with static files (.gitgnore or something like that). Then you start developing in feature branches and merge to develop. After three sprints you create a release branch and do your extended tests.

After all tests pass and you are willing to release your code, you merge into master. So you first merge to master after three months from now.

Answer 3

First, if you're asking this question, you're going to want to start off with a clean, simple flow, then once everyone on the team is rowing ahead well, you can consider incorporating additional branches or level. Don't be surprise if you find you don't need any! It can be a non-trivial task trying to keep separate parallel branches all in sync, with an understandable commit log when you're cherry picking features between them.

NOTE: the squash merges below are for only finished features being merged into master. As you develop a feature, if you periodically need to update your feature branch from master, don't squash your update merges from master.

Some folks prefer keeping individuals sub-commits of each feature branch when merging back into master. I don't, but feel to exclude the squashing, it does't chage the workflow.

I suggest you use this simple flow:

• HEAD of master is for all intents develop
• All development happens on feature branches cut from the HEAD of master (unless it's a patch for a release branch)
• Once tested, features are merged back to master (Merge squash if you want a single commit point in master!)
  • Occassionally, you might want a integration test of several features at once
  • Merge (squash here if you want a single commit point!) them together in order in which they occur into a combined branch off of master, branched at the commit just where the earliest feature being tested had it's branch cut from master.
  • Test that combined branch then merge that into master (no squash needed as each feature is already squashed to a single commit on this combined feature branch and you don't want to loose the distinct individual feature commits)
  • Delete the combined branch
• Delete the merged in feature branch
• We test HEAD master, when a release candidate is ready we branch off a major minor numbered release branch (like release-2.4)--this never merges back to master.
• We also tag the initial commit on branch a full version 2.4.0
• Any patches to a branch get a feature branch off of it, then when merged (squash if you want the patch to be a single commit point in your release branch!) back in a new tag like 2.4.1
• Any fixes / patches from a realease branch that needs to get to Master or other release branches is done manually on master and each other release branch, not by merging in entire release branch. Hopefully, fixes should be minor changes

Release don't have to be at HEAD you can use any commit after the last release branch for that.

Once you've got this running smoothly, you can try to incorporating additional 'staging/develop' branches, I think you'll find limited value and much headache keeping them clean and in sync. I've consistently found trying to keep separate develop and master branches to be more work than value.

One of the greatest benifits of this flow is how clean your history is. If you look at the network graph of it it github it's one continual chain, with only feature branches being worked on, (squashed) feature commits to master), and release branches that never merge back in. Anybody can understand clearly everything without a local git guru to interpret and without deep understanding of any idiosyncratic dev process your company may have.

Answer 4

Here are a few options:

Git Flow (branch from develop, merge into develop)

The idea behind git flow is that developers build and contribute to a "develop" branch and once the powers-that-be decide it's about time to do a release, you "cut" off of that branch and create a release branch to refine until it's good enough to actually be released.

Pros:

• You're almost always working off of the latest version of the code. If you make a change, you merge it into the develop branch right away and everyone else can build off of it. This is convenient!
• It's one of the most well known flows so a lot of people are comfortable with it

Cons:

• The develop code can often be unstable or outright broken. Since QA is not usually testing directly against the develop branch, issues may go unnoticed until the next release is ready to be cut. In other words, quality feedback may be delayed
• If you are using agile, it can be difficult to keep track of where your code lives. Imagine having a ticket that is assigned to a specific release and sprint. The code you write for this ends up being merged into develop despite what release or sprint the ticket is in. If a manager goes and moves that ticket to a different release or sprint, you may have to pull the code out of the develop branch or do some hacking to make it all work nicely. This can become tedious and difficult to manage if it's happening frequently
• When doing hotfixes or making fixes to a release branch, you have to change your ordinary workflow and instead branch off of the release branch, master, or something entirely different. This complicates the workflow and for newer developers can become very confusing

Branch from master; merge into release branch

This is one that I think is the most straight forward but definitely has drawbacks. The idea is that all features are branched off of master (which matches production at all times) with the assumption that these branches can be merged into ANY branch at ANY time. When you are ready to start testing a release, you simply make a new Release_v99 branch (with an appropriate name) off of the master branch. You merge in the feature branches you want to be released, then test against the Release_v99 branch.

Pros:

• Safe! Feature branches are always "safe" to be merged anywhere because they're built directly off production code.
• Feature branches aren't tied to a specific version of the code that isn't already deployed, so you can pretty easily move tickets around as needed without any major headaches
• If your release branch turns into a disaster (due to reverts or something), it's easy to scrap it and make a new one since your feature branches can easily be merged into it again.
• If you want to have "long running" branches for other test environments, you can easily merge your features to these without accidentally pulling in other peoples changes

Cons:

• You will likely be building off of old code and therefore run into some merge conflicts. Working off of stale code can sometimes cause issues if many people are working on similar things