git这货共有几个合并策略_百度知道
git这货共有几个合并策略
提问者采纳
　git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：　　去自己的工作分支　　$ git checkout work　　工作　　....　　提交工作分支的修改　　$ git commit -a　　回到主分支　　$ git checkout master　　获取远程最新的修改，此时不会产生冲突　　$ git pull　　回到工作分支　　$ git checkout work　　用rebase合并主干的修改，如果有冲突在此时解决　　$ git rebase master　　回到主分支　　$ git checkout master　　合并工作分支的修改，此时不会产生冲突。　　$ git merge work　　提交到远程主干　　$ git push　　这样做的好处是，远程珐敞粹缎诔等达劝惮滑主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。
其他类似问题
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁git这货共有几个合并策略_百度知道
git这货共有几个合并策略
提问者采纳
一般情况下;（fast-farward merge），会直接将Master分支指向需合并的分支。　　希望我的回答对你有帮助　　您好;快进式合并&quot，Git执行&quot，我来为您解答，你可以去仔细研究一下：　　git merge的合并策略可以在git merge --help里面根据不同的参数产生不同的合并策略
微软认证系统工程师
其他类似问题
git的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁git这货共有几个合并策略呢？ - GIT - 网站开发技术
帮助别人就是帮助自己！
如果这里解决了您的问题，请您点一下推荐
git这货共有几个合并策略呢？
-& FETCH_HEAD
Merge made by the 'recursive' strategy.
只见过一只呢：（
git merge的合并策略可以在git merge --help里面根据不同的参数产生不同的合并策略，你可以去仔细研究一下。一般情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向需合并的分支。
我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看
引用 2 楼 jianwu5 的回复:
我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看这篇吧&&
哦打错了，是下一commit
引用 2 楼 jianwu5 的回复:
我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看这篇吧&&
很少用rebase这种高级功能：（
这货有啥用？
出现很多冲突，会郁闷死鸟的：（
引用 4 楼 myy101 的回复:
引用 2 楼 jianwu5 的回复:我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看这篇吧&&
很少用rebase这种高级功能：（
这货有啥用？
出现很多冲突，会郁闷死鸟的：（
最近用github很郁闷的说，网速慢的时候老是提醒连接失败
引用 5 楼 jianwu5 的回复:
引用 4 楼 myy101 的回复:引用 2 楼 jianwu5 的回复:我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看这篇吧&&
很少用rebase这种高级功能：（
这货有啥用？
出现很多冲突，会郁……
乃回去用svn吧：）
引用 2 楼 jianwu5 的回复:
我刚使用，而且是windows版本。很不错的说！！！最近非常非常火，而且github托管了不少大项目！
貌似还有个分支的衍合rebase，它是先在基干上重演分支的演化，再快照到基干上直接变成基干的下一分支。看这篇吧&&
这篇写的很全，不过对git的新用户来说，显得复杂了些。最好是在测试环境中边看边做，有助于更好的理解。git这货共有几个合并策略_百度知道
git这货共有几个合并策略
我有更好的答案
按默认排序
Git执行&quot，你可以去仔细研究一下。一般情况下;快进式合并&（fast-farward merge），会直接将Master分支指向需合并的分支git merge的合并策略可以在git merge --help里面根据不同的参数产生不同的合并策略
　　git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：　　去自己的工作分支　　$ git checkout work　　工作　　....　　提交工作分支的修改　　$ git commit -a　　回到主分支　　$ git checkout master　　获取远程最新的修改，此时不会产生冲突　　$ git pull　　回到工作分支　　$ git checkout work　　用rebase合并主干的修改，如果有冲突在此时解决　　$ git rebase master　　回到主分支　　$ git checkout master　　合并工作分支的修改，此时不会产生冲突。　　$ git merge work　　提交到远程主干　　$ git push　　这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。
其他类似问题
git的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁1st Edition
6.7 Git 工具 - 子树合并
现在你已经看到了子模块系统的麻烦之处，让我们来看一下解决相同问题的另一途径。当 Git 归并时，它会检查需要归并的内容然后选择一个合适的归并策略。如果你归并的分支是两个，Git使用一个递归策略。如果你归并的分支超过两个，Git采用章鱼策略。这些策略是自动选择的，因为递归策略可以处理复杂的三路归并情况——比如多于一个共同祖先的——但是它只能处理两个分支的归并。章鱼归并可以处理多个分支但是但必须更加小心以避免冲突带来的麻烦，因此它被选中作为归并两个以上分支的默认策略。
实际上，你也可以选择其他策略。其中的一个就是子树归并，你可以用它来处理子项目问题。这里你会看到如何换用子树归并的方法来实现前一节里所做的 rack 的嵌入。
子树归并的思想是你拥有两个工程，其中一个项目映射到另外一个项目的子目录中，反过来也一样。当你指定一个子树归并，Git可以聪明地探知其中一个是另外一个的子树从而实现正确的归并——这相当神奇。
首先你将 Rack 应用加入到项目中。你将 Rack 项目当作你项目中的一个远程引用，然后将它检出到它自身的分支：
$ git remote add rack_remote :schacon/rack.git
$ git fetch rack_remote
warning: no common commits
remote: Counting objects: 3184, done.
remote: Compressing objects: 100% (), done.
remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
Receiving objects: 100% (), 677.42 KiB | 4 KiB/s, done.
Resolving deltas: 100% (), done.
From :schacon/rack
* [new branch]
-& rack_remote/build
* [new branch]
-& rack_remote/master
* [new branch]
-& rack_remote/rack-0.4
* [new branch]
-& rack_remote/rack-0.9
$ git checkout -b rack_branch rack_remote/master
Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
Switched to a new branch &rack_branch&
现在在你的rack_branch分支中就有了Rack项目的根目录，而你自己的项目在master分支中。如果你先检出其中一个然后另外一个，你会看到它们有不同的项目根目录：
KNOWN-ISSUES
$ git checkout master
Switched to branch &master&
要将 Rack 项目当作子目录拉取到你的master项目中。你可以在 Git 中用git read-tree来实现。你会在第9章学到更多与read-tree和它的朋友相关的东西，当前你会知道它读取一个分支的根目录树到当前的暂存区和工作目录。你只要切换回你的master分支，然后拉取rack_branch到你主项目的master分支的rack子目录：
$ git read-tree --prefix=rack/ -u rack_branch
当你提交的时候，看起来就像你在那个子目录下拥有Rack的文件——就像你从一个tarball里拷贝的一样。有意思的是你可以比较容易地归并其中一个分支的变更到另外一个。因此，如果 Rack 项目更新了，你可以通过切换到那个分支并执行拉取来获得上游的变更：
$ git checkout rack_branch
$ git pull
然后，你可以将那些变更归并回你的 master 分支。你可以使用git merge -s subtree，它会工作的很好；但是 Git 同时会把历史归并到一起，这可能不是你想要的。为了拉取变更并预置提交说明，需要在-s subtree策略选项的同时使用--squash和--no-commit选项。
$ git checkout master
$ git merge --squash -s subtree --no-commit rack_branch
Squash commit -- not updating HEAD
Autom stopped before committing as requested
所有 Rack 项目的变更都被归并并且可以进行本地提交。你也可以做相反的事情——在你主分支的rack目录里进行变更然后归并回rack_branch分支，然后将它们提交给维护者或者推送到上游。
为了得到rack子目录和你rack_branch分支的区别——以决定你是否需要归并它们——你不能使用一般的diff命令。而是对你想比较的分支运行git diff-tree：
$ git diff-tree -p rack_branch
或者，为了比较你的rack子目录和服务器上你拉取时的master分支，你可以运行
$ git diff-tree -p rack_remote/master
Patches, suggestions and comments are welcome.
Git is a member of