12. Git Workflow
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. When evaluating a workflow for your team, it's most important that you consider your team’s culture.
Some things to consider when evaluating a Git workflow are:
Does this workflow scale with team size?
Is it easy to undo mistakes and errors with this workflow?
Does this workflow impose any new unnecessary cognitive overhead to the team?
Centralized Workflow
The Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. The default development branch is called master
and all changes are committed into this branch. This workflow doesn’t require any other branches besides master
.
How it works:
Developers start by cloning the central repository.
In their own local copies of the project, they edit files and commit changes
To publish changes to the official project, developers "push" their local
master
branch to the central repository.
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 should never contain broken code, which is a huge advantage for continuous integration environments.
In addition, feature
branches can (and should) be pushed to the central repository. This makes it possible to share a feature
with other developers without touching any official code.
How it works:
Start with the
master
branchCreate a new
feature
branchUpdate, add, commit, and push changes
Push
feature
branch to remote:git push -u origin new-feature
Resolve feedback
Merge your pull request
Gitflow workflow
Instead of a 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. Key features:
The workflow is great for a release-based software workflow.
-Gitflow offers a dedicated channel for hotfixes to production.
How it works:
Develop: Create
develop
andmaster
branches. Adevelop
branch is created frommaster
.Features: 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 usedevelop
as their parent branch. When a feature is complete, it gets merged back intodevelop
. Features should never interact directly withmaster
.Release: Once
develop
has acquired enough features for a release (or a predetermined release date is approaching), you fork arelease
branch off ofdevelop
. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. When therelease
branch is done it is merged intodevelop
andmaster
Master: 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.Hotfix: Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of
master
. As soon as the fix is complete, it should be merged into bothmaster
and develop (or the current release branch), andmaster
should be tagged with an updated version number.
Forking Workflow
The Forking Workflow is fundamentally different than the other workflows discussed in this tutorial. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. The Forking Workflow is most often seen in public open source projects.
Developers push to their own server-side repositories — not the official one.
Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated.
Only the project maintainer can push to the official repository.
Trunk Based Development
A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ (master
in git terms) , resist any pressure to create other long-lived development branches by employing documented techniques.
Основная (trunk) ветка представляет собой последнюю версию кода, изменения в которую вносятся разово и последовательно. Сразу после коммита новая версия кода доступна всем пользователям, то есть, по сути, у разработчика перед глазами всегда свежая версия кода.
How it works:
Developers create short-lived feature branches.
Features hidden until ready.
Developers squash their feature branch to single commit and submit PR.
Developers try to commit to
master
at least once per day.For release create new branch from
master
(only Release managers allowed to do it).Hotfixes commited to
master
and cherry-picked into supported release branches.Do CI & CD after merging PR.
Advantages:
lean history
can release at any time
merge problems surface early
merge problems are smaller
release branches are cheap
commits document features (not branches)
Last updated
Was this helpful?