2017-09-29 10 views
0

Je viens d'essayer de suivre these Atlassian Bitbucket instructions pour résoudre les conflits de fusion et constaté qu'il ne fonctionne pas correctement.Instructions Git Merge ne fonctionnent pas comme prévu

Si ces instructions sont suivies, il arrive que des changements dans la branche "develop" écrasent les changements effectués dans la "branche source".

Par exemple, dans un fichier Swift (notez que ces deux versions et les numéros de ligne sont inclus):

c'est de développer et git essaie de garder celui-ci.

required init?(map: Map){ // 67 
    super.init()   // 68 
    mapping(map: map)  // 69 
    if origin == nil { // 70 
     origin = ""  // 71 
    }      // 72 
}       // 73 

ce fichier source est

required init?(map: Map){ // 67 
    super.init()   // 68 
    mapping(map: map)  // 69 
}       // 70 

Comme vous pouvez voir la « branche source » a ces lignes de code supprimé mais git pense « développer » devrait les ajouter à nouveau. (à juste titre, si je dis développer développer pour fusionner dans ma branche selon les instructions Atlassian)

Ceci est incorrect car tout dans ma branche devrait essayer d'écraser tous les fichiers/changements dans la branche de développement et soulever un conflit s'il y a un.

Est-ce que je vais au noob ou ces instructions sont-elles incorrectes?

Est-ce que quelqu'un peut également suggérer la résolution de conflit qui utilise ma branche comme l'être tout et finir?

(je pense que je dois avoir « développer » vérifié puis fusionner la « branche de fonction » dans ce. Obtenez le sentiment que ce passe l'étape de la demande de traction mais ... ne veulent pas)

+0

Non, nous ne pouvons « voir » que tout a été supprimé de ce que vous montrez. Pour voir cela, nous avons besoin de savoir ce qui a changé et où, ainsi que la branche qui fusionne dans quelle branche. La seule fois où l'on obtient généralement des conflits de fusion, c'est quand des modifications ont été apportées aux mêmes lignes de code ou aux lignes adjacentes. – crashmstr

+0

@crashmstr J'ai ajouté des numéros de ligne et divisé les deux fichiers en blocs de code séparés pour plus de clarté. – user1567453

+0

Fusionnez-vous 'source' dans' develop' et ce fichier et ces lignes * n'ont pas changé * dans 'develop'? En outre, si vous allez faire une demande de tirage, vous ne les fusionnez pas manuellement. La demande de traction le fera après approbation. – crashmstr

Répondre

0

Cela était dû au fait que la branche de développement avait fait l'objet d'une "réversion" après que la branche source ait été ramifiée et extraite. Cela a donné à la branche de développement une priorité plus élevée dans l'histoire et git rejettera donc tout changement dans ma branche. (tous les fichiers 20 et qui sait combien de lignes de code)

En parlant avec un collègue, il s'avère que la réversion a été effectuée en raison d'une fusion accidentelle dans l'origine/développer.

Règle simple - Ne pas utiliser "reverse commit to" si d'autres développeurs ont des branches avec des modifications.

Faire que chaque changement^écrase seul fait à d'autres développeurs branches locales lorsqu'elles fusionnent XD