git config --global user.name "Your Name" git config --global user.email "Your email address" git config -l // lowercase letter L, list config options. git init git add . git commit git diff revpath svn diff -rrev path git checkout path svn revert path git branch // list known branches. The current branch is marked with // an asterisk. svn list http://example.com/svn/branches/ git checkout rev git checkout prevBranchName svn update -r rev svn update git reset HEAD^ // Remove the latest commit from the staging area. // This will not change the working copy / tree. git show rev:path/to/file git show rev:path/to/directory git show rev svn cat url svn list url svn log -rrev url svn diff -crev url git tag -a name svn copy http://example.com/svn/trunk http://example.com/svn/tags/name git tag -l git show tag svn list http://example.com/svn/tags svn log -- limit 1 http://example.com/svn/tags/tag git branch branchName git checkout branchName svn copy http://example.com/svn/trunk http://example.com/svn/branches/branchName svn switch http://example.com/svn/branches/branchName With 'git merge', if there is no conflict, a commit is automatically with a convenient log message, or we can do 'git merge --no-commitbranch' to review the merge result and then do the commit yourself. git cherry-pick rev git merge -c rev URL In the clone's default setup, the default local branch tracks the origin remote, which represents the default branch in the remote repository. git checkout --track -b branchName origin/branchName svn switch url git fetch // fetch all the changes, but does not merge these changes into your // working copy. git log origin git log HEAD..origin // see just the changes that you do not have in your working copy. git pull // fetch and merge the tracking remote branch svn update git push remote // push all local branches with a corresponding remote branch git help log git diff --cached // see what is about to be committed. Without the --cached option, 'git diff' will show you any changes that you've made but not yet added to the staging area. git commit -a // will automatically add any modified (but not new) files to the // staging area, and commit, all in one step. It is a good idea to begin the commit message with a single short (less than 50 characters) line summarizing the change, followed by a blank line, and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body. We should push only to remote branches that are not currently checked out on the other side! Otherwise the working copy at the remote branch will get out of date and confusion will ensue. The best way to avoid that is to push only to remote repositories with no working copy at all, a so called bare repositories which are commonly used for public access or developers' meeting point, just for exchange of history where a checked out copy would be a waste of space anyway. You can create such a repository. Git can work with the same workflow as Subversion, with a group of developers using a single repository for exchange of their work. The only change is that their changes aren't submitted automatically but they have to push (however, you can setup a post-commit hook that will push for you every time you commit; that loses the flexibility to fix up a screwed commit, though). The developers must have either an entry in htaccess (for HTTP DAV) or a UNIX account (for SSH). You can restrict their shell account only to Git pushing/fetching by using the git-shell login shell. You can also exchange patches by mail. Git has very good support for patches incoming by mail. You can apply them by feeding mailboxes with patch mails to git am. If you want to send patches use git format-patch and possibly git send-email. To maintain a set of patches it is best to use the StGIT tool. git log git log -p // See complete diff at each step git log --stat --summary // See just the overview of the change git checkout branchName // switch the working copy to a local branch git merge experimental // merge changes from the local branch named // "experimental" into the working copy. gitk We can refer to the latest revision by HEAD, its parent by HEAD^, and its parent as HEAD^^ or HEAD~2 In Git, we can make commits on top of the older revision and use it as another branch.
How can a commit has more than one parent?
Not sure. https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html (search for "Note that merge commits may have more than one parent").
How can we give a commit a name?
You can also give commits names of your own; after running:
git tag v2.5 1b2e1d63ff
You can refer to 1b2e1d63ff by the name "v2.5". If you intend to share this name with other people (for example, to identify a release version), you should create a "tag" object, and perhaps sign it. See git-tag(1) for details.
$ git diff v2.5 HEAD # compare the current HEAD to v2.5 $ git branch stable v2.5 # start a new branch named "stable" based # at v2.5 $ git reset --hard HEAD^ # reset your current branch and working # directory to its state at HEAD^
How can we view project history?
What protocol does git support?
- local file like /path/to/repository
How can we specify a range?
Many Git commands also take sets of commits, which can be specified in a number of ways.
$ git log v2.5..v2.6 # commits between v2.5 and v2.6 $ git log v2.5.. # commits since v2.5 $ git log --since="2 weeks ago" # commits from the last 2 weeks $ git log v2.5.. Makefile # commits since v2.5 which modify # Makefile
What is the purpose of the colon syntax?
Most commands that take filenames will optionally allow you to precede any filename by a commit, to specify a particular version of the file:
git diff v2.5:Makefile HEAD:Makefile.in
How can we refer to different revisions?
# by name $ git log v1.0.0 # show history leading up to tag "v1.0.0" $ git log master # show history of branch "master" # relative to a name $ git show master^ # show parent to last revision of master $ git show master~2 # show grand parent to tip of master $ git show master~3 # show great grand parent to tip of master (you get the idea) # by output of "git describe" $ git show v1.4.4-g730996f # you get this string by calling "git describe" # by hash (internally, all objects are identified by a hash) $ git show f665776185ad074b236c00751d666da7d1977dbe $ git show f665776 # a unique prefix is sufficient # tag a revision $ git tag v1.0.0 # make current HEAD known as "v1.0.0" $ git tag interesting v1.4.4-g730996f # tag a specific revision (not HEAD)
You can refer to the latest revision by HEAD, its parent as HEAD^ and its parent as HEAD^^ = HEAD~2 (you can go on adding carrets), cut'n'paste helps a lot and you can write only the few leading digits of a revision - as long as it is unique, Git will guess the rest. (You can do even more advanced stuff with revision specifiers, see the git-rev-parse manpage for details.)
How can we see the differences between revisions?
# diff between two branches $ git diff origin..master # pipes a diff into PAGER $ git diff origin..master > my.patch # pipes a diff into my.patch # get diffstat of uncommitted work $ git diff --stat HEAD
Why does each git commit has a field for author and a field for committer?
Each commit has an author and a committer field, which record who and when created the change and who committed it (Git is designed to work well with patches coming by mail - in that case, the author and the committer will be different). Git will try to guess your realname and email, but especially with email it is likely to get it wrong. You can check it using git config -l and set them with:
git config --global user.name "Your Name Comes Here" git config --global user.email firstname.lastname@example.org
You can exchange patches by mail. Git has very good support for patches incoming by mail. You can apply them by feeding mailboxes with patch mails to git am. If you want to send patches use git format-patch and possibly git send-email.
How can we turn on color output?
Git can produce colorful output with some commands; since some people hate colors way more than the rest likes them, by default the colors are turned off. If you would like to have colors in your output:
git config --global color.diff auto git config --global color.status auto git config --global color.branch auto
What is the equivalent of the 'svn revert' command for git?
git checkout path
Can we have multiple commit messages for each commit?
Yes and No. You can specify the commit message using the -m parameter, but you can pass several -m arguments and they will create separate paragraphs in the commit message.
If you don't pass any -m parameter or pass the -e parameter, your favorite $EDITOR will get run and you can compose your commit message there, just as with Subversion. In addition, the list of files to be committed is shown.
And as a bonus, if you pass it the -v parameter it will show the whole patch being committed in the editor so that you can do a quick last-time review.