-
-
Notifications
You must be signed in to change notification settings - Fork 872
Add Git Bootcamp page #144
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.
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
Changes from all commits
142f1df
4321772
2104dea
efee4f7
2993cbc
6284566
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,250 @@ | ||
.. highlight:: console | ||
|
||
.. _gitbootcamp: | ||
|
||
Git Bootcamp and Cheat Sheet | ||
============================ | ||
|
||
In this section, we'll go over some commonly used Git commands that are | ||
relevant to CPython's workflow. | ||
|
||
.. contents:: | ||
|
||
|
||
Forking CPython GitHub Repository | ||
--------------------------------- | ||
|
||
You'll only need to do this once. | ||
|
||
1. Go to https://github.com/python/cpython. | ||
|
||
2. Press ``Fork`` on the top right. | ||
|
||
3. When asked where to fork the repository, choose to fork it to your username. | ||
|
||
4. Your fork will be created at https://github.com/<username>/cpython. | ||
|
||
|
||
Cloning The Forked CPython Repository | ||
------------------------------------- | ||
|
||
You'll only need to do this once. From your command line:: | ||
|
||
$ git clone [email protected]:<username>/cpython.git | ||
$ cd cpython | ||
$ git remote add upstream [email protected]:python/cpython.git | ||
|
||
|
||
Listing the Remote Repositories | ||
------------------------------- | ||
|
||
To list the remote repositories that are configured, along with their urls:: | ||
|
||
$ git remote -v | ||
|
||
|
||
Creating and Switching Branches | ||
------------------------------- | ||
|
||
.. note:: | ||
Never commit directly to the ``master`` branch. | ||
|
||
Create a new branch and switch to it:: | ||
|
||
# creates a new branch off master and switch to it | ||
$ git checkout -b <branch-name> master | ||
|
||
This is equivalent to:: | ||
|
||
# create a new branch off 'master', without checking it out | ||
$ git branch <branch-name> master | ||
# check out the branch | ||
$ git checkout <branch-name> | ||
|
||
To find out which branch you are in now:: | ||
|
||
$ git branch | ||
|
||
The current branch will have an asterisk next to the branch name. Note, this | ||
will list all of your local branches. | ||
|
||
To list all the branches, including the remote branches:: | ||
|
||
$ git branch -a | ||
|
||
To switch to a different branch:: | ||
|
||
$ git checkout <another-branch-name> | ||
|
||
|
||
Delete Local Branch | ||
------------------- | ||
|
||
To delete branch that you no longer need:: | ||
|
||
$ git branch -D <branch-name> | ||
|
||
|
||
Staging and Committing Files | ||
---------------------------- | ||
|
||
1. To show the current changes:: | ||
|
||
$ git status | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe mention |
||
|
||
2. To stage the files to be included in your commit:: | ||
|
||
$ git add path/to/file1 path/to/file2 path/to/file3 | ||
|
||
3. To commit the files that have been staged (done in step 2):: | ||
|
||
$ git commit -m "bpo-XXXX: This is the commit message." | ||
|
||
|
||
Reverting Changes | ||
----------------- | ||
|
||
To revert changes to a file that has not been committed yet:: | ||
|
||
$ git checkout path/to/file | ||
|
||
If the change has been committed, and now you want to reset it to whatever | ||
the origin is at:: | ||
|
||
$ git reset --hard HEAD | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the difference between this and There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure... I don't normally use the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I find this section a bit confusing/misleading. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are two more scenarios where I used
The second case works differently since we are using PRs. With HG I could apply a patch and do |
||
|
||
|
||
Stashing Changes | ||
---------------- | ||
|
||
To stash away changes that are not ready to be committed yet:: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Coming from HG, the concept of staging and stashing are foreign. While I am now somewhat familiar with them, I'd prefer a goal-oriented approach, i.e.:
(Feel free to change the wording if it doesn't accurately reflect what |
||
|
||
$ git stash | ||
|
||
To re-apply last stashed change:: | ||
|
||
$ git stash pop | ||
|
||
|
||
Pushing Changes | ||
--------------- | ||
|
||
Once your changes are ready for a review or a pull request, you'll need to push | ||
them to the remote repository. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "...push them to your GitHub fork." |
||
|
||
:: | ||
|
||
$ git checkout <branch-name> | ||
$ git push origin <branch-name> | ||
|
||
|
||
Creating a Pull Request | ||
----------------------- | ||
|
||
1. Go to https://github.com/python/cpython. | ||
|
||
2. Click ``compare across forks`` link. | ||
|
||
3. Select the base fork: ``python/cpython`` and base branch: ``master``. | ||
|
||
4. Select the head fork: ``<username>/cpython`` and base branch: the branch | ||
containing your changes. | ||
|
||
5. Press ``Create Pull Request`` button. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't it easier to just go on my fork, and press the "Compare & pull request" button? I'm not sure when that button is available, but so far I've always found it after pushing a new branch. Edit: after reading below I'm not sure if this works for other branches, but maybe it does? |
||
|
||
|
||
Syncing With Upstream | ||
--------------------- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be easier to configure the remote to |
||
|
||
Scenario: | ||
|
||
- You forked the CPython repository some time ago. | ||
- Time passes. | ||
- There have been new commits made in upstream CPython repository. | ||
- Your forked CPython repository is no longer up to date. | ||
- You now want to update your forked CPython repository to be the same as | ||
upstream. | ||
|
||
Solution:: | ||
|
||
$ git checkout master | ||
$ git pull --rebase upstream master | ||
$ git push origin master | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW I've been using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Inline comments would be useful:
|
||
|
||
The `--rebase` is only needed if you have local changes to the branch. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Above you mentioned that you should never commit to master, so I would assume |
||
|
||
Another scenario: | ||
|
||
- You created ``some-branch`` some time ago. | ||
- Time passes. | ||
- You made some commits to ``some-branch``. | ||
- Meanwhile, there are recent changes from upstream CPython repository. | ||
- You want to incorporate the recent changes from upstream into ``some-branch``. | ||
|
||
Solution:: | ||
|
||
$ git checkout some-branch | ||
$ git fetch upstream | ||
$ git rebase upstream/master | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I recently came across this scenario, and the solution I used was:
This has the advantage of also updating the local master. I think this also assumes that the first command is done in the Perhaps this should also mention two other things:
|
||
|
||
|
||
Backporting Merged Changes | ||
-------------------------- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Who is the target here? Are contributors supposed to do this or is it only for core devs? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think core dev who merged the PR is expected to do the backport, mainly because it involves removing For now I will just state here that the core dev is expected to do the backport. Once the cherry-picking bot is in place, this section will just be obsolete. |
||
|
||
A pull request may need to be backported into one of the maintenance branches | ||
after it has been accepted and merged into ``master``. It is usually indicated | ||
by the label ``needs backport to X.Y`` on the pull request itself. | ||
|
||
Use the utility script `cherry_picker.py <https://github.com/python/core-workflow/tree/master/cherry_picker>`_ | ||
from the `core-workflow <https://github.com/python/core-workflow>`_ | ||
repository to backport the commit . | ||
|
||
The core developer who merged the pull request is expected to do the backport. | ||
|
||
|
||
Downloading Other's Patches | ||
--------------------------- | ||
|
||
Scenario: | ||
|
||
- A contributor made a pull request to CPython. | ||
- Before merging it, you want to be able to test their changes locally. | ||
|
||
Set up the following git alias:: | ||
|
||
$ git config --global alias.pr '!sh -c "git fetch upstream pull/${1}/head:pr_${1} && git checkout pr_${1}" -' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the third variant of what I believe is the same thing. The other two I saw are:
The first one seem equivalent to the alias, except that it needs to be done manually every time. The second one doesn't require to create an additional alias but it needs to be added to each There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This alias was suggested by @zware. I don't actually know about the other variants. So I'll just leave this as is. |
||
|
||
The alias only needs to be done once. After the alias is set up, you can get a | ||
local copy of a pull request as follows:: | ||
|
||
$ git pr <pr_number> | ||
|
||
|
||
Accepting and Merging A Pull Request | ||
------------------------------------ | ||
|
||
Pull requests can be accepted and merged by a Python Core Developer. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A question about "merging etiquette": if another core-dev submitted a PR, and it looks good to me, should I go ahead and merge it, or should I just leave a positive review and let the original core-dev merge it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps this is to be asked at core-workflow or python-committers? :) |
||
|
||
1. At the bottom of the pull request page, click the ``Squash and merge`` | ||
button. | ||
|
||
2. Adjust and clean up the commit message. Replace the reference | ||
to GitHub PR #XXX into GH-XXX. | ||
|
||
Example of good commit message:: | ||
|
||
bpo-12345: Improve the spam module (GH-777) | ||
|
||
* Add method A to the spam module | ||
* Update the documentation of the spam module | ||
|
||
Example of bad commit message:: | ||
|
||
bpo-12345: Improve the spam module (#777) | ||
|
||
* Improve the spam module | ||
* merge from master | ||
* adjust code based on review comment | ||
* rebased | ||
|
||
3. Press the ``Confirm squash and merge`` button. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lately I've been using
git status
instead ofgit branch
, as it tells the current branch at the beginning.Should this be mentioned instead/in addition to
git branch
?