---
# System prepended metadata

title: Praca z GIT

---

# Praca z GIT
Dokumentacja sprządzona dnia 22 sierpna 2018
Modyfikacja: 06 sierpień 2019
Autor: Michał Bahn
Wersja 1.2

Do poprawy:
Do uzupełnienia: 

---
* [Konfiguracja i dostosowanie](#Konfiguracja-i-dostosowanie)
    * [Aliasy](#Aliasy)
    * [Ładne logi](#Ładne-logi)
* [Zbiór różnych trików z GIT-em](#Zbiór-różnych-trików-z-GITem)
* [Operacje na historii](#Operacje-na-historii)
    * [Ograniczanie historii](#Ograniczanie-historii)
    * [Pobieranie płytkiego clona](#Pobieranie-płytkiego-clona)
* [Łączenie branchy](#Łączenie-branchy)
    * [Merge squash](#Merge-squash)
    * [Rebase](#Rebase)
* [Paczka z ostanimi modyfikacjami](#Przygotowanie-paczki-z-ostanimi-zmianami)


Konfiguracja i dostosowanie
---
### Aliasy
Aby uprościć wpisywanie komend można skorzystać z aliasów. Są to skróty jake chcemy przyspisać zadanym komendom.
```
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
```

Niezłym pomysłem może być stworznei aliasu do listowania utworzonych aliasów. Wywołamy go komendą `gt alias`.
```
git config --global alias.alias "! git config --get-regexp ^alias\. | sed -e s/^alias\.// -e s/\ /\ =\ /"
```



### Ładne logi 
Git nie zawsze w sposób czytelny prezentuje prezentuje logi. Można temu zaradzić definiujac formatowanie logów. 

```shell
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
```
Co więcej można to ustawienie wprowadzić na stałe tworząc wpis w pliku konfiguracynym. Możana to zrobić automatycznie używjac komendy: 

```shell
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
```
Teraz można komendą  `git lg` lub  ` git lg -p` wyświetlić w sposób ładnie sformatowany historię dotychczasowych komitów wraz ze zmianami. 


### Zabezpieczenie katalogu repozytorium 
Bardzo ważne by katalog repozytorium nie był dostępny z zewnątrz. Sprawdzamy to wywpłując w przegladarce `moja_domena.pl/.git`  oraz (nie lub) `moja_domena.pl/.git/config` oraz `moje_ip/.git` oraz `moje_ip/.git/config` . We wszytkich przypadkach powinniśmy otrzymać  komunikat `Forbidden`. Jeśl nie, należy dodatkowo zabepieczyć katalogi wpisując w konfiguracje apache, lub lokalny .htaccess, następujacy fragment:

```
<DirectoryMatch "^/.*/\.git/">
    Require all denied
</DirectoryMatch>
```

:::info 
Dodatkowo warto zabepieczyć serwer przed listowaniem katalogów. Parz "Zbiór dobrych praktyk" sekcja "Zabezpieczenie katalogu" w szczegółności kod dotyczący listowania katalogów, wykorzystujaca dyrektywę `Options` z parametrem `-Indexes`: 

https://hackmd.io/m-GyoFnOTEmqwmpDMljTyQ?view#Zabezpieczenie-katalogu
:::






Używane branche
---
W projektach używamy następujecego zestawu branchy: 
* master
* hot-fix
* release
* develop
* features
* staging

**master** - wersja produkcyjna kodu. Branch ten powienien być 1:1 z wersją na serwerze produkcyjnym.

**hot-fix** - branch pozwaljacy na nanoszenie szybkich poprawek na produkcję i do wyrównywania stanów na branchu developerskim.


**release** - branch przygotowujący nowe wydanie, z tego branch są tworzone nowe merge dla master i staging.

**develop** - podstawowy branch developerski. Można doń mergować lokalne/indywidualne branche członków zespołu.

**features** - nieformalna nazwa dla zbioru baranchy indywidualnych lub rozwijających określoną funkcjonalność.

**staging** - branch powstajacy z barancha develop lub release dla potrzeb testów na serwerze stagingowym. 



:::success 
Szczegóły practy z repozytorium opisane w tym dokumencie: 

https://docs.google.com/presentation/d/1w2Nm3t1LfWtf6LknKB9RUewokAtXxpQulUpF0PuiRys/edit?usp=sharing
:::



Zbiór różnych trików z GITem
---
https://github.com/git-tips/tips


Operacje na historii
---


### Ograniczanie historii

Gdy istnieje potrzba odfiltorwania histori tylko do ostatnich commitów. Podając po myśłniku liczbę, określasz ile commitów wstecz ma być wyświetlane. 
```
git lg -2
```
lub
```
git log -2
```

### Pobieranie płytkiego clona

Gdy zależy ci na płytkim clonie bez kompletnej historii możesz instrukcję klonowania rozszerzyć o parametr `--depth`. Parametr ten ogranicza pobranie  historii do `n` commitów wstecz. Im większa liczba tym większa/dłuższa będzie historia. 

```bash=
git clone --depth=2
```
Jeśli chcesz lokalnie obciąć historię już istniejacego projektu możesz zastosować parametr `--depth` dla konendy `ferch`.

```bash=
git fetch --depth=2
```





Łączenie branchy
---
Różne sposoby mergowania prac w róznych branchach.

### Merge squash 
Pobiera do `master` zmiany z `features` ==nie pobierając historii==, a jedynie wstawiajac pliki do indexu kolejki. Fajne i przydatne ale nie utrzymuje zgodności hash commitów z innymi branchami. Zmianę musisz ostatecznie zacommitować. 
````bash=
git co master
git merge --squash features
````
Możesz tego użyć np. gdy na niezależnym tymczasowym branchu prowadzisz zmiany, czesto commitujesz poprawki, komentarze commitów się powtarzają, prcujesz nad jedną funkcjonalnością. Na koniec chcesz wpiąć zmiany do głównego brancha i opisać je jednym commitem, nie bacząc na dalszy los tymczasowego.


#### Rebase
Opcja `-i` wymusza tryb interaktywny w którym decydujesz o zamianach. Najsprostrzą metodą jest rebase do jendego hash commitów poprzedzajacych. 

```bash=
git lg
git rebase -i <that_commit_id>
```
Pojawi się okienko edycji z listą commitów w kolejnosci odwrotnej do historii powstawania. Najnowszy na dole listy, najstarszy u gówry. Przykładowo:


> pick 89731fb Add folder for app
pick cef3286 Disallow inexed working directories by googlebot and other
pick bc0a877 Minor fixes for README file
pick 218b5d4 To jest nanjnowsza poprawka

>Rebase eb5619c..218b5d4 onto eb5619c (4 commands) 

> Commands:
p, pick = use commit
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
f, fixup = like "squash", but discard this commit's log message
x, exec = run command (the rest of the line) using shell
d, drop = remove commit

>These lines can be re-ordered; they are executed from top to bottom.
 If you remove a line here THAT COMMIT WILL BE LOST.
 However, if you remove everything, the rebase will be aborted.
 Note that empty commits are commented out

Jak sugeruje podpowiedź, mamy kilka opcji komend do wyboru:
* p, pick = utrzymuje commit
* r, reword = zmienia komentarz commita
* e, edit = use commit, but stop for amending
* s, squash = łączy commit z wcześniejszym (u góry) nadając swoją nazwę
* f, fixup = łączy commit z wcześniejszym, zostawiajac nazwę wcześniejszego
* d, drop = usuwa commit

Zmieniamy w naszej liscie commitów wyraz `pick` na `fixup`, lub gdy chemy zachować nazwę komentarza użyjemy `squash`. Zapisujemy zmianę `Ctr+o` i zamykamy dialog `ctrl+z`. Po tej operacji następuje rebase commitów i historia zawiera połączone zmiany. 


Przygotowanie paczki z ostanimi zmianami
---

Jeśli chcemy wykonać paczkę z ostaniego commitu możemy użyć genialnego polecenia ktore przygotuje wyfiltrowane zmiany, zachowując całą strukturę katalogów potrzbna do wgrania zdmian w deploymentach ręcznych.

```bash=
git archive -o "_Paczka_$(date '+%F').zip" HEAD $(git diff --name-only HEAD^)
```

lub

```bash=
git archive -o "_Paczka_$(date '+%F').zip" HEAD $(git diff --name-only [nr_rewizji])
```
gdze `[nr_rewizji]` pozycujmey z `git lg`.




