git merge --squash 是否会导致跨分支合并令人头痛
我所在的团队正在不断壮大并使用 git。我们通常在自己的分支机构工作。
我从另一个工作人员存储库中提取了一些更改。他的更改最终被添加到并合并到具有压缩提交的主分支中。
当我尝试从 master 获取并合并时，我遇到了很多冲突。我认为这是因为挤压合并以及它会混淆合并跟踪的事实。有没有简单的方法可以解决这个问题？
第二。如果开发人员正在处理多个分支，并且在进入 master 之前可能需要彼此进行更改，那么有没有办法在继续在 master 上进行压缩提交的同时处理此问题。
Rebase 被提及很多。但我不明白这如何适用于多个根分支？
I'm working in a team which is growing and making use of git. We are generally working in our own branches.
I pulled some changes from another workers repository. His changes eventually were added to and merged into a master branch with a squash commit.
When I tried to fetch from master and merge I got a load of conflicts. I am thinking this is because of the squash merge and the fact that it will confuse the merge tracking. Is there an easy way out of this?
Secondly. If developers are working on a number of branches and possibly needing each others changes before they go into master is there a way to handle this while continuing with the squash commits on master.
Rebase is mentioned a lot. But I don't see how this will work with more than one root branch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，挤压会对重复合并造成严重破坏。最好的建议是不要压制 - 具体来说，不要压制公开的东西。在与其他人共享之前重写您自己的提交，但是一旦共享它们，它们应该保持原样，并定期合并提交。
您仍然可以通过使用 git log --first-parent 来将合并分支的 log 压缩为合并提交，同时保留实际的 < em>历史完好无损。
Yes, squashing plays havoc with repeated merging. The best advice is don't squash - specifically, don't squash things that are public. Rewrite your own commits before you share them with others, but once they're shared, they should remain as they are, with regular merge commits.
You can still get reasonable log output by using
git log --first-parentto condense the log of a merged branch down to just the merge commit, while keeping the actual history intact.我想补充一点，挤压只会在分支公开时造成严重破坏，如果开发人员在本地分支上工作且提交混乱，例如“哦，真糟糕，又破坏了这个”，然后是“它有效！”接下来是“该死的，它又坏了”，然后是“好吧，现在修复它”，很容易将这些（在它们被推送到远程存储库或共享之前）压缩到一个提交中，并附上一条关于代码中发生了什么变化的好消息。
一旦推送到远程仓库，这看起来与在没有压缩的情况下创建的单个正常提交相同，就好像开发人员正在与天使一起编程，确保他所做的一切都是完美的，然后开发人员可以在本地自由使用 git 进行增量更改，这我发现对于找出我最近在代码中破坏的内容很有用。
我的看法：squash 对于本地工作流程（即一个开发人员）来说是一个很棒的工具。一旦提交被共享，它就永远不应该被压缩。
I would add that squashing only causes havoc when the branches are public, if a dev works locally on a branch with messy commit such as "oh bummer broke this again" followed by "it works!" followed by "darn it's broken again" followed by "ok fixed it now" it's easy to squash these (before they are pushed to a remote repo or shared) into one commit with a nice message about what has changed in the code.
once pushed to a remote repo this will look identical to a single normal commit created without squash, as if the developer was programming with angels making sure everything he did was perfect, and the dev is then free to use git locally for incremental changes, which I find usefull for figuring out what I most recently broke in the code.
my take on things: squash is a great tool for a local workflow, ie one dev. once a commit is shared it should never be squashed.