Pokażemy tutaj, jak nauczyciele mogą wykorzystać profesjonalne i bezpłatne narzędzia do wersjonowania kodów źródłowych i wszystkich innych plików.

System kontroli wersji śledzi wszystkie zmiany dokonywane na pliku (lub plikach) i umożliwia przywołanie dowolnej wcześniejszej wersji. Nauczyciele pracujący z plikami które zmieniają się z przykładu na przykład, z ćwiczenia na ćwiczenie mogą np. skorzystać z systemu kontroli wersji do synchronizacji przykładów na poszczególnych etapach swojej pracy.

Dzięki takim narzędziom możemy porzucić przesyłanie i rozpakowywanie archiwów, kopiowanie plików na rzecz komend które szybko doprowadzą ujednolicą stan plików naszych uczniów.

Każdy z uczniów może meć lokalną kopię całej historii zmian w plikach, będzie mógł modyfikować swoje przykłady, ale w kluczowym momencie nauczyciel może poprosić by wszyscy zsynchronizowali swoje kopie do jednej sprawdzonej wersji.

Okresowa synchronizacja przykładów, które uczniowie z założenia zmieniają podczas zajęć pozwala wykluczyć pomyłki i wyeliminować problemy wynikające z różnic we wprowadzonych zmianach.

$ git checkout -f zadanie2/wersja5

Przed porzuceniem swoich zmian uczeń może zapisać kopię swojej pracy w repozytorium.

$ git commit -a -m "Moje zmiany w przykładzie 5"

Posługując się repozytoriami plików często mówimy o nich jako o „projektach“. Projekty mogą mieć swoje centralne repozytoria dostępne publicznie lub dla wybranych użytkowników.

W szczególności polecamy serwisy:

1. GitHub - https://github.com/ - bezpłatne repozytoria dla projektów widocznych publicznie
2. Bitbucket - https://bitbucket.org/ - bezpłatne repozytoria dla projektów bez wymogu ich upubliczniania

W każdym z nich możemy ograniczyć możliwość modyfikacji kodu do wybranych osób, a wymienione serwisy różnią się tym, że GitHub jest większy i bardziej popularny w środowisku open source, natomiast Bitbucket bezpłatnie umożliwia całkowite ukrycie projektów.

Dodatkowo te serwisy oferują rozszerzony bezpłatnych dostęp dla uczniów i nauczycieli, a także oferują rozbudowane płatne funkcje.

Zakładamy, że nauczyciele nie muszą korzystać z prywatnych repozytoriów, a dostęp do większej liczby projektów pomoże w nauce, dlatego początkującym proponujemy założenie konta w serwisie GitHub.

Każdy może sobie skopiować (do własnego repozytorium) i modyfikować projekty publicznie dostępne w GitHub. Dzięki temu każdy może wykonać — na swojej kopii — poprawki i zaprezentować te poprawki światu i autorom projektu :)

Wykonajmy teraz forka naszego projektu z przykładami i tą dokumentacją.

https://github.com/koduj-z-klasa/python101

Oczywiście możemy sobie założyć nowy pusty projekt, ale łatwiej będzie nam się pobawić narzędziami na istniejącym projekcie.

Do korzystania z naszego repozytorium lokalnie na naszym komputerze musimy doinstalować niezbędne oprogramowanie.

Pod linuksem:

$ sudo apt-get install git

Pod windows polecamy zainstalować SourceTree:

> @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
> choco install sourcetree

Jeśli nie mamy PowerShell'a możemy sciągnąć i zainstalować narzędzie ręcznie.

Przed pierwszym użyciem warto jeszcze skonfigurować dwie informacje identyfikujące ciebie jako autora zmian. W komendach poniżej wstaw swoje dane.

$ git config --global user.name "Jan Nowak"
$ git config --global user.email [email protected]

Klonowanie to proces tworzenia lokalnej kopii historii zmian. Dzięki temu możemy wprowadzić zmiany i zapisać je lokalnej kopii historii zmian, a następnie synchronizować historie zmian pomiędzy repozytoriami.

~$ git clone https://github.com/<MOJA-NAZWA-UŻYTKOWNIKA>/python101.git

W efekcie uzyskamy katalog python101 zawierający kopie plików, które będziemy zmieniać.

Klon repozytorium zawiera całą historię zmian projektu:

~$ cd python101
~/python101$ git log

commit 510611a351c7c3ff60e2506d8704e3f786fcedb7
Author: Janusz Skonieczny <...>
Date:   Thu Dec 11 15:37:46 2014 +0100

    git > source_code

commit f7019bc1f433eb4a6c2c88f8f48337c77e5e415e
Author: Janusz Skonieczny <...>
Date:   Thu Dec 11 15:26:16 2014 +0100

    req

commit 302fb3a974954ad936a825ba37519e145c148290
Author: wilku-ceo <...>
Date:   Thu Dec 11 11:05:43 2014 +0100

    poprawiona nazwa CEO

Możemy skoczyć do dowolnej z nich ustawiając wersje plików w kopii roboczej według jednej z wersji zapamiętanej w historii zmian.

~/python101$ git checkout 302fb3

Previous HEAD position was 510611a... git > source_code
HEAD is now at 302fb3a... poprawiona nazwa CEO

Zmiany można też oznaczyć czytelnym tag'iem tak by łatwiej było zapamiętać miejsca docelowe. W przykładzie poniżej pong/z1 jest przykładową etykietą wersji plików potrzebnej podczas pracy z pierwszym zadaniem ćwiczenia z grą pong.

~/python101$ git checkout pong/z1

Tyle tytułem wprowadzenia. Wróćmy do ostatniej wersji i wprowadź jakieś zmiany.

~/python101$ git checkout master

Dopiszmy coś co pliku README i zapiszmy go na dysku. A następnie sprawdźmy pzy pomocy komendy git status czy nasza zmiana zostanie wykryta.

~/python101$ git status

On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

Następnie dodajmy zmiany do repozytorium. Normalnie nie zajmuje to tylu operacji, ale chcemy zobaczyć co się dzieje na każdym etapie.

~/python101$ git add README.md
~/python101$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README.md


~/python101$ git commit -m "Moja pierwsza zmiana!"
[master 87ec5f4] Moja pierwsza zmiana!
1 file changed, 1 insertion(+), 1 deletion(-)

~/python101$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

Zazwyczaj wszystkie operacje zapisania zmian w historii zawrzemy w jednej komendzie:

~/python101$ git commit -a -m "Moja pierwsza zmiana!"`

Na razie historia naszych zmian została zapisana lokalnie. Możemy w ten sposób pracować nad projektami jednak gdy chcemy podzielić swoim geniuszem ze światem, musimy go wysłać do repozytorium dostępnego przez innych.

~/python101$ git push origin master

Komenda push przyjmuje dwa parametry alias zdalnego repozytorium origin oraz nazwę gałęzi zmian master.

Sprawdź teraz czy w twoim repozytorium w serwisie GitHub pojawiły się zmiany.

Możemy etykietę przypisać do aktualnej wersji zmian:

~/python101$ git tag moja_zmiana

Lub wybrać i przypisać ją do wybranej wersji historycznej.

~/python101$ git log --pretty=oneline
87ec5f4d8e639365f360bc11b9b51629b909ee9d Moja pierwsza zmiana!
510611a351c7c3ff60e2506d8704e3f786fcedb7 git > source_code
f7019bc1f433eb4a6c2c88f8f48337c77e5e415e req
302fb3a974954ad936a825ba37519e145c148290 poprawiona nazwa CEO

~/python101$ git tag zmiana_ceo 302fb3a

~/python101$ git show zmiana_ceo
commit 302fb3a974954ad936a825ba37519e145c148290
Author: wilku-ceo <[email protected]>
Date:   Thu Dec 11 11:05:43 2014 +0100

    poprawiona nazwa CEO

diff --git a/docs/copyright.rst b/docs/copyright.rst
index 85feb38..431eb81 100644
--- a/docs/copyright.rst
+++ b/docs/copyright.rst
@@ -5,7 +5,7 @@
             <img alt="Licencja Creative Commons" style="border-width:0" src="ht
         Materiały <span xmlns:dct="http://purl.org/dc/terms/" href="http://purl
         udostępniane przez <a xmlns:cc="http://creativecommons.org/ns#" href="h
-        Centrum Edudkacji Europejsci</a> na licencji <a rel="license" href="htt
+        Centrum Edukacji Obywatelskiej</a> na licencji <a rel="license" href="h
         Creative Commons Uznanie autorstwa-Na tych samych warunkach 4.0 Międzyn
     </p>

Etykiety które przypiszemy do wersji w historii zmian muszą zostać wypchnięte do centralnego repozytorium przy pomocy specjalnej wersji komendy push.

~/python101$ git push origin --tags --force

Parametr --tags mowi komendzie by wypchnęła nasze etykiety, natomiast --force wymusi zmiany w ew. istniejących etykietach — bez --force serwer może odrzucić nasze zmiany jeśli takie same etykiety już istnieją w centralnym repozytorium i są przypisane do innych wersji zmian.

Jeśli już mamy klona repozytorium i chcemy upewnić się że mamy lokalnie najnowsze wersje plików (np. gdy nauczyciel zaktualizował przykłady lub dodał nowe pliki), to ciągniemy zmiany z centralnego repozytorium:

~/python101$ git pull

Ta komenda ściągnie historię zmian z centralnego repozytorium i zaktualizuje naszą kopię roboczą plików.