trunk is called master SHA1-Hashes as Revisionnumber, 40 hexdecimal digits
- known as ref (git term)
- prefix of 7 digits should be enough
- commits refer the whole project not just one file file or directory as in svn
remote - upstream repository, hosted on the internet or network, ensuring all your changes are available for other developers local repo - a subdirectory named .git that contains all neccessary files of your repository index - holds a snapshot of your working tree. workspace - local checkout stash - a cache of your local changes.
Usually there is still a central place, where everyone can synchronize with. This is called “origin”. Git is a distributed version control system, that means, everybody has its OWN local working copy of the whole repository and you can do, whatever you want with it.
show config: git config –list get a certain config parameter git config –get option use –get-all if there are more than one parameter for one option unsetting a option git config –unset option git config –unset-all option distinguish config parameter global and repository-local Global config are saved under $HOME/.gitconfig local config are saved under .git/config First of all, you’ll probably want to set your name and email for git: git config –global user.name “Mario Bielert” git config –global user.email “mario.bielert@tu-dresden.de” (or in a specific repository without –global to set it for the this git repository) git config color.ui “auto” what can be configured? man git commit
If you tired of typing, like me, you can also create aliases inside git. For instance I’ve got: git config alias.st status So I just have to type “git st” instead of “git status”.
.gitignore file can be placed in every directory of the project one entry per line empty lines and lines beginnig with ‘#’ will be ignored entries ending with ‘/’ will handled as directory entries beginning with ‘!’ will negated shell globs
git init
| Remote | LocalRepo -> | Committed | Index | Stash | LocalChanges (untracked) |
You can view the state of the hole repository at any time. git status this will show you, the state of your index files and modifications that are staged and waiting to be committed. Modified files, files with local changes. The file is already under version control but these secific changes are not. Untracked files, files that are in the sense of the filesystem in the repository but git doesn’t care about.
If you want to know who does a specific change you can use git blame file git blame knows a lot of commandline switches. Please see the manpage here. Good example might be git blame -L 1,3 file #the part between the first and third line The -L switch works also with regular expressions git blame -L foo, bar file # from the first occurence of foo to the first following occurence of bar git blame -L /foo, +3 file # from the first occurence of foo and the next 3 lines
You can view the history of your repository/current branch with git log Command to view the hole commit tree pretty branch graphs
local copy are always a complete repository complete history of every branch, not just current state Getting a local copy of a remote repository git clone URL Where URL is defined as: protocol://host[:port]/path/to/repository If you clone a Repository you always get a copy of the whole repository contains the complete revision history. For cloning just a few commit e.g to contribute a bugfix use the –depth option git clone –depth=42 URL #just clone the last three commits After clone git checks the HEAD revision of the repository automatically out
The index is a snapshot of the working tree to trace changes that should be committed. Changing the index is also known as staging. A commit adds the state of the index to the repository. Adding a file to the index git add file After git add the file or directory (with all underlying files) are under version control. You can use git commit file dir/ to commit files that are already under version control direct to the repository - no staging necessary If you want to commit all changes from files that are under version control directly you can use git commit -a Just adding certain changes to the index git add –patch file or git add -p file In Patch modus changes are processed hunk-wise. Where a hunk is a peace of a file surrounded by unchanged lines (Context) Interactive staging git add –interactive
files, directories, or symbolic links can be moved with git mv foo bar/foo
- do not lose the history
- changes considered in the index and in the local working copy
If git rm is called without the –cached parameter the file or directory is deleted in the index and from filesystem. If –cached is given it’s just deleted from the index git rm file git rm –chached file git rm -r dir/
To commit the changes in the index git commit or git commit -m “commit message”
To commit all changes at once (without adding them before) git commit -a
To change the last commit git commit –amend
Using git reset to throwing away Reset the HEAD Pointer to a commit before without delete the newer commit git reset commitId If you just want to jump one commit backwards use git reset HEAD~1
To save the index and modified files while you goes backwards through your commits git reset –soft HEAD~1
If you want to delete all commits with there changes until a certain commit git reset –hard HEAD~1
If you want to delete commit and index but not the filesystem you can use git reset –mixed HEAD~1
If you want to bring one single file to a state of a certain commit git checkout [commitid] filename
To delete a specific commit, and his changes from revision history git revert commitid Attention SVN-Users!!! svn revert is equivalent to git checkout
Once we all are familiar with git, we should consider to switching to git-flow git-flow
To change the history of a branch is something powerful but maybe also dangerous. To merge, change, alter commits use git rebase. git rebase –interactive HEAD~5 #alter the last five revisions possible action’s when rebasing commits: pick - retain commit squash - merge with the commit before edit - let’s you change the selected commit from the filesystem after that you stage them and change the commit with git commit –amend and continue rebasing with git rebase –continue To delete a certain commit, just delete the line of the commit
With stashes you are able to cache local changes. If you need a clean workspace e.g. to switch in an other branch this may be very useful. Stashes are organized as a stack. To create a stash it is enough just to say git stash This will store every uncommitted changes you’ve done. you can give it a description (normally last commit message) git stash save “before bugfix” to keep also already staged changes use git stash –keep-index You can list all your stashes with git stash list the output contain the name of the stash, the branch where the stash was created from and the stash message Display a certain stash git stash show if no stash is specified, git use the first form the top of the stack With the following, you can reapply them: git stash apply will reapply the stash from the top of the stack git stash pop same as git stash apply but remove the stash from the list If you has stored stashes with –keep-index you must reapply them with git stash apply –index to reapply the index correctly It is also possible to reapply an stack in a new branch, this branch comes from the revisionbranch where the stack was created. git stash branch branchname # takes the top of the stash stack git stash branchname stash@{0} # take a specific stash entry To delete stashes you can use git stash drop # will delete the stash from the top of the stack git stash drop stash@{0} # will delete a certain stash or delete all stashes git stash clear
A tag is a symbolic name for a commit. You can use tags to refer a commit also from other commands. Create a Tag to the current HEAD git tag -a tagname or git tag -a tagname commitid If a tag name already exists you can override them by using the -f parameter. You can append a short description to the tag. This is really useful e.g. to list the new features of the release. This can be happen with the -m parameter to add the description direct from the commandline. git tag -a tagname -m “this is a relly important commit” or you can also read the description from a file using -F as parameter. git tag -tagname -F relase/1.0/notes.txt If you neither using -m or -F git will open your configured editor where you can place your tag description. To delete a tag use git tag -d tagname To list all existing tags: git tag you can filter the result with git tag -l pattern or to display all commits that conatins a certain commit git tag –contains commitid
Its also possible to sign tags with your pgp key using the -s parameter. If you want to use an other keyid for signing then you can use the -u parameter. And verify the signed tag with git verify-tag signedtagname
The Remote is something often named “origin” which is usual a bare repository where you ‘pull’ from and ‘push’ in. It represents the remote site of your repository.
Getting a repository git clone url [folder]
Updating your local repository with the remote repository git pull remote branch
Putting your local updates to the remote repository git push remote branch
You can also maintain more than one remote of your repository (for example to provide mirrors on different plattforms e.g. github) git remote show
See detail of a certain remote git remote show remotename
(set upstream foo)
List all branches git branch Create a new branch git branch branchname or git checkout -b branchname Change to a certain branch git checkout <branchname> Delete a certain branch git -d my_merged_branch
If you’re not satisfied with an uncommitted change, you can use: git checkout some_file.ext to undo your changes, similar to “svn revert”.
Git really favours branching and I endorse you, to do so. The idea is, that every time you want to change something, you’ll create a branch of master for your own. You should consider this branch private and shouldn’t push it to origin. Then you’ll work on this branch, until you’ll be done. When you’ll merge your changes back to the master branch. So a typical workflow would be:
- Create a new branch of master branch and check it out
git checkout -b my_cool_feature
- Do whatever you have to do, commit it in a regular fashion
git add … git commit
- If there was several commits to master since you’ve branched of it, it’s time to get those changes
git pull git rebase master
- Merge your changes back to master
git checkout master git merge my_cool_feature
(Note: You could also rebase master on your branch, both methods have their own pros and cons. Simply stick to merge for now.)
- Push your changes of master to origin
git push
(You might have to type the full commands once: git pull origin master git push origin master )
Changes in the working tree not yet staged for the next commit git diff Changes between the index and your last commit; what you would be committing if you run “git commit” without “-a” option. git diff –cached Changes in the working tree since your last commit; what you would be committing if you run “git commit -a” git diff HEAD