GIT - Index of commands

1. get commit IDs :
   git log --oneline
2. enter bisect mode :
   git bisect start
   you can also narrow the search area to some files / directories with :
   git bisect start -- someFile someDir
3. specify a bad commit :
   • git bisect bad badCommitId
   • git bisect bad will generally suffice since the latest commit in history actually has the bug
4. specify a good commit :
   git bisect good goodCommitId
5. git bisect picks a commit between those two endpoints and expects you to specify whether the selected commit is good or bad (does it "git checkout commitId" ? Anyway, you'll end in "detached head" during the process ;-)). Validate this commit by running the program, running unit tests, ..., and let Git know : :
   • git bisect good
   • git bisect bad
   • git bisect skip (undetermined)
6. git bisect continues narrowing down the range until it finds the exact commit that introduced the change and displays results
7. at any point, leave bisect mode :
   git bisect reset

1. setup of "repoOrigin" :
   export TMPDIR='/run/shm/'; repoOriginDir=$(mktemp -d); cd "$repoOriginDir"; git init; echo 'hello world' > myFile; git add myFile; git commit -m 'initial version'; git log; cat myFile
2. setup of "repo2", as a clone of "repoOrigin" :
   repo2Dir=$(mktemp -d); cd "$repo2Dir"; git clone "$repoOriginDir" .; git log; cat myFile
3. create new branch on "repoOrigin" :
   branchName='myBranch'; cd "$repoOriginDir"; git checkout -b "$branchName"; echo "hello to all my friends from the '$branchName' branch" >> myFile; git add myFile; git commit -m 'for my friends'; cat myFile; git log
4. making sure there is different stuff on branches of "repoOrigin" :
   git checkout master; cat myFile; git log
5. let's get the "$branchName" branch on "repo2" :
   cd "$repo2Dir"; git fetch origin "$branchName":"$branchName"; git branch; git log; cat myFile
6. so far, nothing in git branch / git log or in files. Lets view the contents of "$branchName" on "repo2" :
   git checkout "$branchName"; git branch; git log; cat myFile
7. make changes on "$branchName" from "repo2" :
   echo "I made this change into '$branchName' from 'repo2'" >> myFile; git add myFile; git commit -m 'changed from repo2'; git log
8. to get this change in "repoOrigin", we have to declare a "remote" first :
   remoteName='repo2'; cd "$repoOriginDir"; git remote add "$remoteName" "$repo2Dir"; git remote -v
9. now get stuff :
   • git fetch "$remoteName"; git checkout "$branchName"; git branch; git log; cat myFile
     no error, but doesn't receive the "changed from repo2" commit
   • git fetch "$remoteName" "$branchName"; git checkout "$branchName"; git branch; git log; cat myFile
     no error, but doesn't receive the "changed from repo2" commit
   • git fetch "$remoteName" "$branchName":"$branchName"; git checkout "$branchName"; git branch; git log; cat myFile
     gets the "changed from repo2" commit
10. clean before leaving :
    cd "$TMPDIR" && for workDir in "$repoOriginDir" "$repo2Dir"; do [ -d "$workDir" ] && rm -rf "$workDir"; done

when sitting on branchToRebase (i.e. it's the current branch) :

git rebase newBaseBranch

otherwise :

git rebase newBaseBranch branchToRebase

Rebasing (and merging) can lead to conflicts in one or more tracked files. This is usually no big deal : basically, it means 2 commits changed the same piece of code in distinct parts of the history (2 branches, or 2 commits being re-ordered) and Git doesn't know which is the "good" version.

You'll be warned of a conflict with a message like :

Auto-merging someFile
CONFLICT (content): Merge conflict in someFile
error: could not apply 4a7406f3... commitMessage
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 4a7406f3... commitMessage

1. fix the conflict in someFile + git add someFile + git rebase --continue. Congratulations : job done !
2. for some reason, you wish you never typed the git rebase command leading to the conflict. git rebase --abort is your "back to the past" ticket . You're out of trouble so far (no data lost), but you'll have to sort things out someday.
3. This 3^rd option — git rebase --skip — is a little bit tough : it will actually rebase as if the commit causing the conflict didn't exist. Consequently, this skipped commit won't be referenced anymore and seem lost. It's not lost anyway and can be recovered using git reflog.

git annotate is now obsolete, use git blame instead.

Revert "commitMessage of commitId"

	This reverts commit commitId.

git diff commitBeforeCommitId..commitId

outputs only the diff

git show commitId

outputs the commit(s) id(s) + author(s) + commit message(s) and the diff itself

git show otherBranch:myFile

This is equivalent to git checkout otherBranch && cat myFile, but better

origin	ssh://git@git.example.com:path/to/repository/name.git	(fetch)
origin	ssh://git@git.example.com:path/to/repository/name.git	(push)

• git remote add remoteName git@gitlab.example.com:path/to/repository/name.git
  origin is a very common remote name. Be careful to give explicit names to your remotes or you'll get lost sooner or later (consider renaming some remotes)
• git remote add remoteName ssh://bob@192.168.56.107/path/to/repository
  (details)

The new remote can even be a local directory (let's say the original repo is /path/to/original/repo/) :

If the remote repository is a directory (local, or mounted or whatever), its path should be declared as /path/to/repository/.git

1. list existing remotes
2. git remote rm remoteName

Since this will probably go to a new host, don't forget to update the SSH configuration.

git push -u remote localBranchName

• git diff olderCommitId newerCommitId path/to/file
• git diff olderCommitId..newerCommitId --color-words myFile

• on the current commit :
  • git tag -a tagName (opens editor for tag message)
  • git tag -a tagName -m 'tagMessage'
• on an other commit :
  • git tag -a tagName commitId -m 'tagMessage'

basic command :

Create + checkout :

Let's give this a try

Get the current Git branch in a shell script :

currentGitBranch=$(git branch 2>/dev/null | awk '/^\*/ {print $2}')
echo "$currentGitBranch"

random notes

PLAYING WITH LOCAL / REMOTE BRANCHES :

Setup playground :
	beforeDir="$PWD"; tmpDir='/run/shm'; workDir=$(mktemp -d --tmpdir="$tmpDir"); cd "$workDir"; mkdir local remote; cd local; git init


Create some commits :
	testFile='myFile'; for i in {A..C}; do echo $i >> "$testFile"; git add "$testFile"; git commit "$testFile" -m "$i"; done; git log --graph --oneline --decorate --all

* f8b2e6c (HEAD -> master) C
* e6f9346 B
* 33d5557 A


Clone into a remote repo and get 'master' branch :
	cd ../remote; git clone ../local .; git log --graph --oneline --decorate --all

* f8b2e6c (HEAD -> master, origin/master, origin/HEAD) C
* e6f9346 B
* 33d5557 A


And about our "remote" thing :
	git remote -v
	origin	/run/shm/tmp.fLG8SwT9fr/remote/../local (fetch)
	origin	/run/shm/tmp.fLG8SwT9fr/remote/../local (push)

	==> the 'local' directory is indeed known as 'origin'


Let's go back to the 'local' dir and create a new branch :
	branchName='my2ndBranch'; cd ../local; git branch "$branchName"; git checkout "$branchName"; git branch

	  master
	* my2ndBranch


And some more commits, on the branch this time :
	for i in {D..E}; do echo $i >> "$testFile"; git add "$testFile"; git commit "$testFile" -m "$i"; done; git log --graph --oneline --decorate --all

* 4aa931d (HEAD -> my2ndBranch) E
* 9ecdc9a D
* f8b2e6c (master) C
* e6f9346 B
* 33d5557 A


One more branch from 'master' :
	branchName='my3rdBranch'; git checkout master; git branch "$branchName"; git checkout "$branchName"; git branch

  master
  my2ndBranch
* my3rdBranch


And some commits :
	for i in {G..I}; do echo $i >> "$testFile"; git add "$testFile"; git commit "$testFile" -m "$i"; done; git log --graph --oneline --decorate --all

* 6e8b6e0 (HEAD -> my3rdBranch) I
* ebe9167 H
* 16be4e4 G
| * 4aa931d (my2ndBranch) E
| * 9ecdc9a D
|/
* f8b2e6c (master) C
* e6f9346 B
* 33d5557 A

==========================================

Now, what if I want to get ALL OF THIS on my remote repo ?

cd ../remote; git branch
* master

	==> only aware of 'master' so far.


Trying to simply pull the branch :
	git pull origin my2ndBranch; git log --graph --oneline --decorate --all

	* 4aa931d (HEAD -> master, origin/my2ndBranch) E
	* 9ecdc9a D
	* f8b2e6c (origin/master, origin/HEAD) C
	* e6f9346 B
	* 33d5557 A

	==> all my commits are there

But :
	git branch
	* master

	==> ooops!


Clean and retry :
	cd ..; rm -rf remote; mkdir remote; cd remote; git clone ../local .; git log --graph --oneline --decorate --all

* 6e8b6e0 (HEAD -> my3rdBranch, origin/my3rdBranch, origin/HEAD) I
* ebe9167 H
* 16be4e4 G
| * 4aa931d (origin/my2ndBranch) E
| * 9ecdc9a D
|/
* f8b2e6c (origin/master) C
* e6f9346 B
* 33d5557 A

But at the same time :
	git branch
		* master
		  my3rdBranch


	==> got it all because of 'clone'. Not what I wanted to do right now
	==> missing the 'my2ndBranch' branch, but commits seen to be there (WTF?!?)






Clean before leaving :
	cd "$beforeDir"; [ -d "$workDir" ] && rm -rf "$workDir"

==========================================
git log variants :

https://stackoverflow.com/questions/2421011/output-of-git-branch-in-tree-like-fashion#9726638
git log --graph --all --format='%C(cyan dim) %p %Cred %h %C(white dim) %s %Cgreen(%cr)%C(cyan dim) <%an>%C(bold yellow)%d%Creset'


https://stackoverflow.com/questions/2421011/output-of-git-branch-in-tree-like-fashion#answer-2421063
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset%n' --abbrev-commit --date=relative --branches

• an explicit date :
  git log --after='2019-03-29'
  When no time is specified, it defaults to 00:00:00 : the behavior (include / exclude commits) depends on whether you're asking for commits before or after this point in time.
• an explicit timestamp :
  git log --before='2019-03-29T13:40:00+01:00'
  • based on the ISO 8601 format
  • read this too
• relative dates :
  • git log --after='3 days ago'
    (looks like ago is optional)
  • git log --after='2 weeks 3 days 2 hours 30 minutes 59 seconds'

There is no such thing like "source" or "destination" branches when merging, but this reminds me of the new "arrow" that will be added to the commit tree :

before :

	      A---B---C feature
	     /
	D---E---F---G master

after git merge feature master :

	      A---B---C feature
	     /         ↘
	D---E---F---G---H master

• The order branch_A branch_B or branch_B branch_A matters in that it will replay commits of (the 1st one) onto (the 2nd one) since they diverged. This means the whole set of commits "lands" on (the 2nd one). This is important when it comes to deleting merged branches.
• destinationBranch can be omitted if it's the current branch :
  git merge sourceBranch
• git merge parameters are commit IDs (which is somewhat equivalent to branch names, since all of this relates to objects IDs anyway)
• Merging generates a new commit that has 2 parents (Except if the "destination" branch remained untouched since the creation of the branch. In such a case, a fast-forward merge will be performed automatically (source)).

1. delete the remote branchName
   • git push remoteName :branchName
   • or : git push -d remoteName branchName
     -d is an alias of --delete
2. delete the local branch :
   git branch -d fullyMergedBranch

Alternate workflow with GitLab & al. :

• record the current state of the working directory and the index, but want to go back to a clean working directory. git stash saves your local modifications away and reverts the working directory to match the HEAD commit.
• "move" uncommitted changes to another branch :
  1. git stash
  2. git checkout myOtherBranch
  3. git stash pop

• git stash save : create a new stash. Can be shortened to : git stash, which will create an "anonymous" stash with default options
• git stash list : list existing stashes
• git stash show : show the changes recorded in the stash as a diff between the stashed state and its original parent (see example below)
• git stash pop : remove a single stashed state from the stash list and apply it on top of the current working tree state (i.e. do the inverse operation of git stash save)
• git stash apply : like git stash pop, but do not remove the state from the stash list
• git stash clear : remove all the stashed states
• git stash drop : remove a single stashed state from the stash list. Defaults to the latest one if no stash ID is given (see example below)

1. List stashed content :
   git stash list

   stash@{0}: WIP on master: ce9100b a great commit message
   stash@{1}: WIP on master: 0765a47 another GREAT commit message
   stash@{2}: WIP on master: cfc2b09 this one is not as great as the others, but still good, though 

   stash@{0} is the latest stash.
2. List files affected by a single stash :
   git stash show 0

    someFile | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

3. View the actual changes made in the stashed content :
   git stash show -p 0
4. Discard stashed content :
   • the latest stash :
     1. git stash drop

        Dropped refs/stash@{0} (20f3a793f379e266cde2131e740591ae186fc188)		don't know (yet!) what this ID (commit ID?) refers to 

     2. git stash list

        stash@{0}: WIP on master: 0765a47 another GREAT commit message			decremented stash IDs
        stash@{1}: WIP on master: cfc2b09 this one is not as great as the others, but still good, though 

   • another stash :
     1. git stash drop 1

        Dropped refs/stash@{1} (6615a1409aa713cc8ec9a8c6a8277b19e06cacc7)

     2. git stash list

        stash@{0}: WIP on master: 0765a47 another GREAT commit message			decremented stash IDs

        There's only 1 stash left because I actually run both drop commands successively (latest stash + another stash) while writing this article.

Enumerating objects: 30475, done.
Counting objects: 100% (30475/30475), done.
Delta compression using up to 2 threads
Compressing objects: 100% (8783/8783), done.
Writing objects: 100% (30475/30475), done.
Total 30475 (delta 21751), reused 30115 (delta 21522)

Total 30475

total number of objects in the repository

(delta 21751) (1^st delta)

number of those total objects which are binary delta objects i.e. how many objects Git has decided have a strong similarity with other objects and can be stored as a binary delta.

reused 30115

how many objects from a compressed source (i.e. a packfile, see .git/objects/pack/*pack) are being used without having been recompressed to include more recent changes. This would occur when you have multiple packfiles but where a more recent SHA object refers to an item in an old packfile as its base, then applies deltas to it to make it modern. This lets Git make use of previously compressed older revisions of data without having to recompress it to include more recent additions. Note that Git may append to an existing pack file without rewriting the entire pack file

delta 21522 (2^nd delta)

?

• git config -l
• git config --list | grep configurationOption
• git config --get user.email
• git config --get-regexp user.*