Git Best Practice

For Develop Your

Application
Fraiza Geraldi Alghifary
Agenda

● What is Git ?
● Why Git ?
● Common mistake using git
● Best Practice Using Git
● Git Work Flow
What is Git?

● Open source distributed version control system designed to handle source code from
small to very large project.
● Initialy designed and developed by Linux Torvalds for Linux Kernel development
● Git working directory contains a full fledged repository with complete history and full
revision tracking capabilities
● Not depend on network access or a central server
Why Git?

● Make your life easy

● Transparency
● Distributed development
● Working on large project
● Need to collaborate with multiple developers
Common mistake using git

● Meaningless commit message

● Altered published history
● Commit generated files
● Commit half-done work
Common mistake using git

● Force commit to branch master

● Developer not review their code before push to repository
● Conflict
● Wrong git workflow
● etc…
Git bad practice = Disaster
Best Practice : Commit Regularly

● Git only takes full responsibility for your data when you commit
● If you fail to commit and then do something that hasn’t been well-thought out, you can
go into trouble
● Having periodic checkpoints can help you understand the reasons behind some errors
in the code.
Best Practice : Make clean, single-purpose
commits

Better to keep commits as small and focused as possible for many reasons, including:

● It makes it easier for other people in the team looking at your change, making code
reviews more efficient.
● If the commit has to be rolled back completely, it’s far easier to do so.
● It’s straightforward to track these changes with your ticketing system.
Best Practice : Write Meaningful Commit
Messages

Example good commit message :

If use a ticketing system, you should also include the ticket id in the description
Best Practice : Don’t Alter Published History

● It’s recommended to not alter published history

● Git and other VCS tools to rewrite branch history, but doing so is problematic for
everyone has access to the repository
● Use rebase for every pull from upstream branch
● Use parameter --no-ff when do merge branch
Example using rebase
Example using rebase

● Using rebase for update local master branch

Example merging with no fast forward
Example merging with no fast forward
Best Practice : Don’t commit generated files
and large binaries

● Committing generated files and large binaries is not helping your repository size
● Especially since they bring no additional value. The effect of these files is especially
bad if they get regenerated very often.
● It is useful to add a .gitignore file in your repository’s root to automatically tell Git
which files or paths you don’t want to track
Git Workflow

● Gitflow Workflow defines a strict branching model designed around the project release.
This provides a robust framework for managing larger projects.
● Gitflow is ideally suited for projects that have a scheduled release cycle
The Main Branches

The development model is greatly inspired by existing models out there. The central repo
holds two main branches with an infinite lifetime:

● master
○ should be familiar to every Git user
○ origin/master to be the main branch where the source code of HEAD always reflects a
production-ready state
● develop
○ Called integration branch
○ 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
Supporting Branches

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

● Feature Branch
● Release Branch
● Hotfix Branch
Feature Branches

May branch off from:

● develop

Must merge back into:

● develop

Branch naming convention:

● anything except master, develop, release-*, or hotfix-*

Feature Branches
Release Branches

May branch off from:

● develop

Must merge back into:

● develop and master

Branch naming convention:

● release-*
Release Branches

● Creating a release branch

Release Branches

● Finishing a release branch

Hotfix Branches

May branch off from:

● master

Must merge back into:

● develop and master

Branch naming convention:

● hotfix-*
Hotfix Branches

● Creating a hotfix branch

Hotfix Branches

● Finishing a hotfix branch

Thank You