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 branch

• Create a new feature branch

• Update, 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 and master branches. A develop branch is created from master.

• 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 use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.

• Release: Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. 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 the release branch is done it is merged into develop and master

• 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 both master and develop (or the current release branch), and master 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)