Skip to content

Improvements to Committing.rst #149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Mar 17, 2017
Merged

Improvements to Committing.rst #149

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f2ea453
Improvements to Committing.rst
Mariatta Mar 17, 2017
234bb6c
grammatical error
Mariatta Mar 17, 2017
7147e92
typo: an -> can
Mariatta Mar 17, 2017
396adb6
was -> is
Mariatta Mar 17, 2017
4f48dbf
add extra line
Mariatta Mar 17, 2017
de86ee7
fix indentation
Mariatta Mar 17, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 29 additions & 11 deletions committing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,8 +252,11 @@ contributed to the resolution, it is good practice to credit them.


Working with Git_
=======================
=================

.. seealso::
:ref:`gitbootcamp`

As a core developer, the ability to push changes to the official Python
repositories means you have to be more careful with your workflow:

Expand All @@ -268,6 +271,10 @@ repositories means you have to be more careful with your workflow:
want the history to be full of intermediate commits recording the private history
of the person working on a patch.

* You should not commit directly into the ``master`` branch, or any of the
maintenance branches (``2.7``, ``3.5``, or ``3.6``). You should commit against
your own feature branch, and create a pull request.

It recommended to keep a fork of the main repository around, as it allows simple
reversion of all local changes (even "committed" ones) if your local clone gets
into a state you aren't happy with.
Expand Down Expand Up @@ -399,16 +406,7 @@ to master branch::
git commit -m 'bpo-12345: fix some issue.'
# Note the commit SHA (e.g. git log or git rev-parse --short HEAD).

Then you can switch to the ``3.6`` branch (or appropriate older version), cherry-pick
the commit and run the test::

git checkout 3.6
# Instead of 3.6 use an appropriate branch reflecting the Python version you
# are backporting your change to.
git cherry-pick -x 123abc
# 123abc is the SHA of the previous commit.
# Fix any conflicts (add changes with git add -A and git cherry-pick --continue).
# Compile; run the test suite.
Then use cherry_picker.py_ to backport the commit.

.. note::
Even when porting an already committed patch, you should *still* check the
Expand All @@ -417,6 +415,26 @@ the commit and run the test::
ported without any modifications.


Backport and Cherry-Pick Labels
-------------------------------

Only Core Developers can apply labels to GitHub pull requests. When it is determined
that a pull request needs to be backported into one or more of the maintenance branches,
a core developer can apply the labels ``needs backport to X.Y`` to the pull request.

After the pull request has been merged, it can be backported using cherry_picker.py_.

Prefix the backport pull request with the branch, for example::

[3.6] bpo-12345: Fix the Spam Module

Apply the label ``cherry-pick or X.Y`` to the backport pull request. Once the backport
pull request has been created, remove the ``needs backport to X.Y`` label from the
original pull request on ``master``.

.. _cherry_picker.py: https://github.com/python/core-workflow/tree/master/cherry_picker


.. _squash-commits:

Squashing commits
Expand Down