Pociągnij za kolejną gałąź Git bez przełączania

55

Niedawno przeszliśmy z SVN na Git i jednocześnie wprowadziliśmy nasze systemy na żywo do kontroli wersji (zamiast lokalnego pobierania i kopiowania plików do życia).

W projekcie, do którego jestem przydzielony, wszyscy uzyskujemy dostęp do tego samego repozytorium i aby wprowadzić zmiany na żywo, właśnie git pulltam jesteśmy . Powoduje to problemy, ponieważ nasi projektanci pchają zmiany w VCS, które nie powinny być jeszcze aktywne, ale powinny znajdować się w środowisku testowania sieci.

Kiedy jeden z programistów włącza się teraz na żywo, otrzymuje wszystkie (prawdopodobnie niedokończone) zmiany.

Myślałem o przejściu na żywo do dodatkowej gałęzi i po prostu scaliłem to, co się zmieniło, ale z powodu braku wiedzy na temat git nie mam pojęcia, jak to zrobić.

Mój pomysł to:

Utwórz nowy oddział w live ( git branch live).
Za każdym razem, gdy coś musi się pojawić
- Wyciągnij zmiany w wzorcu (jak git checkout master; git pull; git checkout live:)
- git merge master

Problem polega na tym, że przejście na master lub wciągnięcie wszystkiego bezpośrednio do systemu na żywo spowodowałoby problemy, więc wolałbym tego uniknąć.

Czy jest na to jakiś sposób lub istnieje lepszy sposób zarządzania systemem Live (z wyjątkiem szkolenia webbiesów, aby nie wypychały niedokończonych rzeczy).

git

— Morfildur
źródło

git pull --alldomyślnie nie uruchomi master na żywo, przeciągnie master i scali go z master, i (jeśli istnieje na serwerze) pull na żywo, aby połączyć się z live. Próbowałeś?

— Tobias Kienzler,

Czy twój problem jest spowodowany przez plik, który nie był pod kontrolą wersji przed rozgałęzieniem i dodany przez git po modyfikacji w celu późniejszego opanowania? Tak mi się wcześniej zdarzyło, zwykle wystarczy tymczasowo zmienić nazwę tego pliku, a jeśli nie jest potrzebny na żywo , git checkout -fzignoruj problem - ale wykonaj kopię zapasową!

— Tobias Kienzler,

1

powiązane: stackoverflow.com/questions/3216360/…

— Ciro Santilli 新疆改造中心法轮功六四事件

21

Możesz użyć git stashprzed sprawdzeniem wzorca i wyciągnięciem, a po ponownym sprawdzeniu na żywo użyj git stash pop(lub jeśli twój git jest starszy git stash applyi git stash clearzakładając, że nie ukryłeś niczego innego)

— Tobias Kienzler
źródło

6

git pull --allpobierze wszystkie piloty, ale nadal będzie próbował połączyć gałąź (lub gałąź domyślną) z bieżącą gałęzią.

— mipadi

@mipadi tak, ale tylko bieżąca gałąź sama w sobie, bez próby kasy i spowodowania konfliktu, nie?

— Tobias Kienzler,

Scali dowolną skonfigurowaną gałąź w celu automatycznego scalenia z bieżącą gałęzią (jeśli taka gałąź jest skonfigurowana).

— mipadi

1

@Superole Jest to udokumentowane jako „pobierz wszystkie piloty”, które obejmują nie tylko wiele repozytoriów, ale także oddziały. Choć z perspektywy czasu git fetch --allmoże to być lepsza odpowiedź

— Tobias Kienzler

2

@TobiasKienzler To tylko instruuje git, aby pobierał ze wszystkich skonfigurowanych pilotów. Najczęstszym przypadkiem jest posiadanie tylko jednego zdalnego źródła o nazwie. JEŚLI zdarzy się, że masz więcej niż jednego pilota z tą samą gałęzią, co twój, i nie są w szybkim stosunku do siebie nawzajem, TO użycie tej --allopcji da ci połączenie ośmiornicy różnych wersji gałęzi z prądem ! Więc radzę trzymać się z daleka, --allchyba że tego właśnie szukasz, ponieważ w większości innych przypadków nic ci to nie da.

— Superole,

74

Byłem w stanie wyciągnąć zmiany z origin/masterdo masterpodczas pracy w innej gałęzi za pomocą tego polecenia:

git fetch origin master:master

— Jeff B.
źródło

6

Niesamowite! Dokładnie to, czego szukałem - musi to być znacznie bardziej wyraźnie udokumentowane ...

— Markus Shepherd

2

Dokumentację na ten temat można znaleźć tutaj: git-scm.com/docs/git-fetch#_examples

— c1moore

fetch! =pull

— D. Kovács

5

Najpierw rozwiąż problem. Nie powinni naciskać na oddział, do którego nie mają żadnego interesu.

Wygląda na to, że pytasz

git checkout live
git pull origin master

Spowoduje to próbę połączenia zdalnego mistrza i twojej żywej gałęzi.

— Josh K.
źródło

Problem polega na tym, że obecnie mamy tylko jedną gałąź i nie da się tego zmienić, ponieważ wszyscy są zbyt przyzwyczajeni do SVN i nie chcą poznać zalet czegoś nowego. Możliwe będzie jedynie utworzenie nowej gałęzi w katalogu na żywo. Scalanie zdalnego mistrza z gałęzią aktywną jest tym, czego chcę uniknąć, ponieważ nie mogę uniemożliwić komukolwiek wypychania kodu debugowania, niekompletnych funkcji, błędów składniowych i wszystkiego innego do mistrza (w końcu jestem tylko młodszym programistą). Dziękuję za twoją sugestię.

— Morfildur,

2

@dbeme: Możesz użyć tarballi i łatek. ;) Jeśli nie będą chcieli nauczyć się git (i nie jest wcale trudno się rozgałęziać i łączyć) będziesz mieć problemy.

— Josh K

0

Zalecam utworzenie testowego repozytorium git dla każdego do zatwierdzenia. Wszystkie repozytorium, w tym witryna na żywo, będą klonami repozytorium testowego. W ten sposób każdy może przejść do testów bez dotykania strony internetowej na żywo. Gdy ktoś musi zaktualizować witrynę na żywo, możesz pobrać witrynę na żywo z repozytorium testowego git. Ten przepływ pracy jest dość podobny do SVN. Aby uzyskać większą elastyczność, zalecamy użycie opisanej gałęzi „na żywo”.

Podsumowując, repozytorium git każdego jest klonem repozytorium testowego. Witryna produkcyjna na żywo jest także klonem repozytorium testowego. Alternatywnie, testowanie może być klonem żywej produkcji, tak że „popychanie gita” zawsze zmierza w kierunku produkcji.

Inne opcje, w tym dodanie gałęzi „live” do tego układu lub repozytorium „inscenizacji” między testowaniem a produkcją. Dla dodatkowego bezpieczeństwa zalecam ograniczenie dostępu do repozytorium git na żywo i zmuszanie ludzi do korzystania z bezpiecznego skryptu, który uruchamia produkcję na żywo.

— edgester
źródło