git push wybranego commita a nie wszystko Opcje

[nospor]

Hej, jak w git mogę zrobić push do wybranego repozytorium ale push tylko wybranego commita lub wybranych commitow a nie wszystkich?
Po co mi to? Załóżmy że mam repozytorium core, z ktorego korzystają wszystkie nowe projekty. I gdy np. rozwijam projekt 3 i zrobie tam zmianę, która jest uniwersalna i ważna i powinna się znaleźć w innych projektach. Chcę więc ją wrzucic do core, by inny projekty mogły z tamtąd te ważną zmianę pociągnąć. Nie chcę jednak wrzucać innych commitow, ktore robiłem w projekt 3, gdyż one są zbędne w innych projektach

[Nattfarinn]

Możesz to zrobić w dowolnym momencie. W skrócie, robisz to tak:

Kod

$ cd /path/to/local/repository
$ git remote add core git@github.com:core.git     # dodaje kolejne repozytorium remote i nazywa je core
$ git fetch core
$ git checkout -b core core/master                # przełącza Cię na nieistniejącego jeszcze lokalnie brancha o nazwie core z upstreamem core/master

I w sumie tyle. Branch 'core' tak naprawdę prowadzi do brancha 'master' repozytorim 'git@github.com:core.git'

Jak napiszesz na branchu 'myfeature' jakiś feature który chciałbyś wrzucić do 'git@github.com:core.git':

Kod

$ git checkout core
$ git pull --rebase               # zaciągnij zmiany przenosząc niepushnięte dotąd zmiany na samą górę
$ git cherry-pick hash_commita
$ git push
$ git checkout myfeature
$ git rebase core                 # zmień bazę swojego brancha na core

To ostatnie polecenie jest po to, żebyś miał 'core' na dole, a wszystkie swoje zmiany projektowe na górze. To powinno wywalić commit który cherry-pickowałeś, bo nie jest już potrzebny (jest częścią 'core'). Tylko musisz pamiętać, że jeśli Twój projekt dorobił się tysięcy commitów, to zmiana bazy 'core' może trochę potrwać. To wygląda tak, że git commit po commicie nakłada Twoje zmiany na bazę. To może spowodować konflikty, jeśli commit który cherry-pickowałeś jest zależny od struktury którą zbudowałeś dopiero w projekcie, ale to oczywiste. Jeśli w pewnym momencie zatrzyma Ci się rebase na konflikce, to po konflikcie nie zaczynasz procesu od nowa (bo dalej 'trwa' rebase) tylko kontynuujesz od miejsca w którym się zatrzymało przez polecenie:

Kod

$ git rebase --continue

Może się też zdarzyć, że proces rebaseowania zatrzyma Ci się w momencie commitu który cherry-pickowałeś. Tutaj po prostu nie dam sobie głowy uciąć, bo zwyczajnie nie pamiętam, czy git załatwi to sobie automatycznie i pominie pusty commit czy też powie Ci, że commit jest pusty (bo zmiany przez tego nakładane zostały już nałożone wcześniej). Jeśli to drugie, to ignorujesz commit jako niepotrzebny poleceniem:

Kod

$ git rebase --skip

Więcej Ci nie potrzeba w sumie. (IMG:style_emoticons/default/smile.gif)

Edit: Jeśli rebase nie idzie po Twojej myśli, konfliktów pełno i końca nie widać, to zawsze możesz go przerwać za pomocą:

Kod

$ git rebase --abort

To w ułamku sekundy przywróci Ci stan sprzed polecenia rebase.

Ogólnie rebase to najpotężniejsze narzędzie jakie stoi za gitem. Za tydzień nie będziesz mógł bez niego żyć. Przenoszenie, łączenie, zmiana nazw commitów jest mega wygodna za pomocą trybu rebase interactive.

Ten post edytował Nattfarinn 2.04.2015, 13:49:24