Question

来自git stash的联机帮助页

插入脏树

当您处于某个事物的中间时，您会发现有   与您所做的工作可能相关的上游更改。   当您的本地更改与   在上游，一个简单的git pull将使您前进。

但是，在某些情况下，您的本地更改确实与   上游发生变化，而git pull拒绝覆盖您的   变化。在这种情况下，您可以将更改保存起来，执行   拉，然后藏起来，像这样：
$ git pull
 ...
file foobar not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop

为什么如果“您的本地更改与上游更改发生冲突，而git pull拒绝覆盖您的更改”，“您可以将您的更改保存，执行提取然后取消保存”？

收藏夹是否也有冲突并中止？

谢谢。

Answer 1

未隐藏的步骤确实可能存在冲突。但这不会中止 pop。它只会中止流行音乐的drop部分，而停止流行音乐的apply部分。

任何一个将合并为动词的Git命令（我称之为）都可以在合并过程中停止，从而使您陷入混乱，必须手动清理。最明显的命令是git merge本身，它有两个主要部分：首先，它执行“动词合并”步骤，该步骤成功或停止。然后，如果该步骤成功，它将执行合并操作，使合并为名词，就像我喜欢的那样。但是，如果它停止了，它会忽略这一部分。

在中间停下来的任何冲突合并都会使您清理混乱。此时，索引中的所有三个输入提交均可用。如果您不需要这些文件，则Git在合并文件方面的最大努力也可在您的工作树中找到。使用您喜欢的任何工具来完成合并，然后使用git add通知Git您的工作树版本是正确的结果，它应该丢弃三个输入，而只是将您的版本存储到索引中（aka暂存区），随时可以提交。

如果您运行的导致此停止的合并的命令是git merge，则可以使用git merge --continue或git commit进行名词合并。如果它是git rebase，则可以使用git rebase --continue，依此类推。不过，对于git stash，没有git stash pop --continue（可能应该有）：一旦确定完全合并，就可以使用{{1} }放下藏匿处。

我建议始终先使用git stash drop（或者一旦使用完，几乎总是使用），然后再彻底检查结果，然后再单独使用git stash apply您对Git一切都正确感到满意。这样一来，“流行不会在合并冲突中掉落”的特殊情况就不会出现。

Answer 2

这段话说的是另一种冲突。

如果您试图拉入当前分支的上游更改包括您也在本地更改的文件，则会遇到此错误：

addToCartVue(itemData) {
  let vm = this;
  return new Promise((resolve, reject) => {

    vm.buildDataString(itemData);

    axios.post(POST_ENDPOINT, {
        data: vm.dataString
      },
      {
        /*headers: {
          "Content-Type": "application/x-www-form-urlencoded"
        }*/
      }).then(response => {
      return vm.updateCartInfo(vm.dataString, itemData.addToCartParameters.itemId, vm.selectedStoreId, vm.quantity);
    }).then(response => {
      if (itemData.addToCartParameters.showLB) {
        vm.emitGlobalEvent('addToCart::open', itemData);
        resolve(response);
      }
    }).catch(error => reject(error));
  }).catch(error => reject(error));
}, // end of addToCartVue method

buildDataString(itemData) {
  // irrelevant code that builds quantity and dataString variables

  vm.quantity = quantity;
  vm.dataString = dataString;
}, // end of buildDataString method

updateCartInfo(dataString, itemId, selectedStore, quantity) {
  axios.get(GET_ENDPOINT, {
    params: {
      data: dataString
    }
  }).then(response => {
    cartDropDown.populateCartDropDown(response);
    const addedItem = response.addedItem;
    const basketInfo = response.basketInfo;

    let productQuantity = quantity;
    if (addedItem.quantity > -1) {
      productQuantity = addedItem.quantity;
    }

    const itemInformation = {
      "itemId": itemId,
      "selectedStore": selectedStore,
      "addedItem": addedItem,
      "basketInfo": basketInfo,
      "displayValues": null,
      "quantity": productQuantity,
      "isCustomProduct": false
    };

    return itemInformation;
  }).catch(err => error => reject(error));
} // end of updateCartInfo method

在这种情况下，git只是拒绝拉，它尚未验证如果实际通过拉来进行操作会产生任何类型的“合并冲突”，相反，它被编程为“比后悔更安全” ”。如果在拉取过程中的任何时候git都会遇到合并冲突，则它必须修改您本地修改但尚未提交的文件。

此操作以及您可能无法清理和解决此合并冲突的可能性，很可能会导致您丢失更改。当涉及到实际的提交时，您可以简单地中止合并并重试，但是对于未提交的更改，您根本没有此选项。

因此git甚至根本没有尝试，相反，您将必须首先提交所做的更改，或将其存储起来以进行保管。

现在，所有这些并不能阻止您在执行建议的命令时出现 actual 合并冲突，但是在您发布的文本中的“ conflict”一词是另一种冲突。

为什么如果本地更改与上游更改冲突，那么您可以将更改保存起来，进行拉取，然后取消保存呢？

2 个答案: