Question

虽然我使用Git来管理我自己的项目，但我很擅长在Github上进行协作，而且我对如何管理我的工作感到有些困惑。

以下是我所做的以及我在哪里：

在Github上做了一个存储库的分支
将其克隆到我的台式电脑
使用以下内容将上游添加到原始存储库：git remote add upstream http_url.git
创建了一个新分支，进行了更改，提交了它们
用git push origin my_branch
在Github上，在我的分支中，切换到刚刚被推送的分支并创建了一个拉取请求

一切都很好。原始存储库的所有者感谢我提出拉取请求，并表示他已离开，并且无法检查并合并到下周末。

我遵循了明智的做法，并对代码的一个方面进行了修改。然而，我还有其他一些事情要做，并发出拉动请求 - 但我对如何最好地使用git管理它感到困惑。

通常情况下，对分支感到满意，我会将其与主人合并并继续前进。但我不确定这是不是我应该做的。我是否应该在分支机构之外创建一个新的分支机构？我已经在那里推动和发展了？我不确定在我的拉取请求被接受并合并到原始存储库后我fetch upstream会发生什么。

我应该如何管理进一步的发展？请注意，我希望进行的开发工作需要我已经进行的更改，并且原始存储库的所有者在我开始之前完成了我所做的更改，因为它们是写得很好，工作很好，我很期待我的拉请求会在他回来时被接受和合并。我也不想等到下周结束才能继续我的发展。

感谢。

Answer 1

我使用feature作为分支的名称而不是my_branch。 “上游回购”是指由http_url.git代表的回购。

通常情况下，对分支感到满意，我会将它与主人合并并继续前进。但我不确定这是不是我应该做的。我是否应该在分支机构中创建一个新分支，我已经在那里推动和发展了？

是的，对于上游回购的master的未来变更，这将非常有效。这方面的一个例子是另一个开发者的PR在你的之前合并。

我应该如何管理进一步的发展？请注意，我希望进行的开发工作需要进行更改

(feature branch)
-commit1--commit2--commit3
                        \ (pr)
------------------------master

说这是您的开发流程的当前状态。上游仓库的管理员发表了一些评论，你必须在feature分支上进行一些更改。由于您已经从feature分支出来进行下一次添加，因此您最终会在feature分支上找到不同的历史记录，以及您正在处理的新历史记录。

(new feature branch)
-commit1--commit2--commit3--newcommit1--newcommit2
                        /
-commit1--commit2--commit3--commit4--commit5
                                      / (pr)
---(possibly other PRs getting merged)--master

上面的图片将是当前状态。现在，下一步将是弄清楚如何从feature分支到新功能分支获取最新更改（具体来说，提交commit4和commit5）。这样做的两种方法是使用git rebase或git merge。这是我要遵循的一系列步骤：

返回master分支
获取所有更改
转到new feature分支
在其上运行git rebase master

这将涉及强制推送到您的GitHub远程分支，因为new feature分支的当前历史记录将发生变化。由于这个原因，一些开发人员不喜欢它。

第二种方法是使用git merge。 1至3步是相同的。第4步将涉及git merge master命令。运行此操作并推送到远程分支后，如果您比较master和new feature分支，则更改将仅包含newcommit1和newcommit2提交。

此策略可让您在提到的情况下继续开发工作流程。这仅考虑最终合并您的更改的情况。

Answer 2

假设您已推送并创建了拉取请求的分支是A，并且您已对其进行了n次提交。所以关于master，它看起来像这样：

commit a1
commit a2
... ...
... ...
commit an

如果您在此分支中推送更多提交，则拉取请求将自动更新。因此，如果您希望将新更改与此拉取请求合并，那么除了在此处推送新提交之外没有任何其他操作。

现在，假设您不想在此拉取请求中添加其他内容，并且新更改需要在此分支中进行更改（即提交a1 a2 ... an）。您可以在此处从B创建新分支A，并在此处进行新的提交b1 b2 ... bn。因此关于A分支B看起来像这样：

Branch B with respect to A
commit b1
commit b2
... ...
commit bn

但关于master分支B看起来像这样：

Branch B with respect to master
commit a1
commit a2
...
commit an
commit b1
commit b2
...
commit bn

请注意，自从a1 a2 ... an B A创建A后，master尚未合并到A。

现在master被主存储库的所有者合并到github中的upstream。如果您在提交后a1 a2 ... an提取upstream/master master将出现在$ git checkout master $ git fetch upstream $ git merge upstream/master但不会出现在您的本地upstream/master中。要获得当地的母版，您必须将其合并到您当地的分支机构中。

master

将a1 a2 ... an合并到本地master后，即在a1 a2 ... an提交后B提交Branch B with respect to master after upstream/master is merged to master commit b1 commit b2 ... commit bn后，B会自动将A移除

现在来自an+1 an+2 ... an+m的请求将仅包含此更改，并且可以合并它们。

但是，有一个问题。如果您在从A创建B后对其进行了更多更改，即新的提交B在合并之前被推送到A，那么您将需要这些提交master也是。如果是这种情况，那么您可以git rebase和interactive rebase rebase到LK_TableName（或合并A后到protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Properties<Guid>() .Where(p => "LK_" + p.Name == p.DeclaringType.Name + "Id") .Configure(p => p.IsKey()); }）。请熟悉rebase，因为这是进行此类工作的最强大工具。

警告：请注意// Counter: keeps track of the order of the column inside the composite key var tableKeys = new Dictionary<Type,int>(); modelBuilder.Properties<Guid>() .Where(p => { // Break the entiy name in segments var segments = p.DeclaringType.Name.Split(new[] {"LK_","_LK_"}, StringSplitOptions.RemoveEmptyEntries); // if the property has a name like one of the segments, it's part of the key if (segments.Any(s => s + "ID" == p.Name)) { // If it's not already in the column counter, adds it if (!tableKeys.ContainsKey(p.DeclaringType)) { tableKeys[p.DeclaringType] = 0; } // increases the counter tableKeys[p.DeclaringType] = tableKeys[p.DeclaringType] + 1; return true; } return false; }) .Configure(a => { a.IsKey(); // use the counter to set the order of the column in the composite key a.HasColumnOrder(tableKeys[a.ClrPropertyInfo.DeclaringType]); });。如果以错误的方式使用，很容易搞砸了。在尝试使用实际工作分支之前，最好先尝试一些测试分支。

如何在拉取请求之后但在上游合并之前管理Github协作的进一步开发

2 个答案: