GIT For Version Control

Welcome to our GIT version control presentation

Mohsen Mabrouki
2020-2021
 2

ABOUT GIT
• Created by Linus Torvalds, creator of
Linux, in 2005
– Came out of Linux development
community
– Designed to do version control on
Linux kernel

• Goals of Git:
– Speed
– Support for non-linear development
(thousands of parallel branches)
– Fully distributed
– Able to handle large projects
efficiently
 3

DISTRIBUTED VCS GIT

In git, mercurial, etc., you don't "checkout"
from a central repo
– you "clone" it and "pull" changes from it

Your local repo is a complete copy of

everything on the remote server
– yours is "just as good" as theirs

Many operations are local:

– check in/out from local repo
– commit changes to local repo
– local repo keeps version history

When you're ready, you can "push" changes back to server

CONTINIOUS INTEGRATION
4
 5

BRANCHES IN GIT
A branch represents an independent line of development.

The diagram above visualizes a repository with two isolated lines of

development, one for a little feature, and one for a longer-running feature.
By developing them in branches, it’s not only possible to work on both of
them in parallel, but it also keeps the main master branch free from
questionable code.
 6

GIT FEATURE BRANCH

WORKFLOW

The core idea behind the Feature Branch Workflow is that all feature
development should take place in a dedicated branch instead of
the master branch. This encapsulation makes it easy for multiple
developers to work on a particular feature without disturbing the
main codebase. It also means the master branch will never contain
broken code, which is a huge advantage for continuous integration
environments.
 7

MERGING FEATURE BRANCHES

Merging is Git's way of putting a branches back together again. The git
merge command lets you take the independent lines of development
created by git branch and integrate them into a single branch.
 8

REBASING BRANCHES
Rebasing is the process of moving or combining a sequence of commits to a
new base commit. Rebasing is most useful and easily visualized in the context
of a feature branching workflow. The general process can be visualized as the
following:
 9

GITFLOW WORKFLOW

Gitflow Workflow is a Git workflow design that was first published and made
popular by Vincent Driessen at nvie. The Gitflow Workflow defines a strict
branching model designed around the project release. This provides a
robust framework for managing larger projects.

This workflow doesn’t add any new concepts or commands beyond what’s
required for the Feature Branch Workflow. Instead, it assigns very specific
roles to different branches and defines how and when they should interact.
 10

DEVELOP AND MASTER

Instead of a
BRANCHES
single master branch, this
workflow uses two branches to
record the history of the
project. The master branch
stores the official release
history, and the develop branch
serves as an integration branch
for features. It's also convenient
to tag all commits in
the master branch with a
version number.
 11

USING GIT

The first step is to complement the default master with

a develop branch. A simple way to do this is for one developer to
create an empty develop branch locally and push it to the server:

git branch develop

This branch will contain the complete history of the project,

whereas master will contain an abridged version.
 12

USING GIT-FLOW

When using the git-flow extension library, executing git flow

init on an existing repo will create the develop branch:

git flow init

 13

FEATURE BRANCHES
Each new feature should
reside in its own branch,
which can be pushed to the
central repository for
backup/collaboration. But,
instead of branching off
of master, feature branches
use develop as their parent
branch. When a feature is
complete, it gets merged back
into develop. Features should
never interact directly
with master.
 14

CREATING A FEATURE
BRANCH
Without the git-flow extensions:
git checkout develop
git checkout -b feature_branch

When using the git-flow extension:

git flow feature start feature_branch

Git-flow will automatically link the newly created feature

branch to the develop branch.
Continue your work and use Git like you normally would.
 15

FINISHING A FEATURE
BRANCH
When you’re done with the development work on the feature, the
next step is to merge the feature_branch into develop.
Without the git-flow extensions:
git checkout develop
git merge feature_branch

Using the git-flow extensions:

git flow feature finish feature_branch
 16

RELEASE BRANCHES

Once develop has acquired enough features for a release (or a

predetermined release date is approaching), you fork
a release branch off of develop.
Once it's ready to ship, the release branch gets merged into master and
tagged with a version number. In addition, it should be merged back
into develop, which may have progressed since the release was initiated.
 17

RELEASE BRANCHES

Using a dedicated branch

to prepare releases makes
it possible for one team to
polish the current release
while another team
continues working on
features for the next
release.
 18

CREATING A RELEASE
BRANCH
Making release branches is another straightforward branching
operation. Like feature branches, release branches are based on
the develop branch. A new release branch can be created using the
following methods.
Without the git-flow extensions:
git checkout develop
git checkout -b release/0.1.0

When using the git-flow extensions:

git flow release start 0.1.0
 19

FINISHING A RELEASE
BRANCH
Once the release is ready to ship, it will get merged it
into master and develop, then the release branch will be deleted. It’s
important to merge back into develop because critical updates may have
been added to the release branch and they need to be accessible to new
features.
To finish a release branch
Without the git-flow extensions:
git checkout master
git merge release/0.1.0
Or with the git-flow extension:
git flow release finish '0.1.0'
 20

HOTFIX BRANCHES
Maintenance
or “hotfix” branches are used
to quickly patch production
releases.
Hotfix branches are a lot
like release branches
and feature branches except
they're based
on master instead of develop.
This is the only branch that
should fork directly off
of master.
 21

CREATING A HOTFIX
BRANCH
Without the git-flow extensions:

git checkout master

git checkout -b hotfix_branch

When using the git-flow extensions:

git flow hotfix start hotfix_branch

 22

FINISHING A HOTFIX
BRANCH
Similar to finishing a release branch, a hotfix branch gets
merged into both master and develop.
git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

with the git-flow extension:

git flow hotfix finish hotfix_branch
 23

Resumé Git Flow

❖ Une branche de développement (develop) est créée à partir de master.
❖ Une branche de version (release) est créée à partir de develop.
❖ Les branches de fonctionnalité (feature) sont créées à partir de develop.
❖ Lorsqu'une branche de fonctionnalité (feature) est terminée, elle est mergée dans la branche
de développement (develop).
❖ Lorsque la branche de version (release) est terminée, elle est mergée dans les branches de
développement (develop) et principale (master).
❖ Si un problème est identifié dans la branche principale (master), une branche de
maintenance (hotfix) est créée à partir de master.
❖ Une fois la branche de maintenance (hotfix) terminée, elle est mergée dans les branches de
développement (develop) et principale (master).
❖ Les branches feature, release, hotfix sont temporaires.
 24

Git Flow Summary

❖ master — this branch contains production code. All development code is merged
into master in sometime.
❖ develop — this branch contains pre-production code. When the features are finished
then they are merged into develop.
During the development cycle, a variety of supporting branches are used:
❖ feature-* — feature branches are used to develop new features for the upcoming
releases. May branch off from develop and must merge into develop.
❖ hotfix-* — hotfix branches are necessary to act immediately upon an undesired status
of master. May branch off from master and must merge into master anddevelop.
❖ release-* — release branches support preparation of a new production release. They
allow many minor bug to be fixed and preparation of meta-data for a release. May
branch off from develop and must merge into master and develop.
 25

Git Flow Summary

Advantages
❖ Ensures a clean state of branches at any given moment in the life cycle of project,
❖ The branches naming follows a systematic pattern making it easier to comprehend,
❖ It has extensions and support on most used git tools,
❖ It is ideal when there it needs to be multiple version in production.
Disdvantages
❖ The Git history becomes unreadable,
❖ The master/develop split is considered redundant and makes the Continuous Delivery
and the Continuous Integration harder,
❖ It isn’t recommended when it need to maintain single version in production.
 26

Git Workflow Summary

❖ Anything in the master branch is deployable,
❖ To work on something new, create a branch off from master and given a descriptively
name(ie: new-oauth2-scopes),
❖ Commit to that branch locally and regularly push your work to the same named
branch on the server,
❖ When you need feedback or help, or you think the branch is ready for merging, open
a pull request,
❖ After someone else has reviewed and signed off on the feature, you can merge it
into master,
❖ Once it is merged and pushed to master, you can and should deploy immediately.
 27

Git WorkFlow Summary

Advantages
❖ it is friendly for the Continuous Delivery and Continuous Integration,
❖ A simpler alternative to Git Flow,
❖ It is ideal when it needs to maintain single version in production.
Disdvantages
❖ The production code can become unstable most easily,
❖ Are not adequate when it needs the release plans,
❖ It doesn’t resolve anything about deploy, environments, releases, and issues,
❖ It isn’t recommended when multiple versions in production are needed.
 28

SCENARIO
We are going to star by creating a directory.
mkdir project
cd project
Then, we initialize the directory as a git directory.
git inti
Before we start commiting code to git, we need to identify
ourselves to git, so when we commit a change of the code,
we can later track who did what
git config –-global user.name "flan"
git config –-global user.email "flan@faltan.com
 29

SCENARIO

The next step is to copy a project of your choice into the

directory that we just created
After that, we add and commit the newly copied project to
git, so git can now follow any further development done to
the project
git add .
git commit –m "initial commit"
 30

SCENARIO
Now that we have a project and git is aware of it, we can begin creating
our branches and start modifying our code.
We are going to use git flow commands to create and finish
our branches.
As shown in previous slides, the first branch that we need to create is
the develop branch, and when we use git flow inti command the
develop branch will be created automatically, the output of the
following command will be some questions about the naming
conventions for you branches, it's recommended to use the default
values.
git flow init
 31

SCENARIO
So far, we initialized our git directory, which should create a master
branch for us, then we run the git flow inti command which created a
develop branch, now we can start adding features to our code, but
before that, we need to create a feature branch
git flow feature start myfeature

In this part feel free to modify your software project (whatever it is you
want to do), and once you've done with that, we need to merge our
new cool features to the develop branch,
git add .
git commit –m "added a feature"
git flow feature finish myfeature

This command will perform the following actions for us

• Merge 'myfeature' into 'develop'
• Remove the feature branch 'myfeature'
• Switch to develop branch
 32

SCENARIO
Our develop branch now have the latest feature, what we need to do
now, is to create a release branch, that contain the new feature that we
added, to do that we use the following command.
git flow release start myrelease
Let's say that we tested our release, and we are happy with the results
and we want to merge it with the master branch, all we have to do is to
run the command below.
git add .
git commit –m "finished a release"
git flow release finish myrelease
This command will perform the following actions for us
• Merge 'myrelease' into the 'master' branch
• Tags the release with its name
• Back-merge 'myrelease' into 'develop' branch
• Remove the release branch 'myrelease'
 33

SCENARIO
Let's imagine that the release we just merged into master, isn't working
the way it supposed to, and we need to fix it, we can't go through the
whole process again to fix a miner issue, as we discussed in earlier
slides, we create a hotfix branch from the master branch, to quickly fix
these issue.
To create a hotfix branch with git-flow tool, just run the command
below
git flow hotfix start myrelease
We need to add our release name, in our case it is 'myrelease'
Let's say we fixed the issue, and we are ready to merge back our newly
fixed code into master, all we have to do is to run the following
command.
git add .
git commit –m "added a feature"
git flow hotfix finish myrelease
 34

SCENARIO
Now if we'd like to work with a remot server like github gitlab etc …
First, we need to create a remot repo in GitHub or anyother VCS server
Then add the remot server in GIT like below
git remote add origin "link of the server repo"

Our remote repository is now added to git we can simply push any
branch that we are working on using this command
git push origin master
Or
git push origin develop
We can also use git flow command to push our braches
To push feature brach use this command
git flow feature publish myfeature
To push feature branch use this command
git flow release publish myrelease
 35

TO CONCLUD
Here we discussed the Gitflow Workflow. Gitflow is one of many styles of Git
workflows you and your team can utilize.

Some key takeaways to know about Gitflow are:

•The workflow is great for a release-based software workflow.

•Gitflow offers a dedicated channel for hotfixes to production.
THANK YOU
For your attention