Завершение выпуска Git Flow - в доступе отказано

Некоторое время я работал с git flow, и теперь пора закончить первую версию v1.0.0. Для этого я использую SourceTree в Windows.

Когда я хотел закончить выпуск, я получил эту ошибку:

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.

Я понятия не имею, почему возникает эта ошибка, поскольку не должно быть проблем с правами доступа к файлам, поскольку этого никогда не было при работе в ветке функции.

После того, как вышеперечисленное не удалось, у меня были в основном все мои изменения от разработки по отношению к мастеру в моей рабочей копии. Я просто пометил все эти изменения, удалил новые файлы и так далее. Нет никаких конфликтов нет. Итак, я снова готов закончить свой релиз.

В настоящее время разработка и выпуск находятся на одном этапе, и, конечно же, впереди много коммитов: Мой текущий репозиторий

Как я могу завершить выпуск, не столкнувшись с этой проблемой?

Есть ли способ принудить мастера к текущей стадии разработки / выпуска? По сути, все коммиты разработки должны применяться к основной ветке, поэтому все конфликты слияния, когда они появляются, я хотел бы решить с помощью версии ветки разработки. Это возможно?


git atlassian-sourcetree git-flow
person hbit    schedule 10.01.2015    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Я нашел человека, который мог мне помочь с этой проблемой, и у него возникла идея, что это связано с каким-то другим процессом, блокирующим файл.

Чтобы проверить это, я скопировал свой репозиторий в другое место, открыл его с помощью SourceTree, и мне удалось завершить выпуск без проблем.

Следовательно, я предполагаю, что это связано с тем, что файл чем-то заблокирован.

Хотя я подозревал, что моя IDE (PHPStorm), я не мог точно определить ее, так как я закрыл ее, а затем все еще была проблема с разрешением файла. Может, это Dropbox (там весь репозиторий), кто знает. Но теперь я знаю, по крайней мере, обходной путь.

person hbit    schedule 30.01.2015
comment
Интересный анализ. +1 - person VonC; 30.01.2015
comment
Вдохновленный OP, я перезапускаю Windows, и она работает. Немного странно. - person gzc; 02.12.2015
comment
У меня была такая же проблема при завершении исправления. Оказывается, среда IDE действительно заблокировала файл. Когда файл сохранен, все в порядке, затем Sourcetree переключается на мастер, и IDE замечает, что файл изменяется (на старую версию в мастере) и, я думаю, блокируется. Так что просто закрытие IDE может сработать для некоторых людей. - person Axel Köhler; 17.09.2018
comment
Я могу подтвердить, что в моем случае это произошло потому, что VSCode был открыт вместе с проектом. - person Zooly; 19.03.2019

arrow_upward
0
arrow_downward

Как показано в проблеме 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 добавляет

По сути, все коммиты разработки должны применяться к основной ветке, поэтому все конфликты слияния, когда они появляются, я хотел бы решить с помощью версии ветки разработки.

Это типично для ветки develop, перебазированной на master:

  • rebase означает, что вы воспроизводите ветку develop поверх master, разрешая любой конфликт в ветке develop
  • rebase означает, что как только ветка develop окажется поверх master (перебазирована), слияние с master (выполняется git-flow release finish) будет тривиальной перемоткой вперед.
person VonC    schedule 13.01.2015
comment
Как вы можете видеть на моем экране, все коммиты ветки feature/... вошли в одну фиксацию в ветке development, которая основана на ветке master. Поэтому я не уверен, нужна ли мне перебазировка - я вроде бы ожидал, что я нахожусь на той стадии, когда git-flow release finish будет слиянием с ускоренной перемоткой вперед. Вы понимаете, о чем я? - person hbit; 14.01.2015

arrow_upward
0
arrow_downward

Я предполагаю, что эта ошибка может произойти не только в том случае, если вы изменили разрешения, но также если вы изменили право собственности на этот файл (что МОЖЕТ привести к изменению разрешений).

Сам я не мог избавиться от этой проблемы, поэтому то, что я сделал (и работал на меня), было чем-то вроде «спрятать скелет в шкафу». Цель состоит в том, чтобы изолировать файл с ошибкой в ​​тестовой ветке, которую вы можете впоследствии удалить.

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

person despina    schedule 16.01.2015