分支和提交
mb: A -> B -> C -> G -> H -> I
\
db: -> D -> E -> F
在db（开发分支）和mb（主）上进行。 重新定位是我通常做的事情。总是，实际上。但是，在＆＃34; F＆＃34;对mb的反驳是不可能的（太多奇怪和奇怪的冲突）。 解决方案：樱桃挑选！
我从＆＃34; mb ＆＃34;创建了一个新分支。 - 让我们称之为＆＃34; nmb＆＃34; （新主分公司） 在这个分支中，我选择提交D，E和F来自＆＃34; db ＆＃34;。 （这是一种简单的方法，因为在＆＃34; db＆＃34;中提交的次数少于＆＃34; mb＆＃34;）
此时，我没有分析git日志，这可能会让我的生活更轻松。 所有文件到位和应用程序按预期工作，所以我继续工作......
现在 - 完全相同的情况正在重复。
我不能退缩＆＃34; nmb＆＃34;反对＆＃34; mb＆＃34;日志看起来很尴尬：
F' 10/6 -14 12:23:43
E' 10/6 -14 10:03:30
D' 10/6 -14 09:54:10
I ...
H ...
G ...
F 10/6 -14 12:23:43
E 10/6 -14 10:03:30
D 10/6 -14 09:54:10
C ...
B ...
etc
D＆＃39;和D，E＆＃39;和E，F＆＃39;和F共享相同的日期/时间，消息和文件，但不同的提交哈希值。
这是樱桃选秀的结果吗？一个提交原始提交和一个提交樱桃选择？
git log是否显示正确的数据？
我真的迷失在git land。
我应该添加一个新手，而不是非常熟悉gits所有不错的功能。这可能是我身边的一个巨大的困难，最容易的事情是将文件保存在别处并重新开始......
答案 0 :(得分：1)
这是樱桃选秀的结果吗？一个提交原始提交和一个提交樱桃选择？
是的：这就是采摘樱桃的方式;它复制提交 - 复制消息和时间戳，即。它也会与原始版本进行相同的更改。当您在nmb并且git cherry-pick D时，git基本上会git show D查看您做了什么，应用了相同的更改，并进行了新的提交D'，离开{{1}周围。
git log是否显示正确的数据？
假设你已经要求它向你展示几个分支，是的。
重新定位就是我通常所做的事情。
所有“rebase”都是对类固醇的挑选（实际上是这样），然后是另外一招。
让我们用另一个方向的箭头重绘你的第一张图片，因为它确实是如何工作的：一个分支指向最尖端的提交，每个提交指向其父代。 （就此而言，合并只是一个指向至少两个父母的提交。）Git必须以这种方式做事，因为所有提交都是永久的 1 且不可更改 - 如果你试图改变任何东西，你得到一个新的，不同的提交。
D（我在A <- B <- C - G - H - I <-- mb
\
D - E - F <-- db
之后停止了对箭头指示的困扰，但它们基本上是向左的。）
如果你想将C重新定义到db，你可以告诉git：
mb git checkout db
git rebase mb
所做的是查找当前分支（rebase）与目标分支（db）连接的位置，并在此之后进行所有提交 - 在这种情况下， mb，D和E - 并挑选它们。要进行挑选，它会创建一个新分支 - 它实际上使用匿名分支，但我们只需将其称为F - 然后执行tmp命令。如果一切顺利，结果是：
git cherry-pick之后，git只会删除旧的 D'- E'- F' <-- tmp
/
A <- B <- C - G - H - I <-- mb
\
D - E - F <-- db
标签并在db标签上粘贴db：
tmp大多数git命令都没有显示旧的，被遗弃的提交，但由于它们是半永久性的， 1 它们仍然在那里。
1 提交（以及存储库中的任何其他对象，实际上）只要它们通过提交图“可达”就会永远存在。分支名称指向分支的尖端，使特定的提交可达。由于每次提交都带有其父ID，因此这些提交也是可以访问的，而它们的父母也是可以访问的，依此类推。它只是未标记的对象无法访问。
当git更新分支时，它通常会记录“分支用于指向的位置”。这些引用日志（简称“reflogs”）在保持提交可达的情况下计数，但 D'- E'- F' <-- db
/
A <- B <- C - G - H - I <-- mb
\
D - E - F <-- [old db, now abandoned]
忽略它们，除非您告诉它使用reflog（git log）。
每个reflog条目都有一个时间戳记。默认情况下，reflog条目最终会在30到90天后过期。一旦reflog条目消失，这些提交将真正被取消引用，然后git log -g最终将删除它们。