`git flow` vs. `git`: A comparison of using `git flow` commands versus raw `git` commands.

gitflow-breakdown.md

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 [email protected]: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

• http://nvie.com/posts/a-successful-git-branching-model/
• https://help.github.com/articles/using-pull-requests#shared-repository-model
• Personal experience

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)

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

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

@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...

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

@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.

@rohanorton Thanks.

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

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

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

@peterblazejewicz, the thing here is that features finished consisting of a single commit, it does a --ff.
A feature finish with multiple commits does a '--no-ff'.
Not sure why.
Imo --no-ff is preferred for tree-readablity and uniformity.

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

colon is specified to delete the branch from remote origin.

Hi,

If a release has been created as release/1.1.0, how can we bring minor changes on it, in term of branching?
I mean, do we need to create a branch like fix/XXXX coming from release/1.1.0 to do our changes and after merging back to release/1.1.0?

Or what is the best pratices to put our changes in release/1.1.0?

Hi,

To create a Feature or a Release before th command git checkout -b feature/MYFEATURE develop
it wouldn't be better to do a "pull" before ? like :

git checkout develop
git pull origin develop