Changes in 3b4880e: tjacquin created page: Guides/bonnes pratiques/git

				Guides/bonnes-pratiques/git.md
			
          @@ -1,43 +1,45 @@

          -> 1. Use feature branches, no direct commits on master.

          -If you're coming over from SVN, for example, you'll be used to a trunk-based workflow. When using Git you should create a branch for whatever you’re working on, so that you end up doing a code review before you merge.

          +>  1: Les messages de commit doivent refléter l'intention

          -> 2. Test all commits, not only ones on master.

          +Vous devez toujours dire non seulement ce que vous avez fait, mais aussi pourquoi vous l'avez fait.

          +C'est encore mieux si vous pouvez expliquez pourquoi vous avez fait ça plutôt qu'autre chose.

          -Some people set up their CI to only test what has been merged into master. This is too late; people should feel confident that master always has green tests. It doesn't make sense for people to have to test master before they start developing new features, for example. CI isn’t expensive, so it makes the best sense to do it this way.

          +> 2: Utiliser des branches pour l'ajout de fonctionnalités, jamais aucun commit sur la branche master !

          -> 3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).

          +Avec Git, il faut créer une branche pour n'importe quel chose sur laquelle vous travaillez, pour qu'au final vous finissiez avec une revue de code avant de merger.

          -If you're working on a feature branch and you add new commits, run tests then and there. If the tests are taking a long time, try running them in parallel. Do this server-side in merge requests, running the complete test suite. If you have a test suite for development and another that you only run for new versions; it’s worthwhile to set up parallel tests and run them all.

          +> 3: Tester tout les commits, pas seulement ceux sur master.

          -> 4. Perform code reviews before merges into master, not afterwards.

          +Certaines personnes configure l'intégration continue uniquement pour les commits mergés sur master. C'est trop tard pour un test ! Il faut voir uniquement des tets réussis sur master. Ça n'a aucun sens d'attendre de réussir les tests sur master avant de commencer à développer de nouvelles fonctionnalités par exemple. L'IC n'est pas compliquée à mettre en place, c'est donc la meilleur manière de faire.

          -Don't test everything at the end of your week. Do it on the spot, because you'll be more likely to catch things that could cause problems and others will also be working to come up with solutions.

          +> 4: Faites tourner les tests sur tout les commit (si vos tests durent plus que 5 minutes, faites les tourner en parallèle.

          -> 5. Deployments are automatic, based on branches or tags.

          +Si vous travaillez sur une branche feature et que vous ajoutez de nouveaux commits, faites tournez les tests. S'ils sont trop longs, essayez de les lancer en parallèle. Faites le du côté serveur dans les merges requests, en lançant la suite de tests complètes. 

          -If you don't want to deploy master every time, you can create a production branch; but there’s no reason why you should use a script or log in somewhere to do it manually. Have everything automated, or a specific branch that triggers a production deploy.

          +> 5: Faites de la revue de code AVANT de merger dans master, jamais après.   

          -> 6. Tags are set by the user, not by CI.

          +Ne testez pas tout à la fin de votre semaine. Faites le sur le moment, vous serez plus à même d'attraper des choses qui pourront posez des problèmes, et d'autres pourront alors travaillez sur une solution.

          -A user sets a tag and, based on that, the CI will perform an action. You shouldn’t have the CI change the repository. If you need very detailed metrics, you should have a server report detailing new versions.

          +> 6: Les déploiements sont automatiques, basés sur des branches ou tags.

          -> 7. Releases are based on tags.

          +Si vous ne voulez pas déployez master à chaque fois, vous pouvez créer une branche de production; il n'y a aucune raison pour ne pas faire un script pour cela. Automatisez tout, selon une branche ou un tag qui active un déploiement en production.

          -If you tag something, that creates a new release.

          +> 7: Les tags sont choisis par les utilisateurs, pas par l'IC

          -> 8. Pushed commits are never rebased.

          +Un utilisateur choisis un tag et, basé sur ça, l'IC fera l'action. Pas l'inverse. Il ne faut pas que l'IC modifie le dépôt. Si vous avez besoin de métriques détaillées, vous devez avoir un serveur de rapport qui détaille chaque nouvelle versions.

          -If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking. We sometimes sin against this rule ourselves when we ask a contributor to squash and rebase at the end of a review process to make something easier to revert. But in general the guideline is: code should be clean, history should be realistic.

          +> 8: Les releases sont basées sur des tags.

          -> 9. Everyone starts from master, and targets master.

          +Si vous taggez quelquechose, ça doit créer une nouvelle release.

          -This means you don’t have any long branches. You check out master, build your feature, create your merge request, and target master again. You should do your complete review before you merge, and not have any intermediate stages.

          +> 9: Les commits pushés ne doivent jamais être rebasés.

          -> 10. Fix bugs in master first and release branches second.

          +Si vous pusher sur une branche public, vous ne devez pas rebase ! Cela rendra la revue de code très difficile, les résultats des tests obscurs, et ça casser les cherrypicking. Parfois on peut faire exception à la règle pour demander à un contributeur de squasher et rebase à la fin du process de revue de code pour avoir quelquechose de plus facile à revert. Mais, en général, le code doit être propre, l'historique doit être réaliste.

          -If you find a bug, the worst thing you can do is fix it in the just-released version, and not fix it in master. To avoid it, you always fix forward. Fix it in master, then cherry-pick it into another patch-release branch.

          +> 10: Tout le monde commence depuis master, et cible master.

          -> 11. Commit messages reflect intent.

          +Vous ne devez pas avoir de branche trop longues. Vous récuperez master, construisez votre feature, créez votre merge request et ciblez master. Vous devez faire une revue complète de votre code avant merge, et ne pas créer d'étapes intermédiaires.

          -You should not only say what you did, but also why you did it. It’s even more useful if you explain why you did this over any other options.

          +> 11: Résoudre les bugs de master d'abord, puis des branches de releases ensuite.

          +

          +Si vous trouvez un bug, la pire chose à faire est de le fixer dans la version tout juste sortie, et d'oubliez de le faire dans master. Pour éviter ça, vous devez toujours corriger le bug sur master, puis cherry-picker dans un branche re patch-release.

...	...	@@ -1,43 +1,45 @@
1		-> 1. Use feature branches, no direct commits on master.
2	1
3		-If you're coming over from SVN, for example, you'll be used to a trunk-based workflow. When using Git you should create a branch for whatever you’re working on, so that you end up doing a code review before you merge.
	2	+> 1: Les messages de commit doivent refléter l'intention
4	3
5		-> 2. Test all commits, not only ones on master.
	4	+Vous devez toujours dire non seulement ce que vous avez fait, mais aussi pourquoi vous l'avez fait.
	5	+C'est encore mieux si vous pouvez expliquez pourquoi vous avez fait ça plutôt qu'autre chose.
6	6
7		-Some people set up their CI to only test what has been merged into master. This is too late; people should feel confident that master always has green tests. It doesn't make sense for people to have to test master before they start developing new features, for example. CI isn’t expensive, so it makes the best sense to do it this way.
	7	+> 2: Utiliser des branches pour l'ajout de fonctionnalités, jamais aucun commit sur la branche master !
8	8
9		-> 3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
	9	+Avec Git, il faut créer une branche pour n'importe quel chose sur laquelle vous travaillez, pour qu'au final vous finissiez avec une revue de code avant de merger.
10	10
11		-If you're working on a feature branch and you add new commits, run tests then and there. If the tests are taking a long time, try running them in parallel. Do this server-side in merge requests, running the complete test suite. If you have a test suite for development and another that you only run for new versions; it’s worthwhile to set up parallel tests and run them all.
	11	+> 3: Tester tout les commits, pas seulement ceux sur master.
12	12
13		-> 4. Perform code reviews before merges into master, not afterwards.
	13	+Certaines personnes configure l'intégration continue uniquement pour les commits mergés sur master. C'est trop tard pour un test ! Il faut voir uniquement des tets réussis sur master. Ça n'a aucun sens d'attendre de réussir les tests sur master avant de commencer à développer de nouvelles fonctionnalités par exemple. L'IC n'est pas compliquée à mettre en place, c'est donc la meilleur manière de faire.
14	14
15		-Don't test everything at the end of your week. Do it on the spot, because you'll be more likely to catch things that could cause problems and others will also be working to come up with solutions.
	15	+> 4: Faites tourner les tests sur tout les commit (si vos tests durent plus que 5 minutes, faites les tourner en parallèle.
16	16
17		-> 5. Deployments are automatic, based on branches or tags.
	17	+Si vous travaillez sur une branche feature et que vous ajoutez de nouveaux commits, faites tournez les tests. S'ils sont trop longs, essayez de les lancer en parallèle. Faites le du côté serveur dans les merges requests, en lançant la suite de tests complètes.
18	18
19		-If you don't want to deploy master every time, you can create a production branch; but there’s no reason why you should use a script or log in somewhere to do it manually. Have everything automated, or a specific branch that triggers a production deploy.
	19	+> 5: Faites de la revue de code AVANT de merger dans master, jamais après.
20	20
21		-> 6. Tags are set by the user, not by CI.
	21	+Ne testez pas tout à la fin de votre semaine. Faites le sur le moment, vous serez plus à même d'attraper des choses qui pourront posez des problèmes, et d'autres pourront alors travaillez sur une solution.
22	22
23		-A user sets a tag and, based on that, the CI will perform an action. You shouldn’t have the CI change the repository. If you need very detailed metrics, you should have a server report detailing new versions.
	23	+> 6: Les déploiements sont automatiques, basés sur des branches ou tags.
24	24
25		-> 7. Releases are based on tags.
	25	+Si vous ne voulez pas déployez master à chaque fois, vous pouvez créer une branche de production; il n'y a aucune raison pour ne pas faire un script pour cela. Automatisez tout, selon une branche ou un tag qui active un déploiement en production.
26	26
27		-If you tag something, that creates a new release.
	27	+> 7: Les tags sont choisis par les utilisateurs, pas par l'IC
28	28
29		-> 8. Pushed commits are never rebased.
	29	+Un utilisateur choisis un tag et, basé sur ça, l'IC fera l'action. Pas l'inverse. Il ne faut pas que l'IC modifie le dépôt. Si vous avez besoin de métriques détaillées, vous devez avoir un serveur de rapport qui détaille chaque nouvelle versions.
30	30
31		-If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking. We sometimes sin against this rule ourselves when we ask a contributor to squash and rebase at the end of a review process to make something easier to revert. But in general the guideline is: code should be clean, history should be realistic.
	31	+> 8: Les releases sont basées sur des tags.
32	32
33		-> 9. Everyone starts from master, and targets master.
	33	+Si vous taggez quelquechose, ça doit créer une nouvelle release.
34	34
35		-This means you don’t have any long branches. You check out master, build your feature, create your merge request, and target master again. You should do your complete review before you merge, and not have any intermediate stages.
	35	+> 9: Les commits pushés ne doivent jamais être rebasés.
36	36
37		-> 10. Fix bugs in master first and release branches second.
	37	+Si vous pusher sur une branche public, vous ne devez pas rebase ! Cela rendra la revue de code très difficile, les résultats des tests obscurs, et ça casser les cherrypicking. Parfois on peut faire exception à la règle pour demander à un contributeur de squasher et rebase à la fin du process de revue de code pour avoir quelquechose de plus facile à revert. Mais, en général, le code doit être propre, l'historique doit être réaliste.
38	38
39		-If you find a bug, the worst thing you can do is fix it in the just-released version, and not fix it in master. To avoid it, you always fix forward. Fix it in master, then cherry-pick it into another patch-release branch.
	39	+> 10: Tout le monde commence depuis master, et cible master.
40	40
41		-> 11. Commit messages reflect intent.
	41	+Vous ne devez pas avoir de branche trop longues. Vous récuperez master, construisez votre feature, créez votre merge request et ciblez master. Vous devez faire une revue complète de votre code avant merge, et ne pas créer d'étapes intermédiaires.
42	42
43		-You should not only say what you did, but also why you did it. It’s even more useful if you explain why you did this over any other options.
	43	+> 11: Résoudre les bugs de master d'abord, puis des branches de releases ensuite.
	44	+
	45	+Si vous trouvez un bug, la pire chose à faire est de le fixer dans la version tout juste sortie, et d'oubliez de le faire dans master. Pour éviter ça, vous devez toujours corriger le bug sur master, puis cherry-picker dans un branche re patch-release.