Discussion :

[tanaka59]

Bonjour,

Dans le cadre d'activités liées au reporting, je vais devoir envoyer des données sur une file "master". De cette file master combien de file "secondaire" conseillez vous d'avoir ?

Je vais faire simple :

la master = projet principal
file 2 = modifications que va récupérer la master
file 3 = modifications que va récupérer la master ou la file 2 ?

Comme pouvez le voir j'ai du mal à voir comment ne pas mettre un bazar sans nom au delà de 2 branche , je suis régulièrement confronté à des branches introuvables, fantômes, on ne sait pas si c'est la file 2 ou la master qui va récupérer en cas de fusion ...

J'utilise du Git GUI

Merci de vos lumières

[Marco46]

On est d'accord que ce que tu appelles une "file" c'est une branche ? Je ne sais pas d'où tu sors ce terme.

Pour les branches il faut distinguer les branches de collaboration des branches de travail.

Une branche de collaboration c'est une branche qui sert de cible à une fusion (merge) et qui est publiée aux autres collaborateurs sur un bare repository (ton dépôt distant GitHub / GitLab). Par convention elle est nommée master. On en parle aussi comme du tronc commun (trunk chez SVN) On peut en avoir plusieurs dans un projet quand on gère le périmètre fonctionnel de son projet avec des branches.

Une branche de travail c'est une branche qui est exclusive à un développeur et qui lui sert à préparer une contribution. Elle n'a pas pour destin de continuer à exister après avoir été fusionnée dans ta master.

Donc de quoi parles-tu ?

[tanaka59]

Bonjour

On est d'accord que ce que tu appelles une "file" c'est une branche ?

Oui , oui quand je parle de file = branche

[Marco46]

Du coup tu parles de branches de collaboration ou de travail ? C'est du reporting à quel type de personnel ? Pourquoi faire ?

Pour les branches de travail, la seule limite est technique, plus tu as de branches plus ça va rendre ton dépôt obèse et ça va impacter la vitesse d'exécution de ton CLI mais on parle de quantités énormes, en général tu as rarement plus que les doigts d'une main de branche de travail en cours et quand elles sont mergées tu peux les supprimer. De même pour la code review une fois la review effectuée il n'y aucune raison de garder la branche.

Pour ce qui est des branches de collaboration il est fortement conseillé d'en avoir une seule et unique, mais c'est pas si simple que ça à faire.

[tanaka59]

Du coup tu parles de branches de collaboration ou de travail ?

Pour le travail

C'est du reporting à quel type de personnel ?

Les clients finaux sont , contrôle de gestion , marketing, comptabilité , finance .

Pourquoi faire ?

Je souhaite conserver des trames de fond en cas de besoin 9 + historiser les versions d'un reporting données . Tel version a tel moment , on intègre telle nouvelle présentation à tel moment.

[Marco46]

Les clients finaux sont , contrôle de gestion , marketing, comptabilité , finance .

En quoi le nombre de branches de travail poussée sur un dépôt à un instant va les intéresser ?

Tu penses que ça représente quoi comme indicateur ?

Je souhaite conserver des trames de fond en cas de besoin 9 + historiser les versions d'un reporting données . Tel version a tel moment , on intègre telle nouvelle présentation à tel moment.

J'ai relu plusieurs fois mais rien à faire je ne comprends rien à cette phrase désolé. C'est juste lunaire.

[tanaka59]

En quoi le nombre de branches de travail poussée sur un dépôt à un instant va les intéresser ?

Exemple : la dsi a la main sur la master, une personne de la dsi crée une branche depuis la master pour modifier un report. Un personne du marketing demande aussi une branche . Du coup la master a 2 branches .

Tu penses que ça représente quoi comme indicateur ?

Je parle de venir stocker des trames de fond de reporting via l'outil de versioning ... et non pas de faire un reporting de ce qu'on commit ou du nombre de version ...

J'ai relu plusieurs fois mais rien à faire je ne comprends rien à cette phrase désolé. C'est juste lunaire.

Exemple concret : pouvoir conserver un versioning pour des fichiers PBIX avec macro à destination d'une DAF ou d'un service marketing. La DAF dirait "sortez moi la version machin truc, pour calculer tel CA" >>> y'a plus qu'a sortir le PBIX et modifier ce qui est nécessaire.

Dans le domaine de la BI quand on fait du reporting il est très important de pouvoir historiser ces versions . Question de traçabilité pour constater les évolutions technique.

[Marco46]

En fait tu veux te servir de Git comme d'une GED ?

Je te le déconseille vivement, Git est conçu pour gérer des fichiers textes, or un XSLM c'est une archive zip qui contient du XML. Tu n'arriveras pas à gérer les conflits proprement de cette manière.

Bref, ce n'est juste pas le bon outil. Déjà que la plupart des devs a du mal avec et est mal formé, demander à des personnels non-technique de gérer ça c'est mission impossible.

Sinon une version dans Git c'est une révision, donc un commit identifié par son SHA-1 que l'on peut aliaser avec un tag. Ce n'est pas une branche. Une branche est une ligne de dev, pas une version.

Pour ta question de branches quand ton administrateur crée une branche pour ajouter / modifier un fichier, il va ensuite merger sa branche dans master et la branche de travail devra être supprimée, elle n'a plus aucune raison d'être.

[tanaka59]

En fait tu veux te servir de Git comme d'une GED ?

Tout a fait

Sinon , on part sur autre chose ... Un Alfresco ??

[Marco46]

Je sais pas ya plein d'outils mais clairement Git n'est pas fait pour ça, c'est fait pour gérer les versions de fichiers textes (codes sources, configs, etc ...).