Discussion :

[tchize_]

Bonjour à tous.

Je suis face à la situation suivante.

Une équipe principale maintient un service intranet en PHP,avec connexion base de données de type "mission critical". En général, le service PHP concerné étant luis aussi critique, il importe parfois de faire des correction "à l'arrache" directement sur le serveur.

Suite à des accords intenes, un personnes d'une autre équipe doit pouvoir faire des modifications "mineures" sur cette interface, modification qui arriveront sur le serveur après revue.

Nous somme parti sur l'idée d'un subversion. Nous avons gardé le trunk pour le serveur principal, et une branche sidework pour cette personne. Avec l'idée que cette personnes fait régulièrement des merges trunk => sidework pour s'assurer que tout fonctionne et, au final, un reintegrate (sidework => trunk) quand son code passe la revue et arrive en production.

Sur papier, c'est beau mais, gros HIC. Cette personnes doit pouvoir continuer à travailler sur sa branche après réintégration. Car elle travaille, en général, sur plusieurs projets à la fois, donc elle dois pouvoir continuer sur les parties non finies.

Je rajoute qu'on parle d'une personne qui n'est pas un programmeur à la base et on ne peux pas lui demander de maitriser les subversion, cvs et cie.

Donc là on s'est arrangé avec lui "tu finis les deux projets en cours et on réintégrera tout, après on verra comment traiter ce problème".


Pour résumer, on cherche à pouvoir avoir ce genre de chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 branche Y    main     branche X 
               |
               v1
               |
               v2
               | \
               |  ------>°
               |         |
               |         X1 
               v3        |
              /| \       |
     °<------- |  ----->°X2
     |         |         |
     |         |         X3
     |         |        /|
     |        °v4<------ |
     Y1        |         |
     |         v5        |
     |         | \       |
     |        /|  ----->°X4
    °Y2<------ |         |
     |         |         X5
     |         |         |
     Y3        |        /|
     |        °v6<------ |
     |        /|         |
    °Y4<------ |         |
     |         |         |
      \        |         |
        ----->°v7        |

Ce n'est pas possible avec subversion puisque le reintegrate marque la fin d'une branche. J'espérais que, puisque GIT est plus orienté branches que subversion, on puisse y arriver. Si oui, quelles seraient les suites de commandes à chaque étape?

J'espère que GIT serait une solution envisageable, on pourrais en profiter pour passer par des pull request pour faire les revues (au prix où coûte stash de atlasian, on va pas être ruinés), mais j'espère que vous pourrez me confirmer cela

Merci.

[Philippe Bastiani]

Git permet de travailler ainsi... Les commandes de base seront
- git pull (ou fetch/rebase) pour la synchro locale avec e dépot distant,
- git merge pour merger 2 branches (ou git cherry-pick pour merger unitairement un commit)
- git push pour synchroniser le dépot distant.

Sans oublier
-git checkout pour passer de branche en branche localement (la personne peut effecftivement travailer localement sur plusieurs branche avec la possibilité de mettre son travail dans un bac à sable 'git stash').

Git est certe fonctionnellement très orienté branche... mais finalement en interne Git se base sur les commits ! C'est pour celà que la chose est possible.

Je t'encourage à lire cet article de référence. L'auteur de l'article est aussi l'auteur de l'extension git-flow qui repose sur cette approche de branches.

Attention: git pour un non informaticien risque d'être difficile ! Toutes ces commandes ont des subtilités...

a+
Philippe

[tchize_]

oui, mais malheureusement, il nous faut un système ou un peux mettre en place une procédure claire. La personne n'aura pas à zapper d'une branche à l'autre. Elle travaillera sur sa propre branche (checkout, commits) et on fournira l'assistance pour les merge.

Ce qui m'importe, c'est d'être certains qu'on peux sans soucis merger dans les deux sens, à tout moment (ramener le main dans sa branche, ramener sa branche à l'état actuel dans le main, et qu'il puisse continuer malgrés tout sur sa branche). A l'état actuel, avec subversion, on tue sa branche lors du reintegrate.

[tchize_]

Salut,

je reviens sur la chose. J'ai lut l'article sur git-flow, mais je m'inquiète. Il ne mentionne pas si il est possible de continuer une branche après l'avoir mergée.

[Philippe Bastiani]

oui, mais malheureusement, il nous faut un système ou un peux mettre en place une procédure claire. La personne n'aura pas à zapper d'une branche à l'autre. Elle travaillera sur sa propre branche (checkout, commits) et on fournira l'assistance pour les merge.

Ce qui m'importe, c'est d'être certains qu'on peux sans soucis merger dans les deux sens, à tout moment (ramener le main dans sa branche, ramener sa branche à l'état actuel dans le main, et qu'il puisse continuer malgrés tout sur sa branche). A l'état actuel, avec subversion, on tue sa branche lors du reintegrate.

D'où l'intéret d'une extention du type git-flow... qui automatise le process ! Mais, Tu peux aller encore plus loin: les extensions git s'intègre au git de base. Tu pourras alors créer ta propre extension sous forme de script (shell, ruby, ...) ou commande.

Tu noteras: le checkout git n'est pas un checkout svn... A savoir: ici, le checkout agit sur ton repo local (et, non le repo partagé); et, te permet de passer d'une branche locale à une autre branche locale sans passer par le repo central (i.e. en mode déconnecté et donc sans synchro). Dans ton repot local, l'ensemble des fichiers sont en accès r/w.

je reviens sur la chose. J'ai lut l'article sur git-flow, mais je m'inquiète. Il ne mentionne pas si il est possible de continuer une branche après l'avoir mergée.

Pour t'en convaincre regardes la branche dévelop des figure 1 et 3... Comme dit plus haut, les branches ne sont qu'un ensemble de commits; et, un merge n'est qu'un cherry-pick automatisé.

Tu es ici dans un système décentralisé. A savoir:
- chacun de tes utilisateurs vont faire un clone du repos central (repo d'origine).
- chacun de tes utilisateurs disposera, dans son repo local, d'une vue sur les objets du repos d'origine
- chaque repos local peut vivre sa vie...
- chaque utilisateur est sur une branche
- cette branche peut référencer une branche partagée; ou, être purement locale.
- pour partager son travail, il est nécessaire de se synchronizer avec le repo d'origine

Admettons, que ton repo partagé
- dispose d'un branche A
- que la master soit ta branche de prod
Tu pourras avoir
- un ou plusieurs utilisateurs travaillant sur des branches locales de A
- un super-utilisateur, qui va faire les merges sur la master et la branche A

Chacune des branches locales vont alors nécessairement diverger : chacun de tes utilisateurs peut travailler et commiter indépendemment des autres sur sa propre branche locale.
Un de tes utilisateurs va pousser ses commits sur le repo partagé.
Un deuxième utilisateur veut pousser ces modifs... il devra, tout d'abord récupérer le travail qui a été poussé avant de pouvoir à son tour pousser ses modifs (celà implique un merge et la résolution éventuelle de conflits).
De même, ton super-utilisateur pourra a tout moment
- faire un merge de sa propre branche A sur la master (après avoir synchonisé sa branche locale avec l'ensemble des commits qui ont été poussés)
- faire des merges entre branches... que les utilisateurs pourront récupérer.

En résumé tu te retrouves avec un système décentralisé (chaque repo peut vivre sa vie) mais tu adoptes un process centralisé (i.e un super-utilisateur gère la vies des branches; chaque utilisateur travaille sur une copie et a en charge de se synchroniser avec le repo central). Ce dernier point est essentiel à comprendre car il diffère de svn!

Voilà,
a+
Philippe

[Philippe Bastiani]

Après sans aller jusqu'à git-flow tu peux affiner le process de tes branches X et Y dans le cas
- où plusieurs utilisateurs travaillent sur une même branche
- où tu souhaites avoir plusieurs merges et conserver tes branches X et Y du repos origin saines.

=> tu peux imposer à tes utilisateurs de travailler sur des branches features purement locales qu'ils vont synchroniser au cours de leur travail avec les branches locales X ou Y (entre chaque merge sur X/Y ils procèderont à des rebase); il faudra biensûr, qu'ils synchronisent régulièrement leurs branches locales X/Y avec le dépos d'origin...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
synchro X régulier (a faire avant de créer la branche et en cours de dev)
>git pull --ff-only origin X
ou 
>git pull --rebase origin X
 
création branche feature
>git checkout -b feature X
on sauvegarde son travail
>git add/commit...
synchro régulier local de X et feature
>git rebase X
Dépot du travail sur X local lorsque l'on est prêt à partager un partie de son travail
>git checkout X
>git merge --no-ff feature
partage de X
>git push origin X
 
Accessoirement à la fin du dev:
>git branch -d feature

Tout celà tu peux le mettre dans des scripts... Il restera la difficulté des merge/rebase qui peuvent aboutir à des conflits.

Au final,
- git impose plus de responsabilité aux utilisateurs dans le sens où ils ne peuvent partager des objets incompatibles
- le chef de projet peut imposer aux utilisateurs de ne partager que ce qui est réellement partageable à l'aide de branches locales par feature/fix...

a+
Philippe