• Edit
  • Delete

git Cheat Sheet

Commit all changes

  • git commit -a -m 'blabla'

Overwrite local repo with all changes from master

WARNING: all local changes are lost!

  • git fetch --all
  • git reset --hard origin/master

A single file:

  • git checkout origin/master myfile.txt

Pull and Rebase

  • git config branch.*branch-name*.rebase true
    • or
  • git config branch.autosetuprebase always

eGit:

  • Open the Git Repositories view and navigate to the local branch
  • Open the context menu and select Configure Branch...
  • In the resulting dialog, select the Rebase checkbox

.gitignore does not work

  • commit changes or you'll loose them with the next command
  • git rm -rf --cached .
  • git add .
  • git commit -m "fixed untracked files"

Unstage

git rm --cached is used to remove a file from the index. In the case where the file is already in the repo, git rm --cached will remove the file from the index, leaving it in the working directory and a commit will now remove it from the repo as well. Basically, after the commit, you would have unversioned the file and kept a local copy.

git reset HEAD file ( which by default is using the --mixed flag) is different in that in the case where the file is already in the repo, it replaces the index version of the file with the one from repo (HEAD), effectively unstaging the modifications to it.

In the case of unversioned file, it is going to unstage the entire file as the file was not there in the HEAD. In this aspect git reset HEAD file and git rm --cached are same, but they are not same ( as explained in the case of files already in the repo)

Git Config

Homedir

vi /home/katinga/.gitconfig

  • [credential]
        helper = cache --timeout=36000
    
    [user]
        name = Katinga Humbuwatso
        email = katinga@ull.at

Cache Credentials

  • git config --global credential.helper "cache --timeout=36000"

Accept Self Signed Certificates

  • git config --global http.sslverify false

Switch branche

  • git checkout branchname

Merge dev into master

I generally like to merge master into the development first so that if there are any conflicts, I can resolve in the development branch itself and my master remains clean.

In the dev branche

  • git pull

  • git merge origin/master -m "merged changes from master"

  • git checkout master (switch to master)

  • git merge --no-ff development (create a separate commit nore to find out later, who did the actual merge to master and at which time)

Create patch files from range of commits

git format-patch 58ce949^..926dc87

git format-patch --stdout 58ce949^..926dc87 > patch1.patch

Apply patches

  • git am *.patch   -> no fuzzy (solution: "-3" option)
  • If that does not work:
    • Revert patch with
      • git am --abort
    • And try
      • git apply -3 xxx.patch
    • Resolve conflicts manually