8.1 Kostumisasi Git - Konfigurasi Git

Secara default, Git menggunakan apapun yang sudah Anda atur sebagai default penyunting teks Anda ($VISUAL atau $EDITOR) jika tidak maka akan kembali menggunakan penyunting vi untuk membuat dan mengubah pesan commit dan tag. Untuk mengubah default tersebut menjadi sesuatu yang lain, Anda bisa menggunakan pengaturan core.editor:

Sekarang, terlepas dari apapun yang dipasang sebagai shell default penyunting Anda, Git akan menggunakan Emacs untuk menyunting pesan-pesan Anda.

Jika Anda memasang ini ke jalur berkas pada komputer Anda, Git akan menggunakan berkas tersebut sebagai pesan default ketika melakukan commit. Sebagai contoh, anggap saja Anda membuat sebuah templat berkas di ~/.gitmessage.txt yang terlihat seperti ini:

Untuk meminta Git menggunakannya sebagai pesan default yang muncul pada penyunting Anda saat Anda menjalankan git commit, aturlah nilai konfigurasi commit.template:

Maka, penyunting Anda akan terbuka seperti ini pada tempat pesan commit Anda ketika Anda melakukan commit:

Jika tim Anda mempunyai aturan untuk pesan-commit, maka memasang templat untuk aturan tersebut pada sistem Anda dan mengkonfigurasi Git untuk menggunakannya secara default akan membantu untuk meningkatkan kemungkinan aturan tersebut diikuti secara teratur.

Pengaturan ini menentukan pager yang mana yang digunakan ketika Git melakukan pages output seperti log dan diff. Anda bisa mengaturnya menjadi more atau ke pager favorit Anda (secara default, hal tersebut merupakan less), atau Anda bisa mematikannya dengan mangaturnya ke string kosong:

Jika Anda menjalankan perintah tersebut, Git akan menampilkan semua pesan tanpa perantara more atau less, tidak perduli seberapa panjang perintah tersebut.

jika Anda membuat signed annotated tags (sebagaimana yang telah dibahas di Signing Your Work), mengatur kunci signin GPG Anda menjadi sebuah pengaturan konfigurasi akan membuat segala sesuatu menjadi lebih mudah. Atur kunci ID Anda seperti contoh berikut:

Sekarang, Anda bisa menandai tag tanpa harus selalu menentukan kunci Anda dengan perintah git tag:

Anda bisa membuat pola pada berkas .gitignore proyek Anda agar Git tidak melihatnya sebagai berkas yang untracked atau coba untuk menampilkannya ketika Anda menjalankan git add pada berkas-berkas tersebut, sebagaimana telah dibahas di Ignoring Files.

Tetapi adakalannya Anda ingin mengabaikan berkas-berkas tertentu untuk semua repositori yang sedang Anda gunakan. Jika komputer Anda menggunakan Mac OS X, mungkin Anda sudah terbiasa dengan berkas-berkas .DS_Store. Jika Anda lebih suka menggunakan penyunting Emacs atau Vim, Anda pasti tahu tentang berkas-berkas yang berakhir dengan tanda ~.

Pengaturan ini membuat Anda bisa menulis sebuah berkas umum dari .gitignore. Jika Anda membuat sebuah berkas ~/.gitignore_global dengan konten-konten berikut:

…dan Anda menjalankan perintah git config --global core.excludesfile ~/.gitignore_global, Git tidak akan pernah lagi mempermasalahkan berkas-berkas tersebut.

Jika Anda salah menulis perintah, Anda akan melihat sesuatu seperti ini:

Git akan mencoba memahami apa yang Anda maksud, tetapi tetap akan menolak untuk melakukannya. Jika Anda mengatur help.autocorrect dengan angka 1, Git hanya akan menjalankan perintah ini untuk Anda:

Catat bahwa nilai “0.1 seconds”. help.autocorrect sebenarnya merupakan sebuah bilangan bulat yang mewakili sepersepuluh detik. Jadi jika Anda mengaturnya pada angka 50, Git akan memberikan anda waktu 5 detik untuk berubah pikiran sebelum melakukan perintah autocorrected (perbaikan secara otomatis).

Git mewarnai hampir semua outputnya secara otomatis, jikan Anda tidak suka dengan pengaturan seperti ini ada opsi untuk mematikannya. Semua pewarnaan pada terminal output Git bisa dimatikan dengan menjalankan perintah berikut:

The default setting is auto, which colors output when it’s going straight to a terminal, but omits the color-control codes when the output is redirected to a pipe or a file.

You can also set it to always to ignore the difference between terminals and pipes. You’ll rarely want this; in most scenarios, if you want color codes in your redirected output, you can instead pass a --color flag to the Git command to force it to use color codes. The default setting is almost always what you’ll want.

If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. Each of these can be set to true, false, or always:

In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color. For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run

You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white. If you want an attribute like bold in the previous example, you can choose from bold, dim, ul (underline), blink, and reverse (swap foreground and background).

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

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.