Skip to content

Instantly share code, notes, and snippets.

@snigo
Last active April 29, 2021 14:20
Show Gist options
  • Save snigo/b0d7f883f003fa670a691d21364bf856 to your computer and use it in GitHub Desktop.
Save snigo/b0d7f883f003fa670a691d21364bf856 to your computer and use it in GitHub Desktop.
Git flow cheat sheet

Git flow


Step 1. Create git repo

git init

Will create default main branch


Step 2. Commit local files

git add .
git commit -m 'Commit description'

Step 3. Add remote and push committed files

git remote add origin https://github.com/myprofile/myrepo.git
git push -u origin main

origin is a nickname of remote repo, normally meaning the main remote repo. We can have many remote repos set up and we can check them with

git remote -v

-u flag means set upstream, so after that we won't need to specify remote repo nickname and branch and can just use git push and it will push commits to upstream


Step 4. Create develop branch and push it with setting it's upstream

git checkout -b develop
git push -u origin develop

checkout -b command means switch to a branch after creating it. If we want to switch to existing branch we won't use -b flag.

As we can see, we can specify separate upstreams for separate branches, so local develop branch will push commits to corresponding remote branch


Step 5. Create feature branch branched off the developer branch

git checkout -b feat/feature-name develop

Normal convention is to label feature branches with feature/ or feat/ prefix.

To set up the branch from which new branch will be brached off we use second argument after the branch name:

git checkout -b <new-branch-name> <branched-off-name>

Step 6 (option A). Complete the feature, pull from develop and merge into develop

git add .
git commit -m 'feat (feature name): Description'
git pull origin develop
# resolve possible conflicts
git add .
git commit -m 'feat (feature name): Merge with current develop'
git push -u origin feat/feature-name
# pull request from feat/feature-name to develop

As normal convention, direct push into develop branch must be restricted and merging process must be accomplished via pull request from your feature branch into develop. This way your peers may review code to double check there are no issues.

Before the push we always want to pull latest version from develop branch to make sure we have latest code. Pulling might possibly create conflicts with your current conflicts, which we need to resolve and then commit resolved version that is ready to merge with develop branch.


Step 6 (option B). Complete the feature, rebase from develop and merge into develop

git add .
git commit -m 'feat (feature name): Description'
git pull --rebase origin develop
# resolve possible conflicts
git add <conflict-file>
git rebase --continue
git push -u origin feat/feature-name
# pull request from feat/feature-name to develop

Note, that if there are no conflicts you won't need to add <conflict-file> to staging and continue rebase, you can just push your commit to remote. Many large companies seemed to prefer rebase tactic over "pull and merge" one.


Step 7. Create release branch

git checkout -b release/releave-tag develop
git push -u origin release/releave-tag

Release branch is the branch that gets tested before merging into main. If we or QA team will find some issues with code in release branch, we will create fix branch, fix the issue and pull request it into release. Release tag would look something like v1.2.5, you can read more about semantic versioning here.


Step 8. Sync develop and main branches and tag the release

Make pull requests from release into develop and main branches to sync codebases.

git checkout main
git tag release-tag
git push origin release-tag

Note that tags and releases are different things on github. Pushing a tag will not create a release. To create a release you need to go to the github and create one from a tag. This post explains difference between tags and releases and how to use them incredibly well!


Step 9. Hotfix branch if any production bugs detected

The only branches that allowed to branch out of main should be hotfix branches:

git checkout -b hotfix/what-to-fix main

Similarly to feature and release branches, hotfix branch is prefixed with hotfix/.


Step 10. Merge hotfix into the main, sync codebase with develop branch and tag the patch

When done fixing hotfix, we make a pull request into main branch and create new tag according to semantic versioning conventions.

git add .
git commit -m 'hotfix (what-to-fix): Fixed'
git push -u origin hotfix/what-to-fix
# pull request from hotfix/what-to-fix into develop
# pull request from hotfix/what-to-fix into main
git checkout main
git tag patch-version
git push origin patch-version

Note the pattern - main branch shall never be ahead of develop, we always sync them when updating main.


Step 11. Clean up all provisional branches

After the release it is a good practice to delete all secondary, previously merged branches.

git branch -d hotfix/what-to-fix
git push --delete origin hotfix/what-to-fix
git branch -d feat/feature-name
git push --delete origin feat/feature-name

Note that deleting a branch locally will not delete it on the remote repo! Therefore we use push --delete command to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment