Git
Ta odpowiedź zawiera GitHub, o co pytało także wielu ludzi.
Lokalne repozytoria
Git (lokalnie) ma katalog ( .git), do którego przypisujesz swoje pliki i jest to twoje „lokalne repozytorium”. Różni się to od systemów takich jak SVN, w których natychmiast dodajesz i zatwierdzasz zdalne repozytorium.
Git przechowuje każdą wersję pliku, która zmienia się, zapisując cały plik. Pod tym względem różni się również od SVN, ponieważ można przejść do dowolnej indywidualnej wersji bez „odtwarzania” jej przez zmiany delta.
Git w ogóle nie „blokuje” plików, a tym samym unika funkcji „wyłącznej blokady” dla edycji (przychodzą na myśl starsze systemy, takie jak pvcs), więc wszystkie pliki można zawsze edytować, nawet gdy są offline. W rzeczywistości wykonuje niesamowitą robotę, łącząc zmiany plików (w tym samym pliku!) Podczas ściągania lub pobierania / wypychania do zdalnego repozytorium, takiego jak GitHub. Jedyne, czego potrzebujesz, aby dokonać ręcznych zmian (w rzeczywistości edycja pliku), jest gdy dwie zmiany dotyczą tej samej linii kodu.
Gałęzie
Gałęzie pozwalają zachować główny kod (gałąź „master”), wykonać kopię (nową gałąź), a następnie pracować w obrębie tej nowej gałęzi. Jeśli praca zajmuje trochę czasu lub master otrzyma wiele aktualizacji od czasu utworzenia gałęzi, wówczas należy połączyć lub zmienić bazę (często preferowaną dla lepszej historii i łatwiejszej do rozwiązywania konfliktów) przeciwko gałęzi master. Po zakończeniu scalasz zmiany dokonane w gałęzi z powrotem do repozytorium głównego. Wiele organizacji używa gałęzi do każdego dzieła, bez względu na to, czy jest to element, błąd, czy zadanie. Inne organizacje używają oddziałów tylko do poważnych zmian, takich jak aktualizacje wersji.
Widelec: Za pomocą gałęzi kontrolujesz i zarządzasz gałęzią, podczas gdy za pomocą widelca ktoś inny kontroluje przyjęcie kodu z powrotem.
Mówiąc ogólnie, istnieją dwa główne podejścia do tworzenia oddziałów. Pierwszym z nich jest utrzymanie większości zmian w gałęzi master, używając tylko gałęzi do większych i dłuższych rzeczy, takich jak zmiany wersji, w których chcesz mieć dwie gałęzie dostępne dla różnych potrzeb. Drugi polega na tym, że zasadniczo tworzysz gałąź dla każdego żądania funkcji, poprawki błędu lub czynności, a następnie ręcznie decydujesz, kiedy faktycznie połączyć te gałęzie z główną gałęzią główną. Choć brzmi to nużąco, jest to powszechne podejście, którego obecnie używam i polecam, ponieważ pozwala to utrzymać czystość gałęzi master i jest to master, który promujemy do produkcji, więc chcemy tylko skompletowanego, przetestowanego kodu, poprzez zmianę wersji i łączenie oddziałów.
Standardowym sposobem doprowadzenia gałęzi do trybu „master” jest wykonanie merge. Oddziały można również „przekształcić” w celu „wyczyszczenia” historii. Nie wpływa to na obecny stan i ma na celu nadanie „czystszej” historii.
Zasadniczo chodzi o to, że rozgałęziłeś się z pewnego punktu (zwykle od mistrza). Odkąd rozgałęziłeś się, sam „mistrz” od tego czasu posunął się do przodu od tego punktu rozgałęzienia. Będzie to „czystsze” (łatwiejsze do rozwiązania problemy, a historia łatwiejsza do zrozumienia), jeśli wszystkie zmiany, które wprowadziłeś w oddziale, będą odtwarzane w stosunku do bieżącego stanu głównego wraz ze wszystkimi jego najnowszymi zmianami. Tak więc proces jest następujący: zapisz zmiany; zdobądź „nowego” wzorca, a następnie ponownie zastosuj (to jest część bazy) zmiany ponownie w stosunku do tego. Pamiętaj, że rebase, podobnie jak scalanie, może powodować konflikty, które musisz ręcznie rozwiązać (tj. Edytować i naprawić).
Jedna wskazówka:
uwzglednij bazę tylko wtedy, gdy oddział jest lokalny, a jeszcze nie wysłałeś go na odległość!
Wynika to głównie z tego, że bazowanie może zmienić historię, którą widzą inni ludzie, która może obejmować ich własne zobowiązania.
Śledzenie oddziałów
Są to gałęzie, które są nazywane origin/branch_name(w przeciwieństwie do just branch_name). Kiedy przepychasz i ciągniesz kod do / ze zdalnych repozytoriów, jest to w rzeczywistości mechanizm, poprzez który to się dzieje. Na przykład, gdy dzwonisz git pushdo oddziału building_groups, twoja gałąź najpierw origin/building_groupsprzechodzi do zdalnego repozytorium, a następnie do niego. Podobnie, jeśli wykonasz a git fetch building_groups, pobrany plik zostanie umieszczony w origin/building_groupsoddziale. Następnie możesz scalić tę gałąź z lokalną kopią. Naszą praktyką jest zawsze git fetchłączenie ręczne i scalanie, a nie tylko git pull(co robi oba powyższe w jednym kroku).
Pobieranie nowych oddziałów.
Zdobywanie nowych gałęzi: w początkowym punkcie klonu będziesz mieć wszystkie gałęzie. Jeśli jednak inni programiści dodadzą gałęzie i wypchną je do pilota, musi istnieć sposób, aby „wiedzieć” o tych gałęziach i ich nazwach, aby móc ściągnąć je lokalnie. Odbywa się to za pośrednictwem, git fetchktóry przenosi wszystkie nowe i zmienione gałęzie do lokalnego repozytorium za pomocą gałęzi śledzących (np origin/.). Po fetchedycji można git branch --remotewyświetlić listę gałęzi śledzenia i git checkout [branch]faktycznie przełączyć się na dowolną z nich.
Scalanie
Scalanie to proces łączenia zmian kodu z różnych gałęzi lub z różnych wersji tej samej gałęzi (na przykład, gdy lokalna gałąź i zdalny nie są zsynchronizowane). Jeśli ktoś opracował pracę w oddziale, a praca jest kompletna, gotowa i przetestowana, można ją połączyć z mastergałęzią. W tym git checkout mastercelu należy przejść do masteroddziału git merge your_branch. Scalenie połączy wszystkie różne pliki, a nawet różne zmiany w tych samych plikach . Oznacza to, że faktycznie zmieni kod w plikach, aby scalić wszystkie zmiany.
Kiedy robi checkoutz masternim jest również zaleca się zrobić git pull origin master, aby uzyskać najnowszą wersję Remote Master połączyły się lokalnego pana. Jeśli zdalny master zmienił się, tzn. moved forwardZobaczysz informacje, które odzwierciedlają to podczas tego git pull. Jeśli tak jest (zmiana wzorca) zaleca się, git checkout your_brancha następnie rebaseopanowanie, aby zmiany zostały faktycznie „odtworzone” na „nowym” wzorcu. Następnie kontynuowałbyś aktualizowanie mistrza, jak pokazano w następnym akapicie.
Jeśli nie ma żadnych konfliktów, wówczas master doda nowe zmiany. Jeśli wystąpią konflikty, oznacza to, że te same pliki mają zmiany wokół podobnych linii kodu, których nie może automatycznie scalić. W takim przypadku git merge new_branchzgłosi, że istnieje konflikt (y) do rozwiązania. „Rozwiązujesz” je, edytując pliki (które zawierają obie zmiany), wybierając żądane zmiany, dosłownie usuwając wiersze zmian, których nie chcesz, a następnie zapisując plik. Zmiany są oznaczone separatorami, takimi jak ========i <<<<<<<<.
Po rozwiązaniu wszelkich konfliktów jeszcze raz git addi git committe zmiany, aby kontynuować scalanie (podczas procesu otrzymasz informacje zwrotne od git).
Gdy proces nie działa dobrze, okaże się, że git merge --abortbardzo przydatne jest zresetowanie rzeczy.
Interaktywne zmiany bazy i zgniatanie / zmiana kolejności / usuwanie zatwierdzeń
Jeśli wykonałeś pracę w wielu małych krokach, np. Codziennie zatwierdzasz kod jako „praca w toku”, możesz chcieć „zgnieść” wiele małych zmian w kilka większych zmian. Może to być szczególnie przydatne, gdy chcesz zrobić recenzje kodu ze współpracownikami. Nie chcesz odtwarzać wszystkich „kroków”, które podjąłeś (za pomocą commits), chcesz tylko powiedzieć, że tutaj jest efekt końcowy (diff) wszystkich moich zmian dla tej pracy w jednym zatwierdzeniu.
Kluczowym czynnikiem do oceny przy rozważaniu, czy to zrobić, jest to, czy wiele zatwierdzeń jest przeciwko temu samemu plikowi lub plikom więcej niż raz (lepiej w tym przypadku zgnieść zatwierdzenia). Odbywa się to za pomocą interaktywnego narzędzia rebasingu. To narzędzie pozwala zgniatać zatwierdzenia, usuwać zatwierdzenia, redagować wiadomości itp. Na przykład git rebase -i HEAD~10( uwaga: to a ~, nie a- ) wywołuje następujące:
Bądź jednak ostrożny i używaj tego narzędzia „ostrożnie”. Wykonuj jednorazowo squash / delete / reorder, wyjdź i zapisz ten commit, a następnie ponownie włącz narzędzie. Jeśli zatwierdzenia nie są ciągłe, możesz zmienić ich kolejność (a następnie zgnieść w razie potrzeby). Możesz tutaj faktycznie usunąć zatwierdzenia, ale naprawdę musisz być pewien, co robisz, kiedy to robisz!
Widelce
Istnieją dwa główne podejścia do współpracy w repozytoriach Git. Pierwszy, wyszczególniony powyżej, jest bezpośrednio przez gałęzie, które ludzie ciągną i pchają z / do. Ci współpracownicy mają zarejestrowane klucze SSH w zdalnym repozytorium. Pozwoli to im przesyłać bezpośrednio do tego repozytorium. Minusem jest to, że musisz utrzymywać listę użytkowników. Drugie podejście - rozwidlenie - pozwala każdemu „rozwidlić” repozytorium, w zasadzie tworząc lokalną kopię na własnym koncie repozytorium Git. Następnie mogą dokonać zmian, a po zakończeniu wysłać „żądanie ściągnięcia” (tak naprawdę jest to bardziej „push” od nich i żądanie „ściągnięcia” dla faktycznego opiekuna repozytorium), aby otrzymać kod akceptowany.
Ta druga metoda, wykorzystująca widelce, nie wymaga, aby ktoś prowadził listę użytkowników repozytorium.
GitHub
GitHub (zdalne repozytorium) to zdalne źródło, do którego normalnie wypychasz i wyciągasz zatwierdzone zmiany, jeśli masz (lub jesteś dodany) takie repozytorium, więc lokalne i zdalne są w rzeczywistości całkiem odrębne. Innym sposobem myślenia o zdalnym repozytorium jest to, że jest to .gitstruktura katalogów na zdalnym serwerze.
Po „rozwidleniu” - w GUI przeglądarki internetowej GitHub możesz kliknąć ten przycisk 
- tworzysz kopię („klon”) kodu na swoim koncie GitHub. Może to być trochę subtelne za pierwszym razem, więc pamiętaj, aby sprawdzić, w czyim repozytorium znajduje się podstawa kodu - pierwotny właściciel lub „rozwidlenie z”, a ty, na przykład:
Po utworzeniu lokalnej kopii możesz wprowadzać zmiany według własnego uznania (przeciągając je i popychając na komputer lokalny). Kiedy skończysz, prześlij „żądanie ściągnięcia” do pierwotnego właściciela / administratora repozytorium (brzmi fantazyjnie, ale tak naprawdę po prostu kliknij to 
:), a oni „ściągną” to.
Bardziej powszechne dla zespołu pracującego nad kodem jest „klonowanie” repozytorium (kliknij ikonę „kopiuj” na głównym ekranie repozytorium). Następnie lokalnie wpisz git clonei wklej. Spowoduje to skonfigurowanie Cię lokalnie, a także możesz wypychać i przyciągać (udostępnioną) lokalizację GitHub.
Klony
Jak wskazano w sekcji na GitHub, klon jest kopią repozytorium. Gdy masz zdalne repozytorium, wydajesz git clonepolecenie przeciwko jego adresowi URL, a następnie kończy się lokalna kopia lub klon repozytorium. Ten klon ma wszystko , pliki, gałąź główną, inne gałęzie, wszystkie istniejące zatwierdzenia, cały shebang. To jest ten klon, do którego dodajesz i zatwierdzasz, a następnie repozytorium zdalne jest tym, do którego wypychasz te zatwierdzenia. Jest to lokalna / zdalna koncepcja, która sprawia, że Git (i podobne do niego systemy, takie jak Mercurial) jest DVCS ( rozproszony system kontroli wersji) w przeciwieństwie do bardziej tradycyjnych CVS (systemów kontroli wersji), takich jak SVN, PVCS, CVS itp., Gdzie zatwierdzasz bezpośrednio w zdalnym repozytorium.
Wyobrażanie sobie
Wizualizację podstawowych pojęć można znaleźć na stronie
http://marklodato.github.com/visual-git-guide/index-en.html i
http://ndpsoftware.com/git-cheatsheet.html#loc=index
Jeśli chcesz wizualnie pokazać, jak działają zmiany, nie możesz pobić narzędzia wizualnego gitg( gitxdla systemu macOS) za pomocą interfejsu GUI, który nazywam „mapą metra” (zwłaszcza London Underground), świetną do pokazania, kto co zrobił, jak rzeczy się zmieniają, dzielą i łączą itp.
Możesz także używać go do dodawania, zatwierdzania i zarządzania zmianami!
Chociaż gitg / gitx jest dość minimalny, liczba narzędzi GUI stale się powiększa. Wielu użytkowników komputerów Mac używa rozwidlenia gitx firmy Brotherbard, a w przypadku Linuksa świetną opcją jest smart-git z intuicyjnym, ale potężnym interfejsem:
Zauważ, że nawet za pomocą narzędzia GUI prawdopodobnie wykonasz wiele poleceń w wierszu poleceń.
W tym celu mam w swoim ~/.bash_aliasespliku następujące aliasy (które są wywoływane z mojego ~/.bashrcpliku dla każdej sesji terminala):
# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '
I mam w swoim ~/.gitconfigpliku następujące „aliasy git” - po co je mają?
Tak więc zakończenie gałęzi (za pomocą klawisza TAB) działa!
Są to:
[alias]
co = checkout
cob = checkout -b
Przykładowe użycie: git co [branch]<- uzupełnianie tabulatorów dla oddziałów będzie działać.
Narzędzie do nauki GUI
Https://learngitbranching.js.org/ może okazać się przydatny w nauce niektórych podstawowych pojęć. Zrzut ekranu:
Wideo: https://youtu.be/23JqqcLPss0
Wreszcie 7 kluczowych ratowników!
Wprowadzasz zmiany, dodajesz i zatwierdzasz (ale nie wypychasz), a potem och! zdajesz sobie sprawę, że jesteś mistrzem!
git reset [filename(s)]
git checkout -b [name_for_a_new_branch]
git add [file(s)]
git commit -m "A useful message"
Voila! You've moved that 'master' commit to its own branch !
Psuwasz niektóre pliki podczas pracy w lokalnym oddziale i po prostu chcesz wrócić do tego, co miałeś ostatnio git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
Zaczynasz wprowadzać zmiany lokalnie, edytujesz pół tuzina plików, a potem, cholera, nadal jesteś w gałęzi master (lub innej):
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit them
Zepsułeś jeden konkretny plik w bieżącym oddziale i chcesz w zasadzie „zresetować” ten plik (utracić zmiany) do tego, jak był ostatni raz, gdy ściągałeś go ze zdalnego repozytorium:
git checkout your/directories/filename
To faktycznie resetuje plik (podobnie jak wiele poleceń Gita, nie jest dobrze nazwany do tego, co tutaj robi).
Wprowadzasz pewne zmiany lokalnie, chcesz mieć pewność, że ich nie zgubisz podczas wykonywania git resetlub rebase: Często robię ręczną kopię całego projektu ( cp -r ../my_project ~/), gdy nie jestem pewien, czy mogę zepsuć się w Git lub stracić ważne zmiany.
Bazujesz, ale wszystko się psuje:
git rebase --abort # To abandon interactive rebase and merge issues
Dodaj gałąź Git do PS1pytania (patrz https://unix.stackexchange.com/a/127800/10043 ), np.
Oddział jest selenium_rspec_conversion.
