git individual developer work collaboratively tips

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.

git standalone developer tips

git branch --no-merged master

See if any branches are not merged with master.

Individual Developer standalone working :

 Use a tarball as a starting point for a new repository.

               $ tar zxf frotz.tar.gz

               $ cd frotz

               $ git init

               $ git add . (1)

               $ git commit -m "import of frotz source tree."

               $ git tag v2.43 (2)

           1. add everything under the current directory.

           2. make a lightweight, unannotated tag.

       Create a topic branch and develop.

               $ git checkout -b alsa-audio (1)

               $ edit/compile/test

               $ git checkout -- curses/ux_audio_oss.c (2)

               $ git add curses/ux_audio_alsa.c (3)

               $ edit/compile/test

               $ git diff HEAD (4)

               $ git commit -a -s (5)

               $ edit/compile/test

               $ git diff HEAD^ (6)

               $ git commit -a --amend (7)

               $ git checkout master (8)

               $ git merge alsa-audio (9)

               $ git log --since='3 days ago' (10)

               $ git log v2.43.. curses/ (11)

           1. create a new topic branch.

           2. revert your botched changes in curses/ux_audio_oss.c.

           3. you need to tell Git if you added a new file; removal and

           modification will be caught if you do git commit -a later.

           4. to see what changes you are committing.

           5. commit everything, as you have tested, with your sign-off.

           6. look at all your changes including the previous commit.

           7. amend the previous commit, adding all your new changes, using

           your original message.

           8. switch to the master branch.

           9. merge a topic branch into your master branch.

           10. review commit logs; other forms to limit output can be combined

           and include -10 (to show up to 10 commits), --until=2005-12-10,

           etc.

           11. view only the changes that touch what's in curses/ directory,

           since v2.43 tag.

git Head , fetch_head,orig_head,merge_head

• HEAD names the commit on which you based the changes in the working tree.
• FETCH_HEAD records the branch which you fetched from a remote repository with your last git fetch invocation.
• ORIG_HEAD is created by commands that move your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them.
• MERGE_HEAD records the commit(s) which you are merging into your branch when you run git merge.
• CHERRY_PICK_HEAD records the commit which you are cherry-picking when you run git cherry-pick.

From the git source, you can also find out about BISECT_HEAD, REVERT_HEAD, REJECT_NON_FF_HEAD and several others that you will almost certainly never need.

That reference also explains suffixes (^N, ~N, @{...}), ranges (.. vs ...), and more.

Ref: stackoverflow