Skip to content

Git workflow

Jump to bottom
Christopher Van edited this page Feb 9, 2014 · 4 revisions

Although GitHub's help docs may tell you otherwise, "origin" is what you should name the remote, central repository (in our case, git@github.com:cvan/galaxy.git).

If you want to understand the specifics of this branching model, read this great tutorial.

If you want to just be spoonfed the commands, keep reading.

We're going to talk about two git repositories:

There should be something like this in your .git/config already:

[remote "origin"]
    url = git://github.com/cvan/galaxy.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Now we'll set up your master to pull directly from the upstream (origin) repo:

[branch "master"]
    remote = origin
    merge = master
    rebase = true

This can also be done through the git config command (e.g. git config branch.master.remote origin) but editing .git/config is often easier.

After you've done that, point the remote repo (origin) to cvan/galaxy:

git remote set-url origin git@github.com:cvan/galaxy.git

After you've forked the repository on GitHub, tell git about your new repo:

git remote add -f yourusername git@github.com:yourusername/galaxy.git

Make sure to replace yourusername with your GitHub username!

Working on a Branch

Let's work on a bug in a branch called your-bug:

git checkout -b your-bug master

Now we're switched to a new branch that was copied from master. We like to work on feature branches, but the master is still moving along. How do we keep up?

git fetch origin && git rebase origin/master

If you want to keep the master branch up to date, do it this way:

git checkout master && git pull && git checkout - && git rebase master

That switched to the master branch, updated master, switched back to our feature branch, and updated (rebased) our branch with the latest changes from the master branch of the origin remote repo.

Resolving conflicts

If you try to rebase and the changeset includes changes to files you're working on in your feature branch, git usually does a fantastic job of figuring out how to cleanly merge the changes. If git can't figure out what to do, it'll ask you to resolve the merge conflicts manually. When you get a rebase Here's how:

git status

Look at all the modified files whose conflicts need to be resolved manually. Go into each file and search for ==== and you'll want to figure out whose changes to keep for each section (HEAD's or your feature branch's). Once you've fixed up all the conflicts, tell git to continue rebasing:

git add <file1> <file2>
git rebase --continue

(Repeat if necessary.)

Publishing your branch

The syntax is git push <repository> <branch>. Here's how to push the your-bug branch to your fork:

git push yourusername your-bug

If you've rebased, git will yell at you saying you're trying to rewrite history. Only if you are the only person working on this branch and you promise to proceed with caution, you can force a push:

git push yourusername your-bug -f

Pushing

To push your feature branch to GitHub:

git checkout master && git pull && git checkout your-bug && git rebase master && git checkout master && git merge your-bug

In my global ~/.gitconfig I have an alias called git get:

[alias]
    get = "!f() { echo Merging $1 && git checkout master && git pull && git submodule sync && git submodule update --recursive && git checkout $1 && git rebase master && git checkout master && git merge $1; }; f"

Feel free to steal that.

Testing someone else's patch locally

First start in a clean branch:

git checkout master && git checkout -b someones-patch

Using hub:

hub cherry-pick 'https://github.com/cvan/galaxy/pull/43'

Or this way:

curl 'https://github.com/cvan/galaxy/pull/43.patch' | git am

Clone this wiki locally