Git is a distributed version-control system for tracking changes in source code during software development. GitFlow is a branching model for Git which is very well suited to collaboration and scaling the development team.

1. Introducing : git + gitflow
Sebin Benjamin,
Software Engineer
Lulu International Exchange

2. What is git ?
Git is an open source, distributed version control system designed for speed and
efficiency.
● Every developer “clones” a copy of a repository and has the full history of the
project on their own hard drive. This copy (or “clone”) has all of the metadata
of the original.
● Enables you to track changes, when they happened, and who made them.
● Revert to different versions if needed
● Develop in parallel using branches
● Easier to collaborate with other developers

3. What is git ?
● Git creates a .git folder (in the current folder) to store the details of the file
system - this folder contains all the data required to track your files and is
known as a repository, or repo.
● Git has got branches which allow you to work on a copy of the code without
destroying the original.

4. Centralized VCS

6. Distributed VCS

8. https://try.github.io

9. ● Working tree
● Staging area
● Git directory
Sections of a Git project

10. http://rogerdudler.github.io
/git-guide/

11. Commits, the basic building blocks
● Code is wrapped into commits
● One thing added per commit
● Commits should have useful names
● git log lists the commits made in that repository in reverse chronological order
● lists each commit with its (40 char) SHA-1 checksum, the author’s name and
email, the date written, and the commit message

12. $ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 10:31:28 2008 -0700
first commit

14. Commit messages
Should be detailed and be descriptive and follow a format.
● Write commit messages as a sentence
● Make sure one commit does just one thing
● Capitalize sentences.
Use either:
● Present tense of the commit does
● A description of what the changes in the code does
● Example : fix off by one error in the Bar loop

15. Tags
● Tags are pointers to a commit of particular significance. Some examples of
these are for marking versions of your product or important changes.
● Right click on the commit you'd like to tag, and select create tag here at the
bottom.
● Tags are similar to branches, but tags are static pointers to a particular
commit, whereas when you add a new commit to a branch, the head of the
branch moves to point to the new commit.
● If you would want to make the tag available on a remote, just right click the tag
and select to push the tag to the remote.

16. Branches
● Branching means you diverge from the main line of development and
continue to do work without messing with that main line
● Git branches is incredibly lightweight, making branching operations nearly
instantaneous, and switching back and forth between branches generally just
as fast
Merging
● Merging takes the commits on two different branches and combines them.
● Files are automatically merged, unless their are two conflicting set of changes
(merge conflicts) , i.e. commits on the different branches updating the same
line in different ways.
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

17. https://support.gitkraken.com/repositories/local

18. .gitignore
● From time to time, there are files/folders you don't want Git to check in to git
repository.
● A .gitignore file should be committed into your repository to share the ignore
rules with any other users that clone the repository.
● Example:
sebin@home:~$ cat .gitignore
# Build Files #
bin
target
build/
.gradle https://github.com/github/gitignore
https://git-scm.com/docs/gitignore

19. Command line instructions - cloning
Git global setup
git config --global user.name "Jenkins"
git config --global user.email "jenkins@devops.com"
Cloning a new repository
git clone http://jenkins@172.30.13.20:8025/utility-apps/remind-me.git
cd remind-me
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

20. Adding existing folder to new repository
cd existing_folder
git init
git remote add origin http://jenkins@172.30.13.20:8025/utility-apps/remind-me.git
git add .
git commit
git push -u origin master
Pushing an existing Git repository
cd existing_repo
git remote add origin http://jenkins@172.30.13.20:8025/utility-apps/remind-me.git
git push -u origin --all
git push -u origin --tags

21. git clients
Users can manage Git primarily from
the command line, however, there
are several graphical user interface
(GUI) Git clients that facilitate
efficient and reliable usage of Git on
a desktop and offer most, if not all of
the command line operations.
- Gitkraken
- Source Tree

22. gitflow
- a branching model for Git...
GitFlow is a list of rules to keep a
repo’s history organized, and is
used to make the release process,
bug fixes, and feature creation
easier.

23. http://nvie.com/img/git-model@2x.png

24. The main branches
● master
○ origin/master to be the main branch where the source code of HEAD always
reflects a production-ready state
● develop
○ origin/develop to be the main branch where the source code of HEAD always
reflects a state with the latest delivered development changes for the next
release. Some would call this the “integration branch”.

26. Supporting branches
A variety of supporting branches aid parallel development between team members,
ease tracking of features, prepare for production releases and to assist in quickly
fixing live production problems.
These branches always have a limited lifetime, since they will be removed
eventually.
Branches are not “special” from a technical perspective. The branch types are
categorized by how we use them. They are of course plain old Git branches.
The different types of branches we may use are:
● Feature branches
● Release branches
● Hotfix branches

27. ● May branch off from:
develop
● Must merge back into:
develop
● Branch naming convention:
anything except master, develop, release-*, or hotfix-*
● Feature branches (or sometimes called topic branches) are used to develop
new features for the upcoming or a distant future release.
Feature branches

28. ● Exists as long as the feature is in development, but will
eventually be merged back into develop (to definitely
add the new feature to the upcoming release) or
discarded (in case of a disappointing experiment).
Feature branches

29. Release branches
● May branch off from:
develop
● Must merge back into:
develop and master
● Branch naming convention:
release-*
● Support preparation of a new production release.
● Allows for last-minute dotting of i’s and crossing t’s.
● Allow for minor bug fixes and preparing metadata for a release (version
number, build dates, etc.).

30. ● develop branch is cleared to receive features for the next big release, once
the release branch is created
● At least all features that are targeted for the release-to-be-built must be
merged into develop at this point in time.
● All features targeted at future releases may not—they must wait until after the
release branch is branched off.
● When the state of the release branch is ready to become a real release,
release branch is merged into master and develop
● Commit on master must be tagged for easy future reference to this historical
version

31. Hotfix branches
● May branch off from:
master
● Must merge back into:
develop and master
● Branch naming convention:
hotfix-*
Hotfix branches are very much like release
branches in that they are also meant to prepare
for a new production release, albeit unplanned.

32. Hotfix branches
● 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.
● Team members (on the develop branch) can
continue, while another person is preparing a
quick production fix.
● Exception to the rule here is that, when a
release branch currently exists, the hotfix
changes need to be merged into that
release branch, instead of develop.

33. Git client support
● Gitkraken -
https://support.gitkraken.com/repositories/git-flow
● Added benefit of adding all features, hotfixes, and
release branches in different folders.
● Prefix for the GitFlow branch type will allow gui to
recognize it as being a GitFlow branch, i.e.
feature/branch-name. Any branches that do not
have the prefix, will be displayed in the local
repository section, but not in the GitFlow menu.

35. If you do not currently have these branches in your local repository, GitKraken
will create them when GitFlow is initialized.

37. Color Conventions - Gitkraken
Red - File deleted
Green - File added (new file)
Orange - File modified

38. Branch naming conventions
● Use dashes (-) to separate parts of your branch names
● Do not use bare numbers as leading parts. Eg: 5450124-bug-remit
● Avoid long descriptive names. Eg: avoid remit-temporary-fix-for-live-important
● Avoid use of capital letters
● Identifiers from corresponding tickets in an external service (eg. a GitHub
issue) are also good candidates for use in branch names. Eg : bug ID’s in yodiz
or other issue reporting tools
https://github.com/agis/git-style-guide

39. References
● “How GitHub will save the World Economy” - Scott Chacon
https://github.com/schacon/git-presentations/tree/master/git_world_economy_talk
● An Introduction to Collaborating with Version Control
https://learn.adafruit.com/an-introduction-to-collaborating-with-version-control/overview
● Git book
https://git-scm.com/book/en/v2/
● Ignoring files - Github help
https://help.github.com/articles/ignoring-files/
● A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/
● GitFlow in Gitkraken
https://support.gitkraken.com/repositories/git-flow

40. Thank you