我是git的新手。 比方说，我已经从远程本地分叉了一个存储库，它被称为localRepo。 Master和testBranch有两个分支。 testBranch提前100次提交，落后5000次提交。对testBranch进行了更改，但从未与Master合并。所以我想在我的分叉localRepo中将testBranch重新绑定到master。
我做了以下事情：
$scope.dates = response.data.outgoing.dates;
$scope.date_pick = Date.parse($scope.dates[0]);
$scope.today = function(){
$scope.date_pick = new Date();
};
$scope.today();
$scope.options = {
minDate: new Date(),
showWeeks: false
};
function areDatesEqual(date1, date2) {
return date1 == date2;
}
$scope.disabled = function(data) {
console.log("TRIGGERED");
var date = data.date,
mode = data.mode;
var isRealDate = false;
for (var i = 0; i < $scope.dates.length; i++) {
if (areDatesEqual($scope.dates[i], date)) {
isRealDate = true;
}
}
return (mode === 'day' && isRealDate);
};
git checkout testBranch git fetch origin 我遇到了几个冲突，我正在使用mergetool（kdiff3）手动解决它并说出要使用的删除或修改的文件等...
由于约有5000次提交，是否有可能发生更多冲突？如果我像这样手动解决冲突，我想知道需要多少天！这将是非常乏味和不切实际的。
我是以正确的方式做到的吗？
这是此方案的唯一方法吗？还是其他任何有效的方式？
答案 0 :(得分：3)
不，除了rebase之外别无选择。就是这样。获得的经验教训：早期变基，经常变基。落后于你的提交意味着你迟早会浪费很多时间。两年前，我编写并合并了一个200个提交功能分支，该分支是在六个月的时间内开发的。我不知道在这六个月内合并了多少次提交。但我确信它们也有数千个。如果我等到我完成我的功能分支，并试图改变，我就会遇到大麻烦。但是我每天都在重新定位，最终的合并变成了一个大而肥胖，没什么汉堡。
如果您的功能分支中的大约一百个提交可以在逻辑上划分为小块，则可以将rebase分成几个阶段。如果您的功能分支中有几个主要检查点，那么您的功能分支功能齐全且可测试，您可能会考虑将所有提交仅提交到检查点，然后重新设置这些检查点，然后测试它们。然后，一旦您测试了提交的初始块在rebase之后正在工作，请继续并重新提交提交，直到下一个检查点。
当您一次性修改所有内容时，git将仅在每次无法重新绑定的提交时停止。至少通过这种方式，您可以更好地控制流程。您可以在预定的检查点停止并暂停，并对重新定义的更改进行广泛的回归测试，然后继续。
但请注意，要使其工作，您必须完美地跟踪功能分支上的所有提交;哪一个已被重新定位，哪些已经重新定位。
答案 1 :(得分：2)
您可以改为使用merge。
merge的优点：必须解决仅在testBranch的当前最终状态和当前状态{{}之间累积的不兼容的更改1}}（虽然冲突的地方在行号方面可以相同），而不是在master的新提示上重新应用testBranch的每个提交（这就是master工作）。 rebase的缺点：历史图表变得更加复杂，有些人不喜欢这样复杂的图表，特别是那些从＆＃34;遗留＆＃34;具有简单树状历史图的VCS。
有时tools like git rerere 可能会提供帮助，尤其是在处理一组重复性冲突时。但当然它不是一颗银弹。
是的，请遵循@SamVarshavchik的建议：定期跟踪上游变化并保持平稳＆＃34;保持平稳＆＃34;与他们在你的功能分支，而不是有一千个线冲突一个阳光明媚的早晨。或者不是那个晴天，或者不是早晨 - 实际上它并不重要，因为人们不得不花费数小时，数天甚至数周来解决它。
通常，将大型功能分支拆分为较小的部分并将这些更改尽快推送到上游会有所帮助。因此，你的同事会使用你的代码和你的方法，而不是发明他们自己的[冲突]，所以合并/重组对所有各方来说都会更简单。
在项目中使用强制性对等代码审查系统也很有用，即使是功能分支中的提交也是如此。如今，我有点怀疑人类是否有能力通过主演来追踪复杂代码中的可能错误。但至少所有参与特定代码开发的人都了解提议的更改，并可以协调不同分支的工作。