Git Flow Release Finish - 权限被拒绝

Question

我已经使用git flow工作了一段时间，现在是时候完成第一个版本v1.0.0。我在Windows上使用SourceTree进行操作。

当我想要完成发布时，出现了以下错误：

sh.exe C:\Users\xy\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow\git-flow release finish -f C:\Users\xy\AppData\Local\Temp\2ffrpxef.20z v1.0.0
Switched to branch 'master'

error: unable to create file component/admin/config.xml (Permission denied)

There were merge conflicts.

Completed with errors, see above.

我不知道为什么会出现这个错误，因为在开发分支中从未出现过文件权限问题。

在以上失败后，我的工作副本基本上包含了 develop 分支与 master 分支有关的所有更改。我只是放弃了所有这些更改并删除了新文件等。现在没有冲突存在。所以，我又可以继续完成我的版本发布了。

目前 develop 分支和 release 分支处于同一阶段，当然比 master 分支多很多次提交记录：

如何在避免出现此问题的情况下完成版本发布呢？

是否有办法将当前的 develop/release 阶段强制应用到 master 分支上？基本上所有开发提交记录都应该应用到主分支上 - 所有合并冲突都需要使用开发分支版本来解决。这可能吗？

- hbit

Answer 1

我找到一个能够帮我解决问题的人，他认为问题与其他进程锁定了该文件有关。

为了验证这一点，我将我的存储库复制到其他地方，在SourceTree中打开它，然后顺利完成了发布。因此，我认为这与某个东西锁定了文件有关。

尽管我怀疑我的IDE (PHPStorm)，但我无法确定，因为我关闭了它，但是仍然遇到了文件许可问题。也许是Dropbox(整个存储库都在其中)，谁知道呢。但现在我至少知道了一个解决方法。

- hbit

---

有趣的分析。+1 - VonC

受到OP的启发，我重新启动了Windows，结果它奇迹般地正常工作了。有点奇怪。 - gzc

当我完成一个热修复时，我遇到了同样的问题。原来是IDE确实锁定了文件。当文件保存后，一切都正常，然后Sourcetree切换到主分支，IDE注意到文件发生了变化（变成了主分支中的旧版本），并进行了锁定。所以对于某些人来说，只需关闭IDE即可解决问题。 - Axel Köhler

在我的情况下，我可以确认是因为VSCode与该项目一起打开了。 - Zooly

Answer 2

如问题107所示，该错误信息意味着合并无法完成，因为存在冲突（请参见git-flow-release#L225-L240）：

  if ! git_is_branch_merged_into "$BRANCH" "$MASTER_BRANCH"; then
    git checkout "$MASTER_BRANCH" || \
      die "Could not check out $MASTER_BRANCH."
    git merge --no-ff "$BRANCH" || \
      die "There were merge conflicts."

这意味着您需要解决合并冲突，并先完成合并。

OP hbit添加了

基本上所有的开发提交都应该应用到主分支上 - 所以当它们出现时，我想用开发分支版本来解决所有的合并冲突。

这是一个典型的在master上重新定位develop分支的例子：

• 重新定位意味着您要在master的顶部重播develop分支，并解决develop分支中的任何冲突
• 重新定位意味着，一旦develop分支在master的顶部（重新定位），对master的合并（由git-flow release finish完成）将是一个微不足道的快进操作。

- VonC

---

从我的屏幕上可以看到，所有的 feature/... 分支提交都合并成了一个基于 master 分支的 development 分支提交。因此我不确定是否需要进行变基 - 我认为我处于 git-flow release finish 快进合并阶段。你能理解我的意思吗？ - hbit

Answer 3

我猜这个错误不仅会在您修改了权限时发生，而且如果您修改了该文件的所有权（可能会导致权限更改），也会发生。

我自己无法解决这个问题，所以我做的是“把骨架藏在衣柜里”。目的是将有缺陷的文件隔离到一个测试分支中，之后可以删除。

sudo rm badfile.xxx - 物理删除文件，确保您有一份副本以便添加

git add —all badfile.xxx - 在阶段中标记为已删除

git checkout -b some_local_branch_we_ll_never_use - 在提交之前创建一个新分支

git commit -m "Delete the bad file" - 在新分支中提交删除有缺陷的文件，工作目录应该是干净的

git checkout my_good_old_branch - 返回您的工作分支并继续您的生活...

然后您可以删除测试分支：

git branch -D some_branch_we_ll_never_use

git status

- despina