在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:susam/gitpr开源软件地址:https://github.com/susam/gitpr开源编程语言:Makefile 67.8%开源软件介绍:Fork and Pull Request WorkflowThis document describes how developers may contribute pull requests to an upstream repository and how upstream owners may merge pull requests from contributors according to the very popular fork and pull request workflow followed in many projects on GitHub. The download buttons above download version 0.6.0 (the latest stable release) of this document. The most recent version of this document is available at git.io/gitpr. ContentsIntroductionEvery project has a main development branch where the developers push
commits on a day-to-day basis. Usually, the main development branch is
We use the following placeholders in the command examples and ASCII-diagrams in this document:
These placeholders should be substituted with appropriate values while executing the commands presented in this document. Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history.
When a new commit is made in a branch, its branch pointer simply moves to point to the last commit in the branch.
A branch is merely a pointer to the tip of a series of commits. With this little thing in mind, seemingly complex operations like rebase and fast-forward merges become easy to understand and use. The next section, Quick Reference, provides a brief summary of all the frequently used commands involved in creating and merging pull requests. Quick ReferenceHere is a brief summary of all the commands used to create and merge pull requests in this document. This section serves as a quick reference.
The next two sections, Create Pull Request and Merge Pull Request, elaborate these commands in detail. Create Pull RequestThis section is meant for developers who contribute new commits to the upstream repository from their personal fork. Fork and CloneOn GitHub, fork the upstream repository to your personal user account. Then clone your fork from your personal GitHub user account to your
local system and set the upstream repository URL as a remote named
Now the remote named Work on Pull RequestWork on a new pull request in a new topic branch and commit it to your
fork. Remember to use a meaningful name instead of
Create pull request via GitHub web interface as per the following steps:
Wait for an upstream developer to review and merge your pull request. If there are review comments to be addressed, continue working on your
branch, commiting, optionally rebasing, amending, squashing, and
dropping them, and pushing them to the topic branch of In the fork and pull request workflow, a contributor should never commit anything to the main development branch of personal fork. This makes it very easy to keep the main development branch of your fork in sync with that of the upstream repository. This is explained in the next subsection. Keep Your Fork UpdatedAs new pull requests get merged into the upstream's main development branch, the main development branch of your fork begins falling behind it. The commands below show how to update your fork's main development branch with the new commits in the upstream's main development branch.
The When your main development branch falls behind the upstream's main development branch, the upstream's main development branch extends linearly from the last commit in your main development branch, provided that there are no additional commits to your main development branch that has caused it to diverge.
With such a commit history, when the upstream's main development branch is merged into your main development branch, the merge is done by simply fast-forwarding the pointer of your main development branch to the last commit in the upstream's main development branch.
After the merge is complete, the upstream's main development branch and your main development branch point to the same commit. Amend Last CommitThis is an optional step to rework on the last commit. After commiting some work, one may realize that some files need to be modified or the commit message needs to updated.
Git allows us to pick the last commit, modify the changes made in that commit including the commit message, and reapply the changes along with the modifications as a new commit that replaces the last commit.
To do so, first rework on the files and make the necessary changes. Then add, remove, move, or rename files to stage them for commiting. Finally, amend the last commit. The commit message may be modified when the editor comes up to show the commit message.
Although the above example shows only the To update only the commit message without changing files, run only Rebase CommitsThis is an optional step to keep the commit history as linear as possible. The main development branch may have diverged since the topic branch was created.
It may be a good idea to move the commits in the topic branch and place them on top of the main development branch, so that the topic branch extends linearly from the last commit in the main development branch.
The following commands show how to rebase the topic branch on the main development branch.
Edit CommitsThis is an optional step to keep the commit history clean and concise. A pull request may contain multiple commits. Sometimes one may need to amend a commit that is not the last commit in the pull request. Commits prior to the last commit can be amended with the interactive rebase command. After developing the required feature or bug-fix in a topic branch, the developer or a reviewer may notice issues in the work that need to be addressed before the pull request can be merged into the upstream repository. This may lead to multiple new commits in the topic branch that should ideally have been part of the first commit that implemented that feature or bug-fix.
In such cases, it may be a good idea to squash multiple commits in the topic branch into a single coherent commit with all changes for the feature or bug-fix being developed.
The following example shows how to amend the last 3 commits.
This brings up an editor with three lines for the last 3 commits ordered from earliest to last followed by instructions on how to edit these lines to amend the commits. For example, to squash all three commits into one, leave the first
commit untouched, replace Apart from Force PushThe steps in the last three sections overwrite the history of the
branch. If these steps are performed after the pull request branch has
already been pushed to GitHub, then it is necessary to use the
The Delete BranchOnce the upstream developer merges your pull request, you may delete the topic branch from your local system as well as from your fork.
The next section, Merge Pull Request, explains how an upstream owner can merge pull request from contributors into the upstream repository. Merge Pull RequestThis section is meant for lead developers who own the upstream repository and merge pull requests from contributors to it. There are two popular methods to merge commits: one that does not introduce an additional merge commit, and another that does. Both are perfectly acceptable. Both are discussed below. Which method you choose depends on whether you want to maintain a concise commit history consisting only of development commits or if you want to introduce additional merge commits for every merge into your commit history. Without Merge CommitClone the upstream repository to your local system.
If the repository was already cloned to the local system earlier, then ensure that the local main development branch is up-to-date with that in the upstream repository.
Create a temporary branch (
If the main development branch has diverged from the branch in the pull request, the above command creates a new merge commit to merge the pull request into the temporary branch. Note: It is okay to have a merge commit while merging pull requests. There is nothing wrong about it. If you are comfortable having a merge commit for the pull request, skip the list of three points below and continue with merging the pull request. If you really want to get rid of the additional merge commit, follow exactly one of these options:
After sufficient testing, merge the commits in the pull request into the main development branch and remove the pull request branch.
Finally, push the current state of the main development branch to the upstream repository.
The After a pull request branch is rebased on the main development branch, the pull request branch becomes a linear extension of the main development branch.
With such a commit history, when the pull request branch is now merged into the main development branch, the merge is done by simply fast-forwarding the pointer of the main development branch to the last commit in the pull request branch.
With Merge CommitClone the upstream repository to your local system.
If the repository was already cloned to the local system earlier, then ensure that the local main development branch is up-to-date with that in the upstream repository.
Create a temporary branch (
If the contributor adds new commits to the pull request later, then run these commands again to pull the new commits. After sufficient testing, merge the commits in the pull request into the main development branch.
Finally, push the current state of the main development branch (with the commits from the pull request in it) to the upstream repository.
The
Nifty CommandsThis is a bonus section that describes a few aliases and commands that may be useful during day-to-day development activities. Pretty LogThe following commands create aliases to run
Staged DiffWhile
Branch ListingThe following commands provides aliases to list branches with verbose information. The second alias includes remote branches too in the output.
More AliasesHere are a few more commands to define aliases for very frequently used commands.
Merge BaseFind a common ancestor of two branches with this command. It helps to find the commit after which two branches began diverging.
Commit Partial ChangesSometimes when you are in the zone, you may make large sweeping changes to a file. However it is a good practice to create separate and small commits for separate concerns. To select some changes in a file while ignoring other changes in the same file for the next commit, stage the changes interactively with this command.
This command shows every change hunk one by one. Enter Some Git WisdomEnter one of the commands below in your command shell depending on your operating system, or just open the URL with your web browser.
LicenseCopyright © 2018 Susam Pal This document is licensed under the Creative Commons Attribution 4.0 International License. You are free to share the material in any medium or format and/or adapt the material for any purpose, even commercially, under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) License. This document is provided as-is and as-available, without representations or warranties of any kind, whether express, implied, statutory, or other. See the CC BY 4.0 Legal Code for details. SupportTo report bugs, suggest improvements, or ask questions, create issues. To contribute improvements to this document, fork this project and create pull request! ;-) |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论