git checkouta la --ourspossibilité d'extraire la version du fichier que vous aviez localement (par opposition à --theirs, qui est la version que vous avez extraite). Vous pouvez passer .à git checkoutpour lui dire de tout vérifier dans l'arbre. Ensuite, vous devez marquer les conflits comme résolus, ce que vous pouvez faire git addet valider votre travail une fois terminé:
git checkout --ours . # checkout our local version of all files
git add -u # mark all conflicted files as merged
git commit # commit the merge
Notez le .dans la git checkoutcommande. C'est très important et facile à manquer. git checkouta deux modes; celui dans lequel il change de branche et celui dans lequel il extrait les fichiers de l'index dans la copie de travail (en les tirant parfois dans l'index d'une autre révision en premier). La façon dont il se distingue est de savoir si vous avez passé un nom de fichier; si vous n'avez pas passé de nom de fichier, il essaie de changer de branche (mais si vous ne passez pas non plus de branche, il essaiera simplement de vérifier à nouveau la branche actuelle), mais il refuse de le faire s'il y a des fichiers modifiés que cela se produirait. Donc, si vous voulez un comportement qui écrasera les fichiers existants, vous devez passer .ou un nom de fichier afin d'obtenir le deuxième comportement git checkout.
C'est aussi une bonne habitude d'avoir, en passant un nom de fichier, pour le compenser avec --, comme git checkout --ours -- <filename>. Si vous ne le faites pas et que le nom de fichier correspond au nom d'une branche ou d'une balise, Git pensera que vous voulez vérifier cette révision, au lieu de vérifier ce nom de fichier, et utilisez donc la première forme de la checkoutcommande .
Je vais développer un peu sur la façon dont les conflits et la fusion fonctionnent dans Git. Lorsque vous fusionnez dans le code de quelqu'un d'autre (ce qui se produit également lors d'un pull; un pull est essentiellement un fetch suivi d'une fusion), il y a peu de situations possibles.
Le plus simple est que vous êtes sur la même révision. Dans ce cas, vous êtes "déjà à jour" et rien ne se passe.
Une autre possibilité est que leur révision soit simplement une descendante de la vôtre, auquel cas vous aurez par défaut une "fusion rapide", dans laquelle votre HEADest juste mis à jour à leur commit, sans fusion se produisant (cela peut être désactivé si vous vraiment envie d'enregistrer une fusion, en utilisant --no-ff).
Ensuite, vous entrez dans les situations dans lesquelles vous devez réellement fusionner deux révisions. Dans ce cas, deux résultats sont possibles. La première est que la fusion se déroule proprement; toutes les modifications se trouvent dans des fichiers différents, ou sont dans les mêmes fichiers mais suffisamment éloignés pour que les deux ensembles de modifications puissent être appliqués sans problème. Par défaut, lorsqu'une fusion propre se produit, elle est automatiquement validée, mais vous pouvez la désactiver --no-commitsi vous devez la modifier au préalable (par exemple, si vous renommez la fonction fooen bar, et que quelqu'un d'autre ajoute un nouveau code qui appelle foo, il fusionnera proprement , mais produisez un arbre cassé, donc vous voudrez peut-être le nettoyer dans le cadre de la validation de fusion afin d'éviter d'avoir des validations cassées).
La dernière possibilité est qu'il y ait une véritable fusion et qu'il y ait des conflits. Dans ce cas, Git fera autant de la fusion comme il peut, et les fichiers de produire avec des marqueurs de conflit ( <<<<<<<, =======et >>>>>>>) dans votre copie de travail. Dans l'index (également connu sous le nom de "zone de transit"; l'endroit où les fichiers sont stockés git addavant de les valider), vous aurez 3 versions de chaque fichier avec des conflits; il existe la version d'origine du fichier de l'ancêtre des deux branches que vous fusionnez, la version de HEAD(votre côté de la fusion) et la version de la branche distante.
Afin de résoudre le conflit, vous pouvez soit modifier le fichier qui se trouve dans votre copie de travail, supprimer les marqueurs de conflit et corriger le code afin qu'il fonctionne. Vous pouvez également extraire la version de l'un ou l'autre côté de la fusion à l'aide de git checkout --oursou git checkout --theirs. Une fois que vous avez placé le fichier dans l'état souhaité, vous indiquez que vous avez terminé de fusionner le fichier et qu'il est prêt à être validé à l'aide de git add, puis vous pouvez valider la fusion avec git commit.