为什么我们的Git存储库中缺少代码，并且可以通过rebase解决？

我们使用，基本上是一个我们创建分支的中央存储库。当我们处理错误修复和小补丁时，我们将创建master的一个分支：

git checkout -b master_bug123 master

完成提交后，我们将执行以下操作将其合并回：

git checkout master
git pull
git merge master_bug123
git branch -d master_bug123

有时候，我们有一些大项目需要大家共同努力。例如，使网站具有响应性：

git checkout -b responsive master
git push -u origin responsive

然后，团队的其他成员可以创建自己的功能分支，就像使用master一样：

git pull
git checkout -b responsive_fixmenu responsive

目前，我们正在这里进行工作，然后将更改合并回以供其他人使用：

git checkout responsive
git pull
git merge responsive_fixmenu
# possibly fix conflicts, add, commit, etc
git push -u origin responsive

有时我们会发现代码丢失了。我最初的想法是，这可能是因为我们中的一个人错误地解决了冲突。但在调查的时候，我有点困惑。一个名为

core.js

的特定文件缺少大量代码。文件中包含一个字符串

mb search

，我想我可以用它作为

git show

和

grep

的一部分，以查看它何时出现和被删除。使用

git log core.js

给我一个提交列表，然后我使用该列表执行类似

git show abc1234:path/to/core.js | grep-c'mb search'

的操作，以输出该提交在文件中出现的次数，但显示给我的不是简单的0、0、1、1、1，甚至不是0、0、1、1、0（这一点被错误地删除了），但是看起来非常随机的0，0，1，0，1，0，0，1等等

这就引出了我问题的第一部分。如果另一个用户出现并进行更改和提交（我们称之为abc1111），然后执行一个

git pull

（在其他推式更改中合并）来创建合并提交，我说的对吗（我们将其称为abc222——mb搜索合并在其中），然后提交abc1111将不包含

mb搜索

代码，该代码在推送后随后与abc222合并在一起？如果是这样，我如何可靠地判断某些代码何时被删除？

这就引出了

responsive

分支。在我们以与

master

分支相同的方式使用

responsive

分支之前，我们通常只直接对

responsive

进行更改、提交和推送。在默认情况下，我们使用

responsive

分支。此时，我们发现有很多问题，包括我相信这是意料之中的。作为使用git的初学者，为了掌握基本知识，我们决定只使用

merge

，而从不使用

rebase

，我们认为我们没有问题。但是现在我看到了上面的问题，我想知道上面的问题是否可以解决（或者至少有帮助）改为使用

重设基础

，但仅在特定条件下使用

我认为在我们在主

响应式
存储库上重新设置基址之前，提交到处都是，代码丢失等等，这通常是你对那些还没有正确掌握基址规则的人的期望。但是，这是否是对基址的合法使用，而且安全

git checkout -b responsive_somefeature responsive
# write code, make commits
git pull --rebase responsive
git checkout responsive
git merge responsive_somefeature

我说的对吗？这将使我在
responsive\u somefeature
中的所有新工作基于
responsive
的
头部，这样当我将其合并回时，它将是线性的？最后一个
合并
是正确的，还是应该/可能也是一个
重基

我说得对吗

是：合并更改将创建具有两个（或更多，但通常是两个）父项的新提交。它不会重新写入任何一个父项以包含另一个父项


如果是这样，我如何可靠地判断某些代码何时被删除

未引入功能与删除功能不同。合并后的下图：

base -> abc1111 [foo]  -> {merge} abc2222 [with foo and mb-search]
     \                         /
      \-> abc0000 [mb-search] /

不会显示删除mb搜索。但是，在提交中查找mb-search也不会显示。基本上，您检查的是错误的内容


相反，请尝试
git bull--reverse base..abc222

--逆转

向前而不是向后浏览历史记录。这不会显示出现行的版本，而是显示中的最后一个版本
这需要一系列的修改，如
START..在START中存在责备路径的地方结束

如果你只是想看看是谁删除了这行


哦，您的功能分支重设基础工作流可能应该是：

git checkout -b responsive_somefeature responsive
# write code, make commits

# update local branch
git checkout responsive
git pull

# rebase feature onto updated branch
git rebase responsive responsive_somefeature
## NB. this ^ will leave your feature branch checked out

# finally merge (this should be fast-forward since we just rebased)
git checkout responsive
git merge responsive_somefeature

定期进行更新和重设基础是明智的，这样您就不会反对过时的
响应性
视图，谢谢。顺便问一下，当您说
base
时，您是指它第一次出现吗？
base
在示例中只是您想要的更改的共同祖先，以及功能分支。谢谢@无用。另外，你介意详细说明一下你建议的重设基础工作流和我写的工作流程之间的区别吗？如果你合并，你在最后一个共同祖先和合并提交之间有两条平行的时间线。如果你只看按日期排序的提交，这些时间线将交错，因此一个分支上的更改将被忽略似乎出现和消失。如果你改为重定基址，你会得到一个没有神秘交错的单一时间线。