@@ -246,16 +246,16 @@ changes in this branch specific to one bug or feature so it is clear
246246what the branch brings to *pandas *. You can have many shiny-new-features
247247and switch in between them using the git checkout command.
248248
249- To update this branch, you need to retrieve the changes from the master branch::
249+ When creating this branch, make sure your master branch is up to date with
250+ the latest upstream master version. To update your local master branch, you
251+ can do::
250252
251- git fetch upstream
252- git rebase upstream/ master
253+ git checkout master
254+ git pull upstream master --ff-only
253255
254- This will replay your commits on top of the latest pandas git master. If this
255- leads to merge conflicts, you must resolve these before submitting your pull
256- request. If you have uncommitted changes, you will need to ``stash `` them prior
257- to updating. This will effectively store your changes and they can be reapplied
258- after updating.
256+ When you want to update the feature branch with changes in master after
257+ you created the branch, check the section on
258+ :ref: `updating a PR <contributing.update-pr >`.
259259
260260.. _contributing.documentation :
261261
@@ -293,12 +293,9 @@ Some other important things to know about the docs:
293293 overviews per topic together with some other information (what's new,
294294 installation, etc).
295295
296- - The docstrings follow the **Numpy Docstring Standard **, which is used widely
297- in the Scientific Python community. This standard specifies the format of
298- the different sections of the docstring. See `this document
299- <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt> `_
300- for a detailed explanation, or look at some of the existing functions to
301- extend it in a similar manner.
296+ - The docstrings follow a pandas convention, based on the **Numpy Docstring
297+ Standard **. Follow the :ref: `pandas docstring guide <docstring >` for detailed
298+ instructions on how to write a correct docstring.
302299
303300- The tutorials make heavy use of the `ipython directive
304301 <http://matplotlib.org/sampledoc/ipython_directive.html> `_ sphinx extension.
@@ -967,32 +964,6 @@ Now you can commit your changes in your local repository::
967964
968965 git commit -m
969966
970- Combining commits
971- -----------------
972-
973- If you have multiple commits, you may want to combine them into one commit, often
974- referred to as "squashing" or "rebasing". This is a common request by package maintainers
975- when submitting a pull request as it maintains a more compact commit history. To rebase
976- your commits::
977-
978- git rebase -i HEAD~#
979-
980- Where # is the number of commits you want to combine. Then you can pick the relevant
981- commit message and discard others.
982-
983- To squash to the master branch do::
984-
985- git rebase -i master
986-
987- Use the ``s`` option on a commit to ``squash``, meaning to keep the commit messages,
988- or ``f`` to ``fixup``, meaning to merge the commit messages.
989-
990- Then you will need to push the branch (see below) forcefully to replace the current
991- commits with the new ones::
992-
993- git push origin shiny-new-feature -f
994-
995-
996967Pushing your changes
997968--------------------
998969
@@ -1048,15 +1019,51 @@ release. To submit a pull request:
10481019#. Click ``Send Pull Request``.
10491020
10501021This request then goes to the repository maintainers, and they will review
1051- the code. If you need to make more changes, you can make them in
1052- your branch, push them to GitHub, and the pull request will be automatically
1053- updated. Pushing them to GitHub again is done by: :
1022+ the code.
1023+
1024+ .. _contributing.update-pr :
10541025
1055- git push -f origin shiny-new-feature
1026+ Updating your pull request
1027+ --------------------------
1028+
1029+ Based on the review you get on your pull request, you will probably need to make
1030+ some changes to the code. In that case, you can make them in your branch,
1031+ add a new commit to that branch, push it to GitHub, and the pull request will be
1032+ automatically updated. Pushing them to GitHub again is done by::
1033+
1034+ git push origin shiny-new-feature
10561035
10571036This will automatically update your pull request with the latest code and restart the
10581037:ref:`Continuous Integration <contributing.ci>` tests.
10591038
1039+ Another reason you might need to update your pull request is to solve conflicts
1040+ with changes that have been merged into the master branch since you opened your
1041+ pull request.
1042+
1043+ To do this, you need to "merge upstream master" in your branch::
1044+
1045+ git checkout shiny-new-feature
1046+ git fetch upstream
1047+ git merge upstream/master
1048+
1049+ If there are no conflicts (or they could be fixed automatically), a file with a
1050+ default commit message will open, and you can simply save and quit this file.
1051+
1052+ If there are merge conflicts, you need to solve those conflicts. See for
1053+ example at https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
1054+ for an explanation on how to do this.
1055+ Once the conflicts are merged and the files where the conflicts were solved are
1056+ added, you can run ``git commit`` to save those fixes.
1057+
1058+ If you have uncommitted changes at the moment you want to update the branch with
1059+ master, you will need to ``stash`` them prior to updating (see the
1060+ `stash docs <https://git-scm.com/book/en/v2 /Git-Tools-Stashing-and-Cleaning>`__).
1061+ This will effectively store your changes and they can be reapplied after updating.
1062+
1063+ After the feature branch has been update locally, you can now update your pull
1064+ request by pushing to the branch on GitHub::
1065+
1066+ git push origin shiny-new-feature
10601067
10611068Delete your merged branch (optional)
10621069------------------------------------
0 commit comments