La je sèche un peu... entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?
Ce n’est pas obligatoire de tagger, un tag est juste un raccourci sur un commit (parce que c’est plus facile d’utiliser, par exemple, v2.1 que 6b0a7b9a2d489b438a0357587823b60e6c2f1387).
Par contre un tag pourrait effectivement être utilisé pour indiquer qu’une branche doit être mergée... soit en « avance rapide », s’il n’y a pas de conflit (ça peut donc se faire automatiquement en utilisant les "hooks" (des scripts qui se lancent automatiquement sur certaines actions sur un dépôt)).
S’il y a des conflits (selon l’algorithme utilisé, y’en a pas mal différents...), il faut que quelqu’un édite les marqueurs de conflit dans les fichiers afin que le merge aboutisse. Cette personne peut aussi dire : « ta branche je veux pas me faire chier à la merger, alors attends que je finisse de merger les autres branches de tes petits camarades qui codent pas comme des gorets, puis tu mergeras ensuite à partir de la nouvelle version pour régler tes conflits toi-même. » ;) Et abandonner le merge de cette branche.
Pour le nom des branches je dirais que les deux possibilités évidentes pour créer des branches c’est soit une branche par développeur, soit une branche par fonctionnalité. On peut bien sûr toujours aussi imaginer faire les deux... et d’autres.
Avec une branche par fonctionnalité, si deux dév travaillent sur une même fonctionnalité, si les deux push dessus depuis leur propre copie locale, c’est le premier qui est servi :)
Imagine le workflow suivant d’un développeur :
Début de journée, je mets à jour ma branche locale NouveauModule depuis le branche distante, disons qu’elle n’a pas changé depuis hier, je suis à jour. C’est bien, au boulot.
Je travaille sur cette branche, au bout d’un moment c’est prêt, j’ai fini ma tâche pour cette fonctionnalité, je nettoie éventuellement mon historique (rebase), parce que j’ai pu commiter localement par commodité pour X raisons, autant regrouper (fixup) les changements de ces commits, souvent peu utiles pour l’historique du projet... Et je push sur le dépôt de référence.
Et là paf, merde, entre temps un autre dév. a pushé son travail sur cette même branche. La branche distante étant maintenant « en avance de 1 commit par rapport à ma branche locale » je ne peux pas pousser comme ça (je pourrais forcer avec --force, si le serveur le permet, ce n’est pas recommandé, c’est pas gentil...), je dois donc d’abord merger moi même (en pullant) son travail, là pareil, si le collègue en question a travaillé sur d’autres fichiers, où à d’autres endroits dans le fichier et que l’algorithme de git est capable de le faire automatiquement il le fera, je pourrait ensuite pousser mon propre travail. Sinon suite au pull je me retrouve dans un état intermédiaire, avec les fichiers « marqués », là il faut éditer les fichiers pour les réconcilier, et le merge peut se terminer. Ensuite je pourrai pousser.
Une autre possibilité que le merge dans ce cas, c’est le rebase. Qui consiste (là encore j’espère qu’on me corrigera si je me trompe), à au lieu de créer un « commit de merge », à placer tous (ou une partie) de nos commits à partir duquel on dérive de la branche distante, en haut en cette branche. Donc il d’y a plus de « branchement », notre branche locale peut être pousser car elle représente la version distante (avec les travail de notre collègue) + seulement nos commits depuis, qui suivent quoi...
Je pense qu’on peut se contenter d’une seule des commandes, entre merge et rebase, pour un workflow défini... (hors le rebase qu’on peut faire soit même en local, pour modifier son historique avant de « publier » ses changements). Il y a des subtilités dont je ne pense pas avoir fait le tour et fonctionnellement elles me semblent équivalentes, elles n’aboutiront simplement pas au même historique. Mais le résultat, une fusion de branche, sera le même quant au contenu des fichiers à la fin de l’opération.
Et oui, du coup quand NouveauModule est de l’histoire ancienne, on supprime généralement la branche pour créer la branche NouveauModule2, que le nom des branches soit parlant. L’historique ne sera pas perdu, mais fusionné.
[^] # Re: git
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2. Dernière modification le 26 novembre 2016 à 03:10.
Ce n’est pas obligatoire de tagger, un tag est juste un raccourci sur un commit (parce que c’est plus facile d’utiliser, par exemple, v2.1 que 6b0a7b9a2d489b438a0357587823b60e6c2f1387).
Par contre un tag pourrait effectivement être utilisé pour indiquer qu’une branche doit être mergée... soit en « avance rapide », s’il n’y a pas de conflit (ça peut donc se faire automatiquement en utilisant les "hooks" (des scripts qui se lancent automatiquement sur certaines actions sur un dépôt)).
S’il y a des conflits (selon l’algorithme utilisé, y’en a pas mal différents...), il faut que quelqu’un édite les marqueurs de conflit dans les fichiers afin que le merge aboutisse. Cette personne peut aussi dire : « ta branche je veux pas me faire chier à la merger, alors attends que je finisse de merger les autres branches de tes petits camarades qui codent pas comme des gorets, puis tu mergeras ensuite à partir de la nouvelle version pour régler tes conflits toi-même. » ;) Et abandonner le merge de cette branche.
Pour le nom des branches je dirais que les deux possibilités évidentes pour créer des branches c’est soit une branche par développeur, soit une branche par fonctionnalité. On peut bien sûr toujours aussi imaginer faire les deux... et d’autres.
Avec une branche par fonctionnalité, si deux dév travaillent sur une même fonctionnalité, si les deux push dessus depuis leur propre copie locale, c’est le premier qui est servi :)
Imagine le workflow suivant d’un développeur :
Début de journée, je mets à jour ma branche locale NouveauModule depuis le branche distante, disons qu’elle n’a pas changé depuis hier, je suis à jour. C’est bien, au boulot.
Je travaille sur cette branche, au bout d’un moment c’est prêt, j’ai fini ma tâche pour cette fonctionnalité, je nettoie éventuellement mon historique (rebase), parce que j’ai pu commiter localement par commodité pour X raisons, autant regrouper (fixup) les changements de ces commits, souvent peu utiles pour l’historique du projet... Et je push sur le dépôt de référence.
Et là paf, merde, entre temps un autre dév. a pushé son travail sur cette même branche. La branche distante étant maintenant « en avance de 1 commit par rapport à ma branche locale » je ne peux pas pousser comme ça (je pourrais forcer avec --force, si le serveur le permet, ce n’est pas recommandé, c’est pas gentil...), je dois donc d’abord merger moi même (en pullant) son travail, là pareil, si le collègue en question a travaillé sur d’autres fichiers, où à d’autres endroits dans le fichier et que l’algorithme de git est capable de le faire automatiquement il le fera, je pourrait ensuite pousser mon propre travail. Sinon suite au pull je me retrouve dans un état intermédiaire, avec les fichiers « marqués », là il faut éditer les fichiers pour les réconcilier, et le merge peut se terminer. Ensuite je pourrai pousser.
Une autre possibilité que le merge dans ce cas, c’est le rebase. Qui consiste (là encore j’espère qu’on me corrigera si je me trompe), à au lieu de créer un « commit de merge », à placer tous (ou une partie) de nos commits à partir duquel on dérive de la branche distante, en haut en cette branche. Donc il d’y a plus de « branchement », notre branche locale peut être pousser car elle représente la version distante (avec les travail de notre collègue) + seulement nos commits depuis, qui suivent quoi...
Je pense qu’on peut se contenter d’une seule des commandes, entre merge et rebase, pour un workflow défini... (hors le rebase qu’on peut faire soit même en local, pour modifier son historique avant de « publier » ses changements). Il y a des subtilités dont je ne pense pas avoir fait le tour et fonctionnellement elles me semblent équivalentes, elles n’aboutiront simplement pas au même historique. Mais le résultat, une fusion de branche, sera le même quant au contenu des fichiers à la fin de l’opération.
Et oui, du coup quand NouveauModule est de l’histoire ancienne, on supprime généralement la branche pour créer la branche NouveauModule2, que le nom des branches soit parlant. L’historique ne sera pas perdu, mais fusionné.