2015-03-09 16 views
14

Czy mogę mieć wiele obszarów pomostowych lub uzyskać podobny efekt za pomocą git?Wiele obszarów pomostowych

Mój typowy przepływ pracy jest wzdłuż linii:

  • pracy, praca, praca
  • teraz mam pomysł na coś pożytecznego, niech zobowiązać go git add -p, y, y
  • ale pierwszy te mniejsze zmiany stylu: git reset HEAD .
  • git add -p, n, n, y, q, git commit -m "style changes"
  • git add -p .. popełnić rzeczywistej rzeczą

Czasami mam 20 mniejszych zobowiązuje się dokonać z ogromnym stosie zmian. Oszczędziłoby mi to wiele godzin dziennie, gdybym mógł przebiec łatki takie jak git add -p, a następnie "wysłać" każdą łatkę do własnego obszaru przemieszczania i zatwierdzić każdy obszar oddzielnie.

+0

Czy możesz przełączać się między lokalnymi oddziałami? – neontapir

+0

Nie jestem pewien, czy rozumiem? W jaki sposób pomógłby mi uniknąć przechodzenia przez wszystkie łaty dla każdego zatwierdzenia? –

+0

Myślę, że jestem tym, który nie rozumie. Próbujesz skonfigurować taki przepływ pracy? http://rypress.com/tutorials/git/patch-workflows – neontapir

Odpowiedz

6

Można faktycznie mieć wiele różnych obszarów pomostowych (bardziej dosłownie, wiele plików indeksu) w git. Aby osiągnąć pożądany efekt, musielibyście napisać swój własny wariant git add -p, więc to, co zrobię, to szkic, jak to się dzieje, jak to zrobić.

Domyślny indeks plików jedna git używa, jeśli nie kieruje go do innych plików indeksu życia w .git/index (lub, bardziej poprawnie powłoki, $GIT_DIR/.index gdzie $GIT_DIR jest pobierane ze środowiska lub, jeśli nie jest ustawiona tam, od git rev-parse --git-dir).

Jeśli jednak ustawisz zmienną środowiskową GIT_INDEX_FILE, git użyje tego pliku zamiast indeksu. Tak więc, można rozpocząć swoje „zmiany scatter czterech oddziałów” procesie robiąc coś takiego:

GIT_DIR=${GIT_DIR:-$(git rev-parse --git-dir)} || exit 1 
index_tmp_dir=$(mktemp -d) || exit 1 
trap "rm -rf $index_tmp_dir" 0 1 2 3 15 # clean up on exit 

# make four copies of initial staging area 
for f in i1 i2 i3 i4; do 
    cp $GIT_DIR/index $index_tmp_dir/$f 
done 

# THIS IS THE HARD PART: 
# Now, using `git diff-files -p` or similar, get patches 
# (diff hunks). 
# Whenever you're ready to stage one, pick an index for it, 
# then use: 
GIT_INDEX_FILE=$index_tmp_dir/$which git apply --cached < diffhunk 

# Once done, commit each index file separately with some 
# variation on: 
for f in i1 i2 i3 i4; do 
    GIT_INDEX_FILE=$index_tmp_dir/$which git commit 
done 

Dla części oznaczonej „Najtrudniejsze”, najlepiej może być również skopiować dodatek interaktywny skrypt perla git za , znalezione w $(git --exec-path)/git-add--interactive, a następnie zmodyfikuj, aby pasowało. Aby usunąć ograniczenie "dokładnie cztery zatwierdzenia", zmień to interaktywnie - dodaj dynamicznie nowy plik indeksu (przez skopiowanie oryginału, lub może utworzenie "pustego" indeksu równego zatwierdzeniu HEAD lub cokolwiek innego, patrz także git read-tree).

+5

To jest dokładnie ten rezultat, którego szukałem. Jestem zaskoczony, że nie jest to bardziej powszechne przynajmniej mieć dobrze znane rozwiązanie strony trzeciej. Czy coś z mojej pracy zostało przerwane? –

+1

Nie powiedziałbym "zepsuty" tak samo jak "nietypowy".I nie, żebym odniósł z tego wielki sukces, ale staram się zrobić wiele drobnych poprawek, zarówno dla "głównego zadania pod ręką", jak i (oddzielne zatwierdzenia, ale w tej samej gałęzi temp.) Dla małej strony poprawki, które mogę następnie podzielić na różne gałęzie za pomocą 'git cherry-pick' (a następnie oczyścić lub odrzucić gałąź, na której zostały wykonane wszystkie małe poprawki). (Która jest metoda, którą mówisz, to więcej księgowości, itp.) – torek

+5

@ThomasJensen, imo ten przepływ pracy jest jedynym rozsądnym. nie jest realistycznie pracować * wyłącznie * dyskretnymi porcjami logicznymi, a następnie je zatwierdzać. wchodzisz w ruch, ponieważ pracujesz nad jednym plikiem, zauważysz coś innego, może tak prostego, jak stare komentarze, które wymagają usunięcia. godzinę później, a twój indeks jest pełen różnych zmian. umiejętność przechodzenia przez nie, odsuwanie każdej zmiany do odpowiedniego kawałka logicznego, jest dokładnie tym, czego potrzebujesz przez większość czasu. to szokujące, że nie jest upieczone w funkcjonalności. – Jonah

Powiązane problemy