EMC Dokumentacja Wiki Git.pdf

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 gitclone 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 commitgit formatpatch 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 checkout

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. Śledź 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 email 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 "gitcore" (pakiet "git" to niepowiązanych programu; nie wybieraj go). Opcjonalnie wybierz opcję "gitk" lub "qgit" (nie na Dapper) do graficznego widoku

historii projektu i "gitgui" 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 dapperbackports, 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 "you@example.com"

Użyj swojego prawdziwego nazwiska (a nie obsługiwać) i użyć unobfuscated adres email.

2. Załóż początkowej checkout

"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 emc2dev

spowoduje to utworzenie nowego lokalnego katalogu "emc2dev '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: / / developername@git.linuxcnc.org / git/emc2.git emc2dev

Wszystkie polecenia zakładają, że znajdują się w katalogu emc2dev, chyba że zaznaczono inaczej.

3. Wyświetl historię

Spójrz na historię:

git logC 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 logCp 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 commitsam "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 commitam "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 email). Po nim pusty wiersz, to już komunikat wyjaśniający zmiany. Przykład:

Pozbądź 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ądra (zwracaERRNO błędu)

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/emc2ignores.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 branchr

Aby sprawdzić oddział na przykład 2,4 oddziału:

git checkoutb 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 mytopic

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.3dev" obok "emc2dev", 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.3dev:

cpr emc2dev / emc2.3dev git ponownie połączyć emc2.3dev / emc2dev / cd emc2.3dev 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 mergebazy master i v2.4_branch. Możesz wykonać poprawkowe i połączyć je w obie gałęzie w taki sposób:

git checkout $ (git mergebase pochodzenia origin/v2.4_branch / master) git checkoutb opisowobugfixbranchname edycji / kompilacji / test / commit git checkout git Scalanie główne opisowobugfixbranchname kompilacji / testów git git v2.4_branch kasie

Sprawdź 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 rebasei 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óźniejszym patch.

Podczas gdy HEAD oddział będzie budować, nie każdy może popełnić budować w takim przypadku, a przerwy gitbisect (znaleźć, przeszukiwanie binarne zmian, które wprowadziła bug) coś,

ktoś inny może używać lateron znaleźć 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/gittestsequence.html , a kod na https://github.com /

Dustin / bindir / blob / master / gittestsekwencji . 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 emc2dev $ gittestsekwencji pochodzenia / master .. (Cd src; się; runtests) "

Będzie to albo raportu "Wszystko w porządku" lub "Broke na <commit>"

7.6. Wyślij łaty poprzez email 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 formatpatchM pochodzenia

To tworzy pliki o nazwach takich jak

0001myw dobrej wierzechange.patch

Pliki te poprawki nadają się do wprowadzenia na serwer lub do wysyłania poczty email z ulubionymi klienta poczty lub gitwyślij email (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 emcdevel # 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 formatupatch 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 emc2dev git git pull gui echo GitRGotowe!

9.3. Kopiowanie na pendrive

Jeśli pojawiają się błędy stara się kopiować emc2dev katalogu do usb potem tar go pierwszy. Z powyższego katalogu emc2dev

tar CVF EMC dev.tar emcdev następnie skopiować emc2dev.tar na kartę następnie tar xvf / ścieŜka / do / emcdev.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

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: