Czołem Bracia i Siostry w kodzie
Jako że dział Newbie został skasowany temat daję tutaj.
Potrzebuję wskazówki czego użyć do następującej operacji - w tortoise git chcę zrobić merge'a mastera do mojej gałęzi, ale z kompletnym odrzuceniem historii commitów z mastera; nie chcę zaśmiecać logu swojej gałęzi informacjami o tym, kto (poza mną) i co commitował. Jak to uzyskać?
Możesz zrobić squash wielu commitów na masterze w jeden i dopiero wtedy zrobić merge.
Ale IMO coś strasznie kombinujesz i prosisz się o problemy w przyszłości
To ja mam lepsza poradę. Tortoise git nawet nie ma tu nic do rzeczy. Przepinasz się na master brancha - kopiujesz wszystkie pliki w projekcie. Przepinasz się na swój projekt (gdzie juz masz wszystko pokomitowane) i po prostu przeklejasz pliki.
Co do mergowania - bo to co przekleisz zastapi Ci Twoje zmiany - albo rozwiazesz to przy commitowaniu - przegladajac zmiany, albo... robisz nowego brancha Y - z mastera, mergujesz do niego to co masz na tym swoim i tyle - historie będziesz miał, a Twój branch powinien mieć tylko wskaźnik na to że poleciał merge z mastera.
Możesz jeszcze zrobić tak, ze zrobisz sobie kopię Twojego brancha X do brancha Y, poczynisz "kopiuj->wklej" (Master->X) jak opisalem wyzej, zakomitujesz i potem zmergujesz do X to co masz w Y.
Twój opis nie jest jasny do końca. Więc albo zastosuj, któreś rozwiązanie, albo powiedz nam w czym przeszkadza Ci zaśmiecenie Twojego brancha.
Moim zdaniem także jest to zbędne kombinowanie.
Zrób rebase na mastera zamiast merga. Operacja rebase przeniesie twoje zmiany na aktualną historię mastera. Nadal masz całą historię z mastera, ale twoje zmiany będą "na górze".
git merge master --squash
Jak to zrobić w git tortoise? Trudno powiedzieć na Windows Używam git extensions.
@MasterBLB ale co potem chcesz zrobić z tą gałęzią? Bo to nie problem mergować mastera do swojej gałęzi i zrobić squash, tylko że potem będziesz miał problem żeby ten twój branch znów zintegrować z masterem, bo będziesz nagle miał konfliktujące zmiany wszędzie (jedna zmiana przychodząca z wielu commitów w masterze, a druga ze zbiorczego squashowanego mastera). Możesz wyjaśnić jaki konkretnie problem próbujesz rozwiązać?
Shalom napisał(a):
@MasterBLB ale co potem chcesz zrobić z tą gałęzią? Bo to nie problem mergować mastera do swojej gałęzi i zrobić squash, tylko że potem będziesz miał problem żeby ten twój branch znów zintegrować z masterem, bo będziesz nagle miał konfliktujące zmiany wszędzie (jedna zmiana przychodząca z wielu commitów w masterze, a druga ze zbiorczego squashowanego mastera). Możesz wyjaśnić jaki konkretnie problem próbujesz rozwiązać?
Sprawa wygląda tak - we wspólnym repo, o jakiejś tam strukturze dorzuciłem narzędzie do testów manualnych GUI stworzonego w qmlu. Owo GUI używa Qt remote objects aby dostawać dane od middleware'a, a moje narzędzie go udaje. Jest ono niezależne od reszty projektu, i robione wyłącznie przeze mnie w oddzielnym branchu. Co jakiś czas jednak potrzebuję zaktualizować całość projektu (głównie owo testowane GUI) do mojej gałęzi, a ponieważ jestem w niej jedynym kontrybutorem to nie chcę śmieci w logu, którymi są commity innych osób. Jak przyjdzie zrobić merge'a mojej gałęzi do mastera to w masterze jego historia pozostanie wszak bez zmian, czyż nie?
No i stąd mój wątek, bo grzebię po dokumentacji, ale tak nędznie to jest opisane, iż nie wiadomo jaka opcja jest potrzebna. Wcześniej pracowałem wyłącznie z SVNem, oraz miałem krótki epizod z Serena Dimensions.
MasterBLB napisał(a):
Sprawa wygląda tak - we wspólnym repo, o jakiejś tam strukturze dorzuciłem narzędzie do testów manualnych GUI stworzonego w qmlu. Owo GUI używa Qt remote objects aby dostawać dane od middleware'a, a moje narzędzie go udaje. Jest ono niezależne od reszty projektu, i robione wyłącznie przeze mnie w oddzielnym branchu. Co jakiś czas jednak potrzebuję zaktualizować całość projektu (głównie owo testowane GUI) do mojej gałęzi, a ponieważ jestem w niej jedynym kontrybutorem to nie chcę śmieci w logu, którymi są commity innych osób.
Jak długo zamierzasz trzymać ten kod na swoim branchu? Bo jak to jest kwestia miesiąca, to robisz co jakiś czas merga albo rebasa i się nie martwisz. Jak roku albo dłużej, to nie wiem czy nie lepiej trzymać taki projekt w osobnym repozytorium, w którym projekt oryginalny jest zmapowany jako git submodule.
Jak przyjdzie zrobić merge'a mojej gałęzi do mastera to w masterze jego historia pozostanie wszak bez zmian, czyż nie?
Merge połączy Ci dwie gałęzie (acykliczne grafy commitów) w jednym commicie na masterze. Po mergu na masterze będą widoczne Twoje commity. Na Twoim branchu, o ile z jakiegoś powodu postnowisz go zachować, nie będzie widać commitów z mastera. (generalnie branch to tylko taki wskaźnik na aktualny commit, który uznaje się za głowę gałęzi)
Jakbyś zrobił merge z mastera do twojego brancha, a potem - kiedyś - z twojego brancha do mastera, to commity na masterze nie będą zduplikowane. Git prześledzi graf commitów i wypisze je w odpowiedniej kolejności.
wszak bez zmian, czyż nie?
Nie. To nie jest SVN który robi diffy plików. Z punktu widzenia gita liczą się konkretne commity. Jak zrobisz squash i wszystkie zmiany wciśniesz w jeden commit, to będzie konfliktować z tymi pojedyńczymi commitami, mimo że efektywnie to ten sam kod.
Wracając do twojego problemu -> robisz rebase i wtedy z punktu widzenia twojego repo twoje commity są "u góry" nad aktualnym stanem mastera.
Niemniej to jest w ogóle dziwne co robisz i ja bym zrobił osobną bibliotekę czy osobny projekt z nie ciągnął jakieś 2 równoległe branche, bo to z czasem coraz trudniej będzie utrzymać ten "lewy" branch.
Porada @MarekR22 sprawdziła się dokładnie tak jak potrzebowałem, dzięki Bracie.