我应该在为apache kafka创建PR时创建分支吗？ [英] Should I create a branch of the fork while creating PR for apache kafka?
问题描述
然后我在本地克隆它。现在，我应该在主服务器上进行更改还是应该在本地创建一个以票证命名的分支？ 解决方案
创建分支以实施功能或错误修正，将你的分支推送到你自己的仓库（你的分支），然后打开一个拉取请求来将你的分支合并到主分支（通常是 master ）在官方Kafka仓库中。
以下是对GitHub上的项目进行贡献时标准工作流程的更详细解释：
GitHub Standard Fork&合并请求工作流
https://gist.github.com/caioproiete/256b560d008d39afc0814a19f41a1d49
无论您是否试图回馈开源社区或在您自己的项目上进行协作，了解如何正确分叉和生成请求是非常重要的。不幸的是，在你最初学习这个过程时，犯错误或者不知道你应该做什么很容易。我知道我确实遇到了相当大的初始问题，我发现GitHub和互联网上的很多信息都是零碎的和不完整的 - 这里描述的过程的一部分，另一个过程，在不同的地方常见的挂断，等等。
为了给我自己和其他人提供这些信息，这个简短的教程是我发现的创建分支的相当标准的过程，做你的工作，发出一个拉请求，并将该拉请求合并回原始项目。
创建分叉
只需转到GitHub页面并点击Fork按钮即可。就这么简单。一旦你这样做了，你可以使用你最喜欢的git客户端克隆你的repo，或者直接进入命令行：
＃克隆你的fork到本地机器
git clone git@github.com：USERNAME / FORKED-PROJECT.git
保持您的货叉最新状态
虽然这不是绝对必要的步骤，但如果您打算做的不仅仅是一个小小的快速修复时，您需要确保通过跟踪分叉的原始上游回购来保持您的货物更新。要做到这一点，你需要添加一个远程：
＃将'upstream'回购添加到远程列表
git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git
＃验证名为'upstream'的新远程
git remote -v
每当您想用最新的上游更改更新叉时，您需要首先获取上游仓库的分支和$ {
$ b
＃从上游远程获取
git fetch upstream
＃查看所有分支，包括来自上游的分支
git分支-va
现在，检出你自己的master分支并合并上游的repo的master分支：
$ $ $ $ $ $ $ $ $ $ $＃$＃$＃$>＃检出你的master分支并合并上游
git checkout master
git merge upstream / master
如果没有唯一的提交本地主分支，g它将简单地执行快进。但是，如果您一直在对主人进行更改（在绝大多数情况下您可能不应该这样做） - 请参阅下一部分，您可能需要处理冲突。这样做时，请小心尊重上游所做的更改。
现在，您的本地主分支是最新的，所有内容都是上游修改过的。
做你的工作
创建分支
每当您开始使用新功能或修补程序时，创建新分支不仅适合git工作流程，而且它还能让您的更改与主分支保持组织和分离，以便您可以轻松地提交和管理您完成的每项任务的多个请求。
创建一个新的分支并开始处理它：
＃签出master分支 - 你想要你的分支新分支来自master
git checkout master
＃创建一个名为newfeature的新分支（给你的分支自己的si mple informative name）
git branch newfeature
＃切换到你的新分支
git checkout newfeature
现在，您可以进入小镇并进行任何您想要的更改。
提交合并请求
清理你的工作
在提交你的请求之前，你可能需要做一些事情来清理你的分支，让原始仓库维护人员尽可能简单地测试，接受和合并您的工作。
如果任何提交到上游主分支，您应该重新分配你的开发分支，这样合并它将是一个简单的快速转换，不需要任何解决冲突的工作。
＃获取上游主，并与你的仓库主分支合并
git fetch upstream
git checkout master
git merge upstream / master
＃如果有任何新的提交，rebase你的发展文胸nch
git checkout newfeature
git rebase master
现在，可能需要把你的一些较小的提交压缩成一小部分更大的更有凝聚力的提交。您可以使用交互式转化来完成此操作：
＃重新开发您的开发分支上的所有提交
git checkout
git rebase -i master
这会打开一个文本编辑器，您可以指定哪些提交。
正在提交
一旦你提交了所有的更改并将其推送到GitHub，就进入页面为了您在GitHub上的分支，请选择您的开发分支，然后单击请求按钮。如果您需要对拉取请求进行任何调整，只需将更新推送到GitHub。您的pull请求会自动跟踪您开发分支上的更改并进行更新。
接受并合并请求
请注意，与从创建分支并生成拉取请求的人的角度编写的前一部分不同，此部分是从处理传入拉取请求的原始存储库所有者的角度编写的。因此，在forker指的是原始仓库 upstream 时，我们现在将它视为原始仓库的所有者和标准 origin remote。
检出并测试合并请求
.git / config 文件，并在 [remoteorigin]下添加一个新行：
fetch = + refs / pull / * / head：refs / pull / origin / *
现在您可以获取并签出任何拉取请求，以便测试它们：
＃获取所有拉取请求分支
git获取原点
＃根据其编号检出给定的拉取请求分支
git checkout -b 999拉/原产地/ 999
请记住，这些分支只能读取，您将无法推送任何更改。
自动合并拉取请求
如果合并为简单快进，您可以通过单击GitHub上的请求页面上的按钮自动执行合并。
手动合并拉取请求
要手动执行合并，您需要在源代码库中签出目标分支，直接从分支中取出，然后合并并推送。
＃在目标仓库中签出你正在合并的分支
git checkout master
＃将开发分支从fork请求开发已完成。
git pull https://github.com/forkuser/forkedrepo.git newfeature
＃合并开发分支
git merge newfeature
＃Push掌握新功能并入其中
git push origin master
现在你已经
git分支-d新特征
版权
Copyright 2017，Chase Pettit
麻省理工学院许可证， http： //www.opensource.org/licenses/mit-license.php
补充阅读
来源
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 ?
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.
Here is a more detailed explanation of the standard workflow when contributing to projects on GitHub:
GitHub Standard Fork & Pull Request Workflow https://gist.github.com/caioproiete/256b560d008d39afc0814a19f41a1d49
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.
Creating a Fork
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
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
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.
Now, your local master branch is up-to-date with everything modified upstream.
Doing Your Work
Create a Branch
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.
Submitting a Pull Request
Cleaning Up Your Work
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
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.
Submitting
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.
Accepting and Merging a Pull Request
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.
Checking Out and Testing Pull Requests
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.
Automatically Merging a Pull Request
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.
Manually Merging a Pull Request
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
Copyright
Copyright 2017, Chase Pettit
MIT License, http://www.opensource.org/licenses/mit-license.php
Additional Reading
Sources
这篇关于我应该在为apache kafka创建PR时创建分支吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
