混帐：藏起来，而不是分支

在我的日常工作中，我发现自己做一个新的代码提交习惯使用Git：而不是创建dev/master/main分支的一个分支，有做我的变化，当我已经完成合并，然后回通过解决冲突到参考分支我根本不分支。相反，我在引用分支上本地执行更改，并且当我必须推送更改时，为了获取其他人已更新的更改，我隐藏了更改，我提交了新提交，然后将我的隐藏更改应用于这些其他人的最新提交并解决冲突（如果有的话）。然后我终于推动变革。我发现这种做法比处理分支更容易和简单。混帐：藏起来，而不是分支

是提交更改错误的，可以接受的或比传统的分支甚至更好的这种方式？为什么？

来源

2014-12-01 AxeEffect

我的理解是你没有做'git commit'，你只是在你的工作目录下开发，直到你决定从上游引入更改？ – 2014-12-01 22:26:49

不，在我要推动我的改变之前，我会立即做出改变。取决于我可以做或不做的任务有多长时间。 – AxeEffect 2014-12-01 22:32:18

只要您在本地进行提交（这只是提供了防止意外删除的附加措施），您正在处理的分支并不重要。 – 2014-12-01 23:15:41

您的规定工作流程与git stash（并且完全可以接受）没有什么不对，因为请记住，它是您的本地存储库。只要你推向世界其他地方的事物保持一致，你就可以做任何你想做的事情。例如，不要让rewriting history提交给其他人。

这里认识到的重要一点是，分支和积攒并不是相互排斥的。如果存储满足您当前的需求，请使用它，直到more complicated scenarios表面，您将需要考虑分支和存储。

有几件事情要记住：

在混帐分支是一个低到没有仪式的操作。在我的团队中，这是我们日常工作流程的一部分。
分支允许团队成员共享工作正在进行代码是不准备推到master（或任何你上游主干分支）。这基本上使我们能够在团队成员中形成团队。
分支允许我们引入请求提交到GitHub上，同时促进其他项目，或请求代码评审。
我总是把我的藏匿名单小，以避免在未来的困惑，通过使用git stash pop和git stash drop。
存储合并冲突仍然存在。

来源

2014-12-01 20:11:54

我完全同意。正如你所说，他们两个都是补充而非排他性的。但即使考虑分支有多容易，也可能有一些简单的场景，其中的分叉可能比分支更容易。 – AxeEffect 2014-12-01 21:52:23

@AxeEffect很高兴听到。希望有所帮助。如果您喜欢答案，请考虑将其标记为可接受。谢谢！ – 2014-12-01 21:55:29

毫无疑问，你的答案很好。然而，由于这不是一个数学/具体问题，它可能有几个有效的好答案，听到他们会很高兴。因此，我想留下一些时间，然后再标记“已接受”的答案。 – AxeEffect 2014-12-01 21:59:45

通常是有点等于衍合你遵循了一个你的特性分支，因此，例如你按照上游主的featureX，你再这样做：

git fetch --all 
git checkout featureX 
git rebase master

根据您的更改，这将适用新的拉代码。

如果你已经有了窝点周围，你可以将它们转换为拥有分支机构的东西，如：

git branch featureX [<stash>]

我发现更地道处理功能分支不是处理储物箱，这对我去容易忘记你您的最终远程开发回购中不能有push them around。

来源

2014-12-01 19:40:18 DRC

混帐：藏起来，而不是分支

回答

相关问题