Stąd że próbuje aplikować commity “od” kodu po zmianach kolegów. Z własnego doświadczenia (anecdata), konflikty przy pull-rebase zdarzały się o wiele częściej niż przy merge.
I dlatego uważam, że nie ma co na siłę utrudniać życia początkującym gitowcom w imię “koszerności” gitloga.
To akurat nie ma żadnego znaczenia. Merge też korzysta z common ancestor commit jako podstawy.
A moje anecdata (i zdrowy rozsądek) wskazuje, że nie ma różnicy w ilości konfliktów.
A ja uważam, że korzystanie z gita to tak samo ważna umiejętność jak pisanie komentarzy, czy testów. Im się szybciej tego nauczysz, tym dla zespołu lepiej.
Jasne. Po prostu osobiście dla mnie nie-bycie-dupkiem przeważa korzyści płynące z rzucania mniej zaawansowanych kolegów na głęboką wodę. No ale, każdy musi sobie sam ocenić co dla niego ważniejsze.
Żeby móc bezstresowo używać gita trzeba zrozumieć jak działa. A jak to rozumiesz, to rebase jest trywialny.
Dla mnie nie-bycie-dupkiem polega na uczeniu kolegów takich prostych rzeczy, żeby się w pracy nie stresowali.
rebase jest bardzo pomocne http://book.git-scm.com/4_rebasing.html
dodajesz swój commit normalnie git commit -m “jakis koment”, potem git pull --rebase, wtedy z repo pobierane sa commity które ktos zrobił w miedzyczasie a Twój commit jest dodawany na końcu. Jeśli wystąpił konflikt to edytujesz plik, następnie git rebase --continue i tak az wszystko bedzie ok.
[quote=sharnik]Żeby móc bezstresowo używać gita trzeba zrozumieć jak działa. A jak to rozumiesz, to rebase jest trywialny.
Dla mnie nie-bycie-dupkiem polega na uczeniu kolegów takich prostych rzeczy, żeby się w pracy nie stresowali.[/quote]
YMMV, ale moim zdaniem najważniejsze dla nowego i niezaawansowanego kolegi/koleżanki jest jak najszybsze wejście w projekt i scommitowanie czegoś własnego (motywacja, rozeznanie się w projekcie). I tak będzie się to wiązało z olbrzymią ilością rzeczy do nauczenia, prędzej czy później, a wolę żeby na początku nauczył się rzeczy naprawdę istotnych (testowanie!). Mistrzostwo w posługiwaniu się narzędziami, od zrozumienia gita i swobodnego rebasingu po wszystkie skróty klawiszowe w swoim edytorze, może chwilę poczekać.
Swoją drogą rebase, jako wymagający głębokiego zrozumienia zasad działania gita, jako “taka prosta rzecz” – kaman 
(tak, wiem, robimy offtop offtopa – można wydzielić)
Dzięki @Tomash 
Tak właśnie działam, napisałem już wszystkie rodzaje testow do swojej aplikacji jakie znalazłem, zrezygnowałem z Cucumbera i teraz piszę sobie w rspecu i steaku(co o nim myślicie?) a co do gita, hmm staram się uczyć na każdym konflikcie.
robię tak:
g checkout -b nowa_funkcjonalnosc
pisze pisze kod
g commit -a -m “nowe rzeczy”
g checkout master
g merge
g pull --rebase
czasami tu jakies konflikty i nie wszystko czaję ale sobie narazie radziłem
g push origin master
Jeżeli features’ów nie piszą Ci klienci (czy inne nie-informatyczne osoby) to moim zdaniem bardzo dobry pomysł Jak dla mnie Cucumber tylko powoduje dublowanie kodu (i tak kroki musisz zdefiniować w Rubym). Jeżeli testy piszą tylko programiści to rspec w zupełności wystarczy
A piszecie ze Steakiem czy w zwykłym czystym Rspecu + capybara
Ja używam rspec + capybara. Steak to troche przerost formy nad treścią 
Gem tylko dla aliasów dla describe, context, before/after i it
[quote=sharnik]Żeby móc bezstresowo używać gita trzeba zrozumieć jak działa. A jak to rozumiesz, to rebase jest trywialny.
Dla mnie nie-bycie-dupkiem polega na uczeniu kolegów takich prostych rzeczy, żeby się w pracy nie stresowali.[/quote]
Skoro frontendowcy (czyt. osoby, które nie muszą znać się bardzo dobrze na systemie kontroli wersji) z powodzeniem mogą używać git-rebase to o czym tu w ogóle gadać, co nie?
Lepiej przejrzyj sobie jakieś porządne wprowadzenie. Np. “Pro Git” Chacona.
Uczenie się gita na rysowanych grafach komitów jest o wiele bardziej przydatne niż uczenie na wpisywanych komendach.
Merge też wymaga zrozumienia zasad działania gita. Różnica jest jedynie taka, że początkującym się wydaje, że wiedzą co się dzieje. Mergują sobie mergują, a tu nagle smuteczek. Wg mnie tak naprawdę rebase jest prostszą operacją niż merge.
+1
„Nie wyglądasz mi na człowieka, który używa rebase.”
Ale mówisz tylko o git pull --rebase czy też np. git rebase master w swojej gałęzi?
O rebase w ogólności (git rebase master), a więc też o pull–rebase w szczególności.