-
1. Ćvod
-
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
-
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.3 Customizing Git - Git Hooks
Git Hooks
Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits. You can use these hooks for all sorts of reasons.
Instalace zƔsuvnƩho modulu
VÅ”echny zĆ”suvnĆ© moduly jsou uloženy v podadresĆ”Åi hooks
adresĆ”Åe Git.
In most projects, thatās .git/hooks
.
When you initialize a new repository with git init
, Git populates the hooks directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script.
All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine ā you can write them in Ruby or Python or what have you.
If you want to use the bundled hook scripts, youāll have to rename them; their file names all end with .sample
.
To enable a hook script, put a file in the hooks
subdirectory of your .git directory that is named appropriately (without any extension) and is executable.
Od tohoto okamžiku by mÄl být skript volĆ”n.
Weāll cover most of the major hook filenames here.
ZĆ”suvnĆ© moduly na stranÄ klienta
Na stranÄ klienta existuje mnoho zĆ”suvných modulÅÆ. This section splits them into committing-workflow hooks, email-workflow scripts, and everything else.
Note
|
Itās important to note that client-side hooks are not copied when you clone a repository. If your intent with these scripts is to enforce a policy, youāll probably want to do that on the server side; see the example in An Example Git-Enforced Policy. |
ZĆ”suvnĆ© moduly k zapisovĆ”nĆ revizĆ
PrvnĆ ÄtyÅi zĆ”suvnĆ© moduly se týkajĆ zapisovĆ”nĆ revizĆ.
ZÔsuvný modul pre-commit
se spouÅ”tĆ jako prvnĆ, jeÅ”tÄ než zaÄnete psĆ”t zprĆ”vu k revizi.
Itās used to inspect the snapshot thatās about to be committed, to see if youāve forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.
Je-li výstup tohoto zĆ”suvnĆ©ho modulu nenulový, zapisovĆ”nĆ bude pÅeruÅ”eno. Ale můžete to obejĆt zadĆ”nĆm pÅĆkazu git commit --no-verify
.
You can do things like check for code style (run lint
or something equivalent), check for trailing whitespace (the default hook does exactly this), or check for appropriate documentation on new methods.
ZÔsuvný modul prepare-commit-msg
se spouÅ”tĆ jeÅ”tÄ pÅedtĆm, než se otevÅe editor pro vytvoÅenĆ zprĆ”vy k revizi, ale potĆ©, co byla vytvoÅena výchozĆ zprĆ”va.
UmožÅuje upravit výchozĆ zprĆ”vu dÅĆv, než se zobrazĆ autorovi revize.
This hook takes a few parameters: the path to the file that holds the commit message so far, the type of commit, and the commit SHA-1 if this is an amended commit.
This hook generally isnāt useful for normal commits; rather, itās good for commits where the default message is auto-generated, such as templated commit messages, merge commits, squashed commits, and amended commits.
ZĆ”suvný modul můžete v kombinaci se Å”ablonou revize využĆvat k vloženĆ informacĆ programem.
The commit-msg
hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.
Je-li nĆ”vratovĆ” hodnota skriptu nenulovĆ”, Git pÅeruŔà proces zapisovĆ”nĆ. Skript tak můžete použĆvat k validaci stavu projektu nebo zprĆ”vy k revizi, než dovolĆte, aby byla revize zapsĆ”na.
In the last section of this chapter, Weāll demonstrate using this hook to check that your commit message is conformant to a required pattern.
Po dokonÄenĆ celĆ©ho procesu zapisovĆ”nĆ revize se spustĆ zĆ”suvný modul post-commit
.
It doesnāt take any parameters, but you can easily get the last commit by running git log -1 HEAD
.
Tento skript se tak vÄtÅ”inou použĆvĆ” pro ĆŗÄely oznĆ”menĆ a podobnÄ.
Email Workflow Hooks
You can set up three client-side hooks for an email-based workflow.
Theyāre all invoked by the git am
command, so if you arenāt using that command in your workflow, you can safely skip to the next section.
If youāre taking patches over email prepared by git format-patch
, then some of these may be helpful to you.
PrvnĆ zĆ”suvným modulem, který se spouÅ”tĆ, je applypatch-msg
.
PoužĆvĆ” jediný parametr: nĆ”zev doÄasnĆ©ho souboru s požadovaným tvarem zprĆ”vy k revizi.
Je-li výstup tohoto skriptu nenulový, Git pÅeruŔà zĆ”platu.
You can use this to make sure a commit message is properly formatted, or to normalize the message by having the script edit it in place.
DalŔà zĆ”suvným modulem, který se může spouÅ”tÄt pÅi aplikaci zĆ”platy pÅĆkazem git am
, je pre-applypatch
.
Somewhat confusingly, it is run after the patch is applied but before a commit is made, so you can use it to inspect the snapshot before making the commit.
TĆmto skriptem lze spouÅ”tÄt rÅÆznĆ© testy nebo jinak kontrolovat pracovnĆ strom.
If something is missing or the tests donāt pass, exiting non-zero aborts the git am
script without committing the patch.
The last hook to run during a git am
operation is post-applypatch
, which runs after the commit is made.
You can use it to notify a group or the author of the patch you pulled in that youāve done so.
You canāt stop the patching process with this script.
Other Client Hooks
ZÔsuvný modul pre-rebase
se spouÅ”tĆ pÅed každým pÅesklĆ”dĆ”nĆm a pÅi nenulovĆ© hodnotÄ může tento proces zastavit.
ZĆ”suvný modul můžete využĆt i k zakĆ”zĆ”nĆ pÅesklĆ”dĆ”nĆ vÅ”ech revizĆ, kterĆ© už byly odeslĆ”ny.
The example pre-rebase
hook that Git installs does this, although it makes some assumptions that may not match with your workflow.
The post-rewrite
hook is run by commands that replace commits, such as git commit --amend
and git rebase
(though not by git filter-branch
).
Its single argument is which command triggered the rewrite, and it receives a list of rewrites on stdin
.
This hook has many of the same uses as the post-checkout
and post-merge
hooks.
Po ĆŗspÄÅ”nĆ©m spuÅ”tÄnĆ pÅĆkazu git checkout
se spustà zÔsuvný modul post-checkout
. Ten sloužà k nastavenĆ pracovnĆho adresĆ”Åe podle potÅeb prostÅedĆ vaÅ”eho projektu.
This may mean moving in large binary files that you donāt want source controlled, auto-generating documentation, or something along those lines.
The post-merge
hook runs after a successful merge
command.
You can use it to restore data in the working tree that Git canāt track, such as permissions data.
ZĆ”suvný modul může rovnÄž ovÄÅit pÅĆtomnost souborÅÆ nezahrnutých do sprĆ”vy verzĆ systĆ©mu Git, kterĆ© možnĆ” budete chtĆt po zmÄnĆ”ch v pracovnĆm stromÄ zkopĆrovat.
The pre-push
hook runs during git push
, after the remote refs have been updated but before any objects have been transferred.
It receives the name and location of the remote as parameters, and a list of to-be-updated refs through stdin
.
You can use it to validate a set of ref updates before a push occurs (a non-zero exit code will abort the push).
Git occasionally does garbage collection as part of its normal operation, by invoking git gc --auto
.
The pre-auto-gc
hook is invoked just before the garbage collection takes place, and can be used to notify you that this is happening, or to abort the collection if now isnāt a good time.
ZĆ”suvnĆ© moduly na stranÄ serveru
Vedle zĆ”suvných modulÅÆ na stranÄ klienta můžete jako sprĆ”vce systĆ©mu využĆvat takĆ© nÄkolik dÅÆležitých zĆ”suvných modulÅÆ na stranÄ serveru, kterĆ© vĆ”m pomohou kontrolovat tĆ©mÄÅ jakýkoli typ standardÅÆ stanovených pro daný projekt. Tyto skripty se spouÅ”tÄjĆ pÅed odesĆlĆ”nĆm revizĆ na server i po nÄm. The pre hooks can exit non-zero at any time to reject the push as well as print an error message back to the client; you can set up a push policy thatās as complex as you wish.
pre-receive
PrvnĆm skriptem, který se pÅi manipulaci s revizemi pÅijatými od klienta spustĆ, je pre-receive
.
Skript použĆvĆ” seznam referencĆ, kterĆ© jsou odesĆlĆ”ny ze standardnĆho vstupu stdin. Je-li nĆ”vratovĆ” hodnota nenulovĆ”, nebude ani jedna z nich pÅijata.
You can use this hook to do things like make sure none of the updated references are non-fast-forwards, or to do access control for all the refs and files theyāre modifying with the push.
update
The update
script is very similar to the pre-receive
script, except that itās run once for each branch the pusher is trying to update.
If the pusher is trying to push to multiple branches, pre-receive
runs only once, whereas update runs once per branch theyāre pushing to.
Tento skript nenaÄĆtĆ” data ze standardnĆho vstupu, mĆsto nich použĆvĆ” tÅi jinĆ© parametry: nĆ”zev reference (vÄtve), hodnotu SHA-1, na niž reference ukazovala pÅed odeslĆ”nĆm, a hodnotu SHA-1, kterou se uživatel pokouŔà odeslat.
Je-li výstup skriptu update nenulový, je zamĆtnuta pouze tato reference, ostatnĆ mohou být aktualizovĆ”ny.
post-receive
ZÔsuvný modul post-receive
se spouÅ”tĆ až potĆ©, co je celý proces dokonÄen. Lze ho použĆt k aktualizaci jiných služeb nebo odeslĆ”nĆ oznĆ”menĆ jiným uživatelÅÆm.
PoužĆvĆ” stejnĆ” data ze standardnĆho vstupu jako zĆ”suvný modul pre-receive
.
Examples include emailing a list, notifying a continuous integration server, or updating a ticket-tracking system ā you can even parse the commit messages to see if any tickets need to be opened, modified, or closed.
This script canāt stop the push process, but the client doesnāt disconnect until it has completed, so be careful if you try to do anything that may take a long time.