git pojedynczy programista w/wielu maszynach - rebase i zobowiązuje pojawiać się dwukrotnie

Question

Niektóre tła:

1. Jestem samotną deweloper pracuje w jednym miejscu.
2. Używam git do kontroli wersji.
3. Mam kilka komputerów, z którymi pracuję od: biura, domu i laptop

Obecnie mam centralny, gołego repozytorium na moim serwerze. Każdy komputer klonuje i przesyła zmiany do tego repozytorium. Obecnie posiadam Master oddziału i deweloper oddziału. Cała praca jest wykonywana w oddziale dev. Master to zawsze aktualny, stabilny kod produkcyjny. Zmiany mogą być zastosowane do Master w dowolnym momencie wraz ze zmianami, które zachodzą w dev.

Mój codzienny obieg składa się z:

git checkout dev 
//pull in changes from remote 
git pull 
//make and commit changes as need throughout the day 
git add -u 
git commit 
//these steps only happens when I know master has changed 
git checkout master 
git pull 
git checkout dev 
git rebase master //to get changes to master into dev branch 
//push changes to central remote at end of day 
git push 

Wierzę, że to powinno być dość standardowy przepływ pracy dla jednego dewelopera.

Teraz wszystko, co jest na uboczu, w celu mojego pytania. Niedawno natknąłem się na sytuację, w której nie jestem pewien, jak właściwie postępować i jak temu zapobiec w przyszłości. Obecnie moja gałąź dev jest długotrwałą gałęzią dev, która jest głównym przeróbką części strony. W związku z tym trwa już od kilku miesięcy. Kiedy robię tę pracę, robię także małe zmiany/poprawki błędów w Master. Kiedy skończę jedną ze zmian w Master, ponownie ustawię dev na Master, aby uzyskać zmiany, a następnie popchnę je do centralnego repo. To działa dobrze.

Jednak kilka dni temu dokonałem zmiany na Mistrza - pierwsza taka zmiana za około miesiąc. Kiedy poszedłem do rebase, całe piekło wydawało się rozpaść. Konflikty scalania występowały w plikach, które nie istniały w programie Master, i ciągle otrzymywałem te same konflikty w tych samych plikach. Po spędzeniu większej części dnia próbując rozwiązać wszystkie konflikty, w końcu się poddałem.

Dziś rano poszedłem spróbować jeszcze raz, ale zanim zacząłem, przejrzałem historię projektów i odkryłem coś dziwnego. Zauważyłem, że około 15 zgłoszeń zostało powtórzonych. Pokazano wszystkie zatwierdzenia od 07.12.2012 - 08/2/2012. Potem znowu miałem te same poprawki, wszystkie z różnymi hashe SHA. Nie zauważyłem tego, dopóki nie zobaczyłem, że daty zatwierdzeń zostały wymienione w porządku chronologicznym, jak można się było spodziewać, ale potem nagle znowu wskoczył w przeszłość.

Aby rozwiązać problem, zrobiłem kolejny rebase, ale pominąłem duplikaty commitów. Kiedy to zrobiłem, wszystko działało dokładnie tak, jak oczekiwałbym bez żadnych konfliktów.

Moje pytanie brzmi: jak to się stało, że te dwa razy doszło do tego, aby zostać zrobione dwa razy i jak mogę zapobiec ponownemu wystąpieniu tego koszmaru w przyszłości? Jak sugeruje tytuł pytania, zakładam, że problem ma coś wspólnego z moim używaniem rebaseingu i pchania gałęzi opartej na rebase. Ale tak naprawdę zgaduję. Potrzebuję tylko pomocy w ustaleniu, co zrobiłem źle.

Answer 1

Uważam, że twój model jest zasadniczo taki sam, jak posiadanie trzech programistów, ponieważ masz trzy maszyny programistyczne. Więc twoja gałąź dev jest podzielona w tym sensie. Czytałem również na SO, że odświeżanie jako dzielone oddziału prowadzi do problemów, i lepiej scalać niż rebase dzielonych oddziałów. Po przeczytaniu tego zacząłem używać rebase tylko dla oddziałów prywatnych, z dobrymi wynikami. Sugerowałbym utworzenie repozytorium testów i wypróbowanie tych dwóch podejść, aby zobaczyć, jak się one porównują.

Jeśli mogę znaleźć inne pytanie SO, dodam link tutaj.

Edit:

Tu jest Rebasing remote branches in Git

Oczywiście, istnieje wiele różnych opinii na ten temat. :)