Git

manual

http://www.kernel.org/pub/software/scm/git/docs/
https://help.github.com/articles/pushing-to-a-remote/

cheatsheet

https://news.ycombinator.com/item?id=13178221

create a local repository

http://tiredblogger.wordpress.com/2009/11/09/creating-local-git-repositories-yeah-its-that-simple/

1)set up remote repository

mkdir ~/example.git
cd example.git/
git init --bare

2)push some content into repository

mkdir workspace
cd workspace/
git clone /Users/xyz/example.git
ls  # note example dir is automatically created.
cd example/ 
touch abc.txt
vim ./abc.txt 
git add ./abc.txt 
git commit -a -m "initial abc.txt"
git push -u origin master

3) on another place, you can verify via creating another git client and clone

git clone /Users/xyz/example.git
cat ./example/abc.txt

create remote repository

http://thelucid.com/2008/12/02/git-setting-up-a-remote-repository-and-doing-an-initial-push/

1) set up initial remote repository with login user xyz on example.com:

ssh [e-mail]  # ssh into example.com host with user name xyz.
mkdir my_project.git
cd my_project.git
git init --bare
git update-server-info # If planning to serve via HTTP
exit

2) push content of master branch in remote repository from a local pc.

cd my_project
git init
git touch readme.txt
vim readme.txt
git add readme.txt
git commit -m "My initial commit message"
git remote add origin [e-mail]:my_project.git
git push -u origin master

3) now you can clone the repository from any pc.

git clone [e-mail]:my_project.git
cd my_project

4) suppose you want to create another branch in remote repository from any pc.

mkdir test
cd test
git clone [e-mail]:my_project.git
cd my_project/
git branch hotfix
git checkout hotfix
vim ./readme.txt 
git commit -a -m "update with world"
git push -u origin hotfix

now remote repository has two branches: master and hotfix

5) suppose you want to cherry the changes in step 4 into master
you can continue work from step 2)

git pull
git branch -a # now it shows 3 branches, master, origin/master, origin/hotfix
git cherry-pick commit-id in step 4.

dropbox

quick commands

http://chrismiles-tech.blogspot.com/2011/03/git-sharing-with-dropbox.html#comment-form
http://stackoverflow.com/questions/827351/push-origin-master-error-on-new-repository

mkdir project3
cd project3
git init
git add .
git commit -m "1st commit"

mkdir -p ~/Dropbox/git/project3.git
git init --bare ~/Dropbox/git/project3.git
git remote add origin ~/Dropbox/git/project3.git/
git push origin master

// on another computer
git clone ~/Dropbox/git/project3.git/

approach 1 : set up local repository and clone to dropbox

1. set up local project repository first

cd project1
git init .
git commit -am "Initial Commit"

2. clone your existing local repo into the shared dropbox folder:

we already have ~/Dropbox/git exists.

git clone --bare . ~/Dropbox/git/project1.git

the above command will create the project1.git automatically. The —bare option tells git to not include the project files. Only those files
needed to track the versioning are cloned (mainly those present in the .git/ folder).

git remote add dropbox ~/Dropbox/git/project1.git

3. push content to dropbox

git push dropbox master

4. you (or others) clone from dropbox on other computers

git clone ~/Dropbox/git/project1.git

If they want to have a dropbox remote instead of the default origin:

git remote add dropbox ~/Dropbox/git/project1.git

They would then push the same way:

git push dropbox master

5. you can get updates from others

git pull dropbox master

approach 2: set up dropbox repository and clone to local

1. set up the dropbox repository first

cd ~/Dropbox
mkdir -p git/home.git
cd home.git/
git init --bare

2. map repository into local

http://stackoverflow.com/questions/2411031/git-how-do-i-clone-into-a-non-empty-directory

cd ~
git clone --no-hardlinks --no-checkout ~/Dropbox/git/home.git/  ~/a.tmp
mv ~/a.tmp/.git ~
git reset HEAD
rm -rf ./a.tmp

3. add home directory files into repository

git add ./.tmux.conf 
git commit -a -m "add .tmux.conf file"
git push origin master

4. pull the same setting files from another computer

repeat the same step 2 and then do a pull

git pull

quick cheatsheet

rebase vs merge

which branch should change, i check out that branch.

feature rebase on master
master merge into feature.

you can rebase the feature branch onto master branch using the following commands:

git checkout feature
git rebase master

Or, you can condense this to a one-liner:

git rebase master feature

But, instead of creating a merge commit on feature, rebasing re-writes the project history by creating brand new commits for each commit in the feature branch.

The easiest option is to merge the master branch into the feature branch using something like the following:

git checkout feature
git merge master

Or, you can condense this to a one-liner:

git merge master feature

This creates a new “merge commit” in the feature branch that ties together the histories of both branches

fast-forward

you can fast-forward the master branch into feature:

$ git checkout master
$ git merge feature

• compare two branches

The .. syntax is a very useful tool for comparing branches. The next example displays a brief overview of all the commits that are in some-feature branch that are not in master.
git log —oneline master..some-feature

• git reset

https://www.atlassian.com/git/tutorials/undoing-changes/git-reset

You should never use git reset <commit> when any snapshots after <commit> have been pushed to a public repository. you have to assume that other developers are reliant upon it.

• Cloning and Creating a Patch

https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/

$ git clone git://github.com/git/hello-world.git
$ cd hello-world
$ (edit files)
$ git add (files)
$ git commit -m 'Explain what I changed'
$ git format-patch origin/master

• Creating and Commiting

$ cd (project-directory)
$ git init
$ (add some files)
$ git add .
$ git commit -m 'Initial commit'

http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png

undo

—soft – The staged snapshot and working directory are not altered in any way. useful for quashing commits(though you can use rebase). refer: http://tednaleid.github.io/understanding-git/
—mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.
—hard – The staged snapshot and the working directory are both updated to match the specified commit.

a file has been accidentally committed.

git checkout HEAD~ path/to/file
git commit --amend

understanding GIT http://www.eecs.harvard.edu/~cduan/technical/git/
GIT magic https://docs.google.com/View?id=dfwthj68_675gz3bw8kj&pli=1
Quick tutorial : http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

http://www.itpub.net/forum.php?mod=viewthread&tid=1817372

rollback to the version in staging area:
  git checkout -- file.txt file2.txt

rollback staging area to the version in commit
  git reset -- file.txt file2.txt

rollback both working and staging area to a version of a commit
  git checkout HEAD file.txt
  or
  git checkout master~2 file.xe
  or 
  git reset --hard HEAD 

git diff   file.txt       compares what is in your working directory with what is in your staging area

git diff --staged.   see what you’ve staged that will go into your next commit, it compares your staged changes to your last commit:
git diff --cached file.txt     see what you’ve staged so far (--staged and --cached are synonyms):

git diff file.txt HEAD   working area vs HEAD

git diff sha1 sha2        diff two commits.

If you run git difftool instead of git diff, you can view any of these diffs in software like emerge, vimdiff and many more

git commit --amend -C HEAD   // update last commit

git rm --cache a.txt // remove file stage area but keep local copy in working area

refs and heads

1)

refs/heads/master
refs/heads/test

.git/HEAD is symbol link to either of them when you switch branch

2) if there is a master branch on the remote repository you can access the log of that branch locally via

$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master

They’re all equivalent, because Git expands each of them to refs/remotes/origin/master.

normally. refs/remotes/origin/HEAD points to refs/remotes/origin/master

3)
https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
To pull the master branch on the remote down to a different name as origin/mymaster locally, you can run

$ git fetch origin master:refs/remotes/origin/mymaster

because the default it is : refs/heads/master:refs/remotes/origin/master

to push a branch to remote with a different name:

git push origin master:refs/heads/qa/master

because the default is: git push origin master

http://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing/15398512#15398512
https://sites.google.com/site/lightrush/random-1/howtoautomaticallyfixremovetrailingwhitespaceingitviaapre-commithook

git rev-parse —git-dir
http://stackoverflow.com/questions/12293944/how-to-find-the-path-of-the-local-git-repository-when-i-am-possibly-in-a-subdire

#!/bin/sh

if git rev-parse --verify HEAD >/dev/null 2>&1 ; then
   against=HEAD
else
   # Initial commit: diff against an empty tree object
   against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

IFS='
'

files=$(git diff-index --check --cached $against -- | sed '/^[+-]/d' | perl -pe 's/:[0-9]+:.*//' | uniq)
for file in $files ; do
    sed -i 's/[[:space:]]*$//' "$file"
    git add $file
done

#!/bin/sh

if git rev-parse --verify HEAD >/dev/null 2>&1 ; then
   against=HEAD
else
   # Initial commit: diff against an empty tree object
   against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

IFS='
'

files=$(git diff-index --check --cached $against -- | sed '/^[+-]/d' | perl -pe 's/:[0-9]+:.*//' | uniq)
for file in $files ; do
    diff=$(git diff --cached $file)
    if test "$(git config diff.noprefix)" = "true"; then
        prefix=0
    else
        prefix=1
    fi
    echo "$diff" | patch -R -p$prefix
    diff=$(echo "$diff" | perl -pe 's/[ \t]+$// if m{^\+}')
    out=$(echo "$diff" | patch -p$prefix -f -s -t -o -)
    if [ $? -eq 0 ]; then
        echo "$diff" | patch -p$prefix -f -t -s
    fi
    git add $file
done

sudo cp ~/.git/hooks/pre-commit /usr/share/git-core/templates/hooks/
sudo chmod 755 /usr/share/git-core/templates/hooks/pre-commit

uncommit and recommit

Undo a commit and redo

$ git commit … (1)
$ git reset —soft 'HEAD^' (2)
$ edit (3)
$ git add …. (4)
$ git commit -c ORIG_HEAD (5)

you can use $git show ORIG_HEAD to show details of the commit. ORIG_HEAD is a file inside .git

patch

suppose I fixed something on dev branch and others are working on release branch.
i need to create the patch on dev and against master

git format-patch release —stdout > fix.patch

NOTE, on gitk, to form this patch, the from will be release branch, the to will be dev. (to is the branch has the fix.)

then others on release branch or any other branch that is based on the HEAD of release branch can apply the patch:
check first:
git apply —check fix.patch
git apply —check fix.patch

rebase

suppose you have two branches topic and master, and you would like to pick up changes from master.

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

              A'--B'--C' topic
             /
D---E---F---G master

git rebase --onto <graft-point> <exclude-from> <include-from>

<graft-point> is the new base or the branch to rebase with.
<exclude-form> <include-form> defines the range of elements of (A B C)

If you don’t specify —onto, <graft-point> defaults to <exclude-from>
If you don’t specify an <include-from>, <include-from> defaults to the current branch.

now you can rebase with each approach:
*) on any branch, run git rebase —onto master master topic
*) on branch topic ru: git rebase master

Recommended approach to keep commits of A B C since they lost after the rebase:
1) git branch -b topic-rebased topic
2) git rebase master
NOTE: it is also recommend to add parameter git rebase —preserve-merges

now you can use topic-rebased. the final chart is :

              A'--B'--C' topic-rebased
             /
D---E---F---G master
     \
      A---B---C topic

to abort the rebase:

git rebase --abort

http://matthew-brett.github.io/pydagogue/rebase_without_tears.html

if there is conflict, resolve them and commit, thenresume with

 git rebase --continue

complicated case:
from:

                       H---I---J topicB
                       /
              E---F---G  topicA
             /
A---B---C---D--K  master

to:

             H'--I'--J'  topicB
            /
            | E---F---G  topicA
            |/
A---B---C---D--K  master

how to identify <exclude-form> <include-form>?
it should define (H, I, J)
thus, the form is git rebase —onto master topicA topicB

rebase to re-organize commit

git rebase -i master~3

Note master~3 commit won't be included in the set of commits(master~2, master~1, HEAD) to be reorganized.

show

show files in staged area.

git ls-files --stage

compute SHA1 of a file

 git hash-object  file

show a specific version of file

git show master~2:c.txt

notice git cat-file only shows repository object file content in .git directory, but the actual file

git cat-file -p 3b18e512d

look up objects by a unique prefix of the object hash

git rev-parse 3b18e512d

then git will print the long SHA1 : 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

git log

git log --graph --pretty=oneline --abbrev-commit

it shows a nice text graph

merge

with regard to merge, Git computes a merge result and creates a new commit that represents the new unified state.

The git merge operation is context sensitive. Your current branch is always the target branch, and the other branch or branches are merged into the current branch.
for instance, merge dev branch into release branch

git checkout release
git merge dev

local storage:
.git/MERGE_HEAD: the tip of the other branch is temporarily recorded in the symref MERGE_HEAD.
.git/MERGE_MSG: contains the default merge message used when you git commit after resolving the conflicts.

resolve conflicts

list commit-1 on branch-1 vs commit-2 on branch-2 and the conflict.

git log --merge --left-right -p file-x

diffs

git diff --ours  == git diff HEAD

because it shows the differences between “our” version and the merged version. Similarly,

git diff --theirs == git diff MERGE_HEAD
git diff --base to see the combined set of changes since the merge base.

If you have botched a conflict resolution and want to return to the original conflict state before trying to resolve it
again, you can use the command

git checkout -m file-x

if you have not commit the merge, you can undo it via:

 git reset --hard HEAD

if you have committed the merge, you can undo as:

git reset --hard ORIG_HEAD

patch

generic linux diff and patch

for file:
diff -uN file new-file > patch.file

for directory:
diff -uNr dir new-dir > patch.dir

-r to recurse through all subfolders of the passed folders
-u to get the “unified format” output
-p prints the c-function a change was contained in
-N treats absent files as empty

apply patch:
patch -p1 < patch.file
patch -p1 < patch.dir

git patch

suppose you create a bugfix branch to fix something, then on the bufgix branch:
(others are working on release branch).

i need to create the patch on bugfix and against release

git checkout bugfix

git format-patch release —stdout > fix.patch
or
git diff release > fix.patch (press q to exit)

NOTE, on gitk, to form this patch, the from will be release branch, the to will be bugfix . (to is the branch has the fix.)

then others on release branch or any other branch that is based on the HEAD of release branch can apply the patch:
check first:
git apply —check fix.patch
git apply —check fix.patch

usage

to use git patch for patch command:
option-1) if the git patch is generated without special instructions, patch -p1 is required.

$ git diff > save.patch
$ patch -p1 < save.patch

option-2)

git diff --no-prefix > diff.patch
patch -p0 < diff.patch

git remote push, pull

http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/
http://dotnet.dzone.com/articles/intro-git
http://reinh.com/blog/2008/04/18/git-push-just-the-tip.html
https://www.kernel.org/pub/software/scm/git/docs/git-push.html#_examples

rebase vs merge

http://mettadore.com/analysis/a-simple-git-rebase-workflow-explained/

http://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase

git and repo

http://blog.csdn.net/qxb1229/article/details/8664856

window

gitk —all
git mergetool

update an old change

http://blog.jacius.info/2008/06/22/git-tip-fix-a-mistake-in-a-previous-commit/

http://git-scm.com/book/ch6-4.html
http://sethrobertson.github.io/GitFixUm/fixup.html#change_single_deep_simple

http://nakkaya.com/2009/09/24/git-delete-last-commit/

git stash

git stash save "your message here"
git stash apply -–index stash@{0}
git stash list

basic concepts

Here, master is a branch in the local repository. remotes/origin/master is a branch named master on the remote named origin. You can refer to this as either origin/master, as in:
remotes/origin/head or refs/remotes/origin/master

refs/heads/master The HEAD is "your current branch", or the branch to which Git will commit. S
https://people.gnome.org/~federico/news-2008-11.html#pushing-and-pulling-with-git-1

unmerge

http://www.deferredprocrastination.co.uk/blog/2012/git-un-merge/

git clean -f
This will remove all untracked files.
Good basic tutorial
http://rypress.com/tutorials/git/distributed-workflows.html

http://git-scm.com/book/en/Git-Tools-Rewriting-History
git rebase –I HEAD~3
When you save and exit the editor, Git rewinds you back to the last commit in that list. You can check with: git log —oneline:

http://rypress.com/tutorials/git/rewriting-history.html

remotes

git remote very clear explained

http://consttype.org/gitnotes.html well explained

It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new serverfix branch — you only have an origin/serverfix pointer that you can’t modify.
To merge this work into your current working branch, you can run git merge origin/serverfix. If you want your own serverfix branch that you can work on, you can base it off your remote branch:
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

Inspect remotes:

http://git-scm.com/book/en/Git-Basics-Working-with-Remotes

git remote show origin
git remote –v
git remote –r

repo

repo commands:

https://github.com/yasuaki/repo-help-ja

repo list projects:

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/xBtwK0RqRws
https://github.com/yasuaki/repo-help-ja/blob/master/repo-list.txt

repo —trace

Check repo —trace rebase . — I just ran this locally on autotest and

https://github.com/yasuaki/repo-help-ja/blob/master/repo-rebase.txt

a simple work flow

http://mettadore.com/analysis/a-simple-git-rebase-workflow-explained/

http://makandracards.com/makandra/5531-git-move-a-commit-between-repositories

In the source repository, create a patch based on the commit by running
git format-patch SHA1_OF_COMMIT~..SHA1_OF_COMMIT
(note the ~).
This will create a .patch file that describes this commit.

Apply the patch
In the target repository, apply the patch with
git apply PATH_TO_PATCH

If the patch does not apply cleanly, git will not do anything. If you want it to apply as much as possible, use
git apply PATH_TO_PATCH –reject

The parts that could not be applied cleanly end up in .rej files. Take care of those manually.