Git
EmcKnowledgeBase | OstatnieZmiany | PageIndex | Preferencje | LinuxCNC.org
Szukaj:
W dniu 20 czerwca 2009 r. projekt emc2 zaczął używać [git] jako systemu kontroli wersji CVS wymiany. [Czytaj ogłoszenie]
Ta strona zbiera instrukcje i wskazówki dotyczące korzystania z emc2 git. Istnieje również wiele dokumentacji git, w tym
[Poradnik git]
[Everyday git]
[Git dla leniwych]
i pełnego podręcznika dla każdego polecenia git (man git-clone git lub - klon pomocy)
Poniższe wskazówki mogą czuć się bardzo trudne, nie panikuj. Twój dnia na dzień życie z git będzie bardzo proste:
git pull git commit-git format-patch lub git push
1. Przygotuj swój system rozwoju z git
1.1. Zainstaluj git w systemie
1.2. Konfigurowanie tożsamości
2. Tworzenie wstępnej check-out
3. Historia
4. Commit zmian
4.1. stylu wiadomość Commit
5. Get zmian od innych
5.1. ... z centralnego repozytorium
5.2. ... z innych repozytoriów
5.3. ... z łat
6. Praca z oddziałów
6.1. Jeśli wolisz korzystać z różnych katalogów dla różnych branż
7. Podziel się z innymi zmiany
7.1. Wybierz odpowiedni punkt wyjścia
7.2. wielokrotnego użytku zobowiązuje się do zorganizowania zmian
7.3. Śledz
stylu kodu okolicy
7.4. Przygotować zobowiązuje do dzielenia się z innymi projektantami
7.5. Upewnienie się co popełnienia buduje
7.6. Wyślij łaty poprzez e-mail lub sieci
7.7. Wciśnij zmian w centralnym repozytorium
7.8. Wciśnij zmian w swoim własnym publicznym repozytorium
8. Polityki
8.1. Zmiana nazwy plików
8.2. Najlepsze "rebase"
9. Porady i wskazówki
9.1. Korzystanie globalnej ignorować plik edytora do tworzenia kopii zapasowych
9.2. Pull Script
9.3. kopiowanie do pamięci USB
9.4. Stash przed ciągnąć
1. Przygotuj swój system rozwoju z git
1.1. Zainstaluj git w systemie
W menedżer pakietów, wybrać pakiet "git-core" (pakiet "git" to niepowiązanych programu; nie wybieraj go). Opcjonalnie wybierz opcję "gitk" lub "qgit" (nie na Dapper) do graficznego widoku
historii projektu i "git-gui" graficznie wybrać pliki do popełnienia.
Jeśli korzystasz z Ubuntu Dapper, git 1,6 pakiety są dostępne na serwerze pakiet linuxcnc.org w emc2.3 katalogu. Jeśli masz już tego repozytorium włączona, wystarczy zaktualizować listę
pakietów, i nowych pakietów git będzie dostępne do instalacji. (Git 1,1 pakiety wysłane z dapper, i git 1,5 pakietów w dapper-backports, nie są zalecane z różnych powodów)
1.2. Skonfiguruj tożsamości
git config - global user.name "Twoje imię i nazwisko" git config - global user.email "[e-mail]"
Użyj swojego prawdziwego nazwiska (a nie obsługiwać) i użyć unobfuscated adres e-mail.
2. Załóż początkowej check-out
"Klon" jest polecenie git, że otrzymuje kopię historii projektu. Jest to mniej więcej jak "cvs co", z wyjątkiem, że cała historia projektu (nie tylko bieżących plików roboczych) są dostępne po clone:
git clone git: / / git.linuxcnc.org/git/emc2.git emc2-dev
spowoduje to utworzenie nowego lokalnego katalogu "emc2-dev 'i pobrać pełną historię projektu. W systemie z połączenia 3 Mb, trwało to około 3 minuty i utworzonego katalogu jest około 80
mega.
Jeśli jesteś programistą z "push" dostępu, korzystania
git clone ssh: / / [e-mail] / git/emc2.git emc2-dev
Wszystkie polecenia zakładają, że znajdują się w katalogu emc2-dev, chyba że zaznaczono inaczej.
3. Wyświetl historię
Spójrz na historię:
git log-C - stat
(Log git ma kilka opcji, ten zestaw wykrywa zmienia nazwę i kopie, i pokazuje podsumowanie, jakie pliki zostały zmienione w każdym commit)
Przyjrzyj się dokładniej w szczególności zmiany przez commit:
git log-C-p -1 57c609
(-P wynika, plaster, -1 ogranicza do jednej zmiany, a 57c609 jest początkiem popełnienia Widoczne po pierwszych "log git 'command)
Uzyskać listę zobowiązuje się do określonego pliku, ponieważ v2.1.7 branży:
git log - v2.1.7..origin/v2_3_branch oneline - src / hal / components / stepgen.c
Historia graficznie, jeśli zainstalowane niezbędne programu:
gitk - wszystkie qgit - wszystkie
Można także [zobacz online historii gitweb] , ale przeglądanie historii lokalnie często jest bardziej wydajny.
4. Dokonać zmian
Edycja niektórych plików, a następnie zatwierdzić zmiany lokalnie:
git commit-s-a-m "moje dobre intencje zmiany"
Użyj "git add", aby wybrać konkretne pliki do popełnienia lub "git add - interactive ', aby określić konkretne zmiany w określonych plików do popełnienia. "Git add" również funkcje, takie jak "cvs
add" dla nowych plików:
git git add README commit-a-m "moje dobre intencje zmiany"
Użyj GUI do wyboru pojedynczych zmian dokonać, i komponować popełnienia wiadomość:
git gui qgit
W git "commit" jest czysto lokalne działania. Patrz "Podziel się zmiany z innymi" poniżej.
4.1. Commit stylu wiadomość
Przechowywać popełnienia wiadomości około 72 kolumn szeroki (tak, że w domyślnej wielkości okna terminala, nie zawijają, gdy wynika z "git log")
Korzystając z pierwszego wiersza jako podsumowanie zamiarem zmiany (niemal jak w temacie wiadomości e-mail). Po nim pusty wiersz, to już komunikat wyjaśniający zmiany. Przykład:
Pozbądz
RTAPI_SUCCESS, u\
yj 0 zamiast
Badanie "retval <0" powinni czuć się znają, jest to tego samego rodzaju test, który u\
ytku w przestrzeni u\
ytkownika (zwraca -1 błędu) oraz w przestrzeni ją
5. Pobierz zmian od innych
5.1. ... z centralnego repozytorium
Aby zmiany, które zostały popełnione na miejscu, w którym pierwotnie sklonowane z:
git pull
5.2. ... z innych repozytoriów
Pull zmiany wprowadzone przez innego autora w jego publicznym repozytorium, ale jeszcze nie zobowiązały się do centralnego repozytorium:
git pull git: / / git.unpythonic.net/emc2-ignores.git mistrza
(Usuwa dwa zobowiązuje się, że zmiana życia. Plików cvsignore do nowych plików. Gitignore i dodać brakujące elementy do. Gitignore)
"Git zdalnego mogą być używane do zarządzania krótkich nazw dla repozytoriów, które są często pobierać papier.
5.3. ... z łat
Użyć patcha z innego dewelopera, przy zachowaniu innych deweloperów tożsamości jako autora poprawki:
git am - signoff patch.mbox
6. Praca z oddziałów
Aby wyświetlić tylko oddziały w lokalnym repozytorium:
git oddział
Aby wyświetlić listę wszystkich oddziałów w zdalnym repozytorium:
git branch-r
Aby sprawdzić oddział na przykład 2,4 oddziału:
git checkout-b origin/v2.4_branch v2.4_branch
Do pracy na 2,4 oddziału, a nie "panów" ("master" jest odpowiednikiem git z 'trunk' cvs):
git branch - v2.4_branch origin/v2.4_branch śledzić git v2.4_branch kasie
Po oddziału, można swobodnie przełączać master i oddziału:
git git checkout mistrza kasie v2.4_branch
Możesz stworzyć swój własny oddział na off innego oddziału:
git oddziału pana my-topic
git często używa "temat" jako miejsce dla nazwę oddziału, bo wszystko w oddziale powinny znajdować się na jednym "temacie" - temat można dodać X funkcji, byłaby podsystemu Y, tylko
poprawki błędów z wersji Z, a więc na.
6.1. Jeśli wolisz korzystać z różnych katalogów dla różnych branż
Następującej kolejności tworzy "emc2.3-dev" obok "emc2-dev", a następnie używa "git ponownie połączyć", aby zaoszczędzić miejsce na dysku, a następnie przełącza się na v2_3_branch w
katalogu emc2.3-dev:
cp-r emc2-dev / emc2.3-dev git ponownie połączyć emc2.3-dev / emc2-dev / cd emc2.3-dev git branch v2_3_branch origin/v2_3_branch git checkout v2_3_branch
7. Podziel się z innymi zmiany
7.1. Wybierz odpowiedni punkt wyjścia
Do nowych funkcji, należy użyć git "pochodzenia / master" oddział jako punkt wyjścia.
Dla błędów, użyj merge-bazy master i v2.4_branch. Możesz wykonać poprawkowe i połączyć je w obie gałęzie w taki sposób:
git checkout $ (git merge-base pochodzenia origin/v2.4_branch / master) git checkout-b opisowo-bugfix-branch-name edycji / kompilacji / test / commit git check
Sprawdz
z jepler przed pchania zmian v2.4_branch. Jeśli bugfix jest dopuszczony do v2.4_branch, to będzie to również ustalić na mistrza, gdy zmiany w gałęzi są połączone w górę.
Aby uzyskać więcej informacji o tym, dlaczego do struktury poprawek tak, patrz [gitworkflows: Scalanie W górę] .
7.2. Wielokrotnego użytku zobowiązuje się do zorganizowania zmian
Kiedy to stosowne, organizują zmiany w serii zobowiązuje, gdzie każdy commit jest logicznym krokiem w kierunku twój ostateczny cel. Na przykład, pierwszy czynnik na kilka skomplikowanych
kod do nowej funkcji. Następnie, w drugim popełnienia, ustala podstawowych błędów. Następnie, w trzeciej popełnienia, dodać nową funkcję, która jest łatwiejsze, refaktoringu i nie będzie
pracował bez ustalenia tego błędu.
Jest to przydatne do recenzentów, ponieważ łatwiej jest zobaczyć, że "czynnikiem się kod do nowej funkcji" krok miał rację, gdy nie ma innych zmian mieszane, łatwiej jest zobaczyć, że problem
został rozwiązany, gdy zmiana, która naprawia jest oddzielony od nowa funkcja, i tak dalej.
7.3. Postępuj zgodnie z stylu kod okolicznych
Dołożyć starań, aby przestrzegać obowiązującego stylu wcięcia wokół kodu. W szczególności, zmiany w białych utrudnić innym programistom do śledzenia zmian w czasie. Jeśli kod
formatowania należy zrobić, zrób to jak popełnić oddzielone od wszelkich zmian semantycznych.
7.4. Przygotuj zobowiązuje do dzielenia się z innymi projektantami
Z git, można nagrywać każdy edytować i falstart jako oddzielny popełnienia. Jest to bardzo wygodne jako sposób tworzenia punktów kontrolnych w trakcie rozwoju, ale często nie chcesz
podzielić się tymi falstartów z innymi.
Git oferuje dwa główne sposoby, aby to zrobić, z których oba mogą być wykonywane swobodnie przed udostępnieniem zmiany:
"Git commit - zmiany" pozwala wprowadzić dodatkowe zmiany część ostatnią rzeczą, którą popełnił, ewentualnie modyfikując popełnienia wiadomość, jak również. Użyj tego, jeśli
realizowane od razu, że zostawiłeś coś z popełnienia lub jeśli typo'd popełnienia.
"Git rebase - interaktywne pochodzenia" pozwala wrócić do każdej zmiany, ponieważ "pochodzenie", w miarę możliwości edycji i łączenia ("zgniecenia") to kolejna zmiana. W przypadku
najbardziej ekstremalnych, można "squash" to w jeden commit, jeżeli nie ma wartość dla innych deweloperów widać pojedynczych kroków.
7.5. Upewniając się co popełnienia buduje
Jeśli zmiany składa się z kilku plastrów, "git rebase-i mogą być używane do zmiany kolejności tych poprawek w ciągu popełnia, które bardziej precyzyjnie opisuje etapy swojej pracy.
Potencjalnych konsekwencji poprawek zmiany kolejności jest to, że może dostać zależności złego - na przykład, wprowadzenie użyć zmiennej, a deklaracja tej zmiennej tylko następuje w
póz
niejszym patch.
Podczas gdy HEAD oddział będzie budować, nie każdy może popełnić budować w takim przypadku, a przerwy git-bisect (znalez
ć, przeszukiwanie binarne zmian, które wprowadziła bug) - coś,
ktoś inny może używać lateron znalez
ć popełnić błąd, który wprowadził . Tak więc poza upewniając się, że oddział buduje, ważne jest, aby zapewnić każdej popełnienia buduje również.
Nie sposób automatyczny, by sprawdzić oddział dla każdego zobowiązują się zbudowania - patrz http://dustin.github.com/2010/03/28/git-test-sequence.html , a kod na https://github.com /
Dustin / bindir / blob / master / git-test-sekwencji . Użyj w następujący sposób (w tym przypadku próbę każdego popełnienia pochodzenia / master do głowy, w tym prowadzenie testów
regresji):
$ Cd emc2-dev $ git-test-sekwencji pochodzenia / master .. (Cd src; się; runtests) "
Będzie to albo raportu "Wszystko w porządku" lub "Broke na "
7.6. Wyślij łaty poprzez e-mail lub sieci
Kiedy myślisz, że zmiany są gotowe do użycia przez innych, można ją udostępnić w formie poprawki. Wprowadza szereg poprawek dla każdego zobowiązania w lokalnym oddziale, ale nie w
"pochodzenia":
git format-patch-M pochodzenia
To tworzy pliki o nazwach takich jak
0001-my-w dobrej wierze-change.patch
Pliki te poprawki nadają się do wprowadzenia na serwer lub do wysyłania poczty e-mail z ulubionymi klienta poczty lub git-wyślij e-mail (w niektórych konfiguracji wymagane).
Aby zgłosić poprawki, istnieje kilka opcji:
Prześlij go jako elementu na sourceforge trackera: http://sourceforge.net/tracker/?group_id=6744 - przedstawienie poprawek w "pluskwy" sekcji. złożyć poprawy "funkcji wniosków"
sekcji.
Zapisz się do EMC deweloperów listy i wysyłać poprawki do listy jako załącznik. Nie ma jednak 24KB limit wiadomości do tej listy.
Na emc-devel # kanał IRC, po link do poprawki (na przykład w witrynie http://pastebin.ca lub na prywatny serwer) i zapytać, czy deweloper będzie na to patrzeć. W przypadku korzystania z
"pastebin' typu usługi, wybierz opcję, która zachowuje złożenia na czas nieokreślony.
Publikując swoje poprawki na forum publicznym, a nie w prywatnych do jednego autora, można stworzyć więcej szans dla przeglądu i komentarz.
Oto niektóre z pytań, deweloperzy mogą mieć o poprawki:
Jaki problem ma rozwiązać lub co funkcja to ma znaczenie?
Konkretne pytania dotyczące funkcjonowania poszczególnych części poprawki
To nie jest rzadkością w przypadku poprawki przejść przez kilka zmian, zanim zostanie przyjęta.
7.7. Naciśnij zmian w centralnym repozytorium
Jeśli już zatwierdzone bezpośrednio push zmian w centralnym repozytorium, a następnie po początkowej konfiguracji kluczy ssh jest dość prostym procesem:
git pull # rozwiązać wszelkie konflikty, ale generalnie nie będzie \
adnych git push
Jeśli inny deweloper wciśnięty między ciągnąć a push, będziesz musiał ściągnąć, a następnie naciśnij przycisk ponownie. Nie ma się bardzo często, ale stanie się to częściej niż z cvs,
ponieważ jest to wymagane w przypadku każdego pliku zmienić, nie tylko gdy określony plik popełnianych zmianie. Dobrze jest też używać "git pull - rebase" w tym przypadku, może to
spowodować zmiany w centralnym repozytorium, aby być umieszczony przed własne zmiany (pomijając w ten sposób scalania).
Z git będziemy chcieli ponownie ocenić, jak łatwo mało przetestowane zmiany są wypychane do "mistrza", ponieważ git zapewnia o wiele więcej sposobów dla programistów do wymiany łatek
i współpracy na nowe funkcje.
7.8. Naciśnij zmian w swoim własnym publicznym repozytorium
Możesz gospodarza publicznym repozytorium, do którego "push", z którego inni mogą "wyciągnąć". Jeśli nie masz własnego serwera to zrobić, usług, takich jak [1] i [2] są bezpłatne dla
projektów open source. Po naciśnięciu na swój publicznym repozytorium, inni programiści mogą przeglądać zmiany lub "pull" im.
8. Polityka
Tylko dlatego, że coś da się zrobić z git nie znaczy, że powinniśmy to zrobić.
8.1. Zmienianie nazw plików
Proszę używać możliwość zmiany nazwy plików bardzo ostrożnie. Jak działa tiret na pojedyncze pliki, zmienia nazwę nadal utrudniają śledzenie zmian w czasie. Jako minimum, należy szukać
porozumienia na IRC lub liście mailingowej, że zmiana nazwy jest poprawa.
8.2. Najlepsze "rebase"
Użyj "git pull - rebase" zamiast gołych "git pull", aby zachować ładny liniowej historii. Kiedy "- rebase", zawsze zachowuje swoją pracę jako korekt, które są przed nami pochodzenia / master,
więc można robić takie rzeczy jak git formatu-patch ich do dzielenia się z innymi bez przesyłania do centralnego repozytorium.
9. Porady i wskazówki
9.1. Korzystanie globalnej ignorować plik edytora do tworzenia kopii zapasowych
Redaktorów różnych deweloperów używać różnych nazw plików kopii zapasowej. . Zamiast umieścić wszelkich możliwych kopii edytora nazwę pliku w każdym projekcie gitignore, używać
prywatnego gitignore ignorować własnych plików kopii zapasowych edytora:
git config -.. globalnej core.excludesfile ~ / gitignore echo '* ~ ">> ~ / gitignore
Teraz wzór wykluczenia "* ~" będą stosowane w każdym katalogu każdego projektu git użyć.
9.2. Pull Script
Zrobiłem mały skrypt, który ściąga i ładuje GUI. Przyspiesza proces dla mnie. BJT
#! / Bin / bash jasne cd emc2-dev git git pull gui echo Git-R-Gotowe!
9.3. Kopiowanie na pendrive
Jeśli pojawiają się błędy stara się kopiować emc2-dev katalogu do usb potem tar go pierwszy. Z powyższego katalogu emc2-dev
tar CVF EMC dev.tar emc-dev następnie skopiować emc2-dev.tar na kartę następnie tar xvf / ście\
ka / do / emc-dev.tar na inny system
Jeśli usb jest pamięć zakwestionowane można skompresować pliki przez dodanie z. Jak cvzf i xvzf.
9.4. Stash przed ciągnąć
Aby wyciągnąć, trzeba mieć nie niezatwierdzone zmiany w drzewie pracy. Jeśli twój lokalny praca jest wykonywana, tylko zobowiązać go, a następnie wyciągnąć.
Jeśli w toku, które nie jest gotowe, aby zaangażować "zapas" to:
git zapas zapisać git pull - ukryta git rebase się
EmcKnowledgeBase | OstatnieZmiany | PageIndex | Preferencje | LinuxCNC.org
Ta strona jest tylko do odczytu. Postępuj zgodnie z BasicSteps móc edytować artykuły. | Zobacz inne wersje
Ostatnio edytowane 25 marca 2011 00:00 przez MichaelHaberler (różn) Opublikowano na licencji Creative Commons