Today I Learned



Fixing mistakes

  1. Spelled last commit message wrong git commit --amend

  2. Spelling mistake on branch name

    git branch -m feture-brunck feature-branch

    If you have already pushed this branch, there are a couple of extra steps required. We need to delete the old branch from the remote and push up the new one:

    git push origin --delete feature-brunch git push origin feature-branch

  3. Accidentally committed all the changes to the master branch Make sure your commit or stash your changes first, or all will be lost!

    git branch feature-branch git reset HEAD~ --hard git checkout feature-branch

  4. Forgot to add a file to that last commit git add missed-file.txt git commit --amend --no-edit

    --no-edit means that the commit message does not change.

  5. Added wrong file in the repo If all you did was stage the file and you haven’t committed it yet, it’s as simple as resetting that staged file:

    git reset /assets/img/misty-and-pepper.jpg

    If you have gone as far as committing that change, no need to worry. You just need to run an extra step before:

    git reset --soft HEAD~1
    git reset /assets/img/misty-and-pepper.jpg
    rm /assets/img/misty-and-pepper.jpg
    git commit

    This will undo the commit, remove the image, then add a new commit in its place.

  6. Last resort (when nothing works)

    git reflog
    git reset HEAD@{index}

    [source] (

Tagging versions

Are you still not git tagging version? If so, you should automatically and for the logs you could just run

“git log git describe --tags --abbrev=0..HEAD –oneline”

which gives you all the change between now & the last version / tag and pipe that to your clipboard

Delete all untracked files

cleaning up (read: removing) untracked files from a local copy of a repository. $ git clean -f -d


Untrack a file or a directory without deleting it

If you want to untrack a file (remove it from the index), but still have it available locally (in the working tree), then you are going to want to use the –cached flag. $ git rm --cached <filename> or for a directory $ git rm --cached -r <directory> Note: If you do this, you may also consider adding that file to the .gitignore file.


Diffing with Patience algorithm

You can set this as the default algorithm by adding the following lines to your ~/.gitconfig file:

    algorithm = patience

or it can be set from the command line with:

$ git config --global diff.algorithm patience

Comparison between the classic algorithm and the patience one


Check to see all the changes in a commit

$ git whatchanged

List all commits that changed a specific file

$ git log --follow -- filename --follow accounts for renames


If you want to see the actual changes use:

$ git log -p filename src

Only log changes for some specific lines in file

$ git log -L 1,10:filename


How to compare same file from two different branches

git diff mybranch master – myfile.cs src

Git philosophy


Git was designed to support a more distributed model with no need for a central repository (though you can certainly use one if you like). Also git was designed so that the client and the “server” don’t need to be online at the same time. Git was designed so that people on an unreliable link could exchange code via email, even. It is possible to work completely disconnected and burn a CD to exchange code via git.


In order to support this model git maintains:

By keeping a copy of the remote repository locally, git can figure out the changes needed even when the remote repository is not reachable. Later when you need to send the changes to someone else, git can transfer them as a set of changes from a point in time known to the remote repository.


The take away is to keep in mind that there are often at least three copies of a project on your workstation. One copy is your working copy where you are editing and building. (/home/you/workingtree) The second copy is your own repository with your own commit history. (/refs/heads) The third copy is your local “cached” copy of a remote repository. (**_refs/remots//_**)


Fetch vs. Pull

Git documentation – git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.


tig blame

To interactively browsing “git blame”. Simply run

tig blame FILE

and you see something very much like the output of “git blame”, but you can now press “,” to get to the “previous” line in history. And press “<” to get back. Use RET to look at the commit, and “q” to close the overview.