Comme chacun donne son workflow, je vais donner le miens.
Je garde une branche master sur la quelle je ne travail pas directement. Je crée des branches pour tout et n'importe quoi. Quand je veux les fusionner je commence par faire un rebase -i pour nettoyer mon historique. Généralement je me retrouve avec 1 ou 2 commits et avec des messages de commits plus long, c'est l'occasion d'expliquer ce que j'ai fais. Ensuite je merge dans master.
Je suis loin d'être un spécialiste de git. Je sais que gitflow reproduit à peu près ce shemas là, mais j'ai pas pris le temps de regarder comment il fonctionne et ça ne représente pas un gros problème de faire ça à la main (au moins le temps de comprendre bien ce que l'on fait et pourquoi).
Ça doit permettre d'avoir un historique plus lisible et plus facile à annuler avec moins de commits.
Avec ça j'essaie d'augmenter un peu ma fréquence de commit pour avoir une meilleure granularité lorsque je fais mon rebase interactif et je ne m'embête pas fréquemment pour le message de commit parce que je sais que je reviendrais dessus quoi qu'il arrive.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Mon workflow
Posté par barmic . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 3.
Comme chacun donne son workflow, je vais donner le miens.
Je garde une branche master sur la quelle je ne travail pas directement. Je crée des branches pour tout et n'importe quoi. Quand je veux les fusionner je commence par faire un
rebase -ipour nettoyer mon historique. Généralement je me retrouve avec 1 ou 2 commits et avec des messages de commits plus long, c'est l'occasion d'expliquer ce que j'ai fais. Ensuite je merge dans master.Je suis loin d'être un spécialiste de git. Je sais que gitflow reproduit à peu près ce shemas là, mais j'ai pas pris le temps de regarder comment il fonctionne et ça ne représente pas un gros problème de faire ça à la main (au moins le temps de comprendre bien ce que l'on fait et pourquoi).
Ça doit permettre d'avoir un historique plus lisible et plus facile à annuler avec moins de commits.
Avec ça j'essaie d'augmenter un peu ma fréquence de commit pour avoir une meilleure granularité lorsque je fais mon rebase interactif et je ne m'embête pas fréquemment pour le message de commit parce que je sais que je reviendrais dessus quoi qu'il arrive.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)