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
 
(48 intermediate revisions by the same user not shown)
Line 1: Line 1:
<center><font color='darkgray'>Work in progress, Gitflow Workarea available.</font></center>
=External=
* https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
* http://nvie.com/posts/a-successful-git-branching-model/
* https://jeffkreeftmeijer.com/git-flow/
* 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.
* <span id='Hotfix'></span>'''Hotfix''' (or "maintenance") branches carry maintenance work for functionality that was released. The results of the maintenance work are used to patch production releases. Hotfix branches are based on [[#Master|master]]. These are the only branches that fork off directly from master. As soon the fix is complete, it should be merged both in [[#Master|master]] or [[#Develop|develop]], or the current [[#Release|release]] branch, if there’s one in progress, and [[#Master|master]] should be tagged with an update release number. Maintenance branches can be thought of as ad-hoc release branches that work directly with master.
 
git-flow is a merge-based solution. It does not rebase feature branches.
 
git-flow is supported by a toolset that can be installed, and which provides specialized command line extensions.
 
=Installation=
 
==Mac==
 
brew install git-flow-avh
 
=Operations=
 
==git-flow-Enabling a Repository==
 
If you intend to use git-flow extension, it is mandatory to "git-flow-enable" the repository with the following command, otherwise the extension commands will complain and will refuse to work.
 
git flow init
 
Which branch should be used for bringing forth production releases?
  - develop
Branch name for production releases: [] master
Which branch should be used for integration of the "next release"?
  - develop
Branch name for "next release" development: [develop] develop
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] release
Hooks and filters directory? [/Users/ovidiu/github/some-repository/.git/hooks]
 
==Create a Feature Branch==
 
git flow feature start <''feature_branch_1''>
 
Note that the repository must be "git-flow enabled" for this to work. See [[#git-flow-Enabling_a_Repository|git-flow-enabling a repository]].
 
The equivalent standard commands:
 
git checkout develop
git checkout -b <''feature_branch_1''>
 
Note that this command does not push the newly created feature branch into the origin repository. If you wish to do so, follow: {{Internal|Git_branch#Create_the_Remote_Branch_and_its_Local_Remote-Tracking_Branch|Create the Remote Branch and Its Local Remote-Tracking Branch}} and then:  {{Internal|Git_branch#Link_the_Local_Branch_to_its_Tracking_Branch|Link the Local Branch to its Tracking Branch}}
 
In our case is:
 
git push origin feature/<''feature_branch_1''>
git branch --set-upstream-to=origin/feature/<''feature_branch_1''> feature/<''feature_branch_1''>
 
==Finish the Feature==
 
Go to the develop branch and synchronize it with origin:
 
git checkout develop
git pull
 
Then go back to the feature branch and merge develop into it, to preemptively resolve merge conflicts:
 
git checkout feature/<''feature_branch_1''>
git merge develop
 
From any branch, including the feature branch being worked on (note that you can simply use "<''feature_branch_1''>", not "feature/<''feature_branch_1''>", git-flow knows what this is about:
 
git flow feature finish <''feature_branch_1''>
 
The command will checkout the develop branch and merge <''feature_branch_1''> into it, then will delete the feature branch. The equivalent base commands:
 
git checkout develop
git merge <''feature_branch_1''>
 
==Start the Release Process (Making the Release Branch)==
 
<font color=darkgray>
git flow release start 0.1.0
 
Manual commands:
 
?
</font>
 
==Finish a Release==
 
<font color=darkgray>
git checkout master
git checkout merge release/0.1.0
git flow release finish ‘0.1.0’
 
Manual:
 
?
</font>
 
==Start a Hotfix==
 
<font color=darkgray>
git flow hotfix start <hotfix_branch>
 
Manual:
</font>
 
==Finish a Hotfix==
 
<font color=darkgray>
git flow hotfix finish <hotfix_branch>
 
Manual:
</font>
 
==Finish a Hotfix==

Latest revision as of 17:20, 6 March 2024

Internal

Subjects

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