Git Branching Strategy

Next to the main branches master and develop, our development model uses a variety of supporting
branches to aid parallel development between team members, ease tracking of features, prepare for
production releases and to assist in quickly fixing live production problems. Unlike the main
branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

• Feature branches
• Release branches
• Hotfix branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches
may be their originating branch and which branches must be their merge targets. We will walk
through them in a minute.

Below mentioned is one of the most common and efficient Git workflows. With this one we can
easily manage feature, develop and master branches all together in a particular flow. Changes can
easily move from one branch to another with merge and rebase features.
 Release branch strategy

In This strategy we can work on multiple releases branched off from master branch. We can further
create story branches from these release branch and then these release branches can be merged
further to master branch. Master branch will receive merges from different release branches.

This also helps team to work simultaneously on various development work to be done on multiple
releases.

Collaborating between Local and Remote Repository

Git is one of distributed version control system which means we don’t have to depend on
network all the time. We have huge number of local repositories of a Git repository on
multiple systems. We can perform all operations like commits, merge, rebases etc. without
even having any connectivity with remote repository.

Local Repository: Local repository cloned on developers’ machine where they can do
modifications. These changes are present locally only and developer is having full control on
them. These does not need any connectivity with remote repositories.
Remote Repository: Purpose of remote repository is to publish these local changes to
remote repository. We can share remote repository with multiple developers and they can
easily read them. We need remote repository only whenever we want to push changes to
remote repo or pulling changes to local repo.
 Basic Git Operations

Checking status for files: We can anytime check the status of files in Git repository using git status
command.
git status

Creating New files: We can create new files in

repo to have untracked files using below
commands:

echo “First Project” > README

git status

Tracking new files: In order to make untracked

files as tracked we can use below commands:

git add .

git status

Stage Modified files: We can stage modified

files so that we can commit those and these
changes will become permanent once done.

git add .

git status

git commit –m “First Commit”

Reverting to Earlier Commits Demo

Git Log: We can check the log history of Git repo using git log command.

git log –oneline

Git Reset: Once we decide the commit to which we want to change our branch pointer, we can
execute below command to reset:
git reset <commit_id>
 git log (Commit should
not be displayed in git log now)

Git Revert: it helps us to revert

the changes done in a specific
commit. This command is used
when there is a situation of
rollback.
git revert <commit_id>

git log –oneline (A new

commit will be displayed now
which reverts that specific
commit)

Deleting Files in Git Demo

Git rm: Git rm command is used to delete files from git repositories. Once below command is
executed the file will be deleted from local repository. In case this is done by mistake we can run git
revert command to revert these changes.

git rm README

git status

git add .

git commit -m “Deleting Readme File

from Git”

Git rm --cached: This option helps to delete file

from git but file will not be permanently deleted
from local repository. We can easily access file
even after running this command.

git rm --cached CONTRIBUTION.md

 Deleting Files in Git Demo
Local .gitignore: if we create a file in our local repository with name .gitignore, Git will be able to
read this file to decide which files and folders to ignore while performing git commit. Create some
log and image files which is described in .gitignore file.

touch app.log

touch image.jpg

git status (This will not show

those files which is mentioned in
.gitignore file)

Global .gitignore: We can create both

local and global .gitignore
configuration to exclude some files
from commit.

git config --global

core.excludesFile ~/.gitignore

git config --global –list

Renaming Files in Git Demo

• Git mv: Git move command is to rename files in Git repo without losing history of that file.
Once the file is renamed, we also have to perform commit in order to save those changes
permanently in repository. We can anytime browse through history of this repo to see which
file is modified and renamed.

git mv old_filename new_filename

git status

git commit –m “Renamed file in Git”

 Git Branching Demo

Git branching helps us to manage the branches in Git repositories. We can create, switch and delete
these branches according to our requirements.

List Branch: We can list branches in an existing repository using command:

git branch –l

Create Branch: We can create branch in Git to

support parallel and independent
programming. Use below command to create
branch.

git branch <branch_name>

Delete Branch: Any time we can delete

obsolete branches from our repository so that
our repo can be light weight.

git branch –D
<branch_name>
Switch Branch: We can switch between branches so that we can work on different streams of source
code. It helps us to move from one branch to another.

git checkout <branch_name>

Resolving Merge Conflicts in Git

Decide if you want to keep only your branch's changes, keep only the other branch's changes,

or make a brand-new change, which may incorporate changes from both branches.

Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes
you want in the final merge. In this example, both changes are incorporated into the final

merge:
 Git Branching

Git branching helps us to manage the branches in Git repositories. We can create, switch and delete
these branches according to our requirements.

List Branch: We can list branches in an existing repository using command:

git branch –l

Create Branch: We can create branch in Git to support parallel and independent programming. Use
below command to create branch.

git branch <branch_name>

Delete Branch: Any time we can delete obsolete branches from our repository so that our repo can
be light weight.

git branch –D <branch_name>

Switch Branch: We can switch between branches so that we can work on different streams of source
code. It helps us to move from one branch to another.

git checkout <branch_name>

Creating a feature/story branch

Feature branches (or sometimes called story branches) are used to develop new
features for the upcoming or a distant future release. When starting development of
a feature, the target release in which this feature will be incorporated may well be
unknown at that point.

When starting work on a new story, branch off from the develop branch.

$ git checkout -b story1 develop

Switched to a new branch "story1"

Now Developer will be working on this individual story branches and performs
Check-ins to these respective branches as per below flow:

$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff story1

Updating ea1b82a..05e9557

(Summary of changes)

$ git branch -d story1

Deleted branch story1 (was 05e9557).

$ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be
performed with a fast-forward. This avoids losing information about the historical existence of a
feature branch and groups together all commits that together added the feature. Compare:
 Creating a Hotfix branch

Hotfix branches are very much like release branches in that they are also meant to prepare for a new
production release, albeit unplanned. They arise from the necessity to act immediately upon an
undesired state of a live production version.

When a critical bug in a production version must be resolved immediately, a hotfix branch may be
branched off from the corresponding tag on the master branch that marks the production version.

$ git checkout -b hotfix-1.2.1 master

Switched to a new branch "hotfix-1.2.1"

$ git commit -m "Fixed severe production problem"

[hotfix-1.2.1 abbe5d6] Fixed severe production problem

5 files changed, 32 insertions (+), 17 deletions (-)

NOTE: When finished, the bugfix needs to be merged back

into master, but also needs to be merged back into
develop, in order to safeguard that the bugfix is included
in the next release as well.

$ git checkout master

Switched to branch 'master'

$ git merge --no-ff hotfix-1.2.1

Merge made by recursive.

(Summary of changes)

$ git tag -a 1.2.1

Next, include the bugfix in develop, too:

$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff hotfix-1.2.1

Merge made by recursive.

(Summary of changes)