INDIVIDUAL DEVELOPER (PARTICIPANT)
A developer working as a participant in a group project needs to learn
how to communicate with others, and uses these commands in addition to
the ones needed by a standalone developer.
o git-clone(1) from the upstream to prime your local repository.
o git-pull(1) and git-fetch(1) from "origin" to keep up-to-date with
the upstream.
o git-push(1) to shared repository, if you adopt CVS style shared
repository workflow.
o git-format-patch(1) to prepare e-mail submission, if you adopt
Linux kernel-style public forum workflow.
o git-send-email(1) to send your e-mail submission without corruption
by your MUA.
o git-request-pull(1) to create a summary of changes for your
upstream to pull.
Examples:
Clone the upstream and work on it. Feed changes to upstream.
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git checkout -b mine master (1)
$ edit/compile/test; git commit -a -s (2)
$ git format-patch master (3)
$ git send-email --to="person <email@example.com>" 00*.patch (4)
$ git checkout master (5)
$ git pull (6)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
$ git reset --hard ORIG_HEAD (10)
$ git gc (11)
1. checkout a new branch mine from master.
2. repeat as needed.
3. extract patches from your branch, relative to master,
4. and email them.
5. return to master, ready to see what's new
6. git pull fetches from origin by default and merges into the
current branch.
7. immediately after pulling, look at the changes done upstream
since last time we checked, only in the area we are interested in.
8. check the branch names in an external repository (if not known).
9. fetch from a specific branch ALL from a specific repository and
merge it.
10. revert the pull.
11. garbage collect leftover objects from reverted pull.
Push into another repository.
satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
remote.origin.url mothership:frotz
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git config remote.origin.push \
+refs/heads/*:refs/remotes/satellite/* (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)
mothership$ cd frotz
mothership$ git checkout master
mothership$ git merge satellite/master (5)
1. mothership machine has a frotz repository under your home
directory; clone from it to start a repository on the satellite
machine.
2. clone sets these configuration variables by default. It arranges
git pull to fetch and store the branches of mothership machine to
local remotes/origin/* remote-tracking branches.
3. arrange git push to push all local branches to their
corresponding branch of the mothership machine.
4. push will stash all our work away on remotes/satellite/*
remote-tracking branches on the mothership machine. You could use
this as a back-up method. Likewise, you can pretend that mothership
"fetched" from you (useful when access is one sided).
5. on mothership machine, merge the work done on the satellite
machine into the master branch.
Branch off of a specific tag.
$ git checkout -b private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 (2)
1. create a private branch based on a well known (but somewhat
behind) tag.
2. forward port all changes in private2.6.14 branch to master
branch without a formal "merging". Or longhand git format-patch -k
-m --stdout v2.6.14..private2.6.14 | git am -3 -k
An alternate participant submission mechanism is using the git
request-pull or pull-request mechanisms (e.g as used on GitHub
(www.github.com) to notify your upstream of your contribution.
No comments:
Post a Comment