GIT Branching strategies and GitFlow

Why GIT?

1.Team’s code at some regulated place
2. History of collaborators
3. Version history of code and commit history
4. Merging of code is easier
5. Multiple branches and multiple tags — option to look back

Internals of GIT

1. Uses Merkle Trees as a data structure
2. Uses SHASUM for hash-object as commit hash — each commit represents an object reference

What people usually See in any repository?

1. If developers are creating a new feature, do not work on master directly.
- Create a feature branch from master.

2. Work freely and independently on this branch.
— Do multiple commits, do right, wrong, experiment, everything.

3. When the work is done, it is merged back into the master branch.

What people don’t see usually?

1. Fixing a bug on a previous version of the software. Yes, that’s branches
- Bug Fixing

2. Having features in validation before going to production. More branches
- Do multiple rounds of testing.

3. Fixing a bug found during testing and before release to production. More branches
- Fixing bugs in pre-prod

Merging branches is not always easy

1. You have two versions, which one should you take? And where should you keep ?

2. Often you’ll have to take changes from both branches.

3. Maybe the changes of one branch impacts code that only exists on the other branch. Who will be responsible for conflicts?

4. On which branch, you’ll resolve conflicts ?

GIT is so great, is precisely because it makes merging easier. How ?

Branching Model — Merging becomes easier

1. So merging can be tricky

2. Depends on when branches are created and on how they are managed.

3. We as a team will follow some kind of branching and merging policy: this policy is called a branching model.

4. Many branches, looks messy but makes life easy.

Multiple Branching Models — Let’s try the widely accepted one

GitFlow, GitHub Flow, GitLab Flow, One Flow

Let’s try GitFlow, Why?

All models are good. But, let’s use GitFlow because

1. Widely accepted across multiple organisations
2. As per many reads, best suited for the team who work in sprints

Lifetime branches — Two main branches

• master —
  1. this branch contains the live-production code.
  2. All development code is merged into master in some time.
  3. represents what’s in production
• develop —
  1. this branch contains before release or development code.
  2. When the features are finished then they are merged into develop.
  3. Code reviews happen when you raise PR against develop from feature
  4. develop is thus some buffer between “dev done” and “in production”

Temporary branches — Close them after a successful merge

1. feature-* — feature branches are used to develop new features for the upcoming releases.
   May branch off from develop and must merge into develop.
2. hotfix-* — hotfix branches are necessary to act immediately upon an undesired status of master.
   May branch off from master and must merge into master and develop.
3. release-* — release branches support the preparation of a new production release. They allow many minor bugs to be fixed and preparation of meta-data for a release.
   May branch off from develop and must merge into master and develop.
   This is not actual release, instead, this is the preparation of the release
4. bugfix* — all the fixes done against the issues raised during the testing of the release branch
   May branch off from release and must merge into release and develop.

Typical Development Cycle and Pull Request

Delivery and Pull Request Stage

Worry as a developer ?

Think about feature and always think about the cycle beside.

Different environment — Different branches

1. Staging — Release branches can thus be tested and validated at length in the staging environment
2. Develop — Develop/feature branches can thus be tested by developers
3. Pre-Prod — Master branch can thus be tested and left for automation testing and sanity testing before we go live.
4. Production — Master branch with live running and used by clients and traders

Advantages

1. Ensures a clean state of branches at any given moment in the life cycle of the project.
2. The branches naming follows a systematic pattern making it easier to comprehend.
3. It has extensions and support on most used git tools.
4. It is ideal when we need to have multiple version in production. How?

Tagging

1. Tagging is like specifying specific points on the project. This is tied to a commit.
2. Create new Git tags in order to have a reference to a given release of your software.

Branching vs Tagging

• A branch is used if you have 2 different versions of the repository at the same time.
• A tag is a way to mark a point in time in your repository.
• You should add a tag to mark a released version.
• If you then need to make bug fixes (via hotfix branch) to that release (master) you would create a branch at the tag.
• HEAD moves with the branch it points to and with tag, we can have a detached HEAD mode

RECAP — More Visuals to understand