ATNEL tech-forum

Re: Git jak najprościej

2016-11-04T19:24:16+01:00

sq5rix napisał(a):

Dzięki!! 500MB dostałem

Ja też. A to już dodatkowa niespodzianka i bonusik

Statystyki: Napisane przez MirkoT — 4 lis 2016, o 19:24

Re: Git jak najprościej

2016-11-04T19:20:37+01:00

Dzięki!! 500MB dostałem

Statystyki: Napisane przez sq5rix — 4 lis 2016, o 19:20

Re: Git jak najprościej

2016-11-04T18:52:05+01:00

No to proszę bardzo.
Więcej powietrza do swobodnego oddychania

Statystyki: Napisane przez MirkoT — 4 lis 2016, o 18:52

Re: Git jak najprościej

2016-11-04T15:30:17+01:00

Jak chcesz mi dołożyć powietrza pod sufitem, to kliknij tu:
https://db.tt/zE4eOWRH

Statystyki: Napisane przez sq5rix — 4 lis 2016, o 15:30

Re: Git jak najprościej

2016-11-04T12:33:55+01:00

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

Statystyki: Napisane przez ndriu — 4 lis 2016, o 12:33

Re: Git jak najprościej

2016-11-04T12:10:55+01:00

To zorientuj się. Jakby co to... mogę "być od Ciebie"

Statystyki: Napisane przez MirkoT — 4 lis 2016, o 12:10

Re: Git jak najprościej

2016-11-04T11:56:52+01:00

Nie wiem czy jeszcze dają dodatkową przestrzeń za polecanie, ja w ten sposób dostałem sporo darmowej powierzchni

Statystyki: Napisane przez sq5rix — 4 lis 2016, o 11:56

Re: Git jak najprościej

2016-11-04T07:52:51+01:00

Jeszcze raz ogromnie dziękuję.
Wypróbuję

Statystyki: Napisane przez MirkoT — 4 lis 2016, o 07:52

Git jak najprościej

2016-11-03T23:32:15+01:00

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

Statystyki: Napisane przez sq5rix — 3 lis 2016, o 23:32

Re: Git jak najprościej

2016-11-03T22:47:03+01:00

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ć

Statystyki: Napisane przez MirkoT — 3 lis 2016, o 22:47

Re: Git jak najprościej

2016-11-03T22:25:40+01:00

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ć.

Statystyki: Napisane przez sq5rix — 3 lis 2016, o 22:25

Re: Git jak najprościej

2016-11-03T22:10:00+01:00

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.

Statystyki: Napisane przez MirkoT — 3 lis 2016, o 22:10

Re: Git jak najprościej

2016-02-26T19:15:04+01:00

Hehe racja

Statystyki: Napisane przez sq5rix — 26 lut 2016, o 19:15

Re: Git jak najprościej

2016-02-26T19:07:04+01:00

Quote:

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

Statystyki: Napisane przez rskup — 26 lut 2016, o 19:07

Re: Git jak najprościej

2016-02-26T14:15:09+01:00

Statystyki: Napisane przez sq5rix — 26 lut 2016, o 14:15

Re: Git jak najprościej

2016-02-26T12:39:56+01:00

Raspberry do kontroli wersji popieram jak najbardziej. Kolega użył też do tego swój router ze zmodyfikowanym firmware Tomato.

Statystyki: Napisane przez Marvinn8686 — 26 lut 2016, o 12:39

Re: Git jak najprościej

2016-02-26T10:47:41+01:00

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

Statystyki: Napisane przez ostap — 26 lut 2016, o 10:47

Re: Git jak najprościej

2016-02-26T08:08:42+01:00

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.

Statystyki: Napisane przez Marvinn8686 — 26 lut 2016, o 08:08

Re: Git jak najprościej

2016-02-26T01:07:17+01:00

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...

Statystyki: Napisane przez sq5rix — 26 lut 2016, o 01:07

Re: Git jak najprościej

2016-02-26T00:07:32+01:00

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

Statystyki: Napisane przez rskup — 26 lut 2016, o 00:07

Git jak najprościej

2016-02-27T14:04:29+01:00

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.

Statystyki: Napisane przez sq5rix — 25 lut 2016, o 23:26