GIT - Commands & HowTo's

rename+commit then change+commit
workDir=$(mktemp --tmpdir -d testGit.XXXXXXXX); echo "$workDir"; cd "$workDir";
git init
echo 'hello world' > file1; git add file1; git commit -m 'commit 1'
git mv file1 file2; git commit -m 'rename'
echo "Don't panic" >> file2; git add file2; git commit -m 'commit 2'

git log file2
# lists 'commit 2' + 'rename' commits

git log --follow file2
# lists all commits

cd ..; [ -d "$workDir" ] && rm -rf "$workDir"

rename+change then commit
workDir=$(mktemp --tmpdir -d testGit.XXXXXXXX); echo "$workDir"; cd "$workDir";
git init
echo 'hello world' > file1; git add file1; git commit -m 'commit 1'
echo "Don't panic" >> file1; git mv file1 file2; git add file2; git commit -m 'commit 2'

git log file2
# lists 'commit 2' only

git log --follow file2
# lists all commits

cd ..; [ -d "$workDir" ] && rm -rf "$workDir"

Foreword

Procedure

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 ?

Stuff that is common to both types of requests :

merge request (aka MR) :

pull request (aka PR) :

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"

1. Read this tutorial
2. Test SSH connection to GitHub :
   • ssh -T git@github.com
   • ssh -i ~/.ssh/github -T git@github.com
3. Append to ~/.ssh/config :

   Host github.com
   	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

• A fast-forward is one method to execute a merge :
  • either when explicitly running git merge
  • or implicitly with a git pull = git fetch + git merge FETCH_HEAD
• available methods to proceed to a merge include (details) :
  • forcing a fast-forward
  • forbidding a fast-forward
  • going best-effort to do a fast-forward and abort if it's not possible
• git merge goes fast-forward when a branch can be advanced along a linear sequence. This happens whenever you pull changes that build directly on top of the same commit you have as your most recent commit. In other words, there was never any divergence or simultaneous commits created in parallel in multiple repositories. If there had been parallel commits, then git merge would actually introduce a new merge commit to tie the two commits together.
• When a non-fast-forward merge occurs, there is always the possibility that a conflict occurs. In this case, git merge will leave conflict markers in the files and instruct you to resolve the conflicts. When you are finished, you would issue a git commit -a to create the merge commit.

Increasing permissions :

Setting permission bits individually :

Conclusion

• are scripts that Git executes before or after events such as: commit, push, and receive
• are a Git built-in feature : nothing to download / install
• are run locally
• appear as scripts found in .git/hooks

Available hooks (source) :

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

OLD_GIT_DIR=$GIT_DIR
unset GIT_DIR

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

GIT_DIR=$OLD_GIT_DIR

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 2^nd commit, git show returns :

commit 93ce9bef143d57b6c0133d659db0c3030c24f75f
Author: Thomas ANDERSON <thomas.anderson@metacortex.com>
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 :

Fine, but why is this important ?

• MUST-READ for beginners : Getting Started - Git Basics
• Some basic Git vocabulary
• For those who need sketches to get things :
  • start with this one : A Visual Git Reference
  • animates as you type : Visualizing Git Concepts with D3
  • the all-in-one : The Git cheatsheet
  • Rachel M. Carmena has great sketches to teach Git.
• Documentations I wrote about Git :
  • A training session I made for colleagues (in french) : Git - Présentation basique et non-exhaustive
  • My humble Git tutorial
• Some extra man pages :
  • man gittutorial
  • man giteveryday
  • man gitglossary
  • man gitworkflows
• The Git FAQ
• Git high-level porcelain commands :
  • git-scm.com
  • kernel.org

"regular" repositories :

bare repositories :

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

git clone git@github.com:/everzet/capifony.git

Cloning into 'capifony'...
ssh: connect to host github.com port 22: Connection timed out
fatal: The remote end hung up unexpectedly

git clone git://github.com/everzet/capifony.git

Cloning into 'capifony'...
fatal: unable to connect to github.com:
github.com[0: 204.232.175.90]: errno=Connexion terminée par expiration du délai d'attente

git clone https://github.com/ehashman/ansiblefest.git

Cloning into 'ansiblefest'...
fatal: unable to access 'https://github.com/ehashman/ansiblefest.git/': Failed to connect to 10.2.0.20 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 10.2.0.20 isn't the proxy to use anymore

1. define the http_proxy environment variable :

   http_proxy=http://user:password@host:port

2. make Git aware of it :
   • git config --global http.proxy $http_proxy
   • OR add into ~/.gitconfig :

     [http]
     	proxy = http://user:password@host:port

3. clone via HTTP : git clone http://github.com/everzet/capifony.git
4. do the same for https

bare

Git bare repositories

FETCH_HEAD

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

TODO:

fork

TODO:

GIT_AUTHOR_DATE, GIT_COMMITTER_DATE

Without surprise, both are dates handled by Git (), and the difference lies in the difference between an author and a committer :

author

the person who wrote the code

committer

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

• 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).

head

• 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.

reflog

Reference logs :

• 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
  (details)

This information belongs to a local repository and is not carried by git clone : the reflog of a cloned repository will have a single entry saying (source) :

commitId HEAD@{0}: clone: from [source repository]

remote

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)

• a remote-tracking branch is a local branch that represents a remote branch
• the label of a remote-tracking branch (i.e. what it points to) is updated only with network operations such as clone, fetch, pull and push
• remote-tracking branches are automatically created on repositories started with git clone. When manually linking a local and a remote repository with git remote add, you'll have to explicitly declare remote-tracking branch(es)
• How to track a remote branch ?

upstream

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.