Git Cheat Sheet

Branching Model

• Inspired by http://nvie.com/posts/a-successful-git-branching-model/.
• Main branches: master, dev
  • master reflects code already released
  • dev reflects state with latest delivered development changes for next release. Every merge from dev to master is a new release.
• Supporting branches: the naming convention for these are discussed separately below.
  • Feature branches
    • For each feature, and must merge back only into dev.
    • Use the --no-ff flag for merging back into dev. “This causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.”
  • Release branches: We do not have these today but these will come in handy once larger number of developers start working on the SDK. The purpose of this branch would be to unblock the dev branch to receive other big features while allowing any last minute minor changes to the feature about to be released. This should be merged back to both master and dev.
  • Hotfix branches: Merge off master, fix critical bugs, merge back into master and dev.

Naming branches

• Use the format "item type"/"item name", where item type could be ‘feature’ (for feature work items), ‘fix’ (for fixing bugs), ‘hotfix’ (for hotfix branches), ‘release’ (for release branches).
• Use hyphens to separate multiple words in the item name
• Examples: feature/windows-port, feature/doc-tracking, fix/sample-app, hotfix/clear-adal-cache
• Use private/"your alias" prefix for any personal experiments that you might be doing to indicate to other developers not to push to these branches. For example: private/anuprat/philosophers-stone is where I try to create the philosophers stone. Private branches can come in handy in various scenarios, for example if you want to test your changes across platforms using our continuous integration capabilities before pushing to dev. Push your changes to a temporary private branch, run CI, and then if everything works push to dev.

Writing commit messages.

• http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html.
• Start with a summary line of 50 chars or less
• Add detailed explanation in the body but wrap each line to about 72 chars.
• Make sure there is an empty line between summary and body.

Git Squash

git rebase -i <parent-of-commit-you-want-to-rebase-from>
git rebase --continue (after resolving merge conflicts)

Show diff of staged changes

git diff --staged

Merging to master

git checkout master
git merge --no-ff dev
git tag -a vX.Y.Z -m "Release message"
git push origin master
git push origin vX.Y.Z

Quick branch create and checkout:

git checkout -b <branch>

Git add:

git add -- folder //adds folder
git add -A //stages All
git add . //stages new and modified, without deleted
git add -u //stages modified and deleted, without new 

Push local branch to remote:

git push -u origin <branch>

Delete remote branch:

git push origin --delete <your_branch>

Delete local branch:

git branch -d <branch_name>