Cytuj:
a katalogi mam na dropboxie, żeby nie uciekły w niebyt. Nie widzę potrzeby używania zewnętrznego serwera
A dropbox to nie zewnętrzy serwer
?--
Pozdrawiam,
Robert
| ATNEL tech-forum https://forum.atnel.pl/ |
|
| Git jak najprościej https://forum.atnel.pl/topic14655.html |
Strona 1 z 1 |
| Autor: | sq5rix [ 25 lut 2016, o 23:26 ] |
| Tytuł: | Git jak najprościej |
Mini poradnik o gicie na podstawie własnego używania i świetnej książki: https://git-scm.com/book/en/v2 Git jest sposobem na zarządzanie wersjami softu/projektu. Najprostszy git jest lokalny, nie wymaga żadnego serwera i można sobie robić wersjonowanie bez łaski. Najprostszy git nie polega na żadnych klientach graficznych i hostingach. Jest całkowicie lokalny i używany z linii komend. Ja dodatkowo katalogi z projektami trzymam na dropboxie, więc mam z automatu backup i archiwizację. Uwaga: poradnik dla początkujących. Nie ma tu o pracy w zespole, repozytoriach rozproszonych, zarządzaniu wielkimi projektami. Cel: wersjonowanie małego, własnego projektu w C, Eagle, Kicadzie, asemblerze, tak, żeby nie wyrywać sobie włosów z głowy jak coś pójdzie nie tak. Dlatego polecam nauczenie się podstawowej składni command-line, bo używa się jej wtedy swobodnie przy każdym projekcie. Poznanie składni spowoduje, że praca w środowisku graficznym będzie łatwiejsza. Nigdy nie używałem nakładek graficznych na git-a. Uważam, że to przerost formy nad treścią. Uważam, że to, co tu napisałem wystarcza do zarządzania 90% projektów. Do dzieła! Instalacja na systemach debianowych, jak ubuntu: $ sudo apt-get install git-all Na windzie jest inaczej, ściągamy instalkę stąd: https://git-scm.com/download/win Większość tego co jest poniżej, działa tak samo na linuxie i na windzie. Po instalacji należy koniecznie zainicjować trzy rzeczy, imię, mail i edytor (można dać notepad.exe lub inny ulubiony) : $ git config --global user.name "Tomek sq5rix" $ git config --global user.email ciacho@cukiernia.pl $ git config --global core.editor vim I to tyle w temacie inicjalizacji. Help też jest i działa tak: $ git help config Oczywiście można zamiast config dać dowolną komendę. Teraz idziemy sobie do katalogu, gdzie siedzi sobie nasz projekt eclipse, eagle lub kicad, lub np. artykuł, praca na zaliczenie - cokolwiek, co piszemy i zapisujemy na dysk co jakiś czas. Np. $ cd avreclipse/migacz $ git init Powstaje katalog .git w naszym katalogu projektu, który trzyma wszystko. Jak nam baaaardzo nie pójdzie to można .git skasować. Następnie dodajemy sobie te pliki, które chcemy śledzić. Powstaje wtedy gałąź master $ git add . Czyli wszystko chcemy śledzić, dokładamy wszystkie pliki na gałąź master. Można sobie śledzić tylko wybrane pliki i katalogi np. $ git add *.[ch] Dodawanie jest rekurencyjne, więc pliki z katalogów nam wejdą jako śledzone. Nie dodajemy do śledzenia wynikowych plików binarnych, np. katalogu Release nie śledzimy. Załóżmy, że ten projekt jest już w jakimś stanie, no powiedzmy beta 0.1 Komitujemy taką pierwszą wersję jako master. Ten master (nie mylić z majstrem z naszego forum) to jest początek pierwszej gałęzi. Git w odróżnieniu od innych systemów, jak svn, nie ma pnia i gałęzi, pień lub gałąź główna nie jest główna, jest taka sama jak inne. Przyjęło się, źe pierwsza gałąź to master. Komitowanie to takie jakby przycięcie gałęzi, żeby dalej nam mogła rosnąć, zapamiętanie stanu projektu, lub po to aby powstało tam rozgałęzienie. $ git commit Pojawia się nam edytor, w którym w pierwszej linijce dajemy opis naszych dokonań i potem zapisujemy. Można też bez edytora, tak: $ git commit -m "to wersja pierwsza, beta" Można jeszcze zatagować, tag to taki wskaźnik na jakieś miejsce na drzewie. Tag pełny, który nam zapamięta cały stan: $ git tag -a v-0.2 -m "wersja z dwoma diodami" Lub tag lekki, pamięta tylko dane miejsce. $ git tag v-0.2 Żeby zobaczyć swoje tagi: $ git tag Polecam również tworzenie sobie aliasów, żeby przyspieszyć stukanie: $ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status Oczywiście te wszystkie rzeczy robimy podczas normalnej pracy eclipse'a czy tam Kicada. Eclipse sobie działa, normalnie tam kompilujemy itd.... Obok odpalamy zwykły terminal w którym sobie piszemy komendy gita. Jak sobie popracujemy, i coś tam zmienimy, to możemy sobie zrobić drugi commit, lub poprawić stary (z tym to ostrożnie, bo nadpisujemy stary commit i nasze zmiany nadpisują stary tekst - nie będzie można się cofnąć) Dołożenie plików do commita jest chyba pojęciowo najtrudniejsze - otóż istnieje taka przestrzeń "stage area" Jak to działa: Coś sobie piszemy w main.c i potem dodajemy do stage area. $ git add main.c Dokładamy plik main.c do stage area - w tym momencie! Jak coś tam jeszcze zapiszemy, zrobimy jakieś zmiany, to jeśli nie ponowimy git add main.c to te ostanie zmiany diabli wezmą. Dlatego ja komituję zawsze tak: $ git commit -a -m "dołożenie migającej diody" To -a dokłada do commita wszystkie pliki, które są śledzone. Nadpisanie poprzedniego, jakby przeniesienie commita, na przykład jak zapomnę dodać jakiegoś pliku, albo zrobię nieznacząca zmianę w pliku. $ git commit --amend W tym momencie przychodzi nam do głowy, żeby stworzyć drugą gałąź. Np. do jakiejś nowej funkcjonalności w naszym migaczu. $ git branch druga_dioda To nic nie robi poza stworzeniem kolejnej gałęzi. Cały czas jesteśmy na gałęzi master. Możemy sobie dalej pracować na master i komitować. Ale, kiedy nam przyjdzie do głowy popracować nad drugą diodą, to robimy: $ git commit -a -m "wersja 0.2" Co oznacza dołożenie drugiego commita z dodaniem wszystkich zmienionych plików, po to żeby zostawić porządek w plikach na gałęzi master. Zwróćcie uwagę, że nowa gałąź druga_dioda wyrasta z wcześniejszego miejsca niż obecnie jesteśmy. Czyli będziemy pracować na kodzie poprzedniego commita, z momentu powstania gałęzi druga_dioda. Teraz przełączymy gałąź na drugą diodę: $ git checkout druga_dioda To checkout stosujemy bardzo często, do przełączania się w inne miejsce na drzewie. Zamiast dwóch komend, wystarczy jedna: $ git checkout -b druga_dioda Tworzy nową gałąź i od razu do niej przechodzi. Ja tego wolę używać, bo wtedy jestem na gałęzi identycznej z ostatnim commitem. Dodamy do niej pliki, których chcemy pilnować: $ git add *.c *.h W tym czasie w eclipse będzie widać zmianę - pojawią się pliki, oczywiście jeśli są otwarte, ze stanem z momentu powstania gałęzi druga_dioda Po zrobieniu zmian można je sobie skomitować. $ git commit -a -m "odpalona druga dioda" I tak dalej i tak dalej. Funkcja checkout przenosi wskaźnik HEAD na odpowiedni fragment drzewka, i można sobie pracować na kodzie z dowolnego miejsca. Ponieważ gałązki są bardzo "lekkie" można tworzyć ich dużo, i do woli merge'ować. A merge'ujemy tak: $ git checkout master $ git merge druga_dioda W ten sposób wszystkie zmiany wejdą do naszej "głównej" gałęzi i tam już pozostaną. Oczywiście można merge'ować dowolne gałęzie. Czasem git zgłosi miszmasz w naszym merge'owaniu i wtedy trzeba mu pomóc skapować się które zmiany chcemy pozostawić. O tym też w książce dokładniej, a w skrócie: $ git diff Pokazuje zmiany, które powodują konflikty. Tu się czasem łamię, ale rzadko, i w ciężkich chwilach używam graficznego narzędzia diffmerge stąd: https://sourcegear.com/diffmerge/ Działa na wszystkim. Zobaczenie, jak wygląda nasze drzewko, to dwie ważne komendy: $ git status $ git log Warto sobie popatrzeć, co pokazują - status to stan bieżący, log to historia... Funkcja checkout pozwala na chodzenie po tej historii, po tagach i commitach. Na tym koniec. To wszystko, co jest potrzebne do lokalnego używania gita i używania własnego wersjonowania kodu. Jest to łatwe i przyjemne, daje możliwość lepszego panowania nad swoim softem. Zobaczcie dalej w książce, która jest podana na początku, jest tam o wiele dokładniej, również o pracy z serwerami zewnętrznymi. Jeśli są pytania do prostej, lokalnej pracy w command line, to proszę bardzo o pytania i komentarze. |
|
| Autor: | rskup [ 26 lut 2016, o 00:07 ] |
| Tytuł: | Re: Git jak najprościej |
Jakoś nie mogę się przemóc by przetestować Git-a i cały czas się bawię z Mercurial-em. Ma on bardzo dobrą nakładkę pod Windows, dobrze zintegrowana z Windows Explorerem - TortoiseHg (http://tortoisehg.bitbucket.org). Co do trzymania repozytoriów to polecam http://Bitbucket.org. Obsługuje on zarówno repozytoria Mercurial jak i Git. Za darmo można trzymać prywatne repozytoria. Ograniczenia są tylko na liczbę przy grupowych dostępach. -- Pozdrawiam, Robert |
|
| Autor: | sq5rix [ 26 lut 2016, o 01:07 ] |
| Tytuł: | Re: Git jak najprościej |
Git jest super, chociaż Mercurial też jest ciekawy. Jednak ze względu na łatwość działania ze wszystkim, co robię, wolę gita. Bez nakładek, bez repozytoriów - oczywiście jak się działa w grupie, to inna bajka, wtedy trzeba wyjść na zewnątrz... |
|
| Autor: | Marvinn8686 [ 26 lut 2016, o 08:08 ] |
| Tytuł: | Re: Git jak najprościej |
Ja używam Tortoise do SVNa i GITa i moim zdaniem jest bardzo ok. Mam awersję do używania konsoli, jestem klikaczem. Gitowe repozytorium też trzymam na Bitbucket jak kolega rskup, świetna sprawa. Kontrola wersji to dobry pomysł nawet w małych, jednoosobowych projektach. |
|
| Autor: | ostap [ 26 lut 2016, o 10:47 ] |
| Tytuł: | Re: Git jak najprościej |
Kontrolowanie wersji to podstawa. Nie wyobrażam sobie pisania kodu bez możliwości powrotu do wersji sprzed x minut/godzin/dni. Chciałem dodać tylko, że raspberry pi do kontroli wersji jest jak znalazł. Używam już RPI właśnie do tego celu od prawie 4 lat (jak tylko rpi można było kupić). Pozdrawiam, Grzegorz |
|
| Autor: | Marvinn8686 [ 26 lut 2016, o 12:39 ] |
| Tytuł: | Re: Git jak najprościej |
Raspberry do kontroli wersji popieram jak najbardziej. Kolega użył też do tego swój router ze zmodyfikowanym firmware Tomato. |
|
| Autor: | sq5rix [ 26 lut 2016, o 14:15 ] |
| Tytuł: | Re: Git jak najprościej |
Na pomysł z pi to bym nie wpadł - ciekawe. Ja używam lokalnego gita, a katalogi mam na dropboxie, żeby nie uciekły w niebyt. Nie widzę potrzeby używania zewnętrznego serwera, chyba, że z kimś współpracujemy, no to wtedy trzeba. |
|
| Autor: | rskup [ 26 lut 2016, o 19:07 ] |
| Tytuł: | Re: Git jak najprościej |
Cytuj: a katalogi mam na dropboxie, żeby nie uciekły w niebyt. Nie widzę potrzeby używania zewnętrznego serwera A dropbox to nie zewnętrzy serwer ?-- Pozdrawiam, Robert |
|
| Autor: | sq5rix [ 26 lut 2016, o 19:15 ] |
| Tytuł: | Re: Git jak najprościej |
Hehe racja 
|
|
| Autor: | MirkoT [ 3 lis 2016, o 22:10 ] |
| Tytuł: | Re: Git jak najprościej |
sq5rix napisał(a): Na pomysł z pi to bym nie wpadł - ciekawe. Ja używam lokalnego gita, a katalogi mam na dropboxie, żeby nie uciekły w niebyt. Nie widzę potrzeby używania zewnętrznego serwera, chyba, że z kimś współpracujemy, no to wtedy trzeba. A mógłbyś mi lejkowi przybliżyć jak to robisz? Jak to w ogóle działa na dropsie? Jak to się konfiguruje wtedy? Moje pytania wynikają stąd, że nigdy jeszcze nie używałem dropboxa, nie mam tam konta, ani zielonego pojęcia jak to funkcjonuje. |
|
| Autor: | sq5rix [ 3 lis 2016, o 22:25 ] |
| Tytuł: | Re: Git jak najprościej |
Dropbox ratuje mi skórę od wielu lat. Jest bardzo prosty. Rejestrujesz się stąd: https://www.dropbox.com/ Instalujesz aplikację na kompie, telefonie, tablecie. Apka na kompie tworzy katalog Dropbox. Wszystko co zapisujesz do niego, leci do chmury i tam sobie siedzi. Co więcej, jeśli coś skasujesz lub nadpiszesz - możesz się dostać do poprzednich wersji. No i teraz po prostu robię np. workspace eclipse w podkalogu np. Dropbox/workspace Wszystko co mam w tym katalogu jest automatycznie backupowane. Jedyny kłopot, to jak przekroczysz limit przestrzeni, wtedy każą płacić. |
|
| Autor: | MirkoT [ 3 lis 2016, o 22:47 ] |
| Tytuł: | Re: Git jak najprościej |
Bardzo dziękuję za odpowiedź. Czyli po prostu konto na dropboksie, a workspace w wirtualnym katalogu który tak na prawdę jest w chmurze? Czy jest na kompie (jakby sieci nie było) a tylko automatyczna aktualizacja (synchronizacja) do chmury? No niby proste. Muszę spróbować
|
|
| Autor: | sq5rix [ 3 lis 2016, o 23:32 ] |
| Tytuł: | Git jak najprościej |
Jest na kompie i w chmurze. Synchronizacja jest automatyczna i bardzo szybka. Można spokojnie pracować, kiedy nie ma sieci, sam sobie wszystko dogrywa, kiedy pojawi się sieć. Mega proste
|
|
| Autor: | MirkoT [ 4 lis 2016, o 07:52 ] |
| Tytuł: | Re: Git jak najprościej |
Jeszcze raz ogromnie dziękuję. Wypróbuję
|
|
| Autor: | sq5rix [ 4 lis 2016, o 11:56 ] |
| Tytuł: | Re: Git jak najprościej |
Nie wiem czy jeszcze dają dodatkową przestrzeń za polecanie, ja w ten sposób dostałem sporo darmowej powierzchni |
|
| Autor: | MirkoT [ 4 lis 2016, o 12:10 ] |
| Tytuł: | Re: Git jak najprościej |
To zorientuj się. Jakby co to... mogę "być od Ciebie" 
|
|
| Autor: | ndriu [ 4 lis 2016, o 12:33 ] |
| Tytuł: | Re: Git jak najprościej |
Ja z mojej strony dla osób które lubią być niezależne i trzymać wszystko "u siebie" polecę GOGS - https://gogs.io. Jest to bardzo lekkie rozwiązanie, obsługujemy je przez przegladarkę - spokojnie może być uruchomione nawet na RPi. W najnowszych wersjach dodana została możliwość tworzenia i edycji kodów źródłowych bezpośrednio przez przeglądarkę. Instalacjaj jest banalna - możemy ściągnąć gotową binarkę i po prostu uruchomić Producent udostępnia demo, więc można wypróbować przed instalacją.Pozdrawiam, Andrzej |
|
| Autor: | sq5rix [ 4 lis 2016, o 15:30 ] |
| Tytuł: | Re: Git jak najprościej |
Jak chcesz mi dołożyć powietrza pod sufitem, to kliknij tu: https://db.tt/zE4eOWRH
|
|
| Autor: | MirkoT [ 4 lis 2016, o 18:52 ] |
| Tytuł: | Re: Git jak najprościej |
No to proszę bardzo. Więcej powietrza do swobodnego oddychania
|
|
| Autor: | sq5rix [ 4 lis 2016, o 19:20 ] |
| Tytuł: | Re: Git jak najprościej |
Dzięki!! 500MB dostałem
|
|
| Autor: | MirkoT [ 4 lis 2016, o 19:24 ] |
| Tytuł: | Re: Git jak najprościej |
sq5rix napisał(a): Dzięki!! 500MB dostałem Ja też. A to już dodatkowa niespodzianka i bonusik 
|
|
| Strona 1 z 1 | Strefa czasowa: UTC + 1 |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|