Czy git-svn dcommit po połączeniu w git jest niebezpieczny?

Moją motywacją do wypróbowania git-svn jest łatwe łączenie i rozgałęzianie. Wtedy zauważyłem, że człowiek git-svn (1) mówi:

Uruchamianie git-merge lub git-pull NIE jest zalecane na gałęzi, z której planujesz dcommitować. Subversion nie reprezentuje fuzji w żaden rozsądny lub użyteczny sposób; więc użytkownicy korzystający z Subversion nie widzą żadnych wykonanych przez ciebie połączeń. Ponadto, jeśli scalisz lub ściągniesz z gałęzi git, która jest lustrzanym odbiciem gałęzi SVN, dcommit może zatwierdzić niewłaściwą gałąź.

Czy to oznacza, że ​​nie mogę utworzyć lokalnego oddziału z svn / trunk (lub oddziału), zhakować, połączyć się z powrotem w svn / trunk, a następnie wykonać dcommit? Rozumiem, że użytkownicy svn zobaczą ten sam bałagan, jaki zawsze występował w svn pre 1.5.x, ale czy są jakieś inne wady? To ostatnie zdanie też mnie martwi. Czy ludzie rutynowo robią takie rzeczy?

Właściwie znalazłem jeszcze lepszy sposób dzięki --no-ffopcji na git merge. Cała ta technika squasha, której używałem wcześniej, nie jest już potrzebna.

Mój nowy przepływ pracy wygląda teraz następująco:

• Mam „master” oddział, który jest jedyną gałąź że dcommit zi że klon repozytorium SVN ( -sZakładam, że masz standardowy układ SVN w repozytorium trunk/, branches/i tags/):

  git svn clone [-s] <svn-url>
  

• Pracuję w lokalnym oddziale „praca” ( -btworzy oddział „praca”)

  git checkout -b work
  

• zatwierdzić lokalnie do gałęzi "work" ( -saby podpisać komunikat o zatwierdzeniu). Zakładam, że w sequelu wykonałeś 3 lokalne zatwierdzenia

  ...
  (work)$> git commit -s -m "msg 1"
  ...
  (work)$> git commit -s -m "msg 2"
  ...
  (work)$> git commit -s -m "msg 3"
  

Teraz chcesz zatwierdzić na serwerze SVN

• [Ostatecznie] przechowuj modyfikacje, których nie chcesz widzieć na serwerze SVN (często komentowałeś jakiś kod w pliku głównym tylko dlatego, że chcesz przyspieszyć kompilację i skupić się na danej funkcji)

  (work)$> git stash
  

• przebuduj gałąź główną za pomocą repozytorium SVN (aby zaktualizować z serwera SVN)

  (work)$> git checkout master
  (master)$> git svn rebase
  

• Wróć do gałęzi pracy i przeprowadź rebase z mistrzem

  (master)$> git checkout work
  (work)$> git rebase master
  

• Upewnij się, że wszystko jest w porządku, na przykład:

  (work)$> git log --graph --oneline --decorate
  

• Teraz nadszedł czas, aby połączyć wszystkie trzy zatwierdzenia z gałęzi „work” w „master”, używając tej wspaniałej --no-ffopcji

  (work)$> git checkout master
  (master)$> git merge --no-ff work
  

• Możesz zauważyć stan dzienników:

  (master)$> git log --graph --oneline --decorate
  * 56a779b (work, master) Merge branch 'work'
  |\  
  | * af6f7ae msg 3
  | * 8750643 msg 2
  | * 08464ae msg 1
  |/  
  * 21e20fa (git-svn) last svn commit
  

• Teraz prawdopodobnie chcesz edytować ( amend) ostatnie zatwierdzenie dla twoich kolesi z SVN (w przeciwnym razie zobaczą tylko pojedyncze zatwierdzenie z komunikatem "Merge branch 'work'"

  (master)$> git commit --amend
  

• Na koniec zatwierdź na serwerze SVN

  (master)$> git svn dcommit
  

• Wróć do pracy i ostatecznie odzyskaj przechowywane pliki:

  (master)$> git checkout work
  (work)$> git stash pop
  

Tworzenie lokalnych oddziałów jest zdecydowanie możliwe dzięki git-svn. Tak długo, jak używasz lokalnych oddziałów dla siebie i nie próbujesz używać git do łączenia się między gałęziami svn wyższego rzędu, powinno być dobrze.

Mam gałąź "master", której używam do śledzenia serwera svn. To jedyna gałąź, z której się zaangażowałem. Jeśli wykonuję jakąś pracę, tworzę gałąź tematyczną i pracuję nad nią. Kiedy chcę to zrobić, wykonuję następujące czynności:

1. Zaangażuj wszystko w gałąź tematyczną
2. git svn rebase (rozwiąż wszelkie konflikty między twoją pracą a svn)
3. git checkout master
4. git svn rebase (dzięki temu następny krok będzie szybkim łączeniem do przodu, zobacz komentarze Aarona poniżej)
5. git merge topic_branch
6. rozwiąż wszelkie konflikty przy scalaniu (w tym momencie nie powinno ich być)
7. git svn dcommit

Mam również inną sytuację, w której muszę zachować pewne lokalne zmiany (do debugowania), które nigdy nie powinny być przenoszone do svn. W tym celu mam powyższą gałąź główną, ale także gałąź zwaną „pracą”, w której normalnie pracuję. Gałęzie tematyczne są rozgałęzione od pracy. Kiedy chcę tam zatwierdzić pracę, wyewidencjonowuję mastera i używam cherry-pick, aby wybrać commity z gałęzi work, które chcę przekazać do svn. Dzieje się tak, ponieważ chcę uniknąć wykonywania trzech lokalnych zatwierdzeń zmian. Następnie dcommend z gałęzi głównej i przebudowuję wszystko.

Warto git svn dcommit -nnajpierw uruchomić, aby upewnić się, że masz zamiar popełnić dokładnie to, co zamierzasz. W przeciwieństwie do gita, przepisywanie historii w svn jest trudne!

Uważam, że musi istnieć lepszy sposób na scalenie zmiany w gałęzi tematycznej, pomijając te lokalne zmiany, niż przy użyciu selektora, więc jeśli ktoś ma jakieś pomysły, byłby mile widziany.

Proste rozwiązanie: Usuń gałąź 'work' po scaleniu

Krótka odpowiedź: Możesz używać git, jak chcesz (zobacz poniżej prosty przepływ pracy), w tym scalanie. Po prostu upewnij się, że podążaj za każdym poleceniem „ git merge work ” z „ git branch -d work ”, aby usunąć tymczasową gałąź pracy.

Wyjaśnienie w tle: Problem merge / dcommit polega na tym, że za każdym razem, gdy 'git svn dcommit' gałąź, historia scalania tej gałęzi jest `` spłaszczona '': git zapomina o wszystkich operacjach scalania, które przeszły do ​​tej gałęzi: tylko zawartość pliku jest zachowywana, ale fakt, że ta treść (częściowo) pochodzi z innej konkretnej branży, jest stracony. Zobacz: Dlaczego git svn dcommit traci historię zatwierdzeń połączeń dla lokalnych oddziałów?

(Uwaga: git-svn nie może wiele na to poradzić: svn po prostu nie rozumie o wiele potężniejszych połączeń git. Tak więc w repozytorium svn te informacje o scalaniu nie mogą być w żaden sposób reprezentowane.)

Ale to jest cały problem. Jeśli usuniesz gałąź 'work' po jej scaleniu z 'gałęzią główną', twoje repozytorium git jest w 100% czyste i wygląda dokładnie tak, jak repozytorium svn.

Mój przepływ pracy: Oczywiście najpierw sklonowałem zdalne repozytorium svn do lokalnego repozytorium git (może to zająć trochę czasu):

$> git svn clone <svn-repository-url> <local-directory>

Cała praca odbywa się wtedy w „katalogu lokalnym”. Za każdym razem, gdy potrzebuję aktualizacji z serwera (np. „Aktualizacja svn”), robię:

$> git checkout master
$> git svn rebase

Wszystkie prace programistyczne wykonuję w osobnej gałęzi „praca”, która jest tworzona w następujący sposób:

$> git checkout -b work

Oczywiście możesz utworzyć dowolną liczbę gałęzi dla swojej pracy, a także scalać i ponownie bazować między nimi, jak chcesz (po prostu usuń je, gdy skończysz - jak omówiono poniżej). W mojej normalnej pracy bardzo często popełniam:

$> git commit -am '-- finished a little piece of work'

Kolejny krok (git rebase -i) jest opcjonalny - po prostu wyczyści historię przed zarchiwizowaniem jej na svn: Kiedy osiągnąłem stabilny kamień milowy, którym chcę się podzielić z innymi, przepisuję historię tej „pracy” rozgałęziaj i wyczyść komunikaty zmian (inni programiści nie muszą widzieć wszystkich małych kroków i błędów, które popełniłem po drodze - tylko wynik). W tym celu robię

$> git log

i skopiuj hash sha-1 ostatniego zatwierdzenia, który znajduje się w repozytorium svn (zgodnie z identyfikatorem git-svn-id). Wtedy dzwonię

$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

Po prostu wklej hash sha-1 naszego ostatniego zatwierdzenia svn zamiast mojego. Aby uzyskać szczegółowe informacje, możesz przeczytać dokumentację za pomocą polecenia „git help rebase”. W skrócie: to polecenie najpierw otwiera edytor prezentujący twoje zatwierdzenia - po prostu zmień 'pick' na 'squash' dla wszystkich tych zatwierdzeń, które chcesz zgnieść z poprzednimi zatwierdzeniami. Oczywiście pierwsza linia powinna pozostać jako „wybór”. W ten sposób możesz skondensować swoje liczne małe zmiany w jedną lub więcej znaczących jednostek. Zapisz i wyjdź z edytora. Otrzymasz inny edytor z prośbą o przepisanie komunikatów dziennika zmian.

W skrócie: po zakończeniu „hakowania kodu” masuję gałąź „praca”, aż wygląda, jak chcę ją zaprezentować innym programistom (lub jak chcę zobaczyć pracę za kilka tygodni, kiedy przeglądam historię) .

Aby wprowadzić zmiany do repozytorium svn, wykonuję:

$> git checkout master
$> git svn rebase

Teraz wracamy do starej gałęzi „master”, zaktualizowanej o wszystkie zmiany, które zaszły w międzyczasie w repozytorium svn (Twoje nowe zmiany są ukryte w gałęzi „praca”).

Jeśli istnieją zmiany, które mogą kolidować z nowymi zmianami „pracy”, musisz je rozwiązać lokalnie, zanim będziesz mógł przesłać nową pracę (zobacz szczegóły poniżej). Następnie możemy przesłać nasze zmiany do svn:

$> git checkout master
$> git merge work        # (1) merge your 'work' into 'master'
$> git branch -d work    # (2) remove the work branch immediately after merging
$> git svn dcommit       # (3) push your changes to the svn repository

Uwaga 1: Polecenie „git branch -d work” jest całkiem bezpieczne: pozwala tylko na usuwanie gałęzi, których już nie potrzebujesz (ponieważ są już włączone do twojej bieżącej gałęzi). Jeśli wykonasz to polecenie przez pomyłkę przed połączeniem pracy z gałęzią „master”, pojawi się komunikat o błędzie.

Uwaga 2: Upewnij się, że usunąłeś swoją gałąź za pomocą 'git branch -d work' między scalaniem a dcommit: Jeśli spróbujesz usunąć gałąź po dcommit, pojawi się komunikat o błędzie: Kiedy wykonujesz 'git svn dcommit', git zapomina o tym twoja gałąź została połączona z 'master'. Musisz go usunąć za pomocą 'git branch -D work', które nie wykonuje testu bezpieczeństwa.

Teraz natychmiast tworzę nową gałąź „work”, aby uniknąć przypadkowego włamania się do gałęzi „master”:

$> git checkout -b work
$> git branch            # show my branches:
  master
* work

Integrowanie twojej 'pracy' ze zmianami na svn: Oto co robię, gdy 'git svn rebase' ujawnia, że ​​inni zmienili repozytorium svn, gdy pracowałem nad moją gałęzią 'work':

$> git checkout master
$> git svn rebase              # 'svn pull' changes
$> git checkout work           # go to my work
$> git checkout -b integration # make a copy of the branch
$> git merge master            # integrate my changes with theirs
$> ... check/fix/debug ...
$> ... rewrite history with rebase -i if needed

$> git checkout master         # try again to push my changes
$> git svn rebase              # hopefully no further changes to merge
$> git merge integration       # (1) merge your work with theirs
$> git branch -d work          # (2) remove branches that are merged
$> git branch -d integration   # (2) remove branches that are merged
$> git svn dcommit             # (3) push your changes to the svn repository

Istnieją mocniejsze rozwiązania: przedstawiony przepływ pracy jest uproszczony: wykorzystuje uprawnienia git tylko w każdej rundzie „update / hack / dcommit” - ale pozostawia długoterminową historię projektu tak samo liniową, jak repozytorium svn. Jest to w porządku, jeśli chcesz po prostu zacząć używać scalania git w małych pierwszych krokach w starszym projekcie svn.

Kiedy stajesz się bardziej zaznajomieni z git scalania, nie krępuj się badać inne przepływy pracy: Jeśli wiesz, co robisz, ty może mieszać git łączy się z scala svn ( Używanie git-svn (lub podobne), żeby pomóc z svn seryjnej? )

Odpowiedź Grega Hewgilla na górze nie jest bezpieczna! Jeśli jakieś nowe zatwierdzenia pojawiły się na linii głównej między dwoma "git svn rebase", scalanie nie będzie szybkie do przodu.

Można to zapewnić używając flagi "--ff-only" do git-merge, ale zwykle nie uruchamiam "git svn rebase" w gałęzi, tylko "git rebase master" (zakładając, że jest to tylko lokalna gałąź). Następnie gwarantuje się szybkie przejście do przodu „git merge thebranch”.

Bezpiecznym sposobem łączenia gałęzi svn w git jest użycie git merge --squash. Spowoduje to utworzenie pojedynczego zatwierdzenia i zatrzymanie dodawania wiadomości.

Powiedzmy, że masz gałąź tematyczną svn o nazwie svn-branch.

git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch

w tym momencie wszystkie zmiany z gałęzi svn są zgniecione w jednym zatwierdzeniu oczekującym w indeksie

git commit

Przebuduj lokalną gałąź git do głównej gałęzi git, a następnie dcommit i wygląda na to, że wykonałeś wszystkie zatwierdzenia po kolei, aby ludzie svn mogli zobaczyć to liniowo, tak jak są przyzwyczajeni. Zakładając, że masz lokalny oddział o nazwie Temat, który możesz zrobić

git rebase master topic

który następnie odegra Twoje zatwierdzenia na gałęzi głównej, gotowy do wykonania polecenia