2016-06-30 13 views
5

Ze względu na niską wartość, używam commit, aby zachować swoje codzienne migawki WIP. Tak więc moja historia commitów zawiera wiele snapshotów i kilka kluczowych commits wymieszanych razem.Najlepsza praktyka łączenia w NEXT commit w git rebase -i?

Zanim przejdę do przeniesienia mojej pracy do zdalnego repozytorium, mogę poczuć się jak czyszczenie mojej historii, aby zawierała tylko kluczowe zatwierdzenia, poprzez scalanie migawki, którą przechodzi, bezpośrednio po kluczowych zatwierdzeniach. Informacja o dacie kluczowego zatwierdzenia jest dla mnie ważna, ponieważ przypomina mi, kiedy i co zmieniłem.

Używanie poleceń squasha/fixup w git rebase -i może być pomocne, ale łączą się w POPRZEDNIE zatwierdzenia, a ich daty autora nie są tym, czego chcę.

Ponowne zamawianie, a następnie zgniatanie często powoduje niepotrzebne konflikty, czego również chcę uniknąć.

So. Jaka jest najlepsza praktyka, aby zaspokoić moje pragnienie?

[Aktualizacja] 03/07/2016
Zainspirowany odpowiedź torek, w wymyśliłem rozwiązanie: użyć git rebase -i jak zwykle docelową popełnić że chcę poprzednia zobowiązuje się do meldunku do edit, a następnie wykonać git reset HEAD~n gdzie n to liczba poprzednich komentarzy, które chcę połączyć. I zatwierdzić melded zmiany z:

% git commit --amend --date "$(grep DATE .git/rebase-merge/author-script | cut -f2 -d '=')"

potem dokończyć resztę pracy przez git rebase --continue.

+2

Jeśli chodzi o wyrażenie „codziennie zrzuty WIP”: I (i wiele innych) zaleca, aby [Commit Early] (//blog.codinghorror.com/check-in-early-check-in-often/), [Commit Często] (// sethrobertson.github.io/GitBestPractices/#commit). W produktywne dni często będę mieć * co najmniej * tuzin lub dwa zatwierdzenia. –

+0

Tak, zgadzam się z tym, co mówi strona. Zrobiłem to w podobny sposób, zanim zacząłem pracować nad rozwojem zespołu. –

Odpowiedz

2

Oto jeden sposób: jak zwykle używaj reorganizacji. Ustaw dyspozycję dla fix-a-squasha-commit na edit. Kiedy Git przestanie pozwalać ci edytować poprawkę, użyj git reset --soft HEAD^; git commit --amend --reset-author-date, ale pamiętaj, że używa ona daty "teraz". Aby uzyskać większą kontrolę i odebrać datę z gry squash/fixup, pobierz datę autora z tego zatwierdzenia i użyj --date: prawdopodobnie będziesz chciał napisać mały skrypt powłoki, aby to zrobić.

(Użyj git log --pretty=format:%ad --no-walk, aby wyodrębnić datę z bieżącego zatwierdzenia, przed krokiem git reset --soft HEAD^. Możesz chcieć zapisać tekst komunikatu zatwierdzenia, lub nawet cały identyfikator zatwierdzenia: miękki reset pozostawia zatwierdzenie w repozytorium , gdzie jest chroniony zarówno przez reorganizację w toku, jak i różne reflogi, dzięki czemu możesz wyodrębnić to, co chcesz z niego później, jak również wcześniej. Oczywiście autor i zgłaszający i ich daty oraz wiadomość, obejmują wszystko, co jest przydatne tutaj.)

Aby znacznie zmniejszyć dystorsję, można wykonać wiele rebase, lub kilka zgniatania w interaktywnej edycji, lub git reset --soft dalej niż HEAD^.

(Nigdy nie przejmuj się tym: konkretne znaczków data nie wydaje się, że tu przydatny.)

+0

Dziękuję za odpowiedź. Zauważyłem, że podczas interaktywnego 'rebase' informacje o autorach przechowywane są w' .git/rebase-merge/author-script'. –

+0

Należy zauważyć, że obecność i nazwa '.git/rebase-merge', a tym bardziej wszelkie pliki w nim zawarte, to szczegół implementacji: nie istniał w starszych wersjach Git i może mieć inną nazwę w niektórych operacjach rebase (w szczególności nieinteraktywny rebase używa '.git/rebase-apply' obecnie). Oczywiście, jeśli zawsze robisz interaktywny rebase i jeśli twoja wersja Git ma ten plik, prawdopodobnie możesz polegać na jego zawartości. Byłoby jednak bezpieczniej nie zakładać tego. – torek

Powiązane problemy