2009-06-03 12 views
9

Używamy centralnego repozytorium git, które sklonowałem i pracuję w lokalnym oddziale.Jak skutecznie zmienić bazę i przesunąć lokalny oddział GIT?

Kiedy chcę, aby moje zmiany dostępne w centralnym repozytorium, muszę wydać następujące polecenia (począwszy od mybranch):

#Stash local changes not yet ready for checkin 
git stash 

#Make sure we have all changes from the central repository 
git checkout master 
git pull 

#Rebase local changes 
git checkout mybranch 
git rebase 

#Push changes 
git checkout master 
git merge mybranch 
git push 

#Back to my branch and continue work 
git checkout mybranch 
git stash apply 

Chciałbym wiedzieć, czy możliwe jest, aby używać mniej Polecenia git, aby osiągnąć ten sam cel. Kilka przełączników między master i mybranch jest szczególnie denerwujących, ponieważ nasze repozytorium jest dość duże, więc zajmuje trochę czasu.

Odpowiedz

13

Nie ma potrzeby dotknij lokalnego oddziału głównego, jeśli nie musisz go aktualizować i wydaje się, że powoduje to niepotrzebne przełączanie gałęzi.

To jest bardziej minimalny przepływ pracy.

git fetch 

# ensure that everything is committed 
# perhaps git commit -a is required... 

git rebase origin/master 


# If you don't want to push the very latest commits you might 
# want to checkout a parent or ancestor of the current commit 
# to test that the proposed commit passes tests, etc. 
# e.g. git checkout HEAD~n 

# push to the remote master 
git push origin HEAD:master 

# if you checked out a parent, go back to the original branch 
git checkout mybranch 

Jeśli jesteś bardzo pewny rodzica popełnić, można pominąć etapy realizacji transakcji i po prostu wykonaj następujące czynności, ale bym Odradzamy niego. Publikowanie nieprzetestowanych zatwierdzeń nie jest "najlepszą praktyką".

git push origin HEAD^:master 
1

Można połączyć przyciąganie i zmieniają bazę do jednego:

git ciągnąć --rebase Mistrza

ale ogólnie, tak, z mojego doświadczenia wynika, że ​​obejmuje wszystkie te polecenia.

Aby utrzymać repozytorium w czystości, pomocne jest często uruchamianie "git gc", które usunie nieużywane obiekty. To powinno zmniejszyć czas przełączania oddziałów.

0

Zwykle robię.

git co master 
git pull 
git rebase master mywrk # fix conflicts if any 
git rebase mywrk master 
git push 

Możesz zdefiniować aliasy, aby zapisać wpisywanie, jeśli lubisz w ten sposób.

6

Nie trzeba wykonywać naciągów na gałęzie master i mybranch. Skoro jest taki miły obywatel i robi fast-forward aktualizacje to całkiem proste:

# Save local mods not ready for commit 
git stash 
# Do the pull & rebase local work assuming this is a remote tracking branch 
git pull --rebase 
git checkout master 
git merge mybranch 
git push 

Oczywiście, można też przesunąć z branży mybranch

# Save local mods not ready for commit 
git stash 
# Do the pull & rebase local work assuming this is a remote tracking branch 
git pull --rebase 
git push origin mybranch:master 
+0

Co masz na myśli mówiąc "zakładając, że jest to gałąź zdalnego śledzenia"? mybranch jest gałęzią lokalną, istniejącą tylko w moim własnym repozytorium. Czy Twoje rozwiązanie działa również w takich okolicznościach? – siebert

+0

"Zdalna gałąź śledzenia" jest tak naprawdę tylko lokalną gałęzią, z tym wyjątkiem, że git zapamiętuje domyślne repozytorium i gałąź do użycia podczas wykonywania "pull". W przeciwnym razie polecenia "git push" i "git pull" musiałyby podać pełną lokalizację repozytorium. Oto przykład tworzenia zdalnego branży śledzenia $ git branch feature_x origin/master lub $ git checkout -b feature_x origin/master Jeżeli pozostawisz wyłączyć zdalne spec ('Powstanie/master' w tym case) wtedy feature_x nie jest gałęzią zdalnego śledzenia. –