Conflits sur un merge - Git/GitLab

Version imprimable

02/12/2019, 09h13
OZ1977

1 pièce(s) jointe(s)

Conflits sur un merge - Git/GitLab

Bonjour,

je ne maitrise pas bien Git et suis bloqué depuis 2 jours sur un merge en raison de conflits.

Je ne comprends pas trop d'où vient le problème et donc quels conflits résoudre :
- est-ce parce que ma branche feature/6 locale est actuellement différente de la branche feature/6 distante ?

Je ne sais pas trop comment résoudre mon problème donc je vais essayer de le présenter le plus précisément possible en espérant qu'un expert Git saura m'aider.
En parallèle, je vais reprendre les bases pour mieux comprendre Git mais dans l'immédiat, il faut impérativement que je puisse résoudre ces conflits et remettre mon projet sur de bons rails.

J'ai un dépôt distant sur GitLab avec 3 branches :
- master (commit aea55d29)
- feature/4 (avec une demande merge abandonnée)
- feature/6 (commit 0542d3f8) avec une demande de merge mais impossible à merger en raison de conflits (message GitLab : "There are merge conflicts" sans avoir la main pour les résoudre via GitLab.)

En local, j'ai les 3 mêmes branches.

Ce que je voulais donc faire, c'est merger la branche feature/6 sur la branche master du dépôt distant. Je ne peut donc pas (cf message ci-dessus) et j'ai 2 options sur Gitlab :
- Merge locally
- You can merge this merge request manually using the command line :

Citation:

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request
git fetch origin
git checkout -b "feature/6" "origin/feature/6"

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up
git fetch origin
git checkout "origin/master"
git merge --no-ff "feature/6"

Step 4. Push the result of the merge to GitLab
git push origin "master"

Afin de voir où j'en étais dans mes commit j'ai fait un git log --oneline --decorate --graph --all et je m’aperçois que j'ai fait n'importe quoi depuis le commit indiqué par la flèche jaune (=mon dernier commit "propre"):

Pièce jointe 521124

En résumé :
Je veux que mes branches master (locales et distantes) correspondent à la branche feature/6 (commit 0542d3f8) qui est la version à jour de mon application.
Mais je ne sais pas comment je dois procéder.

d'avance merci pour votre aide
02/12/2019, 10h02
Marco46

Je te suggère une lecture de la FAQ, notamment la section sur les merge.

Pour manipuler les commits ça se passe ici.

Mais le merge n'est pas l'action à effectuer immédiatement ici. Avant de tenter de merge sa branche de travail dans master il faut la rebaser sur master.

Bon courage !
02/12/2019, 10h34
OZ1977

1 pièce(s) jointe(s)

merci pour ta réponse
j'ai lu les FAQ ce matin

concernant le rebase, j'ai un peu peur de faire plus de bêtise qu'actuellement...
et bien qu'elle n'est pas été mergé dans le dépôt distant la branche feature/6 est publiée sur Gitlab avec demande de merge request
or il est mentionné :

Citation:

De ce fait, il ne faut jamais faire un rebase d’une branche qui a été publiée quelque part et donc le rebase ne doit s’appliquer qu’à des branches privées, c’est à dire qui n’existent que sur votre machine.

si je comprends bien, çà placerait ma branche feature/6 (HEAD -> feature/6) / commit 8d2ca29 au niveau de ma branche master (commit 7a2c3dd qui deviendra le commit parent de ma branche feature/6) ?

ne serait-il pas également possible de ré-écrire l'historique sans utiliser le rebase mais en supprimant les commits postérieurs au dernier commit que je considère propre ?

Pièce jointe 521173
02/12/2019, 10h46
OZ1977

repartir sur de bonnes bases...

ou alors, si je fait un git checkout 0542d3f pour me replacer sur mon commit "propre" et à partir de ce commit, je fait un git rebase master
02/12/2019, 11h22
Marco46

Non il te faut être une sur une branche pour ça.

Tu peux nettoyer ton historique local avec les commandes de la section commit de la FAQ. Supprime les commits un par un et fait des git log à chaque étape pour voir ce qu'il se passe.

Une fois que tu as nettoyé là tu peux rebase avec master.

Et enfin il te faudra git push --force ta feature branch pour pouvoir la merger.
02/12/2019, 11h44
OZ1977

je vais devenir fou...

je me suis replacé sur ma master pour faire un rebase comme tu le suggérais dans ta première réponse
et visiblement ma branche master locale diverge de la branche master distante

Citation:

On branch master
Your branch and 'origin/master' have diverged,
and have 6 and 5 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

donc j'essaie de faire un
git pull origin master
j'ai de nombreux conflits que je dois donc résoudre
je tente un
git mergetool --tool=vimdiff3
et là il m'ouvre vimdiff sur mon fichier db.sqlite3 et c'est incompréhensible !

j'ai l'impression que ce fichier db.sqllite3 (ma base de donnée sur Django) me pose systématiquement des problèmes)
pourtant je l'ai mis dans le .gitignore (*.slqit3 et db.sqlite3) mais il intervient toujours dans mes manip git...

Il faut vraiment que je trouve une solution même radical pour avancer dans mon projet.
Je développe seul sur ce projet pour le moment et il n'y a eu aucun merge d'effectué dans le dépôt distant

n'y-a-t-il pas moyen de faire en sorte de tout recommencer pour que le code de ma feature/6 soit le code de ma master sur le dépôt distant et en local ?

en local :
- supprimer mes branches master et feature/4
- renommer ma branche feature/6 en master

à distance :
- supprimer ou écraser ma branche origin/master avec ma branche feature/6

je suis un peu désespéré je sais mais je ne m'y retrouve plus même en lisant la doc et suivant les tuto.

PS : @Marco46
je me suis aperçu qu'il y avait peut-être un forum plus adapté : https://www.developpez.net/forums/f1...ielle/scm/git/
en tant que modérateur, peux-tu le déplacer ?
02/12/2019, 12h45
Marco46

Citation:

Envoyé par OZ1977

je me suis aperçu qu'il y avait peut-être un forum plus adapté : https://www.developpez.net/forums/f1...ielle/scm/git/
en tant que modérateur, peux-tu le déplacer ?

Oui t'es pas dans le bon forum mais j'ai pas les droits sur cette partie du forum. Si un autre modo passe par là il fera le transfert sinon je demanderai ça plus tard.

Citation:

Envoyé par OZ1977

je me suis replacé sur ma master pour faire un rebase comme tu le suggérais dans ta première réponse

Pour rebase une branche avec master il faut avoir checkout cette branche et surtout pas master.

C'est le commit parent du 1er commit de ta feature branch que tu veux rebase avec le dernier commit de la branche master, donc il te faut checkout ta branche et pas master.

Citation:

Envoyé par OZ1977

ma branche master locale diverge de la branche master distante

git log --oneline sur ta master locale et tu check l'historique de ta master sur GitLab via le browser et tu compares. Mais tu dois avoir ce problème justement parce que tu as rebase master sur ta feature branch au lieu de rebase ta feature branch sur master.

Il faut que tu prennes le temps de te former à Git sinon tu vas finir par faire de grosses boulettes. C'est pas compliqué mais ya un apprentissage, ça doit pouvoir se faire en quelques jours. Il y a des formations pour ça sinon ça s'apprend très bien en solo. Tu peux simplement jouer avec les questions de la FAQ dans un dépôt de test que tu auras créé avec de simples fichiers textes.

Citation:

Envoyé par OZ1977

j'ai l'impression que ce fichier db.sqllite3 (ma base de donnée sur Django) me pose systématiquement des problèmes)
pourtant je l'ai mis dans le .gitignore (*.slqit3 et db.sqlite3) mais il intervient toujours dans mes manip git...

Tu l'as probablement versionné dans ton dépôt avant d'ajouter le pattern au .gitignore.

Il te faut :

- enlever le pattern du .gitignore.
- supprimer le fichier du versionning via git rm --cached db.sqllite3 (ça supprime le fichier de Git mais pas de ton filesystem).
- commiter.
- ajouter le pattern du .gitignore.
- commiter.

Citation:

Envoyé par OZ1977

Je développe seul sur ce projet pour le moment et il n'y a eu aucun merge d'effectué dans le dépôt distant

Du coup tu ne devrais jamais avoir de conflits. Pour avoir des conflits seul ça veut dire que tu fais quelque chose comme ça :

- tu crées une branche de travail A depuis master.
- tu modifies le fichier toto.txt.
- tu reviens sur master tu crées une nouvelle branche de travail B.
- tu reviens sur ta branche A et tu commit la modif de toto.txt.
- tu vas sur master et tu merges A dans master.
- tu vas sur ta branche B et tu modifies dans le fichier toto.txt la même ligne que celle modifiée lors de ta modif dans la branche A et tu commit.
- tu vas sur master et tu merge B dedans, là tu auras un conflit sur toto.txt lors du merge.

Le mieux c'est de tester sur un dépôt de test pour comprendre le mécanisme. Ça prend 5 minutes, juste avec un fichier texte et 2 lignes dedans.

Le fix ici c'est de rebase la branche B avec master avant de merge, et le conflit sera à résoudre pendant le rebase. Ainsi lors du merge tu n'auras pas de conflits puisque résolu précédemment.

Citation:

Envoyé par OZ1977

n'y-a-t-il pas moyen de faire en sorte de tout recommencer pour que le code de ma feature/6 soit le code de ma master sur le dépôt distant et en local ?

en local :
- supprimer mes branches master et feature/4
- renommer ma branche feature/6 en master

à distance :
- supprimer ou écraser ma branche origin/master avec ma branche feature/6

Je ne ferai pas comme ça. Clones ton dépôt distant une 2ème fois dans un autre répertoire. Depuis ce 2ème dépôt soit tu ajoutes manuellement les modifs de ta feature et tu recommences ton merge comme si de rien n'était, soit tu as ajoute le premier dépôt local en remote du deuxième et tu cherry-pick les commits qui t'intéresse puis tu pousses et tu ouvres ta MR.

Citation:

Envoyé par OZ1977

je suis un peu désespéré je sais mais je ne m'y retrouve plus même en lisant la doc et suivant les tuto.

Il te faut prendre le temps de te former pour bien comprendre les fondamentaux. On ne peut pas utiliser un tel outil correctement sans un minimum d'apprentissage. Je sais que beaucoup de gens fonctionnent comme ça mais le risque c'est de faire de très grosses boulettes.
02/12/2019, 14h25
OZ1977

procédure si je clone de nouveau mon dépôt...

Je sais que tu as raison et qu'il va falloir que je me forme
et je vais le faire cette semaine mais j'aurais aimé remettre mon projet sur de bon rails avant

je pense que c'est effectivement le scénario que tu décris que j'ai fait avec master, feature/4 et feature/6

je viens de cloner mon dépôt une 2ème fois (après avoir archivé mon projet sur ma branche feature/6)

je n'ai donc plus qu'une seule branche en local (master)
j'ai modifié ma branche master locale pour y intégrer l'ensemble des modifications que j'avais opéré sur la branche feature/6 et désormais ma branche master locale est à jour
j'ai commit

git status me donne :

Citation:

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)

nothing to commit, working tree clean

ce qui est donc normal
maintenant, il faut que je push ma master local vers origin/master (git push origin master)

cela va mettre mon projet à jour sur le dépôt distant c'est bien çà ?
02/12/2019, 14h39
Marco46

Oui sauf qu'en général on écrit jamais rien directement sur master, on passe par des features branch et on fait des merge request sur GitLab / pull request sur GitHub.
02/12/2019, 14h53
OZ1977

oui tu as raison mais vraiment là çà devenait compliqué
en tout cas maintenant j'ai un projet à jour en local et sur Gitlab
je vais maintenant prendre le temps de mieux comprendre ce que je fais et réfléchir à un workflow par écrit pour éviter de me retrouver dans une telle galère

en tous cas merci beaucoup pour ta patience et ton aide précieuse
02/12/2019, 17h45
Marco46

Résolu plz !
04/12/2019, 09h25
OZ1977

Encore une question...

Bonjour,

alors j'ai un peu 'étudié' git en lisant la doc officielle et en suivant un tuto sur OC
j'ai essayé de formaliser un workflow dev pour mon projet Django en cours.

Et j'ai malgré tout encore des questions.

J'ai une branche origin/master dans mon repo distant qui est ma branche dev (c'est le choix qui a été fiat dans mon équipe ; on aura par ailleurs des branches preprod et prod).
J'ai compris qu'il faut essayer de rester au maximum à jour par rapport à cette branche en faisant régulièrement des git pull origin master.

En local, j'ai ma branche master qui "correspond" à la branche origin/master.

Après avoir défini un certain nombre d'issues à traiter pour le projet, je commence à travailler sur l'issue #1 : je créé donc une branche feature/1 en local, dérivée de master (après m'être assuré d'être à jour).
Je travaille sur ma feature/1 et je commit. Je n'ai donc pas travaillé sur ma master locale.
Je décide de retourner sur ma master pour voir si je suis à jour par rapport à origin/master (git status) et effectivement je suis à jour mais git m'informe que j'ai également 3 fichiers qui ont changé (settings.cpython-37.pyc, urls.cpython-37.pyc et views.cpython-37.pyc dans le dossier __pycache__).
C'est là que je ne comprends pas. Si j'ai travaillé directement sur ma master, comment se fait-il qu'il y ait des fichiers modifiés ?

Pour retourner sur ma feature/1, il faut que je commit les changements opérés sur ces 3 fichiers.
Si je fait çà, je vais être en avance d'un commit par rapport à origin/master et çà va être le début des problèmes...

Qu'est-ce qui cloche dans le workflow décrit ci-dessus ?
D'après ce que j'ai lu, les dossiers __pycache__ contiennent du code compilé.
La première ligne de mon fichier .gitignore précise pourtant que je ne veux pas le prendre en compte dans les git (__pychache__/). Pourquoi alors est-il pris en compte ?

d'avance merci pour votre aide
04/12/2019, 12h24
Marco46

Citation:

Envoyé par OZ1977

La première ligne de mon fichier .gitignore précise pourtant que je ne veux pas le prendre en compte dans les git (__pychache__/). Pourquoi alors est-il pris en compte ?

C'est le même problème que précédemment. Ces fichiers ont du être versionnés avant que tu les passes dans .gitignore.

Citation:

Envoyé par OZ1977

C'est là que je ne comprends pas. Si j'ai travaillé directement sur ma master, comment se fait-il qu'il y ait des fichiers modifiés ?

Il est fort probable que ces fichiers ont été modifiés lors de ton travail sur la branche feature/1 mais pas embarqués dans le commit.

Pour t'en convaincre refait les mêmes opérations en exécutant un git status avant ton commit sur feature/1 et un autre après.

D'une manière générale il est fortement conseillé de faire un git status après chaque commande quasiment quand on débute sous Git.

Citation:

C'est le même problème que précédemment. Ces fichiers ont du être versionnés avant que tu les passes dans .gitignore.

non, là j'en suis sûr ! je n'ai pas modifié le .gitignore depuis que je suis reparti du remote
git status m'indiquait que j'étais bien à jour par rapport à origin/master
j'ai donc créé ma feature/1 et travaillé dessus puis add . et commit

je repasse alors sur master et je vois ces 3 fichiers qui ont été mis à jour !

Citation:

Il est fort probable que ces fichiers ont été modifiés lors de ton travail sur la branche feature/1 mais pas embarqués dans le commit.

git add . prend bien tous les fichiers non ?

Citation:

Pour t'en convaincre refait les mêmes opérations en exécutant un git status avant ton commit sur feature/1 et un autre après.

c'est exactement ce que j'ai fait.
j'avais fait un git status juste avant git add . (pour voir fichiers rouges à commit) et juste après git add . (pour voir fichiers verts à commit)
donc sauf si je ne comprends toujours pas quelque chose, tous les fichiers indiqués par git status étaient pris en compte sauf si certains fichiers n'apparaissent pas même avec un git add .

Citation:

D'une manière générale il est fortement conseillé de faire un git status après chaque commande quasiment quand on débute sous Git.

c'est ce que je fais...

le problème peut-il venir de mon .gitignore ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 # Byte-compiled / optimized / DLL files __pycache__/ *.py[cod] *$py.class # C extensions *.so # Distribution / packaging .Python env/ build/ develop-eggs/ dist/ downloads/ eggs/ .eggs/ lib/ lib64/ parts/ sdist/ var/ wheels/ *.egg-info/ .installed.cfg *.egg # PyInstaller # Usually these files are written by a python script from a template # before PyInstaller builds the exe, so as to inject date/other infos into it. *.manifest *.spec # Installer logs pip-log.txt pip-delete-this-directory.txt # Unit test / coverage reports htmlcov/ .tox/ .coverage .coverage.* .cache nosetests.xml coverage.xml *.cover .hypothesis/ # Translations *.mo *.pot # Django stuff: *.log local_settings.py # Flask stuff: instance/ .webassets-cache # Scrapy stuff: .scrapy # Sphinx documentation docs/_build/ # PyBuilder target/ # Jupyter Notebook .ipynb_checkpoints # pyenv .python-version # celery beat schedule file celerybeat-schedule # SageMath parsed files *.sage.py # dotenv .env # virtualenv .venv venv/ ENV/ .vscode # Spyder project settings .spyderproject .spyproject # Rope project settings .ropeproject # mkdocs documentation /site # mypy .mypy_cache/ .DS_Store *.sqlite3 media/ *.pyc *.db *.pid # Dossier généré par l'IDE Pycharm .idea # No migrations **/migrations/** !**/migrations/** !**/migrations/__init__.py # VS Code .vscode

04/12/2019, 13h38
Marco46
Citation:

Envoyé par OZ1977

non, là j'en suis sûr ! je n'ai pas modifié le .gitignore depuis que je suis reparti du remote

Ce que je veux dire c'est que tu as pu versionner ces fichiers il y a longtemps puis les ajouter au .gitignore après.

Du coup ces fichiers sont (seraient, c'est une hypothèse de ma part) versionnés mais ne sont pas pris en compte lors de tes opérations. Mais comme ils sont tout de même versionnés Git t'informe qu'il y a des changements dessus.

Du coup pour nettoyer ce bordel, si tu es certain de ta conf .gitignore tu peux faire ça dans une branche de travail :
Code:

1 2 3 4 git rm -r --cached . git add . git commit -m "<le msg que tu veux pour identifier cette operation>"
Donc pour faire ça tu pars de master, du crée une branche de travail, tu fais l'opération de nettoyage puis tu merge sur master.

Citation:

Envoyé par OZ1977

git status m'indiquait que j'étais bien à jour par rapport à origin/master
j'ai donc créé ma feature/1 et travaillé dessus puis add . et commit

C'est à cette étape qu'il manque un git status.

Il faut savoir quel est l'état de ta working directory après le commit et avant de git checkout master. Est-ce qu'il reste pas des trucs non pris en compte par git add . ce qui serait logique puisqu'ils sont dans le .gitignore ?

Citation:

Envoyé par OZ1977

git add . prend bien tous les fichiers non ?

Pas ceux du .gitignore.

détails .gitignore

j'ai fait un git status --ignored et j'obtiens la liste ci-dessous :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 On branch master Your branch is up to date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: intenseTBM_eTool/__pycache__/settings.cpython-37.pyc deleted: intenseTBM_eTool/__pycache__/urls.cpython-37.pyc deleted: intenseTBM_eTool/__pycache__/views.cpython-37.pyc Ignored files: (use "git add -f <file>..." to include in what will be committed) db.sqlite3 geckodriver.log intenseTBM_eTool/__pycache__/settings.cpython-37.pyc intenseTBM_eTool/__pycache__/urls.cpython-37.pyc intenseTBM_eTool/__pycache__/views.cpython-37.pyc locale/ parameters/__pycache__/
il y a donc les 3 fichiers en question, qui apparaissent comme des fichiers ignorés et des fichiers à commit

je fais un git check-ignore -v intenseTBM_eTool/__pycache__/settings.cpython-37.pyc et j'obtiens

Code:

.gitignore:2:__pycache__/ intenseTBM_eTool/__pycache__/settings.cpython-37.pyc

donc ces fichiers sont bien ignorés par la ligne 2 de mon fichier .gitignore actuel

Malgré tout, si je avancer, je pense que je dois faire la manip ci-dessous mais j'aimerais confirmation même si çà m'oblige à modifier origin/master :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 # source : https://riptutorial.com/fr/git/example/16165/effacer-les-fichiers-deja-valides--mais-inclus-dans--gitignore # Remove everything from the index (the files will stay in the file system) $ git rm -r --cached . # Re-add everything (they'll be added in the current state, changes included) $ git add . # Commit, if anything changed. You should see only deletions $ git commit -m 'Remove all files that are in the .gitignore' # Update the remote $ git push origin master

04/12/2019, 14h29
Marco46

C'est exactement la même manip que je t'ai expliqué dans mon message précédent. La seule différence c'est que je te propose de la faire dans une branche de travail puis de merger au lieu de la faire directement sur master.

Est-ce que tu as compris le problème de fond ?
04/12/2019, 14h46
OZ1977

excuse-moi, je n'avais pas vu ton précédent message
oui, je pense avoir compris

je ne peux pas checkout de master à cause des 3 fichiers versionnés
donc je vais faire l'opération sur ma master locale et push sur origin