GIT

Git grep

--count files and count matches

-p method or function

--break --heading split up the output

--and multiple matches in same line

#If you want to find all commits where commit message contains given word, use

git log --grep=word

#If you want to find all commits where "word" was added or removed in the file contents (to be more exact: where number of occurences of "word" changed), i.e. search the commit contents, use so called 'pickaxe' search with

git log -Sword

Short answer:

git reset 'HEAD@{1}'

Long answer:

Git keeps a log of all ref updates (e.g., checkout, reset, commit, merge). You can view it by typing:

git reflog

Somewhere in this list is the commit that you lost. Let's say you just typed git reset HEAD~ and want to undo it. My reflog looks like this:

$ git reflog

3f6db14 HEAD@{0}: HEAD~: updating HEAD

d27924e HEAD@{1}: checkout: moving from d27924e0fe16776f0d0f1ee2933a0334a4787b4c

[...]

The first line says that HEAD 0 positions ago (in other words, the current position) is 3f6db14; it was obtained by resetting to HEAD~. The second line says that HEAD 1 position ago (in other words, the state before the reset) is d27924e. It was obtained by checking out a particular commit (though that's not important right now). So, to undo the reset, run git reset HEAD@{1} (or git reset d27924e).

If, on the other hand, you've run some other commands since then that update HEAD, the commit you want won't be at the top of the list, and you'll need to search through the reflog.

One final note: It may be easier to look at the reflog for the specific branch you want to un-reset, say master, rather than HEAD:

$ git reflog show master

c24138b master@{0}: merge origin/master: Fast-forward

90a2bf9 master@{1}: merge origin/master: Fast-forward

[...]

This should have less noise it in than the general HEAD reflog.

My situation was slightly different, I did git reset HEAD~ three times.

To undo it I had to do

git reset HEAD@{3}

so you should be able to do

git reset HEAD@{N}

But if you have done git reset using

git reset HEAD~3

you will need to do

git reset HEAD@{1}

As {N} represents number of operations in Reflog. As Mark pointed out in the comments.

------------------------------------------------------------------------------------------------------------------------------------

My situation was slightly different, I did git reset HEAD~ three times.

To undo it I had to do

git reset HEAD@{3}

so you should be able to do

git reset HEAD@{N}

But if you have done git reset using

git reset HEAD~3

you will need to do

git reset HEAD@{1}

As {N} represents number of operations in Reflog. As Mark pointed out in the comments.

My situation was slightly different, I did git reset HEAD~ three times.

To undo it I had to do

git reset HEAD@{3}

so you should be able to do

git reset HEAD@{N}

But if you have done git reset using

git reset HEAD~3

you will need to do

git reset HEAD@{1}

As {N} represents number of operations in Reflog. As Mark pointed out in the comments.

How do I show the git branch with colors in Bash prompt?

add below before unset color_prompt force_color_prompt

parse_git_branch() {

git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'

}

export PS1="\u@\h \[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] $ "

Fix Non-ASCII characters in content are shown "garbled" in tig

1. Make sure that libncursesw5-dev package(ubuntu) was installed.

sudo apt-get install libncursesw5-dev

2. Remove tig and then reintall it

sudo ./Download/tig-<version>/make uninstall

sudo apt-get remove tig

sudo apt-get install tig

Git conflict merge (using vimdiff)

move your cursor (by [ & ]) to a merge conflict area and then:

:diffg RE " get from REMOTE

:diffg BA " get from BASE

:diffg LO " get from LOCAL

git merge -Xignore-space-change

Create a remote branch

git push <repo> <local_branch>:<remote_branch>

Remove a branch

git push <repo> --delete <branch_name>

git branch -d <branch_name>

Undo published commits with new commits

# This will create three separate revert commits:

git revert a867b4af 25eee4ca 0766c053

# It also takes ranges. This will revert the last two commits:

git revert HEAD~2..HEAD

#Similarly, you can revert a range of commits using commit hashes:

git revert a867b4af..0766c053

# Reverting a merge commit

git revert -m 1 <merge_commit_sha>

# To get just one, you could use `rebase -i` to squash them afterwards

# Or, you could do it manually (be sure to do this at top level of the repo)

# get your index and work tree into the desired state, without changing HEAD:

git checkout 0d1d7fc32 .

# Then commit. Be sure and write a good message describing what you just did

git commit

upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow).

simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one.

When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.

This mode has become the default in Git 2.0.

matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).

How do I “git blame” a deleted line?

git blame --reverse abcdef01..HEAD -- <file>

git log -S <string> path/to/file

When added or removed a word?

git log -S string

Find and restore a deleted file in a Git repository

git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file"

Blame a deleted file

git blame $(git rev-list -n 1 HEAD -- $file)~1 -- $file

File diff or full diff (also shows other files diff with the same commit)

git log -p --full-diff <path>

--full-diff

Without this flag, git log -p <path>... shows commits that touch the specified paths, and diffs about the same specified paths. With this, the full diff is shown for commits that touch the specified paths; this means that

"<path>..." limits only commits, and doesn’t limit diff for those commits.

Trace Lines or function

git log

-L <start>,<end>:<file>, -L :<funcname>:<file>

how to create a patch without commit

new files that are untracked and won't be in your git diff output (add first then)

git diff --cached --binary > mypatch.patch

stash -> patch (not work for untracked files. untracked files need to be tracked first)

git stash -u

git stash show -p --color=never > my-patch-name.patch

For new patches that mysteriously fail with git apply:

Stripping trailing CRs from patch; use --binary to disable.

patch -p1 --binary < thepatch.patch

Change multiple commit messages​(last three)

git rebase -i <previous-commit-id-need-to-be-amend>

pick -> edit

git rebase --continue

Configure commit template

git config --global commit.template ~/.gitmessage.txt