Git - Miscellaneous

git

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?

git log

What protocol does git support?

  • local file like /path/to/repository
  • ssh
  • rsync
  • http

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 you@yourdomain.example.com

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.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License