> For the complete documentation index, see [llms.txt](https://strctr.gitbook.io/programming/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://strctr.gitbook.io/programming/02-tools/git/12-git-workflow.md). # 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)