Igo*_*nko 10 git version-control
最近我开始在Git工作,有8人团队.我们决定在每个个人分支中单独工作(有人在某处阅读)是一种很好的做法.在这样的拓扑中工作了一段时间后,我很生气地从主服务器获取/合并更改所需的时间并将其推回/合并.我花在问题上的一半时间 - 与某人的变化合并.
我想每2个小时从主人那里得到最新的变化.但每次我都要花时间将它们合并到我的分支机构中.
我认为git没问题,我们选择了错误的工作流程.何我们可以避免经常合并并且总是有最新的主人登记？
UPD.
正如Neil注意到的那样 - 我们中的一些人同时在一段代码上工作.我们将在其他VCS中合并 - 这是真的.但不像git那么频繁!
例如:我想重命名项目中的类.本课程广泛用于项目中.我在我的分店里做过.好吧,我每次都从主人那里得到 - 从我的队友那里合并.然后我决定最终将它合并到主人.另一个合并.我做到了.然后我的队友拉了另一个合并.因此,团队合并的时间浪费了.
我不是在责备git.我认为这有更好的工作流程.现在我们决定拒绝使用分支机构并直接与主人合作,希望没有人会破坏我们的构建.
UPD.2
此外,它经常发生,我正在与我从未修改过的代码合并.这很奇怪,因为我必须解决我不知道的代码冲突.可能还有一些避免这些合并的变通方法？
小智 14
如果您有很多需要手动解决的合并冲突,那么您的问题就是应用程序中的代码布局 - 这意味着有几个人在同一个源文件上不断工作.您可能需要考虑使代码更加模块化,以便各个开发人员在处理不同功能时不必更改相同的文件.如果不这样做,您将遇到与所有VCS合并的问题.
ssa*_*ota 10
似乎有多个人正在处理同一个文件并且经常更改它.这意味着您的任务部门或项目模块化是错误的.
更新:
有三种工具可以帮助您
使用rebase保持历史线性.这只会解决周围的冲突,但这个想法是在推送到存储库之前,或者请求维护者从您的存储库中提取,以便git rebase在当前版本之上使用.注意:不要对已发布的历史记录执行此操作.这可以确保其他人不必解决冲突.
舌头在脸上:如果你厌倦了合并,你可以git pull --rebase改为;-)虽然这不会帮助你解决冲突.
如果你发现自己解决同冲突连连,尝试启用git rerere-它是工具,重新使用重新绳再冲突合并的解决方案.
您需要设置配置变量rerere.enabled才能启用此命令.
如果标准3向文本合并不适合您,但可以以编程方式解析合并冲突,则可以为指定文件设置合并驱动程序.请参阅gitattributes联机帮助页中的merge属性说明.
替代解决方案是改变工作方式.
相反的第一拉动,解决合并,然后推到"中央"资料库,你可以问维护者从你拉的变化(git request-pull可能有助于在这里).
如果您是维护者,您可以要求开发人员修改他/她的更改,以便它可以干净地合并(例如,通过在当前版本之上进行重新定位),或者要求他们合并.他们可能更清楚如何解决冲突.
只要其他人将更改推送到中央存储库,每次您将存储库与中央存储库同步时,就会发生合并.我猜你的意思是你每次都厌倦了解决冲突.
这个问题与git无关,它与您正在使用的分支模型以及您正在更改的代码部分有关.如果你想完全摆脱合并,那么如果你想摆脱合并冲突,开始查看冲突是什么以及如何以更正交的方式工作,这是不可能的.
可能是某人正在更改文件并使用与其他人不同的行结尾进行推送.此文件将始终与使用另一行结尾的人发生合并冲突,例如,如果您有人在unix和windows上进行开发.