Considérez les marqueurs de conflit. c'est à dire:
<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD
Dans le cas particulier qui m'a motivé à poster cette question, le responsable de l'équipe venait de réaliser une fusion de l'amont vers notre agence, et dans certains cas les avait laissés, en commentaires, comme une sorte de documentation sur ce qui venait d'être résolu. Il l'a laissé dans un état compilé, les tests ont réussi, donc ce n'est pas aussi mauvais qu'on pourrait le penser.
Cependant, instinctivement, je me suis vraiment opposé à cela, mais étant moi-même défenseur des démons, je peux voir pourquoi il aurait pu le faire:
- car il met en évidence pour les autres développeurs d'équipe ce qui a changé à la suite de la fusion.
- parce que ceux qui sont plus experts avec les morceaux de code particuliers peuvent alors répondre aux préoccupations illustrées par les commentaires afin qu'il n'ait pas à deviner.
- car la fusion en amont est une vraie douleur et il peut être difficile de justifier le temps de tout résoudre correctement et complètement, donc un avis FIXME semi-complet est nécessaire, alors pourquoi ne pas utiliser le conflit d'origine comme commentaire pour documenter cela.
Mon objection était instinctive, mais j'aimerais pouvoir la justifier rationnellement, ou voir ma position plus sagement. Quelqu'un peut-il me donner des exemples ou même des expériences où les gens ont eu du mal avec quelqu'un d'autre à faire cela et / ou les raisons pour lesquelles c'est une mauvaise pratique (ou vous pouvez jouer l'avocat du diable et le soutenir).
Ma propre préoccupation immédiate était que cela aurait clairement été ennuyeux si j'avais édité l'un des fichiers concernés, retiré les modifications, obtenu de véritables conflits, mais aussi intégré les commentaires. J'aurais alors eu un dossier très salissant. Heureusement, cela ne s'est pas produit.
// MatrixFrog 10/25/2011: Updated this function to fix bug #1234
. Si je vois des trucs comme ça, je pense: "Quoi? C'est pour ça git blame
!"