Collaborative Development and Branch Management in Git

"individual developer" who does not have a "public" repository is somewhat different. It goes like this: 1. Prepare your work repository, by 'git clone' the public repository of the "project lead" (or a "subsystem maintainer", if you work on a subsystem). The URL used for the initial cloning is stored in the remote.origin.url configuration variable. 2. Do your work in your repository on 'master' branch. 3. Run `git fetch origin` from the public repository of your upstream every once in a while. This does only the first half of `git pull` but does not merge. The head of the public repository is stored in `.git/refs/remotes/origin/master`. 4. Use `git cherry origin` to see which ones of your patches were accepted, and/or use `git rebase origin` to port your unmerged changes forward to the updated upstream. 5. Use `git format-patch origin` to prepare patches for e-mail submission to your upstream and send it out. Go back to step 2. and continue. Working with Others, Shared Repository Style -------------------------------------------- If you are coming from a CVS background, the style of cooperation suggested in the previous section may be new to you. You do not have to worry. Git supports the "shared public repository" style of cooperation you are probably more familiar with as well. See linkgit:gitcvs-migration[7] for the details. Bundling your work together --------------------------- It is likely that you will be working on more than one thing at a time. It is easy to manage those more-or-less independent tasks using branches with Git. We have already seen how branches work previously, with "fun and work" example using two branches. The idea is the same if there are more than two branches. Let's say you started out from "master" head, and have some new code in the "master" branch, and two independent fixes in the "commit-fix" and "diff-fix" branches: ------------ $ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Release candidate #1 --- + [diff-fix] Fix rename detection. + [diff-fix~1] Better common substring algorithm. + [commit-fix] Fix commit message normalization. * [master] Release candidate #1 ++* [diff-fix~2] Pretty-print messages. ------------ Both fixes are tested well, and at this point, you want to merge in both of them. You could merge in 'diff-fix' first and then 'commit-fix' next, like this: ------------ $ git merge -m "Merge fix in diff-fix" diff-fix $ git merge -m "Merge fix in commit-fix" commit-fix ------------ Which would

This section discusses how individual developers without a public repository can work with others, including using a shared public repository style, and how to manage multiple tasks using branches in Git, with examples of merging and managing different branches.