My Wiki!

Git quick refs

1. Workflow

https://deltaspike.apache.org/suggested-git-workflows.html

1.1 Update after long time - merge theirs

https://stackoverflow.com/questions/10697463/resolve-git-merge-conflicts-in-favor-of-their-changes-during-a-pull

  git pull -s recursive -X theirs <remoterepo or other repo>

Or, simply, for the default repository:

git pull -X theirs

If you're already in conflicted state…

git checkout --theirs path/to/file

1.2 Avoid git-pull!

git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master. This will always lead to some dirty artifacts in the commit history:

Merge branch 'master' of http://git-wip-us.apache.org/deltaspike into master

1.3 git pull --rebase

An easy version for getting rid of the auto-merges is using

$ git pull --rebase

Please note that this sometimes trashes your working tree if there are unmergeable files around. Cleaning this up with a forced manual rebase is not something we would recommend for a git beginner.

Working in an own branch

This is actually the suggested way to prevent auto-merges.

Create an own branch where you do your feature work. Either do all your work in one branch or create one branch per feature you are working on.

 $ git branch mybranch

After you finished your feature, git-add and git-commit your work. Check with git-status that you don’t have any dirty files and uncommitted changes around. You can use git-stash to 'backup' unfinished work.

Then switch back to the master branch and pull changes done by other committers in the meantime.

$ git checkout master
$ git pull --rebase

You should now get all the changes done by other committers and the will get applied to your local master branch. Now go back to your private branch and rebase your locally performed work to the HEAD of master.

$ git checkout mybranch
$ git rebase master

If you got conflicts, you will get lines with “

>>>>" added to those files. Resolve those conflicts manually, add them and finish the rebase.

Check with git-status and gitk if the merge went well and the history now contains your changes. If all is well, go back to the master branch and merge your changes in.

$ git pull --rebase     // (just for safety, you should see no changes)
$ git checkout master
$ git merge mybranch

Finally you can push your changes to the ASF git repo

$ git push

2. Untrack already commited files

Make appropriate changes in .gitignore
This command will cause git to untrack your directory and all files under it without actually deleting them:

  git rm -r --cached <your directory>

The -r option causes the removal of all files under your directory.

The –cached option causes the files to only be removed from git's index, not your working copy. By default git rm <file> would delete <file>

Branch and merge

http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging

Checkout all repo

look at this: http://stackoverflow.com/questions/67699/how-do-i-clone-all-remote-branches-with-git

Checkout folders, Sparse checkout

https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository

You can combine the sparse checkout and the shallow clone features. The shallow clone cuts off the history and the sparse checkout only pulls the files matching your patterns.

git init <repo>
cd <repo>
git remote add origin <url>
git config core.sparsecheckout true
echo "finisht/*" >> .git/info/sparse-checkout
git pull --depth=1 origin master

You'll need minimum git 1.9 for this to work. Tested it myself only with 2.2.0 and 2.2.2.

This way you'll be still able to push, which is not possible with git archive.

Git diff

Diff branches

This is important to see what branch (from master) is different from that branching point.

  git diff master..branch

Diff Files:

git diff mybranch master -- myfile.cs

Or, equivalently:

  git diff mybranch..master -- myfile.cs

Git diff HEAD, staged (cached), unstaged

git diff

Shows the changes between the working directory and the index. This shows what has been changed, but is not staged for a commit.

git diff –cached

Shows the changes between the index and the HEAD (which is the last commit on this branch). This shows what has been added to the index and staged for a commit.

git diff HEAD

Shows all the changes between the working directory and HEAD (which includes changes in the index). This shows all the changes since the last commit, whether or not they have been staged for commit or not.

GUI

In git dir run:

  diffuse -m

Git diff readability

To improve readablity

  git diff --word-diff master..origin/denis
  git diff --color-words

On Linux is possibly apt get install colordiff or something like that, depending on your distro.

Then:

 $ git difftool --extcmd="colordiff -ydw" HEAD^ HEAD

Or create an alias

$ git alias diffy "difftool --extcmd=\"colordiff -ydw\""

Then you can use it

 $ git diffy HEAD^ HEAD

I called it “diffy” because diff -y is the side-by-side diff in unix. Colordiff also adds colors, that are nicer. In the option -ydw, the y is for the side-by-side, the w is to ignore whitespaces, and the d is to produce the minimal diff (usually you get a better result as diff)

Commit existing project as submodule

do not do this

Subdirectory Checkouts with git sparse-checkout

http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/

Trace: • maven • vim_as_a_python_ide • crosstools • systemd_debug_log • 02_restful • firewalld • latex_quick • jpa • rcp_jetty • git_short

Table of Contents