Wykończenie Git Flow Release - Odmowa uprawnień

Question

Pracowałem z przepływem git przez pewien czas, a teraz nadszedł czas na ukończenie pierwszego wydania v1.0.0. Używam SourceTree na Windows do tego.

Gdy chciałem zakończyć uwalnianie to mam ten błąd:

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. 

Nie mam pojęcia, dlaczego ten błąd ma miejsce, ponieważ nie powinno być żadnych problemów z uprawnieniami do plików jako że nigdy nie zdarzyło się wcześniej podczas pracy w gałąź funkcji.

Po tym, jak zawiodłem, zasadniczo zmieniłem wszystkie moje zmiany w stosunku do mistrza w mojej kopii roboczej. Po prostu usunąłem wszystkie te zmiany i usunąłem nowe pliki i tak dalej. Nie ma żadnych konfliktów. Więc znowu jestem gotowy, aby dokończyć moje wydanie.

Obecnie rozwijać i uwalnianie są na tym samym etapie i oczywiście dużo zobowiązuje wyprzedzając mistrza:

Jak mogę skończyć uwalnianie bez uruchamiania w tej kwestii?

Czy jest jakiś sposób, aby wymusić obecny etap rozwoju/uwalniania na master? Zasadniczo wszystkie programy deweloperskie powinny zostać zastosowane do głównej gałęzi - więc wszystkie konflikty łączą się, gdy się pojawią, chciałbym rozwiązać za pomocą wersji rozwojowej. Czy to jest możliwe?

Answer 1

znalazłem kogoś, kto może mi pomóc w tej kwestii, a on wpadł na pomysł to było związane z jakimś innym procesem blokującym plik.

Aby to sprawdzić, skopiowałem moje repozytorium gdzie indziej, otworzyłem je za pomocą SourceTree i udało mi się zakończyć wydanie bez problemu.

W związku z tym wydaje mi się, że jest to związane z plikiem zablokowanym przed czymś.

Chociaż podejrzewałem, że mój IDE (PHPStorm), nie mogłem zlokalizować go tak, jak go zamknąłem, a następnie nadal miałem problem z prawem dostępu do pliku. Może to Dropbox (całe repozytorium tam jest), kto wie. Ale teraz wiem, że przynajmniej obejdę.

Answer 2

Jak pokazano na issue 107, że komunikat o błędzie oznacza scalenie nie może ukończyć z powodu konfliktu „zobaczyć 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." 

Oznacza to, że trzeba resolve the merge conflicts i complete the merge first.

OP hbit dodaje

Basically all the development commits should be applied onto the master branch - so all merge conflicts when they appear I'd like to solve with the development branch version.

To typowe develop oddziału rebased na master:

• rebase oznacza, że ​​odtworzyć develop oddział na szczycie master, rozwiązywaniu wszelkich konfliktów w develop branży
• rebase oznacza, gdy oddział develop znajduje się na górze master (rebased), połączenie do master (wykonane przez git-flow release finish) będzie trywialnym przyspieszeniem.

Answer 3

Ten błąd może się zdarzyć nie tylko w przypadku zmodyfikowania uprawnień, ale także w przypadku zmodyfikowania własności tego pliku (co może spowodować zmianę uprawnień).

Sam nie mogłem się tego problemu pozbyć, więc to, co zrobiłem (i dla mnie pracowałem) było coś w stylu "ukryć szkielet w szafie". Celem jest odizolowanie pliku buggy od gałęzi testowej, którą można później usunąć.

sudo rm badfile.xxx - usuń plik fizycznie, upewnij się, że masz kopię je dodać później

git add —all badfile.xxx - oznaczona jako usunięta w etapie

git checkout -b some_local_branch_we_ll_never_use - stworzyć nową gałąź przed popełnieniem

git commit -m "Delete the bad file" - commit z usunięciem złego pliku w nowym oddziale, katalog roboczy powinien być czysty

git checkout my_good_old_branch - wróć do Pracujesz gałąź i dalej ze swoim życiem ...

Następnie można usunąć gałąź badawczej:

git branch -D some_branch_we_ll_never_use

git status