git integrator tips

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. An sub-area lieutenant for a repository will

       act both as a participant and as an integrator.

       o   git-am(1) to apply patches e-mailed in from your contributors.

       o   git-pull(1) to merge from your trusted lieutenants.

       o   git-format-patch(1) to prepare and send suggested alternative to

           contributors.

       o   git-revert(1) to undo botched commits.

       o   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 checkout -b topic/one master

               $ git am -3 -i -s ./+to-apply (4)

               $ compile/test

               $ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus (5)

               $ git checkout topic/one && git rebase master (6)

               $ git checkout pu && git reset --hard next (7)

               $ git merge topic/one topic/two && git merge hold/linus (8)

               $ git checkout 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 pu (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 pu

           (potential updates).

(potential updates).

           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 pu 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, and next should have everything ko/next

           has, etc.

           13. push out the bleeding edge, together with new tags that point

           into the pushed history.

       In this example, the ko shorthand points at the Git maintainer's

       repository at kernel.org, and looks like this:

           (in .git/config)

           [remote "ko"]

                   url = kernel.org:/pub/scm/git/git.git

                   fetch = refs/heads/*:refs/remotes/ko/*

                   push = refs/heads/master

                   push = refs/heads/next

                   push = +refs/heads/pu

                   push = refs/heads/maint