我最近参与了一个来自 GitHub 的项目。我做了以下事情：
分叉原始存储库，将其克隆到我的本地计算机，创建一个分支以修复现有错误，修复该分支中的错误，将该分支推送到我的存储库，向存储库的作者发送拉取请求以将我的修复分支合并到它的主分支。
这是我第一次提交别人的代码，所以我不知道该怎么做。现在我的拉取请求已被作者合并到原始仓库/项目中。
接下来我该怎么办？我应该删除分支吗？我应该合并分支吗？还要别的吗？
原始项目只有一个分支。
我还有一个上游集，可以从原始存储库中获取最新更新。（我是这样做的）：
git remote add upstream https://path/to/original/repo.git
我得到这样的更新：
git fetch upstream
What to do next is: going on contributing new features or fixing other bugs in their own dedicated branches (pushed only to your fork).
Meaning your fork stays, but the branches within your fork can come and go.
You can also remove the fork if you are not planning to contribute further, but it will remove the corresponding entry in 'Repositories you contribute to'.
It is easier to:
fix branch (actually, it is now deleted for you) on your fork (and in your local cloned repo: see "Delete a Git branch both locally and remotely")git pull upstream master (if master was the branch in which your fix has been integrated: the merge will be a fast-forward one): no rebase needed at this point.master (now with the latest from upstream master).However, never forget one step before submitting any future pull request:
rebase first your current branch (fix) from upstream destination branch
(upstream being the original repo you have forked: see "What is the difference between origin and upstream in github")
Before submitting anything back to the original repo ("upstream"), you need to make sure your work is based on top of the latest from said original repo (or the pull-request won't result in a fast-forward merge once applied back on upstream repo).
See, for instance, "Workflow for managing pull requests on shared repos in github".
In other words, upstream can evolve (have new commits pushed on it) while you are busy fixing stuff. You need to replay your fixes on top of that latest work from upstream to make sure your commits are still compatible with the latest of upstream.
The OP Santosh Kumar asks in the comments:
I have pulled and merged from
upstreamto master, now what?
If you haven't made any new fixes since your recent pull request, see above (delete and recreate an new branch fix on top of your updated master).
If you have done any more work since your pull request, I wouldn't merge from upstream if I want to make a new pull request: I would pull and rebase:
git pull --rebase upstream master
That way, all my new local work is replayed on top of the most recent upstream master commits (fetched in my local repo), supposing that master is the target branch that will integrate my future pull request.
Then I can push my local work to 'origin', which is my fork on GitHub of upstream.
And from my fork on GitHub, I can safely make a pull request, knowing that it will only add new commits to upstream without needing any merge resolution: merging those new commits in upstream repo will mean a simple fast-forward merge.
A git pull --rebase without specifying the branch on top of which you want to rebase your (currently checked out) fix branch wouldn't work:
That (
git pull --rebase) says:
You asked to pull from the remote '`upstream`', but did not specify a branch.
Should I append master at last? And what will this do?, will it delete my
fixbranch?
Yes, you can specify the branch which will be the target of the pull request, for instance 'master'.
That will not delete your fix branch, but will replay it on top of upstream master fetched in your repo.
首先，祝贺你对 Github 上的一个项目做出了第一次贡献。
通常的 Github 工作流程是为您解决的每个问题创建一个新分支。这样，主线存储库的维护者可以决定合并哪个解决方案以及拒绝哪个解决方案。分支在上游合并后，将不再需要该分支，通常可以将其删除。