Scalanie do przodu ma sens w przypadku krótkotrwałych gałęzi, ale w bardziej złożonej historii scalanie bez szybkiego przewijania może ułatwić zrozumienie historii i ułatwić przywrócenie grupy zatwierdzeń.
Ostrzeżenie : niezwiązane z szybkim przekazywaniem ma również potencjalne skutki uboczne. Zapoznaj się z https://sandofsky.com/blog/git-workflow.html , unikaj „no-ff” z jego „punktami kontrolnymi zatwierdzeń”, które łamią bisect lub winę, i dokładnie zastanów się, czy to powinno być twoje domyślne podejście master
.
(Od nvie.com , Vincent Driessen , post „ Udany model rozgałęziania Git ”)
Włączanie gotowej funkcji przy programowaniu
Gotowe funkcje można połączyć z gałęzią programistyczną, aby dodać je do nadchodzącej wersji:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
--no-ff
Flaga powoduje seryjnej zawsze utworzyć nowy popełnić obiektu, nawet jeśli seryjnej mogą być wykonywane szybko do przodu. Pozwala to uniknąć utraty informacji o historycznym istnieniu gałęzi obiektów i grupuje wszystkie zatwierdzenia, które razem dodały obiekt.
Jakub Narębski również wspomina się configmerge.ff
:
Domyślnie Git nie tworzy dodatkowego zatwierdzenia scalania podczas scalania zatwierdzenia będącego potomkiem bieżącego zatwierdzenia. Zamiast tego wierzchołek bieżącej gałęzi jest przewijany do przodu.
Po ustawieniu na false
ta zmienna mówi Gitowi, aby w takim przypadku utworzył dodatkowe zatwierdzenie scalania (równoważne z podaniem --no-ff
opcji z wiersza poleceń).
Po ustawieniu na „ only
” dozwolone są tylko takie szybkie przewijanie do przodu (co odpowiada --ff-only
opcji z linii poleceń).
Szybkie przewijanie do przodu jest domyślne, ponieważ:
- Krótkotrwałe gałęzie są bardzo łatwe do utworzenia i użycia w Git
- krótkotrwałe gałęzie często izolują wiele zmian, które można dowolnie zreorganizować w ramach tej gałęzi
- te zatwierdzenia są w rzeczywistości częścią głównej gałęzi: po reorganizacji główna gałąź jest szybko przekazywana, aby je uwzględnić.
Ale jeśli spodziewasz się iteracyjnego przepływu pracy dla jednej gałęzi tematów / funkcji (tj. Scalam, a następnie wrócę do tej gałęzi funkcji i dodam więcej zatwierdzeń), to przydatne jest włączenie tylko scalania w gałęzi głównej, a nie wszystkie pośrednie zatwierdzenia gałęzi cech.
W takim przypadku możesz zakończyć konfigurowanie tego rodzaju pliku konfiguracyjnego :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
OP dodaje w komentarzach:
Widzę trochę sensu w przewijaniu do przodu dla [krótkotrwałych] gałęzi, ale ustawienie domyślnej akcji oznacza, że git zakłada, że ... często masz [krótkotrwałe] gałęzie. Rozsądny?
Jefromi odpowiada:
Myślę, że czas życia oddziałów różni się znacznie w zależności od użytkownika. Jednak wśród doświadczonych użytkowników prawdopodobnie istnieje tendencja do posiadania znacznie krótszych oddziałów.
Dla mnie gałąź krótkotrwała to taka, którą tworzę, aby ułatwić pewną operację (bazowanie, prawdopodobnie lub szybkie łatanie i testowanie), a następnie natychmiast usuwam, gdy skończę.
Oznacza to, że prawdopodobnie powinien zostać zaabsorbowany w gałęzi tematycznej, z której rozwidlił się , a gałąź tematyczna zostanie scalona jako jedna gałąź. Nikt nie musi wiedzieć, co zrobiłem wewnętrznie, aby utworzyć serię zatwierdzeń implementujących daną funkcję.
Ogólniej dodaję:
to naprawdę zależy od przepływu pracy programisty :
- jeśli jest liniowy, jedna gałąź ma sens.
- Jeśli chcesz wyodrębnić funkcje i pracować nad nimi przez długi okres czasu i wielokrotnie je scalać, kilka gałęzi ma sens.
Zobacz „ Kiedy należy rozgałęzić? ”
W rzeczywistości, jeśli weźmie się pod uwagę model gałęzi Mercurial, jest on w centrum jednej gałęzi na repozytorium (nawet jeśli można tworzyć anonimowe nagłówki, zakładki, a nawet nazwane gałęzie )
Patrz „Git i Mercurial - Porównaj i skontrastuj” .
Mercurial domyślnie stosuje anonimowe lekkie linie kodowe, które w swojej terminologii nazywane są „główkami”.
Git używa lekkich nazwanych gałęzi z iniekcyjnym mapowaniem do mapowania nazw gałęzi w zdalnym repozytorium na nazwy gałęzi zdalnego śledzenia.
Git „zmusza” cię do nazywania gałęzi (no, z wyjątkiem pojedynczej gałęzi bez nazwy, co jest sytuacją zwaną „ odłączoną HEAD ”), ale myślę, że działa to lepiej w przypadku przepływów pracy obciążających gałęzie, takich jak przepływ pracy gałęzi tematu, co oznacza wiele oddziałów w jednym paradygmacie repozytorium.
no-ff
” z „zatwierdzeniem punktu kontrolnego”, który łamie bisect lub winę.