git odpowiednik hg mq?

Question

Właśnie zacząłem używać Gita wraz z Mercurialem, aby zapoznać się z Git.

Używam rozszerzenia mq w Mercurial, aby zarządzać lokalnymi poprawkami i szukam odpowiednika Git.

Czy powinienem użyć tylko oddziału Git? A może istnieją lepsze sposoby zarządzania lokalnymi poprawkami, które umożliwiają łatwe stosowanie i usuwanie poprawek?

Dzięki,

Answer 1

Zobacz sekcję "Interfejsy zarządzania łatkami" na stronie Git Wiki na stronie Interfaces, Frontends And Tools. Tam są wymienione dwa interfejsy zarządzania poprawkami grubsza odpowiednik „MQ” rtęciowe przedłużenie:

• StGIT (Ułożone GIT), starszy z nich, napisany w Pythonie, wykorzystuje dwa zrzuty do reprezentowania plaster
• Guilt (wcześniej "gq"), napisane jako seria skryptów bash, plik serii i łatki (jeden na plik) są przechowywane jako plik tekstowy.
• pg (Niewielkie Git) to przestarzałe i nie jest już konserwowane.

Ale jeśli nie potrzebujesz bardziej zaawansowanego użycia, możesz zamiast tego użyć "git rebase --interactive" do zmiany kolejności, zgniatania i dzielenia łat. I aby zarządzać swoją gałęzią przeciw aktualnej wersji upstream, zwykle wystarczy "git rebase".

Answer 2

Git tak naprawdę nie udostępnia tej funkcji. W zależności od twoich zastosowań, możesz być w stanie przetrwać dzięki "git stash" i/lub oddziałom, ale będzie to całkiem proste. Jeśli ludzie mają bardziej zaawansowane potrzeby zarządzania poprawkami z git, wydają się zwracać do Quilt lub StGit: zobacz http://git.or.cz/gitwiki/PatchManagement

Answer 3

Po prostu używaj oddziału i regularnie zmieniaj go w swoją gałąź. Jest to łatwiejsze w zarządzaniu i bezpieczniejsze niż używanie mq (do którego straciłem dane w przeszłości).

Answer 4

Nota prawna: Nie jestem użytkownikiem hg, więc przeczytałem o hg, ale nie mam zbyt dużego doświadczenia z jej używania.

git dostarcza kilku bardzo potężnych i elastycznych narzędzi do zarządzania oddziałami w stylu 'kolejki łatek', więc dla wielu podstawowych (a nawet dość złożonych) przypadków użycia, rodzimy git jest wystarczająco potężny.

Zazwyczaj większość projektów utrzymuje centralny stały oddział główny, który tylko zyskuje nowe zatwierdzenia i nigdy nie jest "przewijany", więc zatwierdzenia w gałęzi głównej są stałe. Ponadto, opiekun (lub programista) może utrzymywać jedną lub więcej płynnych gałęzi łatek roboczych w toku (tj. Zatwierdzeń) opartych na stabilnym odgałęzieniu.

typowych działań zarządza plastra są:

przebazowania kolejkę plastra najnowszą stabilnej - stosować git rebase,

powielenie kolejkę plastra starej maintentance gałęzi - stosować git branch i git rebase,

zmiana kolejności poprawek w kolejce - użyj git rebase --interactive (alias git rebase -i) za pomocą edytora tekstu, aby zmienić kolejność kolejki.

zgniecenia łaty - użyj git rebase -i z dyrektywą squash

poprawki zmieniające lub łata popełnić wiadomości - użyj git rebase -i (spot motyw?) Z dyrektywą edycji.

Każda czynność, która w jakikolwiek sposób zmieni łatkę (tj. Jej zawartość, opis lub pochodzenie), utworzy nowe zatwierdzenie z nowym identyfikatorem zatwierdzenia dla tej poprawki. Fakt, że stare commity mogą być wyrzucane i regularnie wymieniane przed awansem do stabilnej gałęzi głównej, jest jedyną rzeczą, która czyni je "kolejką łatki", a nie odgałęzieniem, ale jest to raczej konwencja projektu niż jakakolwiek fizyczna różnica w danych, które składają się na zatwierdzenia. Aby git są identyczne obiekty.

Aby promować poprawkę do "prawdziwego" zatwierdzenia, wystarczy przenieść poprawkę na wierzch kolejki i połączyć ją w gałąź główna. Po przeniesieniu łaty do przodu kolejki, jest to to samo, co normalne zatwierdzenie oparte na gałęzi głównej, więc połączenie go po prostu przeskakuje wskaźnik gałęzi głównej do punktu zatwierdzenia poprawki.

Opublikowanie tego zatwierdzenia jako "stabilnej" poprawki głównej to akt, który mówi: to jest zobowiązanie, które się nie zmieni i jest częścią niezmiennej historii projektu.