使用 git 和 github 的正确工作流程
目前我一直在使用 git 和 github 编写 Rails 应用程序。我通常单独工作，但在我最新的项目中，我正在与第二个开发人员合作。我正在尝试找出与其他用户合作的标准方法。
目前，我让他分叉我的 gitrepo，然后在他准备好更改时提交拉取请求。这还不算太糟糕，除了我编写了更多代码 - 当 fork 队列中有更改供他推送时，其中许多会失败（即使他自上次推送我的代码以来没有进行任何更改） ）。
整个过程对他来说每次重新分叉似乎都更有效率，这让我觉得我们做错了一些事情。我们应该使用分支而不是叉子吗？或者也许是叉子和树枝？
谢谢！
So currently I've been coding rails apps using git and github. I usually work alone, but in my latest project I'm working with a second developer. I'm trying to figure out the standard methods for working with another user.
Currently, I had him fork my gitrepo, and then just submit pull requests when he has changes ready. That hasn't been so bad, except I code a lot more - and when there are changes in the fork queue for him to push, many of them fail (even if he hasn't made any changes from the last time he pushed mine).
The whole process just seems more efficient for him to re-fork everytime, which makes me think we're going about something incorrectly. Should we be using branches instead of forks? Or maybe forks and branches?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第二个开发人员应该首先将 GitHub 存储库拉到他的本地存储库中，解决那里的任何冲突。
然后他可以提出拉取请求。
master”上工作）拉取请求的想法仍然是提交快进补丁（易于应用于您的 GitHub 存储库）。
这是通过在发出拉取请求之前首先在本地解决所有冲突来实现的。
另一种选择是声明第二个开发人员为 GitHub 项目的“协作者”（他可以直接推送），但这不会改变“先拉”是必要的以确保推送的事实直截了当。
The second developer should pull first the GitHub repo into his local repo, solving any conflict there.
And then he can make pull requests.
master' for example)The idea of a pull request remains to submit patches that will be fast-forward ones (easy to apply to your GitHub repo).
And that is achieved by solving any conflicts locally first, before making pull request.
The other options would be to declare said second developer as a "collaborator" on your GitHub project (he would be able to push directly), but that wouldn't change the fact that a "pull first" is necessary to ensure the push will be straightforward.
有许多 git 工作流程向您开放，因为它是一个灵活的工具，但一个简单的工作流程是拥有一个“master”分支和一个“develop”分支。您可以直接推送和拉取到您的存储库，无需在 github 上进行分叉，也无需您的协作者不断提交 Github 拉取请求。
你们都可以在开发分支上进行大部分本地提交，但经常从远程开发分支中拉取，以便合并彼此的代码 - 在这个阶段，您可以在推送到远程之前处理合并冲突。
不太常见的是，您可以拉下 master 并将其与开发合并。这个想法是主分支更稳定，可以随时准备发布，因此不会在其上进行主动开发。这就是全部内容了。
如果你想更进一步，你可以从你的开发分支创建“功能分支”，但原理是相同的 - 合并回“向上”到开发，然后从那里“向上”到掌握。
重要的是经常同步（合并）您的工作，否则代码库的单独副本中的差异可能会更大，这意味着发生冲突的可能性更大。如果仍然存在冲突，请更频繁地推拉，这样差异就会更小并且更容易处理。
如果你们都在同一个文件上大量工作，则特别有可能发生冲突。在这种情况下，有时进行组织并将工作划分为更改代码库不同部分（文件）的功能是值得的，这样你们就不太可能踩到对方的脚趾。
请记住在拉取之前提交本地更改，否则更改将被视为处于“暂存”状态，并且不会在拉取期间自动合并。幸运的是，git 相当宽容，并且非常擅长处理合并冲突。
There are a number of git workflows open to you because it's a flexible tool, but a simple workflow is to have a 'master' branch and a 'develop' branch. You can both push and pull directly to your repo without forking on github and without your collaborator having to constantly submit Github pull requests.
You can both make the majority of your local commits on the develop branch but frequently pull down from the remote develop branch in order to merge each other's code - it's at this stage that you can deal with merge conflicts, before pushing to remote.
Less frequently, you can pull down master and merge that with develop. The idea is that the master branch is more stable and can be prepped for release at any time, so active development does not occur on it. That's all there is to it.
If you want to go further you can both make "feature branches" from your develop branch, but the principle is the same - merge back 'up' to develop, and from there 'up' to master.
The important thing is to synchronise (merge) your work often, otherwise the differences in your separate copies of the codebase are likely to be greater, which means a greater chance of conflicts. If you continue to have conflicts, push and pull more frequently so the differences are smaller and easier to handle.
Conflicts are especially likely to occur if you are both working heavily on the same files. In such cases, it sometimes pays to be organised and divide up the work into features that change different parts (files) of the codebase, so you are less likely to step on each other's toes.
Remember to commit your local changes before pulling, otherwise the changes will be considered to be in "staging" and will not be merged automatically during the pull. Fortunately, git is fairly forgiving and very good at dealing with merge conflicts.