Sunday, July 20, 2014

Concise Git Reference for everyday use

This is compilation of all Git commands referring to "Pro Git" book by Scott Chacon.
  • Git config files:
    • /etc/gitconfig - config applicable to all users.
    • /.gitconfig - specific to a user.
    • ~/.git/config - config per git repo.
    • Typical configs:
      • git config --global "Watsh Rajneesh"
      • git config --global ""
      • git config --global color.ui true
      • git config --global push.default simple
      • git config alias.last=log -1 HEAD
    • git config -l => shows the current config.
  • git [command]  --help
    • e.g. git commit --help
  • Create a new git repo from existing directory:
    • git init
    • git add *
    • git commit -m 'my comment'
  • Cloning an existing repo:
    • git clone
      • will create a local .git directory which will hold the entire repo with all the history known at the time of cloning.
      • will create a tracking branch "master" which will track the "master" branch on remote (or origin/master - see below point)
      • will save the as remote named "origin"
  • Git lifecycle states:
    • Untracked -> staged -> committed (tracked)
  • git status => shows:
    • Changes to be committed - staged files
    • Changed but not updated - modified files
  • git diff - to see diff between modified and staged version
    • git diff --cached - to see diff between staged and last committed version
  • git commit -a -m 'message' => skips staging and directly commits all modified files.
  • Remove files:
    • git rm [file]
    • git rm --cached => keeps the modified file but removes the staged versions of the file.
  • Rename a file:
    • git mv [file_from] [file_to]
  • Git log:
    • git log --pretty=format:"%h <%cr> [%cn] %s" --graph --name-only --since=2.weeks --author=Watsh
    • gitk - GUI to visualize history
  • Change last commit:
    • git commit --amend
  • Unstage a staged file:
    • git reset HEAD [file]
  • Unmodify a modified file:
    • git checkout -- [file]
  • Remotes:
    • git remote -v
    • git remote add watsh_repo
    • Inspecting remote:
      • git remote show watsh_repo
    • Removing and renaming remote:
      • git remote rename watsh_repo watsh_repo2
      • git remote rm watsh_repo2
  • Fetching from remote:
    • git fetch [remote]
      • git fetch watsh_repo
    • The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.
    • If you fetched a new branch created and pushed by your colleague and you need to start working on the same branch, you first get the branch reference in your local git repo (the .git directory) by doing a git fetch and then create a new branch referring to that reference ([remote]/[remotebranch]). The new branch thus created will be a tracking branch (hence git pull/push will automatically resolve to the right remote branch from the local tracking branch context).
      • git fetch watsh_repo
      • git checkout -b bug456 watsh_repo/bug456
  • Pushing to remote:
    • git push
      • git push watsh_repo master
      • It pushes your "master" branch changes to watsh_repo's "master" branch.
    • git push [remote] [localbranch]:[remotebranch]
      • git push watsh_repo master:release1.2.3_branch
      • Pushes local master to release1.2.3_branch remote branch on watsh_repo.
  • Tagging:
    • git tag -l 'v1.2.3.*'
    • git tag -a v1.4 -m 'my version 1.4' => creates annotated tags
    • git show  [tagname]
    • git push [remote] [tagname] => by default tags are not pushed with git push so we need to do this explicitly.
      • git push watsh_repo2 v1.4
      • git push watsh_repo2 --tags => push all tags
  • Auto completion for git:
    • wget 
    • . ~/.git-completion.bash
    • cp ~/.git-completion.bash /etc/bash_completion.d => will enable git auto completion on bash launch for all users.
  • Branching & Merging:
    • git branch bug123
    • git checkout bug123
      • Fix the bug123 by making changes
      • git commit -a -m 'added fix for bug123'
    • git checkout -b 'hotfix'
      • Make hotfixes
      • git commit -a -m 'hotfixes done'
    • git checkout master
      • git merge hostfix
      • git branch -d hotfix => since we are done with hotfix branch, so delete it.
      • git merge bug123
      • git branch -d bug123
    • See which branches are already merged into:
      • git branch --merged
    • See all branches that contain work you have not merged in:
      • git branch --no-merged
    • Checking out a local branch from a remote branch automatically creates what is called a tracking branch. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Same is true for git pull.
    •  git checkout -b [branch] [remotename]/[branch]
      • git checkout -b sf origin/serverfix
      • Now, your local branch sf will automatically push to and pull from origin/serverfix 
    • Delete remote branch:
      • git push [remotename]  :[remotebranch]
      • Giving no local branch name before ':' above has the effect of deleting the remote branch.
  • Use cases:
    • Begin working on a new feature/bug:
      • git checkout -b myfeature_branch origin_feature_branch
      • git pull 
      • // do your works on myfeature_branch
      • git push --set-upstream origin myfeature_branch
      • git push origin myfeature_branch 
        • Make your myfeature_branch available on the remote git server so others can checkout it for reviewing or working with you (say multiple ppl working on the myfeature feature).
      • // once work is reviewed and ready to be merged to origin_feature_branch
      • git checkout origin_feature_branch
      • git pull
      • git merge --squash myfeature_branch 
        • Merge with --squash option which will commit all changes from myfeature_branch (across several commits on myfeature_branch) into a single commit on the origin_feature_branch. This ensures a cleaner history, ease of reverting the changes collectively that were brought in from myfeature_branch.
        • Note down this SHA-1 - we can use this for cherry picking this change to release branch next.
      • git push origin origin_feature_branch 
      • Delete the myfeature_branch from remote and local:
        • git branch -d myfeature_branch
        • git push origin :myfeature_branch
    • Cherry pick a change by its SHA-1 id:
      • git checkout release_branch
      • git cherry-pick [SHA-1 of the squashed commit from myfeature_branch]
      • git push origin release_branch
  • Git credentials:
You can store your credentials using the following command. This was very helpful to not having to re-enter credentials everytime i did a git push for instance.
$ git config credential.helper store
$ git push
Also I suggest you to read
$git help credentials
The above is generally the basic working knowledge of Git which one needs on a day-to-day basis. Of course there are more advanced use cases related to stashing away your changes (pushing to a stack and popping them out), rebasing (which is more or less like merge command). I intend to cover those in later updates to this post. So long...

No comments:

Using a Console Cable (USB TTL Serial Cable) with Raspberry Pi 3

A console cable provides terminal access to Raspberry Pi from say a laptop host without requiring to connect a monitor to Pi's HDMI port...