GIT - Commands & HowTo's


What happens when I cherry-pick then rebase ?


  1. Here's a very classic situation, I have 2 branches :
       A---B---C---D master
                     X---Y---Z feature
  2. I cherry-pick Z :
       A---B---C---D---Z' master
                     X---Y---Z feature
  3. I rebase feature on master :
       A---B---C---D---Z' master
                         X---Y---Z feature
  4. ... and I get :
       A---B---C---D---Z' master
                         X---Y feature
    Looks like Git detected that Z and Z' do the same changes, hence hides Z. How can I confirm ?


As said in the rebase manual : Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..upstream are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

What's the difference between a merge request (MR) and a pull request (PR) ?

Stuff that is common to both types of requests :

  • In both cases, you have a local repository on your workstation. You commit and pull there and it is up-to-date. The difference is mostly in the context :
    • how / why / when you interact with a repository which isn't yours
    • and "how" your commits reach such repository
  • Since there's the word request, you can guess you're actually asking someone to let your commits in.
  • Both involve actions in a web UI such as GitLab or GitHub.

merge request (aka MR) :

At work, there's a shared Git repository where you can push any branch (mostly feature branches, actually) except the master branch. This is because the development team leaders / code quality specialists want to review every commit before accepting it on master. Thus, they make sure every commit meets the internal coding standards (and succeeds at the CI tests, of course).

So, when the development of your feature is done and you feel it's ready to join the master branch, you ask —via the web UI— your colleagues to merge your branch.

  • if your commits are accepted, an actual merge is performed (and your feature branch may optionally be deleted once merged)
  • otherwise, they'll ask you to fix things and to make a new merge request

pull request (aka PR) :

  1. There's this very interesting project on GitHub you wish to give a try / have a look at, so you fork it.
    There is no git fork command. forking is a "special clone" you can do on GitHub, which actually clones the remote repository on the remote server (not locally like a regular clone).
  2. This forked repository is yours, you can work normally with it (usually starting by making a local clone on your workstation).
  3. You can, of course, push / pull / merge as you like since this is yours.
  4. You can also receive ("pull") the commits made on the original repository after you forked it. (commands ?)
  5. But what if you want to share your work / contribute to this original repository ? This is what the pull request is for : you ask the owner of the original repository to pull commits from your repository to his own.
  6. At this time, it's very likely there will be some discussion / comments between you and them before they actually pull your commits (coding standards, code quality, ...)

Git repeatedly prompts for credentials


I have a script (an Ansible Galaxy Makefile, actually) that gets stuff from a list of Git repositories (pull or clone ? Whatever...), via HTTPS. Running this prompts for my username and password for every repository it has to get stuff from, which is rather long / annoying / inefficient / error-prone / I-want-to-stop-that!!!


Ask Git to cache your credentials :
git config --global credential.helper cache
If the default 15 minutes aren't enough :
git config --global credential.helper "cache --timeout=3600"
Thus, you'll only be prompted once.

Alternate solution

Append to ~/.gitconfig :
	helper = cache --timeout=3600

How to create SSH keys for GitHub ?

  1. Read this tutorial
  2. Test SSH connection to GitHub :
  3. Append to ~/.ssh/config :
    	User		git				not an example, this MUST be "git"
    	IdentityFile	/home/stuart/.ssh/github
  4. Then, you can create a new repository and store it on GitHub

What is a Git fast-forward ?


git diff and file permissions

What does Git know / track about file permissions ? Let's experiment (or jump to the conclusion) :

Increasing permissions :

workDir='/tmp/testGit'; mkdir "$workDir"; cd "$workDir"; git init; myFile="$workDir/test.txt"; echo 'hello world' > $myFile; chmod 000 $myFile; ls -l $myFile
Just creating our testing environment.
---------- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
git add $myFile; git commit $myFile -m 'hello'
Our 1st commit :
[master (root-commit) e13e5bb] hello
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 test.txt
Committed with 644 permission whereas the file actually has 000.
chmod u+r $myFile; ls -l $myFile; git diff
-r-------- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod u+w $myFile; ls -l $myFile; git diff
-rw------- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod u+x $myFile; ls -l $myFile; git diff
-rwx------ 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
diff --git a/test.txt b/test.txt
old mode 100644
new mode 100755
With the executable bit, the file is now considered having 755 permission whereas it actually has 700.
Let's commit it to go further : git add $myFile; git commit $myFile -m "u+x"
[master 93560cf] u+x
 0 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 test.txt/
chmod g+r $myFile; ls -l $myFile; git diff
-rwxr----- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod g+w $myFile; ls -l $myFile; git diff
-rwxrw---- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod g+x $myFile; ls -l $myFile; git diff
-rwxrwx--- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod o+r $myFile; ls -l $myFile; git diff
-rwxrwxr-- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod o+w $myFile; ls -l $myFile; git diff
-rwxrwxrw- 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)
chmod o+x $myFile; ls -l $myFile; git diff
-rwxrwxrwx 1 kevin developers 12 Dec 23 11:37 /tmp/testGit/test.txt
(no diff seen by Git)

Setting permission bits individually :

  1. Let's start by creating our test file :
    myOtherFile="$workDir/test2.txt"; echo 'blah blah blah' > $myOtherFile; chmod 000 $myOtherFile; git add $myOtherFile; git commit $myOtherFile -m 'Blah'
    [master 891cf3b] Blah
     1 files changed, 1 insertions(+), 0 deletions(-)
     create mode 100644 test2.txt
  2. Then, let's toggle permission bits one by one and see what Git detects :
    for person in u g o; do
    	for permission in r w x; do
    		echo $person+$permission
    		chmod $person+$permission $myOtherFile
    		ls -l $myOtherFile
    		git diff $myOtherFile
    		chmod $person-$permission $myOtherFile
    -r-------- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    --w------- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    ---x------ 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    diff --git a/test2.txt b/test2.txt
    old mode 100644
    new mode 100755
    ----r----- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    -----w---- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    ------x--- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    -------r-- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    --------w- 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt
    ---------x 1 kevin developers 15 Dec 23 12:55 /tmp/testGit/test2.txt


Git can only store two types of modes: 755 (executable) and 644 (not executable). If your file was 444 Git would store it has 644. (source)
Git is a content tracker, where content is de facto defined as "whatever is relevant to the state of a typical sourcecode tree". Basically, this is just files' data and "executable" attribute. (source)

Git hooks

Git hooks :

Available hooks (source) :

hook name is run at trigger
post-receive a local repository when the local repository is the destination of a git push

Hook execution fails on fatal: not a git repository: '.' (source) :

So far this is wizardry to me, but the solution is to unset the GIT_DIR variable. Suggested way of proceeding :
unset GIT_DIR

(part of the script where taking actions on a repo occur)


How are generated Git commit IDs ?

In order to find out, let's build a repo and commit some stuff :
testDir='/tmp/test'; testFile='test.txt'; mkdir -p "$testDir"; cd "$testDir"; git init; echo 'hello world' > "$testFile"; git add "$testFile"; git commit -m 'Hello to the world.'; echo 'hello everybody' >> "$testFile"; git add "$testFile"; git commit -m 'Hello to people.'; git show
Here's our 2nd commit, git show returns :
commit 93ce9bef143d57b6c0133d659db0c3030c24f75f
Author: Thomas ANDERSON <>
Date:	Mon Dec 15 17:54:22 2014 +0100

	Hello to people.
So, how is generated this commit ID : 93ce9bef143d57b6c0133d659db0c3030c24f75f ?
Try this :
(printf "commit %s\0" $(git cat-file commit HEAD | wc -c); git cat-file commit HEAD) | sha1sum
This should output the exact commit ID we're talking about : 93ce9bef143d57b6c0133d659db0c3030c24f75f

More details :

The commit ID is the sha1sum of :
  • the string commit [length of commit metadata]NULL
  • then commit metadata itself, being :
    • the tree ID
    • the parent ID
    • the string author firstname lastname email
    • the string committer firstname lastname email
    • (a blank line)
    • the string commit message

Fine, but why is this important ?

This shows that the commit message is used to compute the commit ID. So if a commit is amended, and the commit message changes, so will the commit ID. But, if the previous commit ID has already been pushed to a remote, this breaks one of Git's rules :

Only rewrite that part of history which you alone possess (source) : don't amend your last commit if you've already pushed it (source) !


My Git beginner's guide

I'm afraid this article will only be a collection of links (but a good link is worth 1000 words )

Git bare repositories

Git has "regular" and bare repositories :

"regular" repositories :

  • contain a working copy (i.e. all the files handled by Git)
  • have a .git sub-directory for the metadata
  • can NOT be pushed to
    You may, actually, push to a non-bare repository, but this requires extra precautions and is not recommended.

bare repositories :

  • have no working copy, just the metadata
  • have no .git sub-directory. Actually, they don't need it since bare repositories only contain metadata : what is stored in .git in non-bare repositories is found one level higher in bare repositories
  • are directories named after (by convention) myRepoName.git
  • CAN be pushed to

How to create a bare repository.

How to convert a "regular" repository into a bare repository ?

The idea is to (source) :
  1. Rename the repository directory to append it a .git : myRepoName.git
  2. Delete the working copy
  3. Move one level up the contents of the .git subdirectory (and delete .git once empty)
  4. Make Git aware of the change : git config --bool core.bare true
  5. You may have some remotes to update

It is also possible to proceed with git clone --bare.


Can not clone behind a proxy


Trying to git clone fails miserably :
git clone
Cloning into 'capifony'...
ssh: connect to host port 22: Connection timed out
fatal: The remote end hung up unexpectedly
git clone git://
Cloning into 'capifony'...
fatal: unable to connect to[0:]: errno=Connexion terminée par expiration du délai d'attente
git clone
Cloning into 'ansiblefest'...
fatal: unable to access '': Failed to connect to port 3128: Connection timed out
This is a special case because :
  • I already did the proxy configuration described below
  • this was on an old VM, and isn't the proxy to use anymore


  1. define the http_proxy environment variable :
  2. make Git aware of it :
    • git config --global http.proxy $http_proxy
    • OR add into ~/.gitconfig :
      	proxy = http://user:password@host:port
  3. clone via HTTP : git clone
  4. do the same for https

Git glossary

Git bare repositories
several definitions until I find one that summarizes them all
  • the SHAs of branch/remote heads that were updated during the last git fetch (source)
  • a short-lived reference (i.e. a pointer) to keep track of what has just been fetched from the remote repository by git fetch (source)
  • FETCH_HEAD records the branch which you fetched from a remote repository with your last git fetch invocation (source)
feature branch
Without surprise, both are dates handled by Git (), and the difference lies in the difference between an author and a committer :
the person who wrote the code
the person who committed the code on behalf of the author (and who is often the author himself)
This is important because Git allows rewriting history, or applying patches on behalf of another person, which is what is done by a maintainer with code written by a contributor on an open source project.
  • HEAD is the commit on top of which git commit would make a new one. (details)
  • Refers to a named branch, which in turn refers to a commit (a branch is updated after each commit to point to the latest commit).
  • HEAD is often considered as the latest commit of the current branch, which is partially true since HEAD can actually point to any commit. In such case (pointing to a specific commit instead of pointing to a named branch), we would be in detached HEAD mode (details 1, 2).
  • a reference to a commit object (i.e. a commit ID)
  • Each head has a name (branch name, tag name, ...). By default, there is a head in every repository called master.
  • A repository can contain any number of heads.
  • At any given time, one head is selected as "the current head". This one is aliased to HEAD (always in capitals).
  • References, heads or branches can be considered like post-it notes stuck onto commits in the commit history. Usually they point to the tip of series of commits, but they can be moved around with Git commands (checkout, revert, ...)
index (aka "cache" or "staging area")
This is where you place files before committing them into the Git repository. You can imagine it works like this :
  • the working area is the plant floor were your product is manufactured
  • the index is the "packaging / shipping" floor : this is where you bring the product itself, some accessories and shipment documents. You pack everything in a box and ship the whole package.
  • well, now, "shipping" is actually what is made with a commit
Adding file(s) to the index is made with git add.
The index is a binary file, usually found at .git/index.
Reference logs (aka reflogs) :
  • the history of HEAD values
  • record when the tips of branches and other references were updated in the local repository
  • are useful in various Git commands to specify the old value of a reference. For example :
    • HEAD@{2} means where HEAD used to be two moves ago
    • master@{one.week.ago} means where master used to point to one week ago in this local repository
Any Git repository you "synchronize" yours with, via push / pull commands. This is typically a GitLab or GitHub repository.
remote-tracking branch (sources : 1, 2)
Due of the decentralized nature of Git, all repositories are born equal, and none has a central or server role more than any other. However, developers teams need some kind of central point to act as a reference for the whole team. This central repository is called the upstream repository, it is typically the one developers interact with via GitLab.
Being an upstream repository is more an organization role than a technical functionality.
upstream branch
Checking out a local branch from a remote-tracking branch automatically creates what is called a tracking branch (and the branch it tracks is called an upstream branch). There are several ways to associate a local branch with a remote branch.

What's the point of defining an upstream branch ?

Adding a remote tracking branch means that Git then knows what you want to do the next time you'll git fetch, git pull or git push. It assumes that you want to keep the local branch and the remote branch it is tracking in sync and does the appropriate thing to achieve this. (source)
working tree (aka "working copy")
These are the files you're working on and that are tracked by Git.