8.1 Dostosowywanie Gita - Konfiguracja Gita

Domyślnie Git używa tego, co ustawiliśmy jako domyślny edytor tekstu ($VISUAL lub $EDITOR) lub w sytuacji awaryjnej wraca do edytora vi podczas tworzenia i edycji wiadomości commit i etykiet. Aby zmienić to domyślne ustawienie na inne, możesz użyć ustawienia core.editor:

Teraz, bez względu na to, co jest ustawione jako domyślny edytor powłoki, Git uruchomi Emacsa do edycji wiadomości.

Jeżeli ustawisz ją na ścieżkę wskazującą na plik w Twoim systemie, Git będzie używał tego pliku jako szablonu komentarza do commita. Na przykład, załóżmy że stworzyłeś plik ~/.gitmessage.txt o następującej treści:

Aby wskazać Gitowi, że chcesz używać go jako domyślnej treści komentarza pokazującej się w edytorze po uruchomieniu git commit, ustaw zmienną konfiguracyjną commit.template na:

Dzięki temu Twój edytor będzie ustawiał coś takiego jako domyślną treść komentarza po commicie:

Jeżeli masz specjalną politykę tworzenia treści komentarzy, to ustawienie takiego szablonu i skonfigurowanie Gita aby go używał zwiększy szanse na to, że będzie ona regularnie przestrzegana.

To ustawienie określa, który program do stronicowania jest używany, gdy Git wypisuje kolejne strony tekstu przy pomocy takich poleceń jak log i diff. Możesz ustawić tutaj more lub swój inny ulubiony program (domyślnie jest to less); ewentualnie możesz go wyłączyć ustawiając pusty łańcuch znaków:

Jeżeli uruchomisz powyższą komendę, to Git będzie pokazywał pełne wyniki wszystkich komend, bez względu na to jak są one długie.

Jeżeli tworzysz opisane etykiety (jak opisano w sekcji Signing Your Work), ustawienie Twojego klucza GPG jako zmiennej konfiguracyjnej ułatwi trochę sprawę. Ustaw swój identyfikator klucza w ten sposób:

Teraz, możesz podpisywać tagi bez konieczności wskazywania za każdym razem klucza podczas uruchamiania komendy git tag:

Możesz umieścić wzorce w pliku .gitignore w swoim projekcie, aby Git nie śledził ich i nie próbował dodawać do przechowalni po wykonaniu komendy git add, jak wspomnieliśmy już w sekcji Ignorowanie plików.

Czasami jednak chcesz zignorować pewne pliki dla wszystkich repozytoriów, z którymi pracujesz. Jeśli Twój komputer pracuje pod kontrolą systemu Mac OS X, prawdopodobnie znasz pliki .DS_Store. Jeśli Twoim preferowanym edytorem jest Emacs lub Vim, wiesz o plikach kończących się znakiem ~.

To ustawienie pozwala na napisanie czegoś w rodzaju globalnego pliku .gitignore. Jeśli utworzysz plik ~/.gitignore_global z poniższą zawartością:

…i uruchomisz git config --global core.excludesfile ~/.gitignore_global, Git nigdy więcej nie będzie zawracał ci głowy tymi plikami.

Jeżeli błędnie wpiszesz komendę w Git, zostanie Ci pokazany wynik podobny do:

Git pomocnie próbuje dowiedzieć się co miałeś na myśli, ale nadal nie chce tego zrobić. Jeśli ustawisz help.autocorrect na 1, Git faktycznie wykona tę komendę za Ciebie:

Zwróć uwagę na fragment "0.1 seconds". Opcja help.autocorrect jest w rzeczywistości liczbą całkowitą, która reprezentuje dziesiąte części sekundy. Jeśli więc ustawisz ją na 50, Git da ci 5 sekund na zmianę zdania przed wykonaniem polecenia z autokorekty.

Git automatycznie koloruje większość swoich danych wyjściowych, ale istnieje główny przełącznik, jeśli nie podoba Ci się to zachowanie. Aby wyłączyć wszystkie kolorowe wyjścia terminala Gita, wykonaj poniższe polecenie:

Domyślnym ustawieniem jest auto, które koloruje wyjście, gdy jest ono kierowane bezpośrednio do terminala, ale pomija kody sterujące związane z kolorami, gdy wyjście jest przekierowywane do potoku lub pliku.

Opcję tę można też ustawić ją na always, by ignorowała różnicę między terminalami a potokami. Rzadko będziesz tego chciał; w większości scenariuszy, jeśli chcesz mieć kody sterujące związane z kolorami na przekierowanym wyjściu, możesz zamiast tego przekazać flagę --color do komendy Git, aby wymusić ich użycie. Domyślne ustawienie jest prawie zawsze tym, czego będziesz potrzebował.

Jeżeli chciałbyś móc bardziej dokładnie ustalać co i w jaki sposób jest pokazywane w kolorze, Git dostarcza odpowiednie ustawienia. Każde z nich może mieć wartość true, false lub always:

Dodatkowo, każde z nich ma dodatkowe ustawienia, których możesz użyć, aby zmienić konkretne kolory dla części z wyświetlanego wyniku, jeżeli chciałbyś nadpisać jakiś z kolorów. Na przykład, aby pokazać w kolorze wynik komendy diff z niebieskim kolorem pierwszoplanowym, czarnym tłem i pogrubioną czcionką, uruchom:

Możesz ustawić kolor na jedną z wartość z podanego zbioru: normal, black, red, green, yellow, blue, magenta, cyan lub white. Jeżeli chciałbyś użyć dodatkowego atrybutu takiego jak pogrubienie z poprzedniego przykładu, możesz wykorzystać bold, dim, ul (z ang. underline, czyli podkreślenie), blink oraz reverse (zamiana koloru liter i tła).

Jeżeli programujesz na systemie Windows, lub używasz innego systemu, ale współpracujesz z osobami które programują na tym systemie, prawdopodobnie będziesz miał w pewnym momencie problemy związane ze znakami końca linii. Dzieje się tak dlatego, ponieważ w celu oznaczenia końca wiersza w swoich plikach system Windows używa dwóch znaków, tj. znaku powrotu karetki (CR) i znaku nowej linii (LF), a tymczasem w systemach Mac i Linux użwany jest jedynie znak nowej linii (LF). To jest subtelny, ale bardzo irytujący fakt przy współpracy na wielu platformach; wiele edytorów w Windows po cichu zastępuje istniejące zakończenia linii w stylu LF znakiem CRLF lub wstawia oba znaki kończące linię, gdy użytkownik naciśnie klawisz Enter.

Git może to obsłużyć poprzez automatyczną konwersję linii CRLF na LF, gdy wykonujesz commit, i odwrotnie podczas pobierania kodu na dysk. Możesz włączyć tą funkcjonalność za pomocą ustawienia core.autocrlf. Jeżeli pracujesz na systemie Windows, ustaw jej wartość na true – zamieni to znaki LF na CRLF podczas pobierania kodu:

Jeżeli pracujesz na systemie Linux lub Mac, który używa znaków LF oznaczających koniec wiersza, nie będziesz chciał, aby Git automatycznie konwertował je podczas pobierania kodu; jednakże, jeżeli zostanie przez pomyłkę wgrany plik z zakończeniami CRLF, możesz chcieć aby Git je poprawił. Możesz wskazać Git, aby konwertował znaki CRLF na LF podczas commita, ale nie w odwrotną stronę ustawiając core.autocrlf na input:

Takie ustawienia powinny zachować znaki CRLF na systemach Windows, a LF na systemach Mac i Linux oraz w repozytorium.

Jeżeli jesteś programistą tworzącym aplikację przeznaczoną wyłącznie na systemy Windows, możesz zupełnie wyłączyć tą funkcjonalność przez ustawienie wartości false, przez co znaki powrotu karetki również będą zapisywanie w repozytorium:

Git comes preset to detect and fix some whitespace issues. It can look for six primary whitespace issues – three are enabled by default and can be turned off, and three are disabled by default but can be activated.

The ones that are turned on by default are blank-at-eol, which looks for spaces at the end of a line; blank-at-eof, which notices blank lines at the end of a file; and space-before-tab, which looks for spaces before tabs at the beginning of a line.

The three that are disabled by default but can be turned on are indent-with-non-tab, which looks for lines that begin with spaces instead of tabs (and is controlled by the tabwidth option); tab-in-indent, which watches for tabs in the indentation portion of a line; and cr-at-eol, which tells Git that carriage returns at the end of lines are OK.

You can tell Git which of these you want enabled by setting core.whitespace to the values you want on or off, separated by commas. You can disable settings by either leaving them out of the setting string or prepending a - in front of the value. For example, if you want all but cr-at-eol to be set, you can do this:

Git will detect these issues when you run a git diff command and try to color them so you can possibly fix them before you commit. It will also use these values to help you when you apply patches with git apply. When you’re applying patches, you can ask Git to warn you if it’s applying patches with the specified whitespace issues:

Or you can have Git try to automatically fix the issue before applying the patch:

These options apply to the git rebase command as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run git rebase --whitespace=fix to have Git automatically fix whitespace issues as it’s rewriting the patches.

Git is capable of making sure every object received during a push still matches its SHA-1 checksum and points to valid objects. However, it doesn’t do this by default; it’s a fairly expensive operation, and might slow down the operation, especially on large repositories or pushes. If you want Git to check object consistency on every push, you can force it to do so by setting receive.fsckObjects to true:

Now, Git will check the integrity of your repository before each push is accepted to make sure faulty (or malicious) clients aren’t introducing corrupt data.

If you rebase commits that you’ve already pushed and then try to push again, or otherwise try to push a commit to a remote branch that doesn’t contain the commit that the remote branch currently points to, you’ll be denied. This is generally good policy; but in the case of the rebase, you may determine that you know what you’re doing and can force-update the remote branch with a -f flag to your push command.

To tell Git to refuse force-pushes, set receive.denyNonFastForwards:

The other way you can do this is via server-side receive hooks, which we’ll cover in a bit. That approach lets you do more complex things like deny non-fast-forwards to a certain subset of users.

One of the workarounds to the denyNonFastForwards policy is for the user to delete the branch and then push it back up with the new reference. To avoid this, set receive.denyDeletes to true:

This denies any deletion of branches or tags – no user can do it. To remove remote branches, you must remove the ref files from the server manually. There are also more interesting ways to do this on a per-user basis via ACLs, as you’ll learn in An Example Git-Enforced Policy.