假设我们有以下修订图:
A-X-Z--B
\
\-C
在B和C之前使用A.进一步假设我从上游重新绑定A,创建一个新的提交A*,然后将B和C重新绑定到A*上.生成的修订图如下:
A*-X'-Z'-B
\
\-X"-Z"-C
请注意,不再共享共享历史记录.有没有一种简单的方法可以解决这个问题,除了说,重新定义B然后明确地将C重新定位到Z'.换句话说,是否有更好的方法可以同时自动修改多个分支以保留共享历史记录？只是人为地在分割点放置一个标记,或者手动检查图形以找出修改C以保留共享历史记录的提交的sha1似乎有点尴尬,更不用说开放可能性了错误,特别是因为我必须在每次改变时都这样做,直到我检查上游分支的变化.
这是我目前的git树:
A - H (master)
|
\- B - C - D - E (feature)
|
\- F (new)
|
\- G (other)
而且我想重新设计侧支,这取决于H而不是A:
A - H (master)
|
\- B'- C'- D'- E'(feature)
|
\- F'(new)
|
\- G'(other)
看似简单的概念,很难自动完成.这已经在这里和这里被问过,但是提议的解决方案对我不起作用.
首先,正如前面所指出的那样,git branch当前分支存在时,输出并不容易解析(有一个*前置).但这不是一个塞子,在我的情况下,我可以轻松提供名称feature,new并other手动,或确保当前分支master.
然后我尝试了这些命令:
git rebase --committer-date-is-author-date --preserve-merges --onto master feature^ feature
git rebase --committer-date-is-author-date --preserve-merges --onto master …git pull --rebase删除未压缩的合并提交.有没有办法让它保存起来？
说我的历史看起来像 -
A
| \
B H
| |
C G
| |
D F
| /
E
(A作为合并提交.)
在git pull --rebase它成为 -
H
|
G
|
F
|
X
|
B
|
C
|
D
|
E
(X作为git pull --rebase我的历史中插入的新提交.) - A被删除.
我知道你可以使用它git rebase --preserve-merges来保存它们git rebase,但是我没有看到用它来保存它们的方法git pull --rebase.
假设我的Git存储库最初有两个分支:Foo和Bar.
... ? Foo ... ? Bar
我创建了第三个分支,FooBar,其中我提交了另外两个分支的合并.
... ? Foo ???
FooBar
... ? Bar ???
FooBar现在领先于Foo和Bar.接下来,我做了一些工作,仅在Foo上做了几次.
... ?? A ?????? B ?? C ?? D ?? Foo
FooBar
... ? Bar ???
问题是:由于分支FooBar的第一个父亲不再是Foo,我可以在分支FooBar中重新合并提交以再次将Foo和Bar作为其两个父母吗？换句话说,我可以将Foo中的开发项目与未更改的Bar一起合并到之前合并的FooBar中吗？
... ?? A ?? B ?? C ?? D ?? Foo ???
FooBar
... ? Bar ????????????????????????
我有一个(大)提交树,其中包含几个我想要重新绑定到另一个提交的合并提交.执行正常的rebase会导致git要求我解决合并冲突.我不想审查每个合并,因为这将是很多工作.在找到--preserve-merges选项后,这里有一个很好的解释,我认为我找到了完成这项任务的完美工具.但是,我似乎无法让它正常工作.我创建了一个演示问题的玩具示例.
从空文件夹开始,我们首先创建一个带有合并的分支和另一个我们将在其上进行rebase的分支.
A---B--
\ \
---C---D
\
---E
其中主指乙,分支指d和再见分支指È.
git init
echo Hello > Hello.txt
git add Hello.txt
git commit -m "Create Hello.txt (commit A)"
git tag start
echo World! >> Hello.txt
git commit -am "Change to Hello World (commit B)"
git checkout start
git checkout -b branch
echo Dave >> Hello.txt
git commit -am "Change to Hello Dave (commit C)"
git merge master
echo Hello …我合并了一个长期存在的分支,由于冲突的解决,我花了很多时间来完成合并.
我发现我无法发布我的工作git-svn:git svn rebase将重新绑定合并分支的所有提交,而不是提交一个单独的合并提交.我发现git merge --squash有点太晚了......
是否有可能将合并提交(rebase interractive？)更改为"squash merge"提交而不会丢失已经完成的所有冲突解决工作(即没有触发新的合并,因为我没有启用该rerere工具)？
我公司的政策是任何拉取请求都必须使用重新分支.我有一个本地Dev分支,它有'任务'分支:
remote master --------
\
Dev ------------------
\-----task1 \
\---task2
当主人得到更新时,我在主人身上重新开始.什么是管理分支task1和task2的最佳方式.他们仍在继续努力.重新分配每个任务分支似乎是我能看到的唯一方式.
我有一个来自 master 的功能分支。现在，master 分支已经高级，feature-branch 之上有许多子分支。我希望将所有新更改从主分支转移到我的功能分支中，并且不应干扰功能分支的任何现有子分支。
如果我在主分支上重新建立我的功能分支，则功能分支上的所有子分支都将陷入困境（根据我之前的经验）。
请告诉我我们该如何处理这个问题。
我们最近遇到了一个奇怪的合并问题,从一个分支发生到一个分支,我们看到了从来没有发生的冲突.
我终于找到了问题的根本原因:"合并提交"不是一个.我的意思是:从提交消息中,它看起来就像是一个合并提交:
Merge remote-tracking branch 'origin/master’ into branchName
Conflicts:
file1
file2
问题？这个提交只有1个父母!
所以,我很确定创建此提交的人没有手动输入所有这些内容.它来自某个时刻的真正合并提交.
但它最终只有1个父母？它是否已经重新定位？这是一种可能性,因为执行此操作的人将"pull --rebase"设置为默认值.但我无法真正重现这个问题.
有任何想法吗？
我有一个要转换为 Git 的 Mercurial 存储库。提交历史非常大，我不需要新仓库中的所有提交历史。一旦我将提交历史转换为 Git（并且在推送到新存储库之前），我想将某个标签之前的所有提交压缩为一个提交。
所以，如果我有：
commit 6
commit 5
commit 4
commit 3
commit 2
commit 1 -- First commit ever
我想结束：
commit 6
commit 5
commit X -- squashed 1, 2, 3, 4
注意：我需要压缩数以千计的提交。因此，手动挑选/标记它们不是一种选择。