Jak pracować jednocześnie na kilku gałęziach

Jest to kontynuacja tego pytania {[2] } na temat tworzenia gałęzi.

Wydaje mi się dziwne, że nadal będę pracował nad jednym repozytorium, Ponieważ pliki na mojej lokalnej maszynie będą dziwną mieszanką różnych eksperymentów.

Wyobrażam sobie, że najlepszą metodą jest powielanie repozytorium i praca w różnych folderach na moim komputerze dla każdej gałęzi -- ale nie wiem jak to skonfigurować. Mam swoje aktualne repozytorium w Documents / San / CompProj więc jakie są polecenia, których użyłbym do utworzenia nowego repozytorium powiązanego z inną gałęzią w innym folderze lokalnym?

Git jest dla mnie dość nowy, więc chciałbym, abyś mógł wprowadzić jakieś poprawki na to, co zakładam/pytam powyżej.

Author: Community, 2011-12-12

4 answers

Od wersji Git 2.5, git-worktree bezpośrednio wspiera ten przepływ pracy. Zobacz odpowiedź VonC na to pytanie po szczegóły.

Moja odpowiedź poniżej może wystarczyć, jeśli nie lubisz git-worktree z jakiegokolwiek powodu.


Git został zaprojektowany, aby umożliwić Ci pracę w jednym folderze na dysku. Jest to jedno repozytorium, które zawiera wszystkie gałęzie, na których Ci zależy. kasujesz oddział, na którym chcesz pracować w tym czasie.

W repozytorium Git, możesz tylko niech jeden oddział sprawdzi się na raz. Jeśli wyewidencjonujesz drugą gałąź, pliki na dysku zostaną usunięte i zastąpione tymi z drugiej gałęzi.

Jeśli masz następujące gałęzie:

BRANCH-A        BRANCH-B
alpha.txt       alpha.txt
bravo.txt
charlie.txt     charlie.txt
                delta.txt

Gdy jesteś na branch-a i dokonujesz zakupu branch-B , bravo.txt zostaną usunięte i delta.txt zostaną dodane do twojego katalogu roboczego.

Jednakże git-checkout Nie zastąpi zmiany wprowadzone do plików, chyba że podasz -f kłótnia. Jeśli dokonasz zmiany na alpha.txt, a następnie spróbuj przełączyć się na branch-B , otrzymasz komunikat ostrzegający, że Twoje zmiany zostaną utracone i przerywa realizację transakcji.

Wyjątki to Pliki bez śledzenia. Jeśli masz branch-a sprawdzony i utworzysz nowy plik o nazwie echo.txt, Git nie dotknie tego pliku podczas kasowania branch-B. W ten sposób możesz zdecydować, że chcesz zatwierdzić echo.txt przeciwko branch-B bez konieczności przechodzenia przez problemy z (1) przeniesieniem pliku poza repo, (2) pobraniem właściwej gałęzi i (3) przeniesieniem pliku z powrotem do repo.


Przypis

właściwie, Git nie zmusza cię do używania jednego katalogu roboczego. Jeśli chcesz, nic nie powstrzymuje cię przed tworzeniem różnych ścieżek na dysku dla każdej gałęzi, nad którą chcesz pracować.

/home/me/project
 +-- branch-a/
 +-- branch-b/
 +-- ...

Każda z tych ścieżek jest własnym repozytorium Git( każda z nich ma folder .git w środku) i możesz wypychać i ściągać commity między repami.

cd ~/project                     ## Go to my projects directory
git clone branch-a branch-b      ## Create a new branch-b

cd branch-b
 ... work work work ...
git commit -a -m "Made some changes on branch-b"

git pull origin                  ## Fetch and merge the changes from branch-a
git push origin                  ## Push my changes back to branch-a

Tak niektórzy ludzie używają Mercuriala, jeśli nie używają nazwanych gałęzi : klonują repozytorium do nowego katalogu na dysku dla każdej gałęzi, którą chcą, a następnie pchają i ciągną zestawy zmian między nimi.

 31
Author: Stephen Jennings,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-02-22 10:34:32

Z Git 2.5+ (Q2 2015), Git nie jest już zaprojektowany do pracy w jednym folderze (tj. pojedynczym drzewie roboczym)

Git będzie obsługiwał wiele drzew roboczych (dla jednego sklonowanego git repo) nowym poleceniem git worktree add <path> [<branch>].

, który zastępuje starszy skrypt contrib/workdir/git-new-workdir, z bardziej rozbudowanym mechanizmem, w którym te" połączone " drzewa robocze są faktycznie rejestrowane w głównym folderze repo new $GIT_DIR/worktrees (tak, że działa na każdym systemie operacyjnym, w tym Windows).

Będziesz mógł dokonać zakupu różne gałęzie na różnych ścieżkach, będąc częścią tego samego głównego sklonowanego repo.

Zobacz więcej na "wiele działających katalogów z Gitem?"

 28
Author: VonC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:10:47

Twoja troska o pliki na mojej lokalnej maszynie będzie dziwną mieszanką różnych eksperymentów.'jest bezpodstawne - jeśli masz sprawdzoną gałąź 2, nie zobaczysz plików z gałąź 1 w tym samym czasie.

Zrobiłbym coś takiego

# on master branch
git checkout master
# Create a branch for feature 1
git checkout -b feature_1
# work on feature 1

# Start a new feature branch
git checkout master
git checkout -b feature_2
# work on feature 2

# feature 2 finished and committed, time to merge 
git checkout master
git merge feature_2

# update feature_1 branch
git checkout feature_1
git merge master
 1
Author: I82Much,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-12-12 06:05:04

Proponuję moje rozwiązanie poprzez mały skrypt http://www.redhotchilipython.com/en_posts/2013-02-01-clone-per-feature.html

Podczas gdy narzędzia Git stash są ładne, uważam, że posiadanie wielu klonów jest o wiele lepsze. Możesz uruchamiać testy w jednej gałęzi, podczas gdy pracować nad inną. Albo nawet nie musisz zatrzymywać debuggera, zamykać edytora, czyścić plików tempfile ani czegoś innego.

 1
Author: Kostiantyn Rybnikov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-02-04 09:46:31