Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
A comparison of using `git flow` commands versus raw `git` commands.

Initialize

gitflow git
git flow init git init
  git commit --allow-empty -m "Initial commit"
  git checkout -b develop master

Connect to the remote repository

gitflow git
N/A git remote add origin git@github.com:MYACCOUNT/MYREPO

Features

Create a feature branch

gitflow git
git flow feature start MYFEATURE git checkout -b feature/MYFEATURE develop

Share a feature branch

gitflow git
git flow feature publish MYFEATURE git checkout feature/MYFEATURE
  git push origin feature/MYFEATURE

Get latest for a feature branch

gitflow git
git flow feature pull origin MYFEATURE git checkout feature/MYFEATURE
  git pull --rebase origin feature/MYFEATURE

Finalize a feature branch

gitflow git
git flow feature finish MYFEATURE git checkout develop
  git merge --no-ff feature/MYFEATURE
  git branch -d feature/MYFEATURE

Push the merged feature branch

gitflow git
N/A git push origin develop
  git push origin :feature/MYFEATURE (if pushed)

Releases

Create a release branch

gitflow git
git flow release start 1.2.0 git checkout -b release/1.2.0 develop

Share a release branch

gitflow git
git flow release publish 1.2.0 git checkout release/1.2.0
  git push origin release/1.2.0

Get latest for a release branch

gitflow git
N/A git checkout release/1.2.0
  git pull --rebase origin release/1.2.0

Finalize a release branch

gitflow git
git flow release finish 1.2.0 git checkout master
  git merge --no-ff release/1.2.0
  git tag -a 1.2.0
  git checkout develop
  git merge --no-ff release/1.2.0
  git branch -d release/1.2.0

Push the merged feature branch

gitflow git
N/A git push origin master
  git push origin develop
  git push origin --tags
  git push origin :release/1.2.0 (if pushed)

Hotfixes

Create a hotfix branch

gitflow git
git flow hotfix start 1.2.1 [commit] git checkout -b hotfix/1.2.1 [commit]

Finalize a hotfix branch

gitflow git
git flow hotfix finish 1.2.1 git checkout master
  git merge --no-ff hotfix/1.2.1
  git tag -a 1.2.1
  git checkout develop
  git merge --no-ff hotfix/1.2.1
  git branch -d hotfix/1.2.1

Push the merged hotfix branch

gitflow git
N/A git push origin master
  git push origin develop
  git push origin --tags
  git push origin :hotfix/1.2.1 (if pushed)

References

@sukima

This comment has been minimized.

Copy link

@sukima sukima commented Aug 10, 2015

git flow init also edits your .git/config and prompts for values:

[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 

'Course this is git flow specific so I guess there is no comparison with vanilla Git.

@sapeish

This comment has been minimized.

Copy link

@sapeish sapeish commented Sep 9, 2015

using the showcommands switch you can see the actual git commands being executed:
git flow feature start FEATURENAME --showcommands

@pedromntomas

This comment has been minimized.

Copy link

@pedromntomas pedromntomas commented Sep 24, 2015

I don't know if it is a bug or not, but my git flow hotfix finish 1.2.1 command merges the hotfix into master first then merges the master into develop. No merge from hotfix to develop. It should be this way?

@klarstrup

This comment has been minimized.

Copy link

@klarstrup klarstrup commented Oct 9, 2015

@pedromntomas: Probably https://github.com/nvie/gitflow is a more appropriate place for that question.

@jdcotter

This comment has been minimized.

Copy link

@jdcotter jdcotter commented Aug 29, 2016

When finalizing a release branch the tag command should include the branch name. e.g. git tag -a 1.2.0 $RELEASE_BRANCH

@blowsie

This comment has been minimized.

Copy link

@blowsie blowsie commented Oct 18, 2016

In addition to @jdcotter s messagegit flow adds a merge commit message eg. Finish v1.3.0

@webfacer

This comment has been minimized.

Copy link

@webfacer webfacer commented Nov 25, 2016

how i can init my whole project for the first time? git flow init did´t do "git add --all", so my project is added before it should commited. is there an option for init?

@jpierson

This comment has been minimized.

Copy link

@jpierson jpierson commented Mar 14, 2017

This section should be labeled Push the merged release branch.

@morrismatts

This comment has been minimized.

Copy link

@morrismatts morrismatts commented May 4, 2017

This is great, thanks! I think your markdown tables got messed up though. They need some  s to keep the empty first table cell from collapsing. Here's a fork with the change: https://gist.github.com/morrismatts/246a1c6272dd7a8fc0ff7511b6c026fc

@Leland

This comment has been minimized.

Copy link

@Leland Leland commented May 17, 2017

Or just use <br>s to keep all the code in one cell: https://gist.github.com/Leland/eae99114bcf5349e692f4aca63193775

@ubante

This comment has been minimized.

Copy link

@ubante ubante commented May 18, 2017

I've been using your gist for a while, so thanks. Another way to fix the spacing is to use a leading pipe: https://gist.github.com/ubante/0b7ff4933adb11c0c3de0166b8e5826c. Thanks again.

@ilabacheuski

This comment has been minimized.

Copy link

@ilabacheuski ilabacheuski commented Jul 21, 2017

Bug git push origin feature/MYFEATURE - for sharing branch should be in another column
And so on. Every column is shifted

@seb54000

This comment has been minimized.

Copy link

@seb54000 seb54000 commented Oct 4, 2017

Thanks a lot for this gists, very useful.
Thanks @morrismatts or @Leland or @ubante for the fork solving the display problem with the leading space in the tables.

@JamesMGreene

This comment has been minimized.

Copy link
Owner Author

@JamesMGreene JamesMGreene commented Nov 30, 2017

Wow, thanks for all the comments, everyone! Since GitHub never notifies of comments on Gists, I had no idea this one had become so popular until a friend of mine mentioned it coming up near the top of his Google search results for git flow initialize repository. Too funny!

Thanks for all the feedback. I've fixed the table markdown so the columns are correct again... that kind of thing happens every once in a while when GitHub decides to tweak their markdown rendering rules. 😕

@JamesMGreene

This comment has been minimized.

Copy link
Owner Author

@JamesMGreene JamesMGreene commented Nov 30, 2017

@sapeish Great tip on the --showcommands flag for git flow. I had no idea about that one but now I'll be curious to compare my assumptions to see how close I was [when I maybe find time... if ever 😛].

@hyptechdev2015

This comment has been minimized.

Copy link

@hyptechdev2015 hyptechdev2015 commented May 16, 2018

Thank you for putting this together, it helps me so much.
I also found this visually helpful, combine with @JamesMGreene's https://danielkummer.github.io/git-flow-cheatsheet/#features

@victor-o-silva

This comment has been minimized.

Copy link

@victor-o-silva victor-o-silva commented Oct 30, 2018

Under Finalize a release branch, after git checkout develop, I think that Git Flow merges the tag instead of the branch, so instead of

git merge --no-ff hotfix/1.2.1

it would be

git merge --no-ff 1.2.1

@braian125

This comment has been minimized.

Copy link

@braian125 braian125 commented Nov 29, 2018

I want to ask a question that for many may be "stupid" but I want to have an opinion about.
In a project using gitflow it may be the case to mix feature branches among them, or it is best to always mix in devops and then keep the rest of the branches updated from it?

@ppazos

This comment has been minimized.

Copy link

@ppazos ppazos commented Feb 22, 2019

It seems git flow feature pull will be deprecated, can you update to use the recommended track command instead?

@hrahimi270

This comment has been minimized.

Copy link

@hrahimi270 hrahimi270 commented May 13, 2019

Hi.
So how can I push a feature branch? with normal git push origin feature/FEATURENAME?

@n8behavior

This comment has been minimized.

Copy link

@n8behavior n8behavior commented May 27, 2019

@hrahimi270, (not an expert here, but...) I think the answer is it depends. Assuming you want to update the upstream tracking branch, then yes. If you want to push it to a mainline branch (eg develop or master) you would finalize your feature branch first, then push it up to all your mainline branches that should have your feature.

@avalanchas

This comment has been minimized.

Copy link

@avalanchas avalanchas commented Aug 11, 2019

when finalizing a release, git flow also pushes the tag, right? So aren't we missing a git push origin 1.2.0 here?

@Startouf

This comment has been minimized.

Copy link

@Startouf Startouf commented Oct 15, 2019

It is possible to automatically push after finishing a git flow branch.

For instance, at my company after opening and publishing a feature/release/hotfix, we manually open a PR on github from the release to our production branch for the purpose of code review, and after the PR is approved, instead of clicking the merge button on github, we finish using git flow to make sure the commit is merged in all the relevant branches.

So in our case, when we "finish" a git flow branch, it makes sense to immediately push the branches + tags to the remote instead of having to enter the git flow commands directly.

We are using git flow (AVH edition) and there are useful git settings that allow pushing directly after finishing a git flow branch

git config gitflow.bugfix.finish.push yes
git config gitflow.feature.finish.push yes
git config gitflow.release.finish.push yes

After entering this config, git flow will automatically push the branches on the remote, thus saving extra time and avoiding confusion.

Here is an example of terminal output when doing a git flow release finish after committing a changelog on the release branch (unlike the VD model, I prefer to have my production branch named "production" instead of "master, and our development branch "master" instead of "develop")

> git flow release finish
Switched to branch 'production'
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
Merge made by the 'recursive' strategy.
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 CHANGELOG.md
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 407 bytes | 407.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To github.com:TEST/git-test.git
   452812e..af890d8  master -> master
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'production' on GitHub by visiting:
remote:      https://github.com/TEST/git-test/pull/new/production
remote:
To github.com:TEST/git-test.git
 * [new branch]      production -> production
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 187 bytes | 187.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:TEST/git-test.git
 * [new tag]         0.1 -> 0.1
To github.com:TEST/git-test.git
 - [deleted]         release/0.1
Deleted branch release/0.1 (was 6248e41).

Summary of actions:
- Release branch 'release/0.1' has been merged into 'production'
- The release was tagged '0.1'
- Release tag '0.1' has been back-merged into 'master'
- Release branch 'release/0.1' has been locally deleted; it has been remotely deleted from 'origin'
- 'master', 'production' and tags have been pushed to 'origin'
- You are now on branch 'master'

More info on the reference page of the git flow AVH config

EDIT :
Our frontend devs had been using flags to achieve the same purpose
git flow hotfix finish -Fp XX.X.X

(fetch + push)

@libert-xyz

This comment has been minimized.

Copy link

@libert-xyz libert-xyz commented Oct 24, 2019

thanks for sharing.
git flow makes everything more confusing. I rather use git raw

@giovannipds

This comment has been minimized.

Copy link

@giovannipds giovannipds commented Feb 20, 2020

I wonder why we have release start and release finish sometimes...

@sepehr-gh

This comment has been minimized.

Copy link

@sepehr-gh sepehr-gh commented Apr 10, 2020

@giovannipds For things like changing environmental variables or anything that has to be done before we push a release. Sometimes even a final code review...

@giovannipds

This comment has been minimized.

Copy link

@giovannipds giovannipds commented Apr 14, 2020

@sepehr-gh thanks. Just thought this should be done before creating the release itself.

@rohanorton

This comment has been minimized.

Copy link

@rohanorton rohanorton commented May 7, 2020

@giovannipds Another reason that you might have a release branch that is started and not immediately finished is if you are required to do some intermediary step, such as user acceptance testing, before releasing. In this scenario you would want to have code ready for release on a release branch but also continue developing new features on your development branch.

@giovannipds

This comment has been minimized.

Copy link

@giovannipds giovannipds commented May 7, 2020

@rohanorton Thanks.

@ms2052001

This comment has been minimized.

Copy link

@ms2052001 ms2052001 commented Aug 28, 2020

Why there is colon here?
git push origin :release/1.2.0

@giovannipds

This comment has been minimized.

Copy link

@giovannipds giovannipds commented Aug 28, 2020

@ms2052001 does this answer your question? But I'd say test it in a scenario you wouldn't lose something.

@peterblazejewicz

This comment has been minimized.

Copy link

@peterblazejewicz peterblazejewicz commented Nov 19, 2020

IMO, finishing a feature should read:

git merge --ff feature/MYFEATURE

not --no--ff

Can be verified with --showcommands

git flow feature finish MYFEATURE --showcommands
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.