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
