Najlepszy (i najbezpieczniejszy) sposób na scalenie gałęzi git w master

Jest to bardzo praktyczne pytanie, ale wszystkie powyższe odpowiedzi nie są praktyczne.

Jak

git checkout master
git pull origin master
git merge test
git push origin master

To podejście ma dwie kwestie:

1. Jest to niebezpieczne, ponieważ nie wiemy, czy są jakieś konflikty między gałęzią testową a gałęzią master.

2. To "wyciśnie" wszystkie commity testowe w jeden commit scalający na master; to znaczy na gałęzi master, nie widzimy wszystkich logów zmian w gałęzi testowej.

Więc, gdy podejrzewamy, że będą jakieś konflikty, możemy wykonać następujące operacje git:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Test merge przed commit, unikaj szybkiego commita przez --no-ff,

git status

Gdy rozwiążemy konflikty, lub jeśli nie ma konfliktu, My commit i push oni

git commit -m 'merge test branch'
git push

Ale w ten sposób utraci historię zmian zalogowanych w gałęzi testowej, a to sprawi, że gałąź master trudno innym programistom zrozumieć historię projektu.

Więc najlepszą metodą jest użycie rebase zamiast merge (Załóżmy, że w tym czasie rozwiązaliśmy konflikty gałęzi).

Poniżej znajduje się jedna prosta Próbka, w przypadku zaawansowanych operacji, zapoznaj się z http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Tak, po wykonaniu upperów, wszystkie commity gałęzi testowej zostaną przeniesione na head gałęzi Master. Na główną zaletą rebasingu jest to, że otrzymujesz liniową i znacznie czystszą historię projektu.

Jedyne czego musisz unikać to: nigdy nie używaj rebase na gałęzi publicznej, jak master branch.

Nigdy nie wykonuj operacji takich jak:

git checkout master
git rebase -i test

Szczegóły dla https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

Dodatek:

• Jeśli nie masz pewności co do operacji rebasingu, zapoznaj się z: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Ani rebase, ani merge nie powinny nadpisywać czyichś zmian (chyba że zdecydujesz się to zrobić podczas rozwiązywania konfliktu).

Zwykłe podejście podczas tworzenia to

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Kiedy będziesz gotowy do połączenia z powrotem w master,

git checkout master
git log ..test # if you're curious
git merge test
git push

Używanie push a następnie pull jako sposobu łączenia jest głupie. Nie jestem też pewien, dlaczego naciskasz test na początek.

Poza KingCrunches odpowiedz, proponuję użyć

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Mogłeś zrobić wiele commitów w drugiej gałęzi, co powinno być tylko jednym commitem w gałęzi master. Aby zachować jak najczystszą historię zmian, możesz chcieć podzielić wszystkie swoje commity z gałęzi testowej na jeden commit w gałęzi master (Zobacz także: Git: squash czy nie squash?). Następnie możesz również przepisać komunikat commit na coś bardzo wyrazistego. Something that is easy czytać i rozumieć, bez zagłębiania się w kod.

Edit: może Cię zainteresować

• w git, jaka jest różnica między merge --squash i rebase?
• łączenie kontra Rebasing
• Jak zmienić hasło Pull Request

Więc na Githubie, kończę robiąc co następuje dla gałęzi feature mybranch:

Pobierz najnowsze z origin

$ git checkout master
$ git pull origin master

Znajdź hash bazy merge:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Teraz zrób oczywiście tylko pierwszy to pick, reszta to s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Następnie wybierz bardzo dobrą wiadomość commit i naciśnij GitHub. Następnie wykonaj polecenie pull.

Po scaleniu żądania pull można go usunąć lokalnie:

$ git branch -d mybranch

I na Githubie

$ git push origin :mybranch

To jest przepływ pracy, który używam w mojej pracy z zespołem. Scenariusz jest taki, jak opisałeś. Po pierwsze, kiedy kończę pracę nad test zmieniam bazę z master, aby pobrać to, co zostało dodane do master podczas pracy nad test gałęzią.

git pull -r upstream master

Spowoduje to pobranie zmian do gałęzi master od czasu rozwidlenia gałęzi test i zastosowanie ich, a następnie zastosowanie zmian, które wprowadziłeś, aby przetestować "na" bieżącym stanie gałęzi master. Mogą tu być konflikty, jeśli inne osoby wprowadziły zmiany w tych samych plikach, które edytowałeś w teście. Jeśli są, będziesz musiał naprawić je ręcznie i zatwierdzić. Gdy już to zrobisz, dobrze będzie przełączyć się do gałęzi master i połączyć test bez żadnych problemów.

git checkout master
git pull origin master
# Merge branch test into master
git merge test

Po scaleniu, jeśli plik zostanie zmieniony, to po scaleniu nastąpi błąd "Rozwiąż konflikt"

Więc najpierw musisz rozwiązać wszystkie konflikty, potem ponownie zatwierdzić wszystkie zmiany i wcisnąć

git push origin master

To lepiej zrobić, kto dokonał zmian w gałęzi testowej, ponieważ wiedział, jakie zmiany zrobił.

Użyłbym metody rebase. Głównie dlatego, że doskonale odzwierciedla Twój przypadek semantycznie, tj. to, co chcesz zrobić, to odświeżyć stan bieżącej gałęzi i "udawać", jakby była oparta na najnowszej.

Więc, nawet nie sprawdzając master, chciałbym:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Oczywiście samo pobieranie z origin nie odświeża lokalnego stanu Twojego master (ponieważ nie wykonuje scalania), ale jest to całkowicie ok dla naszego celu - chcemy uniknąć przełączania, dla ze względu na oszczędność czasu.