Gitflow: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
(Replaced content with "=Internal= * Git * Trunk-Based Development * GitHub Flow * Semantic Versioning =Subjects= * Concepts * Operations")
Tag: Replaced
 
(73 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
* https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
* http://nvie.com/posts/a-successful-git-branching-model/
* https://danielkummer.github.io/git-flow-cheatsheet/
* https://github.com/petervanderdoes/gitflow-avh/wiki/Installation
* http://weaintplastic.github.io/web-development-field-guide/Collaboration/Working_with_Git/Git_Workflow/The_Concept_of_Gitflow
=Internal=
=Internal=
* [[Git]]
* [[Git]]
* [[Trunk-Based Development]]
* [[GitHub Flow#Overview|GitHub Flow]]
* [[Semantic Versioning]]


=Overview=
=Subjects=
 
* [[Gitflow_Concepts#Overview|Concepts]]
git-flow defines a branching model that is tightly coupled with the project release cycle. This model is suited for projects that have a scheduled release cycle.
* [[Gitflow_Operations#Overview|Operations]]
 
git-flow comes with a well-defined set of branches, where each branch (or each branch type) has a specific role:
* <span id='Master'></span>The '''master''' branch stores the official release history. The master contains the abridged history of the project, unlike [[#Develop|develop]], which contains the complete history.
* <span id='Develop'></span>The '''develop''' branch serves as integration branch for features. This branch contains the complete history of the project.
* <span id='Feature'></span>'''Feature''' branches serve to develop features. Each feature should reside on its own branch. The feature branches branch off [[#Develop|develop]], not [[#Master|master]]. When a feature is complete, the corresponding feature branch is merged back into [[#Develop|develop]]. Features should never interact directly with master.
* <span id='Release'></span>'''Release''' branches host release preparation development. Once [[#Develop|develop]] contains enough features for a release, or the schedule release date is approaching, a new release branch is forked off [[#Develop|develop]]. The creation of the release branch starts the release cycle: no new features can be added after this point, only bug fixes, documentation and other release-related content. Once the release work is finalized: 1) the release branch is merged into the [[#Master|master]] and tagged with a release number and 2) the release branch is merged back into [[#Develop|develop]]. Merging the release branch back into [[#Develop|develop]] is critical because important updates may have been added to the release branch during the release process and we want those into the main development state. Having a dedicated release branch facilitates communication regarding the specific release: "we're preparing version 7.7". After release and merging, the release branch should be deleted.
 
git-flow is a merge-based solution. It does not rebase feature branches.

Latest revision as of 17:20, 6 March 2024

Internal

Subjects

Retrieved from "https://kb.novaordis.com/index.php?title=Gitflow&oldid=108234"