维护分叉的git仓库的工作流程是什么？ [英] What is the workflow for maintaining a forked git repository?

问题描述

我没有得到git。我在颠覆和mercurial中胜任，但是当我尝试合并来自上游存储库的更改并将结果推送到github上的fork时，我总是以重复提交，无意义冲突，重定位循环和其他意外结果结束。
在这里stackoverflow的其他答案没有提及使用 git远程添加上游，似乎缺乏我需要停止失败的细节。

例如，假设我从WorldEdit开始，它是 https：// github上的github repo。 com / sk89q / WorldEdit
在github上，我将回购分叉到 https：// github。 com / Charlweed / WorldEdit
现在我将它克隆到Linux或Cygwin上的本地工作站。我使用-recursive选项，因为WorldEdit似乎有三个子模块。
git clone --recursive [e-mail]：Charlweed / WorldEdit.git

cd WorldEdit

现在，按照github上的说明，我设置了对父存储库的跟踪：

git remote add upstream [e-mail]：sk89q / WorldEdit.git

最后，我尝试更新已注册的子模块以匹配超级项目的期望：
$ b $ git submodule update --init --recursive

这就是我所知道的知道如何设置。我编码时一切正常，并检查本地更改。当我拉到我的github fork时，一切似乎都很简单而且不复杂。不幸的是，当我尝试以下任何一种情况时，混乱就开始了：

1. 将原始的父github库中的更改合并到我的
   中github repo。


2. 将我的许多小本地提交转换为
   单提交。
   

我拒绝详细介绍我在工作流程中做的错误事情:)。我应该做些什么来跟上源代码回购，并提供适合拉取请求的整齐提交？

谢谢！

解决方案

GIT开发

这就是我们管理开发周期的方法。
http://nvie.com/posts/a-successful- git-branchching-model /

真的没有什么特别的......我们每个人都在自己的分支上工作，每个分支都是一个功能。当功能变得非常大时，我们将它们分解成更小的部分，并在各自的分支中实现。确保我们合并分支机构后再进入下一步。

这张图看起来很复杂，但实际上它显示的是只有两个永久分支。
$ b

1. 开发


2. master

你可以想象这样的分支......

  master->开发 - > feature_branch 
  

。

  master< -development< -feature_branch 
  

因此，我们只有我们的 master 分支。然后，我们分支出一个与全球测试环境紧密结合的开发分支。最后，我们每个人都创建自己的短期 feature_branch ，我们在自己的开发环境中测试。

通过这个工作流程，我们遵循三条规则

1. 不要直接提交给master


2. 不要直接提交给开发者
   
3. 始终实施新的SHORT-LIVED分行的功能

功能

所有新功能分支都是从开发创建的。完成后，它们将被合并回开发 ...在其中可以在任何其他新更改（可能是其他人同时写入）中进行测试，并在一切正常运行时进行最终确认，然后合并到 master 。

修补程序

现在技术上的修补程序可以从 / strong>并快速实施，但需要将它们合并到开发中。我个人更喜欢以与功能分支相同的方式实现Bug修复，但这取决于您。

测试

<在开发新的分支时，您可以通过SSH连接到服务器（最好是开发环境）并切换到您的分支。
git checkout< branch-name>

您可能还需要做一个 git pull ，然后再进行首次检查。还有 git branch 会告诉你你在哪个分支，并列出所有其他分支。

准备好部署后，只需简单地将开发分支合并到主服务器中，并提交+推送更改即可。然后SSH到服务器（Live）并做一个git pull。要成为CLEAR，在登录到服务器时，不应使用除pull之外的任何其他git cmd。当然也不例外。

这个想法是您的生产服务器应该与您的主分支紧密结合。换句话说，不要在这台服务器上使用 git checkout< branch> 。
$ b

工具

这一个纯粹由您决定，但我们的团队更喜欢使用称为sourcetree的Windows GUI工具。
https://www.sourcetreeapp.com/

如果您更喜欢CMD线，那很好。这个文档帮助我学习了CMD的一些基础知识。
http://rogerdudler.github.io/git-guide/ p>

大部分时间GIT和SourceTree处理合并冲突非常好。然而有时你需要一个3路diff工具来帮助...我强烈推荐Kdiff
http：// kdiff3。 sourceforge.net/

它与SourceTree集成，可以处理一些非常复杂的合并问题。如果你正确地做事，你可能永远都不需要这样做。

同步一个分支

用Forked回购的心态。在尝试遵循正常的工作流程之前，您需要确保您始终将上游更改合并到回购库中。
https://help.github.com/articles/syncing-a- fork /

执行此操作时，强烈首选您没有上游存储库没有的未完成提交。如果你这样做，那么你需要提出拉请求......当然这是假设这些提交已准备好提交。 （有关更具体的规则，请参阅报价）
https：//help.github。 com / articles / using-pull-requests /

@JBNizet非常棒！

不要在已经存在于上游回购
的分支中工作（例如，主人）。创建你自己的，并在这些工作。
定期从上游更新主分支（它应该总是
快进），并定期重新分配主分支。当
准备好时，你的分支发送一个pull请求给上游的master
分支

如果我们把这些字考虑到这一点，你可以采取这种标准的工作流程并修改它来处理项目。 询问作者他们通常是如何进行的，以便您可以知道应该从哪个分支中分支出来。通过这种方式，您可以通过自己的稳定分支来实施更改，准备好后可以执行拉取请求，以便作者可以查看更改。

I don’t get git. I am competent in subversion and mercurial, but I when I try to merge changes from an upstream repository and push the results to my fork on github, I always end up with duplicate commits, senseless conflicts, rebase loops, and other unexpected results. Other answers here on stackoverflow do not mention using git remote add upstream and seem to lack the detail I need to stop failing.

For example, say I start start with WorldEdit, a github repo at https://github.com/sk89q/WorldEdit On github, I fork the repo to https://github.com/Charlweed/WorldEdit Now I clone it to a local workstation on linux or Cygwin. I use the –recursive option, because WorldEdit seems to have three submodules. git clone --recursive [e-mail]:Charlweed/WorldEdit.git

cd WorldEdit

Now, following the instructions on github, I set up tracking for the parent repository:

git remote add upstream [e-mail]:sk89q/WorldEdit.git

Finally, I try to update the registered submodules to match what the superproject expects:

git submodule update --init --recursive

This is all I "know how" to set up. Everything is fine as I code, and check in local changes. As I pull and push to my github fork, everything seems to be simple and uncomplicated. Unfortunately, confusion starts as soon as I try to either:

1. Merge changes from the original, parent github repo into my forked github repo.
2. "rebase" my many small local commits into a single commit.

I decline to detail here the wrong things I do in my workflow :) . What SHOULD I be doing to keep up with the source repo, and have tidy commits suitable for pull requests?

Thanks!

解决方案

GIT Development

This is how we manage our development cycle. http://nvie.com/posts/a-successful-git-branching-model/

Nothing fancy really… Each of us works on our own branch where each branch is a feature. When features get really large in scope we break them down into smaller pieces and implement each in their own branch. Making sure we merge our branches back in before moving on to the next.

That diagram seems pretty convoluted but really what it is showing is that there are only ever two permanent branches.

1. development
2. master

You can imagine Branching like this...

master->development->feature_branch

While merging like this...

master<-development<-feature_branch

So to start we have only our master branch. We then branch off a development branch which is tightly coupled with a global testing environment. Finally each of us creates our own short-lived feature_branch that we test on our own dev environments.

With this workflow we follow three rules

1. Never commit directly to master
2. Never commit directly to development
3. Always implement features from a new SHORT-LIVED branch

Feature

All new feature branches are created from development. When complete they are then merged back into development… where they can be tested among any other new changes (maybe someone else wrote at the same time) and final when everything works well it is merged into master.

Hotfix

Now technically hotfixes can be branched off of master and implemented quickly but then they need to be merged into development. Personally I prefer to implement Bug fixes the same way as a feature branch but that is up to you.

Testing

While developing your new branch you can SSH into the server (preferably a dev environment) and switch to your branch. git checkout <branch-name>

You may also need to do a git pull prior to checking out for the first time. Also git branch will tell you what branch you are on plus list all others.

GIT Deployment

Once you are ready to deploy you simply merge your development branch into master and commit+push your changes. Then SSH on to the server (Live) and do a git pull. To be CLEAR you should never need to use any other git cmd other than pull when logged on to the server. Rare cases not withstanding of course.

The idea is that your production server should be tightly coupled with your master branch. In other words never use git checkout <branch> on this server.

Tools

This one is purely on you to decide but our team prefers using a windows GUI tool called sourcetree. https://www.sourcetreeapp.com/

If you prefer CMD line that is fine. This doc helped me learn some of the basics of CMD. http://rogerdudler.github.io/git-guide/

Most of the time GIT and SourceTree handle merge conflicts really well. However sometimes you need a 3-way diff tool to help out… I HIGHLY recommend Kdiff http://kdiff3.sourceforge.net/

It integrates with SourceTree and can handle some really complex merge issues. If you do things correctly you will likely never need this.

Syncing a fork

Now something to keep in mind with Forked repos. You need to make sure you are pulling/merging upstream changes into your repo consistently before you attempt to follow your normal workflow. https://help.github.com/articles/syncing-a-fork/

When you do this it is strongly preferred that you have no outstanding commits that the upstream repository does not have. If you do then you need to make a pull request... Of course this is assuming those commits are ready for submission. (See quote for more specific rules) https://help.github.com/articles/using-pull-requests/

@JBNizet Makes a great point!

Don't, ever, work in branches that already exist on the upstream repo (i.e. master, for example). Create your own and work in these ones. Regularly update the master branch from upstream (it should always be fast-forward), and regularly rebase your own branches on master. When ready send a pull request from your branch to the upstream master branch

If we take these words into consideration then you can take this std workflow and modify it to work with the project. Ask the author how they usually proceed so that you can know which branch you should be branching off of. That way you can implement changes through your own stable branch and when ready you can do a pull request so that the author can review your changes.

这篇关于维护分叉的git仓库的工作流程是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！