Plutôt que de donner les raisons pour lesquelles je préfère Git, voici deux liens vers des comparatifs de CVS que j'aime bien consulter de temps à autre :
- La PEP 374, une discussion afin de choisir le CVS pour le développement de Python ;
- WhyGitIsBetterThanX, un gros argumentaire pro Git.
Gitbuster permet effectivement de la même façon que stg ou mq de réordonner les commits dans l'historique. Cela peut être fait au cours du développement ou après coup.
Une autre façon d'utiliser Gitbuster concerne le cherry-pick d'une branche à l'autre. Par exemple, je travaille sur ma branche feature, et je m'aperçois que certains commits ont vocation à être intégrés immédiatement à master (corrections de bugs par exemple). J'ouvre Gitbuster avec les deux branches en vis-à-vis, et je copie les commits concernés de ma branche feature à ma branche master. Si le cherry-pick échoue pour cause de conflit de merge, Gitbuster propose une interface de résolution avec des informations pour aider à résoudre le conflit : état original du fichier, modifications qui devaient être appliquées par le cherry-pick (mais qui conflictent), état actuel du fichier, solutions à appliquer (ajouter le fichier tel quel, ajouter le fichier en le modifiant, supprimer le fichier).
Gitbuster peut aussi être utilisé pour répondre aux pull request. Le cas d'utilisation est proche de celui du paragraphe précédent, sauf que la branche feature est distante. De la même façon, on pourra mettre les branches en vis-à-vis et intégrer à la branche master les commits proposés.
Pour reprendre l'image d'un des commentaires, Gitbuster permet donc aussi de construire sur le passé, et de suivre certains workflows d'intégration de commits dans une branche.
C'est effectivement un des cas d'utilisation qui m'a poussé à développer Gitbuster. Un cas très similaire : le développeur en télétravail qui préfère travailler la nuit et dormir le jour. Pour éviter les conflits avec son chef de projet, il peut décaller toutes les heures de commit avant de pousser son travail sur le dépôt distant.
Je vois d'autres cas où la modification de l'historique peut s'avérer intéressante, notamment avant d'envoyer ses commits :
- corriger les typos dans les messages de commit
- squasher des commits (prévu dans la roadmap)
- corriger l'adresse email ou du nom du committer (il m'est déjà arrivé de committer sur des projets libres mon adresse email professionnelle)
Je suis assez partisan de l'idée de pouvoir committer très fréquemment, sur des modifications atomiques, avant de revenir éventuellement sur l'historique pour harmoniser et regrouper les commits ayant des sujets communs.
Un autre cas d'utilisation : un chef de projet m'a récemment contacté pour me demander si Gitbuster était capable de supprimer tous les commits n'ayant pas été faits par un auteur donné. Il souhaitait passer un projet propriétaire en libre.
Enfin, pour revenir sur la notion de passé : Gitbuster n'incite pas à modifier l'historique commun, et affiche les commits en grisé s'ils ont déjà été envoyés.
# Quelques comparatifs existants
Posté par mikePerdide . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à -1.
Plutôt que de donner les raisons pour lesquelles je préfère Git, voici deux liens vers des comparatifs de CVS que j'aime bien consulter de temps à autre :
- La PEP 374, une discussion afin de choisir le CVS pour le développement de Python ;
- WhyGitIsBetterThanX, un gros argumentaire pro Git.
[^] # Re: Et les queues ?
Posté par mikePerdide . En réponse à la dépêche Gitbuster II. Évalué à 2.
"Il y a un ticket pour ça" (tm)
[^] # Re: Et les queues ?
Posté par mikePerdide . En réponse à la dépêche Gitbuster II. Évalué à 3.
Gitbuster permet effectivement de la même façon que stg ou mq de réordonner les commits dans l'historique. Cela peut être fait au cours du développement ou après coup.
Une autre façon d'utiliser Gitbuster concerne le cherry-pick d'une branche à l'autre. Par exemple, je travaille sur ma branche feature, et je m'aperçois que certains commits ont vocation à être intégrés immédiatement à master (corrections de bugs par exemple). J'ouvre Gitbuster avec les deux branches en vis-à-vis, et je copie les commits concernés de ma branche feature à ma branche master. Si le cherry-pick échoue pour cause de conflit de merge, Gitbuster propose une interface de résolution avec des informations pour aider à résoudre le conflit : état original du fichier, modifications qui devaient être appliquées par le cherry-pick (mais qui conflictent), état actuel du fichier, solutions à appliquer (ajouter le fichier tel quel, ajouter le fichier en le modifiant, supprimer le fichier).
Gitbuster peut aussi être utilisé pour répondre aux pull request. Le cas d'utilisation est proche de celui du paragraphe précédent, sauf que la branche feature est distante. De la même façon, on pourra mettre les branches en vis-à-vis et intégrer à la branche master les commits proposés.
Pour reprendre l'image d'un des commentaires, Gitbuster permet donc aussi de construire sur le passé, et de suivre certains workflows d'intégration de commits dans une branche.
[^] # Re:Métadonnées
Posté par mikePerdide . En réponse à la dépêche Gitbuster II. Évalué à 10.
C'est effectivement un des cas d'utilisation qui m'a poussé à développer Gitbuster. Un cas très similaire : le développeur en télétravail qui préfère travailler la nuit et dormir le jour. Pour éviter les conflits avec son chef de projet, il peut décaller toutes les heures de commit avant de pousser son travail sur le dépôt distant.
Je vois d'autres cas où la modification de l'historique peut s'avérer intéressante, notamment avant d'envoyer ses commits :
- corriger les typos dans les messages de commit
- squasher des commits (prévu dans la roadmap)
- corriger l'adresse email ou du nom du committer (il m'est déjà arrivé de committer sur des projets libres mon adresse email professionnelle)
Je suis assez partisan de l'idée de pouvoir committer très fréquemment, sur des modifications atomiques, avant de revenir éventuellement sur l'historique pour harmoniser et regrouper les commits ayant des sujets communs.
Un autre cas d'utilisation : un chef de projet m'a récemment contacté pour me demander si Gitbuster était capable de supprimer tous les commits n'ayant pas été faits par un auteur donné. Il souhaitait passer un projet propriétaire en libre.
Enfin, pour revenir sur la notion de passé : Gitbuster n'incite pas à modifier l'historique commun, et affiche les commits en grisé s'ils ont déjà été envoyés.