Fusionner avec écrasement forcé dans Git

La plupart du temps, lorsque nous appliquons git push ou git merge, un conflit finit par se produire. Dans certains cas, la solution au conflit de fusion est aussi simple que de supprimer les modifications locales ou les modifications de branche distantes ou autres.

Lorsque Git ne parvient pas à comprendre comment fusionner deux modifications conflictuelles, il crée une demande de conflit. Une demande de conflit est un type spécial de correctif qui décrit le problème et contient les deux côtés du changement conflictuel (le nôtre et le leur) et le résultat de la tentative de fusion.

Tout en travaillant sur les mêmes fichiers par deux membres d’équipes et en ayant un conflit dans ce fichier, Git applique le conflit à notre fichier de travail. Nous pouvons ensuite modifier le fichier résultant et Git enregistrera nos modifications. Si une modification conflictuelle se produit, Git marquera le fichier comme étant dans un état de conflit. Il existe plusieurs commandes pour résoudre les conflits dans cette branche particulière.

Les conflits sont plus fréquents lorsque deux personnes ou plus travaillent sur le même fichier dans le même référentiel. Cependant, lorsque le conflit est trouvé dans un fichier, Git est très intelligent et intelligent sur la façon de résoudre cela d’une manière assez impressionnante. Git utilise des marqueurs de conflit pour montrer quelles parties du fichier sont en conflit. Les marqueurs de conflit sont de petits hachages placés de chaque côté de la section conflictuelle du fichier.

Pull n’est pas utilisé seul. Il est utilisé avec l’aide de la récupération des données du serveur distant, puis de l’application de la fusion avec les modifications dans le référentiel local. Ces deux opérations mentionnées ci-dessous peuvent être exécutées si nous le voulons.

git fetch
git merge origin/$CURRENT_BRANCH

Le origin/$CURRENT_BRANCH mentionné ci-dessus signifie ci-dessous.

• Git appliquera les options de fusion et appliquera les modifications du référentiel distant, à savoir origin.
• Et cela s’ajoute au $CURRENT_BRANCH
• Qui ne sont pas actuellement présents dans notre branch de caisse locale

git pull n’est pas seulement recommandé, il exécute simplement git fetch suivi de git merge. Nous ferons trois fusions, à travers lesquelles Git exécutera trois opérations de récupération, où une récupération est tout ce dont nous aurons besoin.

git fetch origin   # it will update all our origin/* remote-tracking branches
git checkout new branch        
git merge origin/new branch     
git checkout master
git merge origin/master
git merge -X theirs new branch  
git push origin master   

Les commandes mentionnées ci-dessus ignoreraient effectivement toutes les modifications qui étaient différentes sur la branche à partir de laquelle nous fusionnions et développeraient un nouveau commit sur la branche vers laquelle nous fusionnons, où les commits sont tous fusionnés.

Nous pouvons également utiliser --ours sur une fusion normale pour fusionner tous les changements dans la branche à partir de laquelle nous fusionnons, puis ignorer tous les fichiers qui existent dans la branche vers laquelle nous fusionnons, faisant ainsi une fusion à trois voies entre les deux branches, puis en utilisant simplement les fichiers de la branche avec laquelle vous fusionnez.

Nous avons trouvé beaucoup plus facile d’utiliser git merge --ours pour fusionner les fichiers, puis d’utiliser git rebase -i pour réappliquer manuellement les modifications de la branche à partir de laquelle je fusionnais.

Les commandes ci-dessus ne fonctionneraient pas sur les fichiers en conflit, mais nous avons constaté que les commandes suivantes permettraient de résoudre le conflit.

git checkout file_with_conflict
git merge --ours --no-commit file_from_branch_with_conflict
git reset --hard git add file_with_conflict git commit -m