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 switch -c 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.

Integrator[[INTEGRATOR]]
------------------------

A fairly central person acting as the integrator in a group
project receives changes made by others, reviews and integrates
them and publishes the result for others to use, using these
commands in addition to the ones needed by participants.

This section can also be used by those who respond to `git
request-pull` or pull-request on GitHub (www.github.com) to
integrate the work of others into their history. A sub-area
lieutenant for a repository will act both as a participant and
as an integrator.


  * linkgit:git-am[1] to apply patches e-mailed in from your
    contributors.

  * linkgit:git-pull[1] to merge from your trusted lieutenants.

  * linkgit:git-format-patch[1] to prepare and send suggested
    alternative to contributors.

  * linkgit:git-revert[1] to undo botched commits.

  * linkgit:git-push[1] to publish the bleeding edge.


Examples
~~~~~~~~

A typical integrator's Git day.::
+
------------
$ git status <1>
$ git branch --no-merged master <2>
$ mailx <3>
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git switch -c topic/one master
$ git am -3 -i -s ./+to-apply <4>
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git switch topic/one && git rebase master <6>
$ git switch -C seen next <7>
$ git merge topic/one topic/two && git merge hold/linus <8>
$ git switch maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
$ git fetch ko && for branch in master maint next seen <11>
    do
	git show-branch ko/$branch $branch <12>
    done
$ git push --follow-tags ko <13>
------------
+
<1> see what you were in the middle of doing, if anything.
<2> see which branches haven't been merged into `master` yet.
Likewise for any other integration branches e.g. `maint`, `next`
and `seen`.
<3> read mails, save ones that are applicable, and save others
that are not quite ready (other mail readers are available).
<4> apply them, interactively, with your sign-offs.
<5> create topic branch as needed and apply, again with sign-offs.
<6> rebase internal topic branch that has not been merged to the
master or exposed as a part of a stable branch.
<7> restart `seen` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
<11> make sure master was not accidentally rewound beyond that
already pushed out.
<12> In the output from `git show-branch`, `master` should have
everything `ko/master` has,