Jaki jest zamierzony przypadek użycia skrytki git?

Jeśli pracuję w gałęzi A i nagle muszę pracować na gałęzi B, zanim będę gotowy z zatwierdzeniem w gałęzi A, przechowuję zmiany w gałęzi A, kasuję B, wykonuję tam swoją pracę, a następnie kasuję A i stosuję skrytkę.

Jeśli pracuję nad A i chcę przestać pracować na jeden dzień, czy powinienem schować swoją pracę i zastosować ją następnego dnia (po wznowieniu pracy), czy po prostu zostawić rzeczy tak, jak są - niezatwierdzone zmodyfikowane pliki w katalog roboczy? Nie rozumiem, dlaczego miałbym w tym przypadku używać skrytki, z wyjątkiem sytuacji, gdy jest jakieś zabezpieczenie.

Również inny scenariusz: pracuję zarówno w pracy, jak iw domu. Jeśli nie jestem gotowy na zatwierdzenie, kiedy chcę wrócić do domu, czy mogę schować swoją pracę, przesłać ją do GitHub, a następnie pobrać tę skrytkę w domu?

Skrytka to tylko wygodna metoda. Ponieważ gałęzie są tak tanie i łatwe w zarządzaniu w git, osobiście prawie zawsze wolę tworzyć nową tymczasową gałąź niż przechowywanie, ale jest to głównie kwestia gustu.

Jedynym miejscem, w którym lubię przechowywać, jest sytuacja, gdy odkrywam, że zapomniałem czegoś w ostatnim zatwierdzeniu i już zacząłem pracować nad następnym w tej samej gałęzi:

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
git stash save

# some changes in the working dir

# and now add them to the last commit:
git add -u
git commit --amend

# back to work!
git stash pop

Odpiszę na trzech akapitach.

Część 1:

git stash(Aby zapisać niezatwierdzone zmiany w „skrytce”. Uwaga: spowoduje to usunięcie zmian z drzewa roboczego!)

git checkout some_branch(zmiana na docelową branżę - w tym przypadku some_branch)

git stash list (lista skrytek)

Możesz zobaczyć:
stash @ {0}: WIP on {branch_name}: {SHA-1 of last commit} {last commit of you branch}
stash @ {0}: WIP on master: 085b095c6 modyfikacja do testu

git stash apply (aby założyć skrytkę na drzewo robocze w aktualnej gałęzi)

git stash apply stash@{12}(jeśli będziesz mieć wiele skrytek, możesz wybrać, która skrytka będzie obowiązywać - w tym przypadku stosujemy skrytkę 12)

git stash drop stash@{0}(do usunięcia z listy skrytek - w tym przypadku skrytka 0)

git stash pop stash@{1} (aby zastosować wybraną skrytkę i zrzucić ją z listy)

Część 2:
Możesz ukryć swoje zmiany za pomocą tego polecenia, ale nie jest to konieczne.
Możesz kontynuować następnego dnia bez skrytki.
To polecenie do ukrywania zmian i pracy na różnych gałęziach lub do implementacji niektórych realizacji kodu i zapisywania w schowkach bez gałęzi i zatwierdzeń niestandardowych przypadków!
Później możesz wykorzystać część skrytek i sprawdzić, która jest lepsza.

Część 3:
Skryj polecenie dla lokalnego ukryj swoje zmiany.
Jeśli chcesz pracować zdalnie, musisz angażować się i naciskać.

Głównym pomysłem jest

Przechowuj zmiany w brudnym katalogu roboczym

Tak więc polecenie Skrytka Podstawowa zachowuje niektóre zmiany, których nie potrzebujesz lub chcesz ich w danej chwili; ale możesz ich potrzebować.

Użyj git stash, jeśli chcesz zarejestrować bieżący stan katalogu roboczego i indeksu, ale chcesz wrócić do czystego katalogu roboczego. Polecenie zapisuje lokalne modyfikacje i przywraca katalog roboczy, aby pasował do zatwierdzenia HEAD .

Możesz użyć następujących poleceń:

• Aby zapisać niezatwierdzone zmiany

  git stash

• Aby wyświetlić listę zapisanych skrytek

  git stash list

• Aby zastosować / odzyskać niezatwierdzone zmiany, gdzie x wynosi 0,1,2 ...

  git stash apply stash@{x}

Uwaga:

• Aby założyć skrytkę i usunąć ją z listy skrytek

  git stash pop stash@{x}

• Zastosować skrytkę i zachować ją na liście skrytek

  git stash apply stash@{x}

Jeśli trafisz, git stashgdy masz zmiany w kopii roboczej (nie w obszarze przejściowym), git utworzy ukryty obiekt i wepchnie go na stos skrytek (tak jak zrobiłeś, git checkout -- .ale nie stracisz zmian). Później możesz wyskoczyć z wierzchu stosu.

Polecenie stash ukryje wszelkie zmiany, które wprowadziłeś od ostatniego zatwierdzenia. W twoim przypadku nie ma powodu, aby go ukrywać, jeśli masz zamiar kontynuować pracę następnego dnia. Użyłbym skrytki tylko do cofania zmian, których nie chcesz zatwierdzać.

Wiem, że StackOverflow nie jest miejscem na odpowiedzi oparte na opiniach, ale tak naprawdę mam dobrą opinię na temat tego, kiedy odkładać zmiany na półkę.

Nie chcesz wprowadzać zmian eksperymentalnych

Kiedy wprowadzasz zmiany w swoim obszarze roboczym / drzewie roboczym, jeśli musisz wykonać jakiekolwiek operacje oparte na gałęzi, takie jak scalanie, wypychanie, pobieranie lub ściąganie, musisz znajdować się w czystym punkcie zatwierdzenia. Więc jeśli masz zmiany w obszarze roboczym, musisz je zatwierdzić. Ale co, jeśli nie chcesz ich popełnić? A jeśli są eksperymentalne? Coś, czego nie chcesz, aby było częścią Twojej historii zmian? Coś, czego nie chcesz, aby inni widzieli, gdy pchasz na GitHub?

Nie chcesz utracić lokalnych zmian podczas twardego resetu

W takim przypadku możesz wykonać twardy reset. Ale jeśli wykonasz twardy reset, utracisz wszystkie zmiany lokalnego drzewa roboczego, ponieważ wszystko zostanie nadpisane do miejsca, w którym znajdowało się w momencie ostatniego zatwierdzenia, i utracisz wszystkie zmiany.

Tak więc, jeśli chodzi o odpowiedź `` kiedy powinieneś schować '', odpowiedź brzmi, gdy musisz wrócić do czystego punktu zatwierdzenia ze zsynchronizowanym drzewem roboczym / indeksem / zatwierdzeniem, ale nie chcesz stracić lokalnych zmian w proces. Po prostu odłóż zmiany do skrytki i wszystko w porządku.

A kiedy już skończysz skrytkę, a następnie scalisz, wyciągniesz lub wypchniesz, możesz po prostu schować pop lub zastosować i wrócisz do miejsca, od którego zacząłeś.

Git stash i GitHub

GitHub stale dodaje nowe funkcje, ale w tej chwili jest teraz sposób na zapisanie tam skrytki. Ponownie, idea skrytki polega na tym, że jest ona lokalna i prywatna. Nikt inny nie może zajrzeć do twojego schowka bez fizycznego dostępu do twojej stacji roboczej. W ten sam sposób git reflog jest prywatny, a dziennik git jest publiczny. Prawdopodobnie nie byłby prywatny, gdyby został przeniesiony do GitHub.

Jedna sztuczka może polegać na zrobieniu różnicy w obszarze roboczym, sprawdzeniu tego pliku w repozytorium git, zatwierdzeniu, a następnie wypchnięciu. Następnie możesz wyciągnąć z domu, pobrać różnicę, a następnie ją rozwinąć. Ale to dość niechlujny sposób na osiągnięcie takich wyników.

git diff > git-dif-file.diff