blocks|key|4036847|text|是的，你可能会发现自己处于这种情况，但这是可以避免的。即使你决定只在几次(N次)提交后才决定push你的存储库，你仍然可以不断地从其他分支，这样你就可以总是与其他人正在做的事情集成。无论如何，Git在合并方面都做得很好。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4036848|entityMap^0|1A|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Well yes, you could find yourself in that situation, but it is avoidable. Even if you decide to push your repo only after several (N amount of) commits, you still can pull from other branches constantly so that you are always integrating with whatever other people are doing. And Git is pretty good at merging anyway.

blocks|key|2138273|text|不用谢。git中的每个提交都是唯一可识别的，无论它位于哪个repo中。因此，合并完全按照它们应该的方式工作。Git对冲突解决也有非常好的支持，这使得它在合并方面甚至比其他一些VCS更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2138274|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Not at all. Each commit in git is uniquely identifiable regardless of which repo it lives in. Therefore merges work exactly as they should. Git also has extremely good support for conflict resolution, making it even better at merges than some other VCSs.

blocks|key|3752069|text|这本质上取决于你决定push你的代码的频率和其他人pull代码的频率。例如，如果您推送了一个小的更改，而其他人拉出了该更改，这将不会是一个大型合并。但是，如果您直到多次在本地提交才推送，那么拉取可能是一个大型合并。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3752070|我希望这能帮到你。|3752071|entityMap^0|A|4|P|4|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

It essentially depends on how often you decide to <code>push</code> your code and how often others are <code>pull</code>ing the code. For example, if you push a small change and someone else pulls that change, it will not be a large merge. However, if you do not push until you have committed locally numerous times, then the pull could be a large merge.

I hope this helps.

blocks|key|4036982|text|真的，在git中几乎所有的情况下都有一种绕过合并的方法。不是合并，而是重新设置本地存储库的基址，重新安排历史。通过使用rebase，规范/源存储库永远不会重新排列，并且很少有任何合并提交，但本地存储库历史记录会重新排列，以便与主存储库更紧密地匹配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4036983|所以：|4036984|git+fetch
git+rebase+origin/master
//+resolve+any+conflicts+(if+there+are+any)+by+altering+your+own+commits
git+rebase+--continue
git+push|code-block|syntax|javascript|4036985|并且所有的提交都是原子的，并且源/主节点永远不会有任何合并提交。|4036986|现在，在极少数的情况下，重新建立基础的过程将变得复杂，你会发现自己解决了很多冲突，在这种情况下，你可能想要git+rebase+--abort并退出重新建立基础的过程，然后进行合并，但我已经几个月没有需要在这一点上求助于合并了，所以保持历史线性并不是太难。|offset|length|style|CODE|4036987|本质上，这是在采取破坏性最小的方法。你会说“嘿，我所有的提交都是我添加到本地主分支的--其他人放在中央分支/规范分支都是我的责任，所以-我-将会重新安排我的代码。”以这种方式，进入任何存储库的主分支的任何内容都首先被认为是规范的，其他人不必处理成功推送到主分支的任何内容的重写历史的合并提交。|4036988|entityMap^0|0|0|0|0|1H|I|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Really, there's a way around merges in almost all cases in git. Instead of merging, you rebase your local repository, re-arranging history. By using rebase, the canonical/origin repository is never re-arranged and rarely has any merge commits, but local repository histories are re-arranged to more closely match the main repo.

So:

<pre><code>git fetch
git rebase origin/master
// resolve any conflicts (if there are any) by altering your own commits
git rebase --continue
git push
</code></pre>

And all commits will be atomic, and the origin/master will never have any merge commits.

Now, in a rare rare case the rebasing process will become complicated and you'll find yourself resolving a lot of conflicts, in which case you may want to <code>git rebase --abort</code> and back out of the rebase process and then go for a merge instead, but I've gone months without needing to resort to a merge at this point, so keeping the history linear isn't too hard.

Essentially what this is doing is taking the least destructive approach. You are saying "hey, all of my commits are ones that I added to my local master branch -after- whatever other people put in the central/canonical branch are my responsibility, so -I- will be the one to re-arrange my code." In this manner, whatever goes into the master branch of whatever repository is deemed canonical FIRST gets precedence, and other people do not have to deal with merge commits that rewrite history for anything that is successfully pushed to the master branch.

I am getting into the GIT world, but it seems like GIT has a huge disadvantage.
Because your are submitting to your own local repository and only after several submissions your are submitting to the outside world, doesn't it creates many big merges?

Doesn't GIT force many big merges?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在进入GIT的世界，但似乎GIT有一个巨大的劣势。因为您正在向自己的本地存储库提交，并且只有在多次提交之后才会向外部世界提交，这不是会创建许多大型合并吗？

问GIT不会强制很多大的合并吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GIT不会强制很多大的合并吗？EN