GIT - tworzenie nowego commita z zawartością innego

0

Witam. Mam taki problem. Powiedzmy, że jestem na branchu: branch_1. Zrobiłem na nim commity: c1, c2, c3. Chciałbym stworzyć c4, które by wyglądało identycznie jak c2. Wiem, że jeśli chcę pracować i rozwijać wszystko od c2, to mogę dać na nim reset, ale chodzi mi o przypadek kiedy chcę zachować historię. Poza tym może się zdażyć że będę chciał pobrać zawartość commita z innego brancha na swój i podejrzewam, że można to rozwiązać w podobny sposób.

2

Poza tym może się zdażyć że będę chciał pobrać zawartość commita z innego brancha na swój i podejrzewam, że można to rozwiązać w podobny sposób.

W takiej sytuacji cherry-pick, ale oryginalnego pytania nie rozumiem

0
KamilAdam napisał(a):

Poza tym może się zdażyć że będę chciał pobrać zawartość commita z innego brancha na swój i podejrzewam, że można to rozwiązać w podobny sposób.

W takiej sytuacji cherry-pick, ale oryginalnego pytania nie rozumiem

Na c1 mam plik zawierający zdanie "Ala ma kota." Na c2 ten sam plik zawiera jedynie słowo "Ala". Tworze c3 i chcę na niego pobrać stan z c1 czyli "Ala ma kota", z tym że jeśli dobrze rozumiem, to przy cherry pick wskazujesz dokładnie jakie pliki chcesz wziąć z innego commita, a mi chodzi o to żeby pobrać cały stan projektu, który na nim jest.

1
paranoise napisał(a):

to przy cherry pick wskazujesz dokładnie jakie pliki chcesz wziąć z innego commita, a mi chodzi o to żeby pobrać cały stan projektu, który na nim jest.

cherry-pick bierze całe commity, nie mam pojęcia jak się w ładny sposób rozbija commity :( Dalej też nie rozumiem co chcesz osiągnąć. Jak chcesz stan z C1 to przełączasz się na niego i odpijasz się od C1 czyli tworzysz nową gałąź

UPDATE Teraz mi coś wpadło do głowy. Jak chcesz mieć stan na c1, czyli bez c2 to możesz zrobić git revert c2 i będziesz mieć historię

  • c1
  • c2
  • revert c2 - stan taki jak w c1
0

Nie kumam tego cherry pick. Korzystam z GIT Extensions, więc może jakoś inaczej to wygląda w trybie graficznym ale... Jestem sobie na commicie c2. Klikam prawym na c1 i wybieram cherry pick. Oczekiwałbym, że odłoży mi się na stejdżu (nie jestem pewien jak to się nazywa) zmiana polegająca na przywróceniu zdania z c1. Na jej podstawie tworzę sobie commit c3. Tymczasem nic się nie dzieje.

A co do tworzenia gałęzi. Powiedzmy, że chyba nie bardzo mogę. Polityka firmy. Tzn. lokalnie bym pewnie mógł sobie porobić i potem połączyć, ale wydawało mi się, że pozostanie na jednym branchu dla niedużego zadania może być prostsze.

0

Powiedzmy, że chyba nie bardzo mogę. Polityka firmy.

W sensie, że prowadzicie trunk based development czy co?

0

Ale to tak nie działa. W commitach nie jest zapisany stan na daną chwilę tylko zmiany plików. Nie możesz zrobić cherry-pick commita do gałęzi jak on jest już w gałęzi. To co chcesz zrobić to zrewertować zmianę zawartąw commicie c2 więc musisz zrobić git revert hash-commita-c2

2
KamilAdam napisał(a):

W commitach nie jest zapisany stan na daną chwilę tylko zmiany plików.

Właśnie nie. Tam jest sporo magii, ale commitom jest znacznie bliżej do zapisów stanu, niż zapisów różnic: https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/

Na diffach bazuje Darcs, ale dopiero od niedawna ludzie zaczęli odkrywać, jak można bazować na zmianach, i mieć system kontroli wersji, który kończy wykonywać operacje w tym samym tygodniu, w którym zaczyna — bardzo łatwo o sytuacje, w których pojawia się wykładnicza złożoność obliczeniowa. Pijul, inny system kontroli wersji, to ponoć rozwiązał, ale jakoś od dwóch lat siedzi w alfie i jakoś nie umie z niej wyjść, więc…

1 użytkowników online, w tym zalogowanych: 0, gości: 1