"update" doit faire un fast-forward, sinon cela entraîne un merge qui pourris l'historique.
L'option --rebase t'évite un merge. Par contre, en cas de conflit, tu es interrompu au milieu de ton rebase.
Du coup, il vaudrait mieux squasher avant:
Ton publish doit comporter un git rebase, avant le push,
Avec svn si tu es empêché de commiter tu updates. Tu n'updates pas avant. Je suppose que tu veux rebaser pour les fichiers disjoints et échouer s'il y a un conflit.
IJe n'ai pas vu d'option de rebase qui le permettrait.
En fait, je pensais plus que tu proposerais une série d'alias précis qui correspond à différentes étapes de ton propre flow.
Je pourrais présenter les commandes enchainées. Mais l'intérêt de l'outiller me parait superflu étant donné qu'il est finalement assez simple.
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
L'option --rebase t'évite un merge. Par contre, en cas de conflit, tu es interrompu au milieu de ton rebase.
Du coup, il vaudrait mieux squasher avant:
Avec svn si tu es empêché de commiter tu updates. Tu n'updates pas avant. Je suppose que tu veux rebaser pour les fichiers disjoints et échouer s'il y a un conflit.
IJe n'ai pas vu d'option de rebase qui le permettrait.