Git
Inhaltsverzeichnis
Basics
Git is a Distributed Version Control System (DVCS).
Local Operations
- Working directory
- Files where you work
- Staging Area
- Staged diffs are ready to be committed
- git repository
- Committed files
Config
- System (/etc/gitconfig)
- git config --system
- Global (~/.gitconfig)
- git config --global
- Repository (%WORKINGDIRECTORY%/.git/config)
- git config --local
Ignoring files
In workingdirectory:
vim .gitignore
core.autocrlf
git config --global core.autocrlf %value%
- true
- convert to CRLF on checkout and back to CR on commit:
commit checkout CRLF --> CR --> CRLF CR --> CR --> CRLF
- input
- convert CRLF to LF on commit:
commit checkout CRLF --> CR --> CR CR --> CR --> CR
- false
- don't change:
commit checkout CRLF --> CRLF --> CRLF CR --> CR --> CR
Working local
Clone existing Repository
git clone git://github.com/schacon/grit.git
- That creates a directory named "grit", initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version
git clone git://github.com/schacon/grit.git mygrit
- Creates "mygrit" directory instead of "grit"
Check Status
git status
Statusmeldung: Your branch is ahead of 'origin/master' by 1 commit. -> Lokal ist 1 commit mehr vorhanden als origin/master.
Show log
git logoder
gitk
git log --stat
Mit Zusammenfssung der Änderungen
Formatting output
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --pretty=format:"%h %s" --graph
Limit output
git log --since=2.weeks
git log --2
git log --pretty="%h - %s" --author=gitster --since="2008-10-01" --before="2008-11-01" --no-merges
Stage files
A modified file under version control can be staged with the command
git addor use
git gui
git add is also used to add new files to version control.
Commit files
git commit
git commit -m 'initial project version'
Remove files
git rm readme.txt
deletes the readme.txt file from working directory (file is really deleted) and from version control.
git rm --cached readme.txt
deletes the readme.txt file from version control, but not from working directory (file is still on filesystem).
Revert commits / Undo changes
git rebase -i
If the commit has not already been pushed, you can use git rebase -i
.
git revert
If you have pushed, you can use the command
git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
Most used options:
<commit>... Commits to revert. For a more complete list of ways to spell commit names, see gitrevisions(7). Sets of commits can also be given but no traversal is done by default, see git-rev-list(1) and its --no-walk option. -e, --edit With this option, git revert will let you edit the commit message prior to committing the revert. This is the default if you run the command from a terminal. --no-edit With this option, git revert will not start the commit message editor. -n, --no-commit Usually the command automatically creates some commits with commit log messages stating which commits were reverted. This flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits. In addition, when this option is used, your index does not have to match the HEAD commit. The revert is done against the beginning state of your index. This is useful when reverting more than one commits' effect to your index in a row.
examples:
git revert -n df0e043088eacb5e8854973c0d575158269af7ff Reverts exactly the commit df0e043088eacb5e8854973c0d575158269af7ff git revert HEAD~3 Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes. git revert -n master~5..master~2 Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any commit with the reverted changes. The revert only modifies the working tree and the index.
Working with Remotes
You must have cloned an existing Repository before working with remotes. See Clone existing Repository
Show remote repositories
git remote
git remote -v
Adding Remote Repositories
git remote add mic git@git-server:~mic/ishop-ap/mic-ishop-ap.git
Update repository
gets all changes from mic without merge:
git fetch mic
gets all changes from origin without merge:
git fetch origin
gets all changes from origin and merges to current branch (or master):
git pull origin
Pushing to Remotes
git push [remote-name] [branch-name]
git push origin masterPushes your master branch to your origin server
Inspecting a Remote
git remote show origin
Merging / Rebase
git merge
Typische Nutzung:git merge <commit>oder
git merge -m <msg> <commit>Im master:
git merge topic
macht aus: A---B---C topic / D---E---F---G master einen neuen Eintrag (H): A---B---C topic / \ D---E---F---G---H master
in case of conflicts
topic = theirs = remote version master = ours = local(current) version
git rebase
Im Gegensatz zu git merge 'kopiert' git rebase alle commits vom <source>
auf dem <target>
.
Und zwar ab dem commit, wo sie sich getrennt haben.
A---B---C branch (<source>) / D---E---F---G master (<target>) D---E---F---G---A'--B'--C' branch master
Rebase current branch on <target>
:
git rebase <target>
Rebase <source>
-branch on <target>
:
git rebase <target> <source>
Das Rebasen funktioniert nur lokal. Also, wenn man ein Branch aus dem Remote-Repository rebasen will, muss dieser Branch lokal vorhanden sein. Ansonsten diesen Branch lokal erstellen vor dem Rebase. Falls der Source-Branch fehlt, wird trotzdem rebased, allerdings ist man dann in keinem Branch, sondern in einem 'Commit' (Hashtag).
in case of conflicts
<target> = ours = upstream
Tagging
List tags
git tag
git tag -l '2.0.*'lists only tags matching '2.0.*'-pattern
Create tags
Annotated (recommended)
Are stored as full objects in the Git database. They’re checksummed, contain the tagger name, e-mail, and date, have a tagging message
git tag -a v1.4 -m 'my version 1.4'
Lightweight (eg. for temporary use)
like a branch that doesn’t change — it’s just a pointer to a specific commit
git tag v1.4-1
Tipps and tricks
Use stash
Stash: Verstauen. 'Versorgt' die aktuellen Änderungen in einer Schublade, um es später wieder hervorzunehmen. Nützlich, wenn man Änderungen hat, die man noch nicht committen will, aber kurzzeitig zu einem anderen Projekt bzw. Branch wechseln will.
Lists the stashes:
git stash list
Save your local modifications to a new stash, and run git reset --hard to revert them. Saves with message: 'no idea what i'm doing here':
git stash save no idea what i'm doing here
Remove a single stashed state from the stash list and apply it on top of the current working tree state:
git stash pop stash@{0}
Like pop, but do not remove the state from the stash list:
git stash apply stash@{0}
Remove a single stashed state from the stash list:
git stash drop stash@{0}
show changes:
git stash show stash@{0}
Use bisect
Bisect: halbiern. Für die Fehlersuche, gibt man an, wo der Fehler noch nicht existierte und wo es existiert. Bisect checkt immer den commit in der Mitte aus un man kann prüfen, ob der Fehler noch existiert. Durch wiederholtes halbieren findet man heraus, bei welchem commit der Fehler entstanden ist.
Start bisect
Usage:
git bisect start <bad> <good>
eg:
git bisect start project-new-db master git bisect start 4b0bd09e46901f3151b4e55b67b3365dd9032e33 d289be1b199c9126b01e98cbc0c4119151150513
or:
git bisect start git bisect bad (current version is bad) git bisect good 1.0.17 (1.0.17 was the last good version)
Bisecting
Deploy/Test the current version. If the bug still exist, use
git bisect bad
otherweise
git bisect good
Re-Deploy/Test the current version until you reached the end of bisecting.
Skip
If you cannot test, skip the current version using
git bisect skip
End
When you’re finished, you should reset your HEAD to where you were before you started:
git bisect reset