• What's the difference between git reflog and git log?: StackOverflow
  • Git log is a record of your commits. The reflog, as the Pro Git book states, is a record of your references (basically, your branch pointers and your HEAD pointer), and which commits they have been pointing at. On a side note, git log can also show you reflog information, but you have to pass a special option flag as an argument to it, --walk-reflogs.
  • git reflog show <branch_name>: Git reflog for a specific branch.
  • Where does Git store its reflogs: StackOverflow

  • git init
  • git status
  • git commit -m "comment"
  • git log: shows the commit history
  • git add .: add all new and modified files to our staging area.
  • git diff: to find the diff between the files in the working tree and the staging area.
  • git diff --staged: find the diff between the files in the staging area and our most recent commit.
  • git diff <branch1..>..<branch2>: to find the diff between branch1 and branch2
  • git rm <file_name>: remove a file from git (removes both from the working tree and the staging area).
  • git checkout -- s1: replace the working tree file s1 with the contents of the s1 file from the staging area.
  • git reset head s1: replace the s1 in the staging area with the s1 from the commit history.
  • git checkout 9ddb -- s2: get the file s2 from the commit 9ddb9 to both the staging area and the working tree
  • .gitignore: contains the files and the folders that you don't want the git to track. You will have to commit the .gitignore file to the git repo like any other file.


  • git stash: save the state of the working directory and the staging area (index) temporarily.
  • git stash save "message": stash the changes with a useful message.
  • git stash list: to see the list of current stashes.
  • git stash list -p: see the list of stashes and also observe the changes occured in each of the stashes.
  • git stash apply: reapplies the changes from the most recent stash


  • Intro to Git - basic functionalities.
  • Mark Lodato visual git guide: github.io link
  • The default branch name in Git is master. For both remote and local computer.
  • origin is a custom and most common name to point to remote.
  • origin/master is just a pointer to refer master branch in the remote repo.
  • Basic rule: do not add compiler generator binary files (like .dll and .bin) to source control.


  • Working with git submodules: link
  • Submodules are Git repositories nested inside a parent Git repository at a specific path in the parent repository’s working directory
  • A submodule is configured via a .gitmodules file located at the root of the parent repository.
  • Submodules allow you to keep projects in separate repositories but still be able to reference them as folders in the working directory of other repositories.
  • git submodule update --init --recursive: if you want to load submodules for the current repository.
  • git submodule add -b master <url>: add a submodule to your current repository and track the master branch of that submodule.
  • Use the git submodule update command to set the submodules to the commit specified by the main repository. This means that if you pull in new changes into the submodules, you need to create a new commit in your main repository in order to track the updates of the nested submodules.
  • To delete a submodule from a repository:
    1. git submodule deinit -f -- mymodule
    2. rm -rf .git/modules/mymodule
    3. git rm -f mymodule

  • git clone <url>: to clone a remote repository on to our local machine.
  • git clone -depth=1 <url>: Clone the repository located at url and only clone the history of commits specified by the option depth=1. The clone of the url is made and only the most recent commit is included in the new cloned Repo. Shallow cloning is most useful when working with repos that have an extensive commit history.
  • git config --local user.name <name>
  • git config --local user.email <email>
  • git remote: displays the names of the remote repositories in our system.
  • git remote -v: displays the names as well as the full location of the remote repositories in our system.
  • The origin/master is a specialized remote tracking branch whose purpose is to tell us what the master branch looks like at the origin.
  • The remote tracking branch (like origin/master) is not the same as the standard local branch (like master). For example, if we check out the remote tracking branch with the command git checkout origin/master, it would result in detatched head.
  • git fetch origin: checks for any updates in the remote repository pointer by origin.
  • git merge origin/master: merge our master branch with the master branch of the remote repository.
  • git pull: combines the git fetch and git merge into a single command.
  • git push origin master: push the changes made on the local repository into the master branch of the remote repository. Keep in mind, this push relies on authentication (like using ssh keys).
  • Creating a fork in Github: A fork is a copy of a repository created in a personal login. This allows you to freely experiment with changes without affecting the original project.
  • git remote add upstream <url>: adds a git remote repository by the name upstream connected to the specified url.
  • git remote remove upstream: to remove a remote repository by the name upstream.
  • git fetch upstream: checks for any updates from the remote repository upstream.
  • git branch -a: to display both local and remote branches.
  • git branch -r: display only remote tracking branches.

  • How to make Git “forget” about a file that was tracked but is now in .gitignore?: StackOverflow
  • .gitignore will prevent untracked files from being added to the set of files tracked by git, however git will continue to track any files that are already being tracked.
  • How to resolve merge conflicts in Git?: StackOverflow
    • Identify which files are in conflict (Git should tell you this).
    • Open each file and examine the diffs; Git demarcates them. Hopefully it will be obvious which version of each block to keep. You may need to discuss it with fellow developers who committed the code.
    • Once you've resolved the conflict in a file git add the_file(s).
    • Once you've resolved all conflicts, do git rebase --continue or whatever command git said to do when you completed.
  • Git Cherrypick - Cherry picking is the act of picking a commit from a branch and applying it to another: Atlassian
  • What does cherry-picking a commit with Git mean?: StackOverflow
  • Strictly speaking, using git cherry-pick doesn’t alter the existing history within a repository; instead, it adds to the history. As with other Git operations that introduce changes via the process of applying a diff, you may need to resolve conflicts to fully apply the changes from the given commit

Git

  • How to remove a single file from a staging area: :StackOverflow
    • git reset head -- <file_name>
    • git reset head -- <folder_name>
  • How do I undo the most recent local commits in Git? : StackOverflow
  • Difference between git reset --hard HEAD and git checkout .: StackOverflow
  • git checkout command: Atlassian
  • git checkout -b <new_branch_name> <existing-branch>: By default git checkout -b will base the new-branch off the current HEAD. An optional additional branch parameter can be passed to git checkout. In the above example, existing-branch is passed which then bases new-branch off of existing-branch instead of the current HEAD.
  • git checkout master~2 Makefile: reverts the Makefile to two revisions back. This wouldn't update the HEAD in anyway. But it would update the Makefile both in the staging area as well as in the working tree.
  • git checkout hello.c: restore hello.c from the index.
  • git diff: Changes in the working tree not yet staged for the next commit.
  • git diff --cached: Changes between the index and your last commit; what you would be committing if you run "git commit" without "-a" option.
  • git diff HEAD: Changes in the working tree since your last commit; what you would be committing if you run git commit -a.
  • git diff test: Changes in the working tree is compared with the tip of the test branch.
  • git diff HEAD -- ./test: Compare changes in the current working tree with the tip of the current branch, but limit the comparison to the file test.
  • git diff HEAD^ HEAD: Compare the version before the last commit and the last commit.
  • Changes between the tips of topic and master branches (both commands would give the same result):
    • git diff topic master
    • git diff topic..master
  • git diff topic...master: Changes that occurred on the master branch since when the topic branch was started off it.

  • git rebase <branch_name>: moves the base commit for the current branch to start from the given branch-name. This is usually followed by a merge operation with branch-name which would result in a fast-forward merge operation.
  • In plain English, what does git reset do?: StackOverflow
  • git reset moves the current branch to another position. And it can optionally updated the staging area and working directory.
  • git reset --hard: you loose your work (uncomiited changes); it doesn't change branches; modifies your work tree and loose your work.
  • git reset --hard is equivalent to git reset --hard HEAD.
  • git reset is equivalent to git reset --mixed; it resets the staging area (index) but not the working tree. Use this when you realize you made some bad commits but you want to keep all the work you have done so you can fix it up and recommit.
  • git reset --soft doesn't touch the index or the working-tree.
  • git reset --merge was added recently; and is intended to help you abort a failed merge.
  • HEAD~ is short for HEAD~1 and means the commit's first parent. HEAD~2 means the commit's first parent's first parent. Think of HEAD~n as "n commits before HEAD" or "the nth generation ancestor of HEAD".
  • HEAD^ (or HEAD^1) also means the commit's first parent. HEAD^2 means the commit's second parent. Remember, a normal merge commit has two parents - the first parent is the merged-into commit, and the second parent is the commit that was merged.
  • Reset demystified: git-scm
  • git reset: schacon.github.io

  • git branch -d branch_name: to delete a local branch. The -d option is an alias for --delete, which only deletes the branch if it has already been fully merged in its upstream branch.
  • git branch -D branch_name: Also used to delete a branch (but forcefully). Use -D, which is an alias for --delete --force, which deletes the branch "irrespective of its merged status".
  • git push remote_name --delete branch_name: To delete a remote branch.
  • git push origin --delete feature1: deletes a remote branch pointed by origin with the branch name feature1.
  • Difference between git pull and git fetch: StackOverflow
  • When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge.
  • git rm --cached file1: to remove file1 from staging area. You could also get similar result using git reset HEAD file1.
  • How to rename a local git branch? StackOverflow
  • git branch -m oldName newName: to rename a git branch frol oldName to newName.
  • How to modify existing, unpushed commit messages? :StackOverflow
  • git commit --amend: changing the most recent commit message
  • git commit --amend -m "New commit message": changing the most recent commit message in a sinlge line.

  • When we are ready to save changes to a file, we make a commit (take a snapshot of the files).
  • A commit saves the state of the file at a particular point in time.
  • Usually, we make a commit when a logical unit of work is done.
  • .git directory holds an object database and metata that makes up our repo. In fact, if we sent our .git directory to someone else, that person would have our complete git project and it's full history. They would have access to all the version of the files in the commits we have made.


  • Difference between Head and Master: StackOverflow
  • Pushing and pulling with git - part 1: link
  • Pushing and pulling with git - part 2: link
  • Why is a 3-way-merge advantageous over a 2-way-merge: StackOverflow
  • Git Branching: Master vs. origin/master vs. remotes/orgins/master: StackOverflow
  • How to git clone including submodules?: StackOverflow
  • git clone --recurse-submodules -j8 <url>
  • git submodule update --init --recursive: To update the submodules for already clone repositories.


  • A branch is just a pointer to a sha1 hash.
  • The way Git knows which branch we are on is using a special pointer called Head. It is a pointer to a branch. Since head points to a branch and not directly to a commit, it is sometimes called a symbolic pointer. In Git terminology, the head pointer tells us what we have checked out. By default, the head pointer points to the Master branch and it tells us that we have checked out the Master branch.
  • git log --all --decorate --oneline --graph: to the git commit history as a graph.
  • To create an alias for the above useful log command: alias graph="git log --all --decorate --oneline --graph"
  • git branch <branch_name>: create new branch at the location where the head points to.
  • git branch: to show all our branches
  • git checkout <branch_name>: to move to a different branch. It moves the head to point to the new branch.
  • Fast-forward merge: when there is a direct path from the current branch to the branch we want to merge with.
  • 3-way merge: when there is not direct path from the master branch to some other branch we want to merge.
  • git branch --merged: shows which branches have been merged with the current branch.
  • git branch -d <branch_name>: to delete a branch.
  • git merge <branch_name>: merges the current branch with the given branch. It could either be a fast-forward merge or a 3-way merge.
  • Git displays the message merge made by the recursive-strategy to denote 3-way-merge.
  • Merge confilicts occur when we try to merge branches that have changed the same lines in the same files. This has to be resolved manually before merging can proceed.
  • git checkout -b dev: Equivalent to
    • git branch dev: create a new branch by the name dev.
    • git checkout dev: move to the dev branch just created.
  • git commit -a -m "commit message": Equivalent to running:
    • git add on all the filenames that existed on the latest commit.
    • Followed by git commit -m "message"
  • git merge --abort: to abort the merge process when you get a conflict. When we have a merge conflict while trying to merge, the git status command will show the message "You have unmerged paths"
  • Detached Head: usually the head points to a branch which in turn points to a commit. But when the head points to a commit directly, we have the detached head problem. This is what happens when we do git checkout <commit_hash>.
  • To take care of detached head:
    1. Either do git checkout <some_branch> which will make the head point again to a valid branch.
    2. Or, create a new branch where the head points to currently and make the head point to that branch.
      • create branch Branch1
      • git checkout Branch1
      • Make sure the head pointer is no longer detached using git log --all --decorate --oneline --graph