当我们的工作流程包含大量未提交的代码时,是否存在使用git-pull的最佳实践,而不是存储？

Question

我的团队和我是Git的新手; 到目前为止我们已经使用过CVS了.我们有一个远程存储库,我们每个人都有自己的存储库.我们每个人都在研究一个功能或错误,但我们中的一些人可能会在相同功能的不同部分工作.

当一个人完成后,他们会提交并推动他们的更改.另一个程序员可能想要使用该代码(例如,如果一个人正在使用BL,另一个正在使用UI),但是没有提交任何内容,因为代码可能甚至还没有编译,或者工作目录可能仍然是脏的.

到目前为止,我只发现了使用藏匿的建议,但我们觉得它很不舒服.我们想从遥控器中提取代码并简单地将其与未提交的代码合并,但据我了解Git,这可能是不可能的.

您认为我们使用遥控器的最佳方式是什么？

Answer 1

问题

您的工作流程中存在CVS/SVN习惯,尤其是"大补丁"思维模式.

解决方案

Git有一个非常便宜的分支模型和交互式分期.这样做的结果是您应该在功能分支上工作,并将非集成分支视为补丁队列.

因此,您应该做一些更易于管理的事情,而不是"代码,代码,代码,代码,推送,拉动,合并,尖叫":

1. 分支很多.为每个迷你功能或变更集创建一个分支.
2. 为您的私人分支机构提供大量小的原子更改.git add -p是你的朋友.
3. 在合并之前,将您的私有分支重新映射到集成分支.
4. 每次完成更改集或完成功能时,请推送到集成分支.

如果您开始将Git提交视为补丁,并将分支视为补丁队列,那么您最终会得到一个工作流程,人们可以在存储库中挑选或合并小的更改集而不会出现偏头痛.Git分支模型使其变得简单,但是由您的团队将工作分解为正确的大小.

Answer 2

只要您不推送自己的代码,就可以提交,然后再提交git pull.

在下次推送之前,提交将保留给您的仓库.

因此,您可以在同一个feature分支机构工作,并仍然受益于同事的推动.

但是,如果你还必须发布自己的作品,那么你可以使用一个" developerX_feature"分支,为了你推你自己的分支机构,以及其他来取,然后你的分支合并到自己的" developerY_feature在当地的回购"分支.