Git/Tips/fr

Une liste de conseils et astuces pour Git



Gérer les anciennes branches
Si vous avez travaillé avec git pour un certain temps vous avez probablement de nombreuses vielles branches plus utiles qui traînent. Celles dont vous n'avez définitivement plus besoin sont celles qui ont déjà été fusionnées avec master. Vous pouvez les identifier avec:

De même, près avoir soums une modification à la révision, vous pouvez faire que votre branche soit automatiquement supprimée après que Gerrit l'aie fusionnée:



Vérifications pré-commit
Git allows you to define checks a commit has to pass via hooks (see  for details). You should keep in mind that you have to define hooks separately for every (for example extension's) repository and that they are not copied by, so you have to create some procedure suiting your personal work patterns for how to keep them organized.

Commencez par activer le prélèvement de pré-commission installé par Git. Il interdit les noms de fichier non-ASCII et les espaces en fin de nom.



Interdire les commits vers master
Committing to  in your local repository usually isn't what you want. Pour désactiver, mettez ce morceau au début:

You could also disallow commits to other branches (REL1_20, etc.), but protecting against  is enough in most cases.

Run php -l on PHP files
It's probably a good idea to check whether any PHP files you added or changed pass a simple  test. To enable this, put this sniplet before the final  line:

Running test suites
As the pre-commit checklist suggests, you should run tests before submitting a change. In a rational world, this tedious task is left to a robot, in the real world where despite frequent a/b tests for UI tidbits this isn't even on the radar, you have to build the robot yourself. Thankfully, Git offers all that is needed in the hooked form of.

The following example somewhat tests the parser and the SQLite backend (cf. the for further inspiration):

Obviously, it's very necessary to adapt this hook to your personal workspace and also not use the same for  as for extensions. Running the test suite as an  job allows you to continue working while the test runs in the background and you'll be mailed the results once it ends. This setup assumes that you run one test suite at a time; if you want to run more in parallel, you can reference the SHA1 of  in   or even try   but be reminded that each clone will consume more than 200 MByte of disk space.

What tests you should run depends on your field of work. If you're working on parser bits, running those tests may be enough. If you plan complex changes to the database schema, you can test fresh installs and running update.php from older installations. If you're working on extensions, you can clone  and tags (not branches, the latter are moving targets)   and   and see whether your code is still compatible with them.

If you develop on a box with few resources, but have access to more powerful machines on the net, you can create bare repositories on the latter and use the hook  in a similar fashion on them (the commit is passed as  ). You then just have to  to start the test suite.

View source code
We use a Gerrit plugin called "Gitiles" to browse the repository as a whole:


 * https://gerrit.wikimedia.org/r/plugins/gitiles/

There are also alternatives:


 * wikimedia/mediawiki-core mirror on GitHub