Jaki jest najlepszy (i najbezpieczniejszy) sposób na scalenie gałęzi Git z masterem?

Jak bym to zrobił

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

Jeśli mam oddział lokalny ze zdalnego, nie czuję się komfortowo z łączeniem innych oddziałów niż ten ze zdalnym. Nie przepychałbym też swoich zmian, dopóki nie będę zadowolony z tego, co chcę wcisnąć, a także nie przepychałbym w ogóle rzeczy, które są tylko dla mnie i mojego lokalnego repozytorium. W Twoim opisie wydaje się, że test jest tylko dla Ciebie? Więc nie ma powodu, żeby to publikować.

git zawsze stara się szanować zmiany Twoje i innych, tak samo będzie --rebase. Nie sądzę, abym mógł to odpowiednio wyjaśnić, więc spójrz na książkę Git - Zmiana bazy lub git-ready: wprowadzenie do zmiany bazy mały opis. To całkiem fajna funkcja

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

Tak jak

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

Takie podejście ma dwa problemy:

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

2. Spowodowałoby to „ściśnięcie” wszystkich zmian testowych w jedno zatwierdzenie scalające na głównym; to znaczy w gałęzi master, nie możemy zobaczyć wszystkich dzienników zmian gałęzi testowej.

Tak więc, gdy podejrzewamy, że wystąpią jakieś konflikty, możemy mieć następujące operacje git:

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

Przetestuj merge przed commit, unikaj szybkiego zatwierdzania do --no-ff,

W przypadku napotkania konfliktu możemy uruchomić git status, aby sprawdzić szczegóły dotyczące konfliktów i spróbować rozwiązać

git status

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

git commit -m 'merge test branch'
git push

Ale w ten sposób utracisz historię zmian zarejestrowaną w gałęzi testowej i utrudniłoby innym deweloperom zrozumienie historii projektu.

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

Poniżej znajduje się jeden prosty przykład. Zaawansowane operacje można znaleźć pod adresem 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, kiedy już skończysz, wszystkie commity z gałęzi Test zostaną przeniesione na główkę gałęzi Master. Główną zaletą zmiany bazy jest to, że otrzymujesz liniową i znacznie czystszą historię projektu.

Jedyne, czego musisz unikać to: nigdy nie używaj rebase w gałęzi publicznej, takiej jak gałąź master.

Nigdy nie wykonuj operacji takich jak:

git checkout master
git rebase -i test

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

dodatek:

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

Ani zmiana bazy, ani scalanie nie powinny zastępować czyichkolwiek zmian (chyba że zdecydujesz się to zrobić podczas rozwiązywania konfliktu).

Typowym podejściem podczas tworzenia jest:

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, aby połączyć się z powrotem w mistrza,

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

Jeśli martwisz się, że coś zepsujesz podczas łączenia, git merge --abort jest dla Ciebie.

Używanie push, a następnie pull jako sposobu łączenia jest głupie. Nie jestem też pewien, dlaczego wypychasz test do źródła.

Najpierw chciałbym, aby gałąź, która ma zostać scalona, ​​była jak najczystsza. Uruchom testy, upewnij się, że stan jest taki, jak chcesz. Wyczyść nowe zatwierdzenia za pomocą git squash.

Oprócz odpowiedzi KingCrunches, sugeruję użyć

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

Mogłeś zrobić wiele zatwierdzeń w innej gałęzi, która powinna być tylko jednym zatwierdzeniem w gałęzi master. Aby historia zatwierdzeń była tak czysta, jak to tylko możliwe, możesz chcieć zmiażdżyć wszystkie swoje zatwierdzenia z gałęzi testowej w jednym zatwierdzeniu w gałęzi master (zobacz także: Git: Zgniatać czy nie zgniatać?). Następnie możesz również przepisać komunikat zatwierdzenia na coś bardzo ekspresyjnego. Coś, co jest łatwe do odczytania i zrozumienia, bez zagłębiania się w kod.

edytuj: Możesz być zainteresowany

• Jaka jest w git różnica między scalaniem --squash a rebase?
• Scalanie a zmiana bazy
• Jak zmienić bazę żądania ściągnięcia

Tak więc na GitHub robię następujące czynności dla gałęzi funkcji mybranch:

Pobierz najnowsze od pochodzenia

$ git checkout master
$ git pull origin master

Znajdź skrót bazy scalania:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Teraz upewnij się, że 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ść o zatwierdzeniu i wypchnij na GitHub. Następnie wyślij żądanie ściągnięcia.

Po scaleniu żądania ściągnięcia możesz je usunąć lokalnie:

$ git branch -d mybranch

i na GitHubie

$ git push origin :mybranch

Stary wątek, ale nie znalazłem swojej drogi robienia tego. Może to być cenne dla kogoś, kto pracuje z rebase i chce scalić wszystkie zatwierdzenia z gałęzi (funkcji) nad głównym. Jeśli pojawi się konflikt, możesz go rozwiązać przy każdym zatwierdzeniu. Zachowujesz pełną kontrolę w trakcie procesu i możesz przerwać w dowolnym momencie.

Pobierz aktualne informacje o Master i Branch:

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

Połącz gałąź z głównym:

git checkout <branch_name>
git rebase master

Opcjonalnie: jeśli natrafisz na konflikty podczas zmiany bazy:

Najpierw rozwiąż konflikt w pliku. Następnie:

git add .
git rebase --continue

W każdej chwili możesz przerwać rebase za pomocą:

git rebase --abort

Wypchnij swoją zmienioną gałąź:

git push origin <branch_name>

Jeśli masz tę gałąź pchniętą wcześniej, musisz ją zastąpić pchnięciem siłowym:

git push origin -f <branch_name>

Zanim to zrobisz, zawsze sprawdź, czy Twój obecny oddział lokalny odpowiada Twoim oczekiwaniom, ponieważ wymuszenie ma pierwszeństwo przed starym w zdalnym repozytorium.

Teraz masz dwie możliwości:

• A) Utwórz PR (np. na GitHub) i połącz go tam za pomocą interfejsu użytkownika
• B) Wróć do wiersza poleceń i połącz gałąź z master

git checkout master
git merge --no-ff <branch_name>
git push origin master

Gotowe.

To jest przepływ pracy, którego używam w mojej pracy z zespołem. Scenariusz jest taki, jak opisałeś. Po pierwsze, kiedy skończę pracę nad test, zmieniam bazę z masterem, aby pobrać wszystko, co zostało dodane do mastera w czasie, gdy pracowałem nad gałęzią test.

git pull -r upstream master

Spowoduje to przeniesienie zmian do wzorca, ponieważ rozwidlałeś gałąź test i zastosujesz je, a następnie zastosujesz zmiany, które wprowadziłeś, aby przetestować „na górze” bieżącego stanu wzorca. Mogą wystąpić tutaj konflikty, jeśli inne osoby wprowadziły zmiany w tych samych plikach, które edytowałeś w teście. Jeśli tak, będziesz musiał je naprawić ręcznie i zatwierdzić. Gdy to zrobisz, dobrze będzie przełączyć się na gałąź główną i bez problemu połączyć test z nią.

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 wystąpi błąd „Rozwiąż konflikt”

Więc musisz najpierw rozwiązać wszystkie swoje konflikty, musisz ponownie zatwierdzić wszystkie swoje zmiany, a następnie popchnąć

git push origin master

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

Użyłbym metody rebase. Przede wszystkim dlatego, że doskonale oddaje twoją sprawę semantycznie, tj. to, co chcesz zrobić, to odświeżyć stan swojej aktualnej gałęzi i „udawać” tak, jakby był oparty na najnowszej.

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

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

Oczywiście samo pobranie ze źródła nie odświeża lokalnego stanu twojego master (ponieważ nie wykonuje scalania), ale jest to całkowicie w porządku dla naszego celu - chcemy uniknąć przełączania się, ze względu na oszczędność czasu.

Odpowiedź @KingCruncha powinna działać w wielu przypadkach. Jednym z problemów, który może się pojawić, jest to, że możesz być na innym komputerze, który musi pobrać najnowsze dane z testu. Tak więc polecam najpierw wyciągnąć test. Wersja wygląda tak:

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

Odpowiem zgodnie z gałęziami deweloperskimi i funkcjonalnymi,

jeśli jesteś na gałęzi funkcji i chcesz ją zaktualizować za pomocą programisty, użyj poniższych poleceń:

git checkout develop
git pull
git checkout feature/xyz
git merge develop

Teraz Twoja feature/xyz jest zaktualizowana o gałąź develop i możesz przekazać swoje zmiany do zdalnego feature/xyz.

Ponieważ tytuł mówi „Najlepszy sposób”, myślę, że dobrym pomysłem jest rozważenie strategii łączenia cierpliwości.

Od: https://git-scm.com/docs/merge-strategies

Dzięki tej opcji „merge-recursive” spędza trochę więcej czasu, aby uniknąć błędów scalania, które czasami występują z powodu nieistotnych pasujących wierszy (np. nawiasów klamrowych z różnych funkcji). Użyj tego, gdy gałęzie, które mają zostać połączone, rozchodzą się gwałtownie. Zobacz także git-diff[1] --cierpliwość.

Stosowanie:

git fetch
git merge -s recursive -X patience origin/master

Alias ​​Gita

Zawsze używam do tego aliasu, np. uruchomione raz:

 git config --global alias.pmerge 'merge -s recursive -X patience'

Teraz możesz zrobić:

git fetch
git pmerge origin/master

Musisz mieć wyrejestrowaną gałąź, aby ściągnąć, ponieważ ciągnięcie oznacza połączenie z głównym i potrzebujesz drzewa roboczego, aby się z nim połączyć.

git checkout master
git pull

Nie musisz się najpierw wymeldowywać; rebase robi słuszną rzecz z dwoma argumentami

git rebase master test  

git checkout master
git merge test

git push domyślnie wypycha wszystkie gałęzie, które istnieją tutaj i na zdalnym

git push
git checkout test

To jest z GitLab: po prostu postępuj zgodnie z instrukcjami:

Zawsze dostaję konflikty scalania, gdy robię tylko git merge feature-branch. Wydaje mi się, że to działa dla mnie:

git checkout -b feature-branch

Wprowadź kilka zmian w kodzie...

git merge -s ours master 

git checkout master

git merge feature-branch

or

git checkout -b feature-branch

Wprowadź kilka zmian w kodzie...

git checkout master

git merge -X theirs feature-branch