Chapters ā–¾ 2nd Edition

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.

scroll-to-top