Scribd
Upload
111 views

Git Best Practice & Workflow

This document discusses Git best practices for developing applications. It recommends committing regularly to checkpoints, making clean single-purpose commits with meaningful messages, and not altering published history. Common mistakes like meaningless commits, force commits to master, and committing generated files are also outlined. The document recommends specific Git workflows like Gitflow that define branching models for features, releases and hotfixes to facilitate collaboration.

Uploaded by

Fraiza Geraldi Alghifary
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
111 views

Git Best Practice & Workflow

This document discusses Git best practices for developing applications. It recommends committing regularly to checkpoints, making clean single-purpose commits with meaningful messages, and not altering published history. Common mistakes like meaningless commits, force commits to master, and committing generated files are also outlined. The document recommends specific Git workflows like Gitflow that define branching models for features, releases and hotfixes to facilitate collaboration.

Uploaded by

Fraiza Geraldi Alghifary
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 29

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

You might also like