Scal gałąź rozwoju z master

Mam dwie gałęzie mianowicie mastera developmentw GitHub repozytorium. Cały rozwój robię w branży programistycznej, jak pokazano.

git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development

Teraz chcę scalić wszystkie zmiany w developmentgałęzi z master. Moje obecne podejście to:

git checkout master 
git merge development
git push -u origin master 

Daj mi znać, jeśli procedura, którą wykonuję, jest prawidłowa.

Zasadniczo lubię łączyć mastersię z developmentpierwszym, aby w razie konfliktów rozwiązać problem w developmentsamej gałęzi i masterzachować czystość.

(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won't be any conflicts now)

Nie ma dużej różnicy między tymi dwoma podejściami, ale czasami zauważyłem, że nie chcę jeszcze scalać gałęzi master, po ich połączeniu, lub że jest jeszcze wiele do zrobienia, zanim można je połączyć , więc zwykle pozostawiam masternietknięte do końca.

EDYCJA: Z komentarzy

Jeśli chcesz śledzić, kto i kiedy dokonał scalenia, możesz użyć --no-ffflagi podczas scalania, aby to zrobić. Jest to na ogół przydatne tylko podczas łączenia developmentw master(ostatni krok), ponieważ może być konieczne wielokrotne scalenie masterw development(pierwszy krok) w przepływie pracy, a utworzenie dla nich węzła zatwierdzania może nie być bardzo przydatne.

git merge --no-ff development

Osobiście moje podejście jest podobne do twojego, z kilkoma dodatkowymi gałęziami i trochę zgniatania zatwierdzeń, kiedy wracają do mistrza.

Jeden z moich współpracowników nie lubi tak bardzo zmieniać gałęzi i pozostaje w gałęzi programistycznej z czymś podobnym do poniższego wykonywanym z gałęzi programistycznej.

git fetch origin master

git merge master

git push origin development:master

Pierwszy wiersz upewnia się, że ma jakieś zatwierdzenia poprzedzające, które zostały wprowadzone do masteringu od czasu ostatniej aktualizacji jego lokalnego repozytorium.

Drugi ciągnie te zmiany (jeśli występują) z mistrza do rozwoju

Trzeci przesuwa gałąź programistyczną (teraz w pełni scaloną z master) do origin / master.

Być może jego podstawowy obieg pracy jest trochę niepoprawny, ale to jest jego główna zaleta.

Wyjaśnienie z dołu dla tych, którzy przybyli tutaj bez znajomości gałęzi.

Podstawowa logika rozwoju gałęzi głównej jest następująca: Pracujesz tylko na innych gałęziach i używasz master tylko do łączenia kolejnych gałęzi.

Zaczynasz tworzyć nowy oddział w ten sposób:

1) Klonuj repozytorium w swoim lokalnym katalogu (lub utwórz nowe repozytorium):

$ cd /var/www
$ git clone git@bitbucket.org:user_name/repository_name.git

2) Utwórz nowy oddział. Będzie zawierał najnowsze pliki z twojego repozytorium oddziału głównego

$ git branch new_branch

3) Zmień obecną gałąź git na new_branch

$ git checkout new_branch

4) Wykonuj kodowanie, zatwierdza, jak zwykle…

$ git add .
$ git commit -m “Initial commit”
$ git push (pushes commits only to “new_branch”)

5) Po zakończeniu pracy w tym oddziale połącz z odgałęzieniem „master”:

$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldn’t have any  commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all “new_branch” commits to both branches - “master” and “new_branch”)

Aktualizacja: Gorąco polecam użyć GitKraken, aby zobaczyć wizualne drzewo zmian i lepiej zobaczyć całą logikę i zatwierdzenia.

Byłoby wspaniale, gdybyś mógł użyć przepływu pracy Git Flow . Może łatwo łączyć rozwój gałęzi z mistrzem.

To, co chcesz zrobić, to po prostu postępować zgodnie z instrukcją git-flow wspomnianą tutaj:

KROKI:

• skonfiguruj projekt git-flow
• tworzyć oddziały i łączyć wszystko, aby się rozwijać
• uruchom polecenie git flow release start <version_number>
• następnie przekaż sensowną wiadomość do wydania
• uruchom polecenie git flow release finish <version_number>
• scali wszystko w master i zmieni gałąź na master .
• uruchom polecenie, git pushaby opublikować zmiany w zdalnym systemie głównym .

Aby uzyskać więcej informacji, odwiedź stronę - http://danielkummer.github.io/git-flow-cheatsheet/

1. //pull the latest changes of current development branch if any        
git pull (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any
git pull

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Tak, jest to poprawne, ale wygląda na bardzo podstawowy przepływ pracy, w którym buforujesz zmiany, zanim będą gotowe do integracji. Powinieneś przyjrzeć się bardziej zaawansowanym przepływom pracy obsługiwanym przez git. Może ci się spodobać podejście do gałęzi tematu , które pozwala pracować równolegle nad wieloma funkcjami, lub podejście stopniowe, które nieco rozszerza bieżący przepływ pracy.

Jeśli korzystasz z komputera Mac lub Ubuntu, przejdź do folderu roboczego oddziału. W terminalu

załóżmy, że harisdev jest nazwą gałęzi.

git checkout master

jeśli istnieją nieśledzone lub niezaangażowane pliki, pojawi się błąd i musisz zatwierdzić lub usunąć wszystkie nieśledzone lub niezaangażowane pliki.

git merge harisdev 

git push origin master

Ostatnie polecenie, aby usunąć gałąź.

$ git branch -d harisdev

Krok 1

Utwórz i przełącz się na nową gałąź „dev”, w której lokalne pliki git są zsynchronizowane ze zdalną, ale gałąź „dev” jeszcze nie istnieje.

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch's files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.

Krok 2

Wprowadź zmiany w gałęzi „dev” (bieżącej, jeśli wykonasz krok 1), zatwierdź i pchnij je do zdalnej gałęzi „dev”.

git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.

Krok 3

Scal swoją gałąź „dev” w „master”.

git checkout dev # switch to "dev" branch if you're not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn't have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.

Tak zwykle to robię. Po pierwsze, upewnij się, że jesteś gotowy, aby scalić swoje zmiany w master.

1. Sprawdź, czy programowanie jest aktualne, wprowadzając najnowsze zmiany ze zdalnego serwera za pomocą git fetch
2. Po zakończeniu pobierania git checkout master.
3. Upewnij się, że gałąź główna ma najnowsze aktualizacje, wykonując git pull
4. Po zakończeniu przygotowań możesz rozpocząć scalanie git merge development
5. Naciśnij zmiany za pomocą git push -u origin masteri gotowe.

Więcej informacji na temat łączenia git można znaleźć w tym artykule.

1) W rozwoju oddziału sprawdź status git za pomocą następującego polecenia:

git status

Nie powinno być nieprzydzielonego kodu. Jeśli tak, wciśnij kod w gałęzi programistycznej:

git add *

git commit -m "My initial commit message"

git push origin Development

2) W gałęzi Programowanie uruchom następujące dwa polecenia:

git branch -f master HEAD

git push -f origin master

Spowoduje to wypchnięcie kodu gałęzi rozwoju do gałęzi master.

Na podstawie @Sailesh i @DavidCulp:

(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won't be any conflicts now)

Pierwsze polecenie upewni się, że wszystkie wcześniejsze zatwierdzenia zostały wykonane dla zdalnego mistrza, z odpowiedzią Sailesh, która by się nie zdarzyła.

Drugi wykona scalenie i stworzy konflikty, które możesz następnie rozwiązać.

Po wykonaniu tej czynności możesz w końcu dokonać transakcji wzorca, aby przełączyć się na wzorzec.

Następnie scalasz gałąź rozwoju z lokalnym wzorcem. Flaga no-ff utworzy węzeł zatwierdzania w systemie głównym, aby śledzenie całego scalenia było możliwe.

Następnie możesz zatwierdzić i pchnąć swoje scalenie.

Ta procedura upewni się, że istnieje połączenie zatwierdzania przez programistę do opanowania, które ludzie mogą zobaczyć, a następnie, jeśli przejdą do gałęzi programistycznej, zobaczą poszczególne zatwierdzenia dokonane w tej gałęzi podczas jej rozwoju.

Opcjonalnie możesz zmienić zatwierdzenie scalania przed wypchnięciem go, jeśli chcesz dodać podsumowanie tego, co zostało zrobione w gałęzi programistycznej.

EDYCJA: moja oryginalna odpowiedź sugerowała, że git merge masternic nie zrobiłem, lepiej zrobić git merge FETCH_HEADpo pobraniu źródła / wzorca

Po „przejściu” do działu rozwoju ...

 git add .
 git commit -m "first commit"
 git push origin dev
 git merge master

 git checkout master 
 git merge dev
 git push origin master 

Jeśli używasz gerrit, poniższe polecenia działają doskonale.

git checkout master
git merge --no-ff development

Możesz zapisać przy pomocy domyślnej wiadomości zatwierdzenia. Upewnij się, że identyfikator zmiany został wygenerowany. Aby się upewnić, możesz użyć następującego polecenia.

git commit --amend

Następnie naciśnij następujące polecenie.

git push origin HEAD:refs/for/refs/heads/master

Może pojawić się komunikat o błędzie, taki jak poniżej.

! [remote rejected] HEAD -> refs/for/refs/heads/master (you are not allowed to upload merges)

Aby rozwiązać ten problem, administrator projektu gerrit musi utworzyć w gerrit inne odwołanie o nazwie „refs / for / refs / heads / master” lub „refs / for / refs / heads / *” (które obejmie wszystkie gałęzie w przyszłości). Następnie udzielić zezwolenia „Push Merge Commit” na to odniesienie i uprawnienia „Prześlij”, jeśli jest to wymagane do przesłania GCR.

Teraz spróbuj ponownie wykonać powyższe polecenie push i powinno działać.

Kredyty:

https://github.com/ReviewAssistant/reviewassistant/wiki/Merging-branches-in-Gerrit

https://stackoverflow.com/a/21199818/3877642

Myślę, że najłatwiejszym rozwiązaniem byłoby

git checkout master
git remote update
git merge origin/Develop -X theirs
git commit -m commit -m "New release"
git push --recurse-submodules=check --progress "origin" refs/heads/Master

To także zachowuje historię wszystkich używanych gałęzi

1. //push the latest changes of current development branch if any        
git push (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any from (current development branch)
git pull origin (current development branch)

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Error
To https://github.com/rajputankit22/todos-posts.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/rajputankit22/todos-posts.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Then Use 
5. //push the master branch forcefully
git push -f origin master