Git: przenieść zmiany między gałęziami bez pracy zmiana katalogu

Question

przypadków użycia: za każdym razem, gdy chcesz przenieść popełnić z jednej gałęzi git do innego ja wykonać następującą sekwencję działań:

1. [zobowiązać do gałęzi roboczej]
2. git checkoutgałąź do seryjnej-INTO
3. git cherry-pickdocelowego popełnienia
4. git push
5. git checkoutpracującej oddział

To działa dobrze z jedynym wyjątkiem - za każdym razem mogę wykonać 'git checkout' git zawartość katalog roboczy zostanie zmieniony (oczekiwane) i który powoduje moje IDE (IntelliJ IDEA) do wykonać aktualizację stanu wewnętrznego (ponieważ podrzędne drzewo systemu monitorowania jest modyfikowane zewnętrznie). To naprawdę denerwuje, szczególnie w przypadku dużej liczby małych commitów.

widzę dwie drogi:

1. wykonują „masa wiśnia wybiera”, czyli wykonać dużą liczbę zatwierdzeń; przenieś je do innego oddziału, powiedzmy, w dniu roboczym;
2. mają drugie lokalne repozytorium git i wykonują na nim wyselekcjonowane komórki wiśniowe, tj. Za każdym razem, gdy faktycznie wykonuje się zatwierdzanie i wypychanie do działającej gałęzi, przechodzimy do tego drugiego repozytorium, przeciągamy zmiany i wykonujemy tam wybieranie wiśni;

Nie podoba mi się pierwsze podejście, ponieważ można zapomnieć o przeniesieniu konkretnego zatwierdzenia. Drugi wygląda trochę ... nienaturalnie.

Zasadniczo byłoby idealnie, gdybym mógł powiedzieć "git" przenieść to zatwierdzenie z oddziału o nazwie branchX do oddziału branchX + 1 'bez aktualizacji katalogu roboczego.

Pytanie: czy można wykonać powyższe czynności?

Answer 1

Jeśli nie trzeba często scalać zmian, zamiast wykonywać cherry-pick, co powiesz raz na jakiś czas git merge <working branch> z Twojego <branch to merge into>? Byłby to odpowiednik czipowania wszystkich zmian od czasu ostatniego połączenia, jeśli się nie mylę (nie ma ryzyka, że ​​zapomnisz o zatwierdzeniu, z tym podejściem). W ten sposób "problem edytora" zdarza się rzadziej.

Answer 2

Nie, przeniesienie commit pomiędzy gałęziami nie jest możliwe bez zmiany katalogu roboczego. Dzieje się tak dlatego, że w końcu napotkasz konflikt, w którym to momencie git zatrzymuje się, aby naprawić konflikt. Jeśli twoja praca bezpośrednio nie reprezentowałaby tego stanu, nie byłbyś w stanie poprawnie naprawić konfliktów.

Jeśli się rozejrzysz, na SO znajdziesz wiele innych możliwych rozwiązań tego problemu, ale podstawowy problem brzmi, że twój edytor nie obsługuje plików, które zostały zmienione spod niego. Jest to w zasadzie fakt używania gita. Tak więc albo zaktualizuj edytor, albo przejdź do czegoś bardziej pasującego do przepływu pracy git.