diff options
Diffstat (limited to 'docs/git.rst')
| -rw-r--r-- | docs/git.rst | 62 |
1 files changed, 40 insertions, 22 deletions
diff --git a/docs/git.rst b/docs/git.rst index c3f7ccce..73e7a311 100644 --- a/docs/git.rst +++ b/docs/git.rst @@ -80,10 +80,10 @@ doing and why. How to send us your changes --------------------------- -There are three ways to let us know how to get it: +There are two ways to let us know how to get it: -1. (preferred) **push changes to publicly available git clone and let - us know where to find it** +1. *(preferred)* **push changes to publicly available git clone and + let us know where to find it** Push your feature/bugfix/issue branch to your publicly available git clone and add a comment to the issue with the url for your @@ -93,14 +93,22 @@ There are three ways to let us know how to get it: Run:: - git format-patch -o patches <remote>/master + git format-patch --stdout <remote>/master > issue_<number>.patch - Then tar up the newly created ``patches`` directory and attach the - directory to the issue. + ``format-patch`` creates a patch of all the commits that are in + your branch that aren't in ``<remote>/master``. The ``--stdout`` + flag causes all this output to go to stdout where it's redirected + to a file named ``issue_<number>.patch``. That file should be + based on the issue you're working with. For example, + ``issue_42.patch`` is a good filename and ``issue_42_rev2.patch`` + is good if you did a revision of it. + + Having said all that, the filename isn't wildly important. Example workflow ================ + Here's an example workflow. @@ -108,8 +116,8 @@ Contributing changes -------------------- Slartibartfast from the planet Magrathea far off in the universe has -decided that he is bored with fjords and wants to fix issue 42 and -send us the changes. +decided that he is bored with fjords and wants to fix issue 42 (the +meaning of life bug) and send us the changes. Slartibartfast has cloned the MediaGoblin repository and his clone lives on gitorious. @@ -124,19 +132,29 @@ Slartibartfast does the following: git fetch --all -p + This tells ``git fetch`` to fetch all the recent data from all of + the remotes (``--all``) and prune any branches that have been + deleted in the remotes (``-p``). + 2. Creates a branch from the tip of the MediaGoblin repository (the - remote is named ``gmg``) master branch called ``issue_42``:: + remote is named ``gmg``) master branch called ``bug42_meaning_of_life``:: - git checkout -b issue_42 gmg/master + git checkout -b bug42_meaning_of_life gmg/master -3. Slartibartfast works hard on his changes in the ``issue_42`` + This creates a new branch (``-b``) named ``bug42_meaning_of_life`` based + on the tip of the ``master`` branch of the remote named ``gmg`` and checks + it out. + +3. Slartibartfast works hard on his changes in the ``bug42_meaning_of_life`` branch. When done, he wants to notify us that he has made changes he wants us to see. -4. Slartibartfast pushes his changes to his clone (the remote is named - ``origin``):: +4. Slartibartfast pushes his changes to his clone:: + + git push origin bug42_meaning_of_life --set-upstream - git push origin issue_42 --set-upstream + This pushes the changes in the ``bug42_meaning_of_life`` branch to the + remote named ``origin``. 5. Slartibartfast adds a comment to issue 42 with the url for his repository and the name of the branch he put the code in. He also @@ -155,19 +173,19 @@ He runs the unit tests and discovers there's a bug in the code! Then he does this: -1. He checks out the ``issue_42`` branch:: +1. He checks out the ``bug42_meaning_of_life`` branch:: - git checkout issue_42 + git checkout bug42_meaning_of_life -2. He fixes the bug and checks it into the ``issue_42`` branch. +2. He fixes the bug and checks it into the ``bug42_meaning_of_life`` branch. 3. He pushes his changes to his clone (the remote is named ``origin``):: - git push origin issue_42 + git push origin bug42_meaning_of_life 4. He adds another comment to issue 42 explaining about the mistake and how he fixed it and that he's pushed the new change to the - ``issue_42`` branch of his publicly available clone. + ``bug42_meaning_of_life`` branch of his publicly available clone. What happens next @@ -180,7 +198,7 @@ request with his changes and explains what they are. Later, someone checks out his code and finds a problem with it. He adds a comment to the issue tracker specifying the problem and asks Slartibartfast to fix it. Slartibartfst goes through the above steps -again, fixes the issue, pushes it to his ``issue_42`` branch and adds +again, fixes the issue, pushes it to his ``bug42_meaning_of_life`` branch and adds another comment to the issue tracker about how he fixed it. Later, someone checks out his code and is happy with it. Someone @@ -192,8 +210,8 @@ Slartibartfast is notified of this. Slartibartfast does a:: git fetch --all The changes show up in the ``master`` branch of the ``gmg`` remote. -Slartibartfast now deletes his ``issue_42`` branch because he doesn't -need it anymore. +Slartibartfast now deletes his ``bug42_meaning_of_life`` branch +because he doesn't need it anymore. How to learn git |