我应该在为 apache kafka 创建 PR 时创建分支的分支吗? [英] Should I create a branch of the fork while creating PR for apache kafka?
问题描述
我计划为 Kafka 开源做出贡献.我将 Kafka 分叉到我的 git hub 帐户中.然后我在本地克隆了它.现在，我应该在 master 中进行更改还是应该在本地创建一个以票证命名的分支?
I am planning to contribute to Kafka open source. I forked Kafka, into my git hub account. Then I cloned it locally. Now, should i make change in master or should I create a branch named after ticket locally ?
推荐答案
创建一个分支来实现功能或错误修复，将您的分支推送到您自己的存储库(您的分支)，然后打开一个拉取请求将您的分支合并到你的分支，在官方 Kafka 存储库中有主分支(通常是 master).
Create a branch to implement the feature or bugfix, push your branch to your own repository (your fork), then open a pull-request to merge your branch in your fork, with the main branch (usually master) in the official Kafka repository.
以下是在 GitHub 上为项目做出贡献时标准工作流程的更详细说明:
Here is a more detailed explanation of the standard workflow when contributing to projects on GitHub:
GitHub 标准分叉 &拉取请求工作流程https://gist.github.com/augustoproiete/256b560d008d14a1fc9f94
GitHub Standard Fork & Pull Request Workflow https://gist.github.com/augustoproiete/256b560d008d39afc0814a19f41a1d49
<小时>
无论您是想回馈开源社区还是在自己的项目上进行合作，了解如何正确分叉和生成拉取请求都是必不可少的.不幸的是，当您最初学习该过程时，很容易犯错误或不知道应该做什么.我知道我一开始确实遇到了相当大的麻烦，而且我发现 GitHub 和互联网上的很多信息都相当零碎和不完整——这里描述的过程的一部分，另一个在不同的地方，常见的挂断，等等.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
为了为我自己和其他人整合这些信息，这个简短的教程是我发现创建分叉、完成工作、发出拉取请求以及将该拉取请求合并回的相当标准的过程原始项目.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
只需转到 GitHub 页面并单击Fork"按钮即可.就是这么简单.完成后，您可以使用您最喜欢的 git 客户端来克隆您的存储库或直接进入命令行:
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:
# Clone your fork to your local machine
git clone git@github.com:USERNAME/FORKED-PROJECT.git
让你的前叉保持最新
虽然这不是绝对必要的步骤，但如果您打算做的不仅仅是一个微小的快速修复，您需要通过跟踪原始的上游"存储库来确保您的分叉是最新的你分叉了.为此，您需要添加一个遥控器:
Keeping Your Fork Up to Date
While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:
# Add 'upstream' repo to list of remotes
git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git
# Verify the new remote named 'upstream'
git remote -v
每当你想用最新的上游更改更新你的 fork 时，你需要首先获取上游仓库的分支和最新提交以将它们引入你的仓库:
Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:
# Fetch from upstream remote
git fetch upstream
# View all branches, including those from upstream
git branch -va
现在，检查您自己的主分支并合并上游存储库的主分支:
Now, checkout your own master branch and merge the upstream repo's master branch:
# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master
如果本地 master 分支上没有唯一的提交，git 将简单地执行快进.但是，如果您一直在对 master 进行更改(在绝大多数情况下您可能不应该这样做 - 请参阅下一节，您可能必须处理冲突.这样做时，请注意尊重上游所做的更改.
If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - see the next section, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
现在，您的本地 master 分支是最新的，上游修改了所有内容.
Now, your local master branch is up-to-date with everything modified upstream.
每当您开始处理新功能或错误修复时，创建新分支都很重要.它不仅是适当的 git 工作流程，而且还使您的更改井井有条并与 master 分支分开，以便您可以轻松地为您完成的每项任务提交和管理多个拉取请求.
Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
要创建一个新分支并开始处理它:
To create a new branch and start working on it:
# Checkout the master branch - you want your new branch to come from master
git checkout master
# Create a new branch named newfeature (give your branch its own simple informative name)
git branch newfeature
# Switch to your new branch
git checkout newfeature
现在，去镇上进行黑客攻击并进行您想要的任何更改.
Now, go to town hacking away and making whatever changes you want to.
在提交您的拉取请求之前，您可能需要做一些事情来清理您的分支，并使原始存储库的维护者尽可能简单地测试、接受和合并您的工作.
Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
如果对上游主分支进行了任何提交，您应该重新设定开发分支的基础，以便合并它是一个简单的快进，不需要任何冲突解决工作.
If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
# Fetch upstream master and merge with your repo's master branch
git fetch upstream
git checkout master
git merge upstream/master
# If there were any new commits, rebase your development branch
git checkout newfeature
git rebase master
现在，可能需要将一些较小的提交压缩为少量较大的、更有凝聚力的提交.您可以通过交互式 rebase 执行此操作:
Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
# Rebase all commits on your development branch
git checkout
git rebase -i master
这将打开一个文本编辑器，您可以在其中指定要压缩的提交.
This will open up a text editor where you can specify which commits to squash.
提交所有更改并将所有更改推送到 GitHub 后，转到 GitHub 上的 fork 页面，选择您的开发分支，然后单击拉取请求按钮.如果您需要对拉取请求进行任何调整，只需将更新推送到 GitHub.您的拉取请求将自动跟踪开发分支上的更改并进行更新.
Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
请注意，与之前从创建分叉并生成拉取请求的人的角度编写的部分不同，本节是从处理传入拉取请求的原始存储库所有者的角度编写的.因此，在forker"将原始存储库称为 upstream 的情况下，我们现在将其视为原始存储库的所有者和标准的 origin 远程存储库.
Take note that unlike the previous sections which were written from the perspective of someone that created a fork and generated a pull request, this section is written from the perspective of the original repository owner who is handling an incoming pull request. Thus, where the "forker" was referring to the original repository as upstream, we're now looking at it as the owner of that original repository and the standard origin remote.
打开.git/config文件，在[remote "origin"]下增加一行:
Open up the .git/config file and add a new line under [remote "origin"]:
fetch = +refs/pull/*/head:refs/pull/origin/*
现在您可以获取和签出任何拉取请求，以便您可以对其进行测试:
Now you can fetch and checkout any pull request so that you can test them:
# Fetch all pull request branches
git fetch origin
# Checkout out a given pull request branch based on its number
git checkout -b 999 pull/origin/999
请记住，这些分支将是只读的，您将无法推送任何更改.
Keep in mind that these branches will be read only and you won't be able to push any changes.
如果合并是简单的快进，您只需点击 GitHub 上的拉取请求页面上的按钮即可自动进行合并.
In cases where the merge would be a simple fast-forward, you can automatically do the merge by just clicking the button on the pull request page on GitHub.
要手动进行合并，您需要检出源代码库中的目标分支，直接从 fork 中拉取，然后合并和推送.
To do the merge manually, you'll need to checkout the target branch in the source repo, pull directly from the fork, and then merge and push.
# Checkout the branch you're merging to in the target repo
git checkout master
# Pull the development branch from the fork repo where the pull request development was done.
git pull https://github.com/forkuser/forkedrepo.git newfeature
# Merge the development branch
git merge newfeature
# Push master with the new feature merged into it
git push origin master
现在您已经完成了开发分支，您可以随意删除它.
Now that you're done with the development branch, you're free to delete it.
git branch -d newfeature
版权
版权所有 2017，蔡斯佩蒂特
Copyright 2017, Chase Pettit
MIT 许可证，http://www.opensource.org/licenses/mit-许可证.php
补充阅读
来源
这篇关于我应该在为 apache kafka 创建 PR 时创建分支的分支吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
