-
1. Úvod
- 1.1 Správa verzí
- 1.2 Stručná historie systému Git
- 1.3 Základy systému Git
- 1.4 Příkazový řádek
- 1.5 Instalace systému Git
- 1.6 První nastavení systému Git
- 1.7 Získání nápovědy
- 1.8 Shrnutí
-
2. Základy práce se systémem Git
-
3. Větve v systému Git
- 3.1 Větve v kostce
- 3.2 Základy větvení a slučování
- 3.3 Správa větví
- 3.4 Postupy při práci s větvemi
- 3.5 Vzdálené větve
- 3.6 Přeskládání
- 3.7 Shrnutí
-
4. Git na serveru
- 4.1 Protokoly
- 4.2 Zprovoznění Gitu na serveru
- 4.3 Generování veřejného klíče SSH
- 4.4 Nastavení serveru
- 4.5 Démon Git
- 4.6 Chytrý HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti hostování u třetí strany
- 4.10 Shrnutí
-
5. Distribuovaný Git
- 5.1 Distribuované pracovní postupy
- 5.2 Přispívání do projektu
- 5.3 Správa projektu
- 5.4 Shrnutí
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Ladění v systému Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Shrnutí
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Atributy Git
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Shrnutí
-
9. Git a ostatní systémy
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Shrnutí
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Balíčkové soubory
- 10.5 The Refspec
- 10.6 Přenosové protokoly
- 10.7 Správa a obnova dat
- 10.8 Environment Variables
- 10.9 Shrnutí
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Shrnutí
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
8.1 Customizing Git - Git Configuration
So far, we’ve covered the basics of how Git works and how to use it, and we’ve introduced a number of tools that Git provides to help you use it easily and efficiently. In this chapter, we’ll see how you can make Git operate in a more customized fashion, by introducing several important configuration settings and the hooks system. With these tools, it’s easy to get Git to work exactly the way you, your company, or your group needs it to.
Git Configuration
As you briefly saw in Úvod, you can specify Git configuration settings with the git config
command.
One of the first things you did was set up your name and email address:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Now you’ll learn a few of the more interesting options that you can set in this manner to customize your Git usage.
First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want.
Prvním místem, kde Git tyto hodnoty vyhledává, je soubor /etc/gitconfig
, obsahující hodnoty pro každého uživatele v systému a všechny jejich repozitáře.
Zadáte-li příkazu git config
parametr --system
, pak Git čte a zapisuje konkrétně do tohoto souboru.
The next place Git looks is the ~/.gitconfig
(or ~/.config/git/config
) file, which is specific to each user.
Git bude načítat a zapisovat výhradně do tohoto souboru, jestliže zadáte parametr --global
.
Finally, Git looks for configuration values in the configuration file in the Git directory (.git/config
) of whatever repository you’re currently using.
Tyto hodnoty platí pouze pro tento konkrétní repozitář.
Each of these “levels” (system, global, local) overwrites values in the previous level, so values in .git/config
trump those in /etc/gitconfig
, for instance.
Note
|
Git’s configuration files are plain-text, so you can also set these values by manually editing the file and inserting the correct syntax.
It’s generally easier to run the |
Základní konfigurace klienta
The configuration options recognized by Git fall into two categories: client-side and server-side. The majority of the options are client-side – configuring your personal working preferences. Many, many configuration options are supported, but a large fraction of them are only useful in certain edge cases. We’ll only be covering the most common and most useful here. Pokud vás zajímá seznam parametrů, které vaše verze systému Git rozeznává, můžete si nechat jejich seznam vypsat příkazem:
$ man git-config
This command lists all the available options in quite a bit of detail. You can also find this reference material at http://git-scm.com/docs/git-config.html.
core.editor
By default, Git uses whatever you’ve set as your default text editor ($VISUAL
or $EDITOR
) or else falls back to the vi
editor to create and edit your commit and tag messages.
Chcete-li změnit výchozí hodnotu, použijte nastavení core.editor
:
$ git config --global core.editor emacs
Now, no matter what is set as your default shell editor, Git will fire up Emacs to edit messages.
commit.template
If you set this to the path of a file on your system, Git will use that file as the default message when you commit.
For instance, suppose you create a template file at ~/.gitmessage.txt
that looks like this:
subject line
co bylo provedeno
[ticket: X]
Chcete-li systému Git zadat, aby soubor používal jako výchozí zprávu, která se zobrazí v textovém editoru po spuštění příkazu git commit
, nastavte konfigurační hodnotu commit.template
:
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
Při zapisování revize váš editor otevře následující šablonu zprávy k revizi:
subject line
co bylo provedeno
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
If your team has a commit-message policy, then putting a template for that policy on your system and configuring Git to use it by default can help increase the chance of that policy being followed regularly.
core.pager
This setting determines which pager is used when Git pages output such as log
and diff
.
You can set it to more
or to your favorite pager (by default, it’s less
), or you can turn it off by setting it to a blank string:
$ git config --global core.pager ''
If you run that, Git will page the entire output of all commands, no matter how long they are.
user.signingkey
If you’re making signed annotated tags (as discussed in Signing Your Work), setting your GPG signing key as a configuration setting makes things easier. ID svého klíče nastavíte takto:
$ git config --global user.signingkey <gpg-key-id>
Nyní můžete podepisovat značky, aniž byste museli pokaždé znovu zadávat svůj klíč příkazem git tag
:
$ git tag -s <tag-name>
core.excludesfile
You can put patterns in your project’s .gitignore
file to have Git not see them as untracked files or try to stage them when you run git add
on them, as discussed in Ignorované soubory.
But sometimes you want to ignore certain files for all repositories that you work with.
If your computer is running Mac OS X, you’re probably familiar with .DS_Store
files.
If your preferred editor is Emacs or Vim, you know about filenames that end with a ~
or .swp
.
This setting lets you write a kind of global .gitignore
file.
If you create a ~/.gitignore_global
file with these contents:
*~
.*.swp
.DS_Store
…and you run git config --global core.excludesfile ~/.gitignore_global
, Git will never again bother you about those files.
help.autocorrect
If you mistype a command, it shows you something like this:
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
Did you mean this?
checkout
Git helpfully tries to figure out what you meant, but it still refuses to do it.
If you set help.autocorrect
to 1, Git will actually run this command for you:
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
Note that “0.1 seconds” business. help.autocorrect
is actually an integer which represents tenths of a second.
So if you set it to 50, Git will give you 5 seconds to change your mind before executing the autocorrected command.
Barvy systému Git
Git fully supports colored terminal output, which greatly aids in visually parsing command output quickly and easily. S individuálním nastavením barev vám pomůže celá řada možností.
color.ui
Git automatically colors most of its output, but there’s a master switch if you don’t like this behavior. To turn off all Git’s colored terminal output, do this:
$ git config --global color.ui false
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.
color.*
Pokud byste rádi nastavili přesněji jak budou zvýrazněny různé příkazy nebo máte starší verzi, nabízí Git nastavení barev pro jednotlivé příkazy.
Každý z příslušných parametrů může nabývat hodnoty na true
(pravda), false
(nepravda) nebo always
(vždy):
color.branch color.diff color.interactive color.status
Chcete-li sami nastavit jednotlivé barvy, mají všechny tyto parametry navíc dílčí nastavení, které můžete použít k určení konkrétních barev pro jednotlivé části výstupu. Budete-li chtít nastavit například meta informace ve výpisu příkazu diff tak, aby měly modré popředí, černé pozadí a tučné písmo, můžete použít příkaz:
$ git config --global color.diff.meta "blue black bold"
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).
External Merge and Diff Tools
Although Git has an internal implementation of diff, which is what we’ve been showing in this book, you can set up an external tool instead. You can also set up a graphical merge-conflict-resolution tool instead of having to resolve conflicts manually. We’ll demonstrate setting up the Perforce Visual Merge Tool (P4Merge) to do your diffs and merge resolutions, because it’s a nice graphical tool and it’s free.
Pokud ho chcete vyzkoušet, nemělo by vám v tom nic bránit, P4Merge funguje na všech hlavních platformách.
We’ll use path names in the examples that work on Mac and Linux systems; for Windows, you’ll have to change /usr/local/bin
to an executable path in your environment.
To begin, download P4Merge from Perforce.
Next, you’ll set up external wrapper scripts to run your commands.
We’ll use the Mac path for the executable; in other systems, it will be where your p4merge
binary is installed.
Nastavte wrapperový skript pro slučování extMerge
, který bude volat binární soubor všemi dostupnými parametry:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
Wrapper nástroje diff zkontroluje zda je skutečně zadáno sedm parametrů a předá dva z nich do skriptu pro slučování. Standardně Git předává do nástoje diff tyto parametry:
path old-file old-hex old-mode new-file new-hex new-mode
Protože chcete pouze parametry old-file
a new-file
, použijete wrapperový skript k zadání těch, které potřebujete.
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
Dále se potřebujete také ujistit, že lze tyto nástroje spustit:
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
Nyní můžete nastavit konfigurační soubor k používání vlastních nástrojů diff a nástrojů k řešení slučování.
This takes a number of custom settings: merge.tool
to tell Git what strategy to use, mergetool.<tool>.cmd
to specify how to run the command, mergetool.<tool>.trustExitCode
to tell Git if the exit code of that program indicates a successful merge resolution or not, and diff.external
to tell Git what command to run for diffs.
Můžete tedy spustit kterýkoli ze čtyř konfiguračních příkazů:
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
or you can edit your ~/.gitconfig
file to add these lines:
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
Až dokončíte celé nastavení, můžete spustit příkaz diff, např.:
$ git diff 32d1776b1^ 32d1776b1
Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like this:
![P4Merge.](png/p4merge.png)
Jestliže se pokusíte sloučit dvě větve a dojde při tom ke konfliktu, můžete spustit příkaz git mergetool
. Příkaz spustí program P4Merge, v němž budete moci v grafickém uživatelském rozhraní konflikt vyřešit.
Příjemné na tomto wrapperovém nastavení je, že lze snadno změnit nástroj diff i nástroj pro slučování.
Chcete-li například změnit nástroje extDiff
a extMerge
, aby se místo nich spouštěl nástroj KDiff3, jediné, co musíte udělat, je upravit soubor extMerge
:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
Git bude nyní k zobrazení výstupů nástoje diff a k řešení konfliktů při slučování používat nástroj KDiff3.
Git je standardně přednastaven tak, aby dokázal používat celou řadu různých nástrojů k řešení konfliktů při slučování, aniž byste museli nastavovat konfiguraci příkazu. To see a list of the tools it supports, try this:
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
If you’re not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run
$ git config --global merge.tool kdiff3
Pokud spustíte tento příkaz místo nastavení souborů extMerge
a extDiff
, Git bude používat KDiff3 k řešení konfliktů při slučování a interní nástroj diff systému Git pro výpisy nástroje diff.
Formátování a prázdné znaky
Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git disponuje několika konfiguračními parametry, které vám pomohou tyto problémy vyřešit.
core.autocrlf
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. Windows ve svých souborech používá pro nové řádky jak znak pro návrat vozíku (carriage return), tak znak pro posun o řádek (linefeed), zatímco systémy Mac a Linux používají pouze znak posun o řádek. 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.
Tato funkce se zapíná pomocí parametru core.autocrlf
.
If you’re on a Windows machine, set it to true
– this converts LF endings into CRLF when you check out code:
$ git config --global core.autocrlf true
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.
Systému Git tak můžete zadat, aby převáděl posloupnosti CRLF na LF (avšak nikoli obráceně) nastavením core.autocrlf
na hodnotu input:
$ git config --global core.autocrlf 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 config --global core.autocrlf false
core.whitespace
Git je standardně nastaven na vyhledávání a opravu chyb způsobených prázdnými znaky. 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 three 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.
Které z těchto funkcí si přejete zapnout a které vypnout, to můžete systému Git sdělit zadáním čárkami oddělených hodnot do parametru core.whitespace
.
Funkci vypnete buď tím, že ji z řetězce nastavení zcela vynecháte, nebo tím, že před hodnotu vložíte znak -
.
Chcete-li například zapnout všechny funkce kromě cr-at-eol
, zadejte příkaz v tomto tvaru:
$ git config --global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
Až spustíte příkaz git diff
, Git se pokusí tyto problémy vyhledat a barevně označit, abyste je mohli případně ještě před zapsáním revize opravit.
Git se těmito hodnotami řídí také při aplikaci záplat příkazem git apply
.
When you’re applying patches, you can ask Git to warn you if it’s applying patches with the specified whitespace issues:
$ git apply --whitespace=warn <patch>
Git se může také pokusit automaticky daný problém vyřešit, ještě než bude záplata aplikována:
$ git apply --whitespace=fix <patch>
A toto nastavení platí také pro příkaz git rebase
.
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.
Konfigurace serveru
Na straně serveru není ani zdaleka tolik parametrů konfigurace jako na straně klienta, avšak několik zajímavých si jistě zaslouží vaši pozornost.
receive.fsckObjects
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.
Pokud chcete, aby Git kontroloval konzistenci objektů při každém odeslání dat, můžete mu to zadat nastavením možnosti receive.fsckObjects
na hodnotu true:
$ git config --system receive.fsckObjects 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.
receive.denyNonFastForwards
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
:
$ git config --system receive.denyNonFastForwards true
The other way you can do this is via server-side receive hooks, which we’ll cover in a bit. Tato metoda umožňuje pokročilejší nastavení, jako zamítnutí jiných aktualizací než „rychle vpřed“ určité skupině uživatelů.
receive.denyDeletes
Jednou z možností, jak může uživatel obejít pravidlo denyNonFastForwards
, je odstranit větev a odeslat ji zpět s novou referencí.
To avoid this, set receive.denyDeletes
to true:
$ git config --system receive.denyDeletes true
This denies any deletion of branches or tags – no user can do it. Budete-li chtít odstranit vzdálenou větev, budete muset ručně smazat referenční soubory ze serveru. 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.