From The Mana World
(Maybe this is becoming way too much text...)
 
Line 25: Line 25:
=== Pushing ===
=== Pushing ===


Once you have committed some stuff, you can push these to the repository on Gitorious using <code>git push</code>. This works since by default the push command pushes to a ''remote'' called ''origin'', and this remote is automatically set up when you clone. However, the push will fail if there have been commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).
Once you have committed some stuff, you can push these to the repository on Gitorious using <code>git push</code>. This works since by default the push command pushes to a ''remote'' called ''origin'', and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).


=== Pulling ===
=== Pulling ===

Revision as of 19:48, 11 November 2008

This page provides some information about our switch to git (which we're slowly trying to make, starting with the tmwserv project). As an initial comforting note, git really isn't so complicated as some people would have you believe. A few months ago I became familiar with distributed version control by using Mercurial, and since a few weeks we're using git at work. I think we'll benefit a lot from switching to it on the long run.

The primary repository

With git, everybody has his own repository. But of course we will keep a central repository through which we cooperate. This central repository is currently hosted at gitorious.org, a friendly website that is also open source. It uses ssh's private/public key authentication for identifying committers.

On Gitorious you can have multiple repositories for each project. The main one (and I suggest we keep just one for the moment) is called mainline. Once you click to the mainline repository, you can see several ways to clone it (the new 'svn checkout'). For development purposes you should clone the "Push url", but this requires that you have:

  1. Signed up to gitorious.org
  2. Generated a private/public ssh keypair (if you haven't got this already)
  3. Filled in your public key in your account details on Gitorious

Working with git

Commit

From now on, a commit is something you do locally. Others won't see your change on Gitorious unless you push it there. You'll notice committing is very fast, and you can commit multiple times before you decide to push. You can also make corrections to your last commit.

Before you start committing, it is important to identify yourself to git, so that it can include the correct authorship information with your commit. You are no longer identified with a username, as was the case with Subversion. You can read exactly how to do this, as well as other useful information geared towards people switching from Subversion, on this page:

Pushing

Once you have committed some stuff, you can push these to the repository on Gitorious using git push. This works since by default the push command pushes to a remote called origin, and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).

Pulling

When you want to get the latest changes from the repository on Gitorious, you generally use git pull. However, note that this command does not work when you have local changes. Also, when you have local commits, the pull command will generate a merge commit (and before that you may have to resolve some conflicts).

If you don't want to create merge commits, but would rather stack your local commits on top of any incoming commits, you should use git pull --rebase. This rebases your local commits on top of the incoming ones. You should never do this when you have pushed these commits elsewhere, so only do it when you are sure the commits are only on your machine.

If you have local changes and want to update your checkout, then there are several options:

  • You commit your local changes, and do a pull, optionally with --rebase.
  • Or you use git stash to place your local changes on a "hidden" stash. Then, after pulling, you apply your changes again with git stash apply.
  • Or you create a patch of your local changes that you apply again after the pull. This approach sometimes makes sense, but I would say in general it's the more clumsy way to go. There are git commands that help you with this though.

Resolving conflicts

TODO