git merge, help - Page 1

j'ai besoin d'aide, je sait utiliser git pour moi tout seul, mais la je collabore sur un projet et il y à de multiple commiter, et pour merger leur commit je ne comprend rien, ca ne veut pas ^^

help !

j'ai externalisé mes changements au max, j'ai besoin de rajouter 5 lignes, mais la j'en ai marre d'effacer le fork, de fixer à la main pour maintenir ...

genre la je suis parti d'un fork neuf, appliqué mon patch de 5 lignes et *réussi* à appliquer le commit suivant




le gars à entre temps fait de nouveaux commit, mais github ne veut pas me les appliquer malgré les 5 lignes de différence :



j'ai bien testé un git mergetool mais c'est du chinois, je ne sais que faire :/



bref, ca marche comment en fait, de manière simple ?

Il utilise Git.

merci

A vrai dire, je n'ai (presque ?) jamais utilisé "git merge"
C'est en partie parce que j'utilise principalement Git au-dessus de SVN.

J'utilise beaucoup "git rebase", en revanche, et j'imagine (mais j'ai peut-être complètement tort ) que merge doit s'utiliser d'une façon similaire.
Avec rebase, je me mets sur la branche à rebaser (`git checkout`, ou en général à travers `gitk`), je déclenche le rebase (`git rebase target`), et s'il y a des conflits, soit je skippe le patch (parce qu'une version plus récente du patch qui pose problème est dans l'autre branche), soit je résous les conflits (je l'ai toujours fait à la main, avec un éditeur de texte puis "git add" puis "git rebase --continue").

merci

je ne connaissais pas pas gitk, ni git-gui ^^
intéressant, mais ca ma peut'être plus embrouillé qu'autre chose en fait

git rebase ça correspond à faire des flèches des autres fork vers le miens plutôt que simplement appliquer le commit sur ma ligne à moi ?
(genre ce qu'il y a à gauche du premier shoot plutôt que le truc à droite que j'ai fait moi cad le même commit sur deux fork à part ?)

si c'est ca c'est ce que je voulais faire en fait ^^

résoudre les conflits, ca veut dire quoi en fait ? mater à la main les différence et jouer du copier coller pour faire le véritable mélange des deux forks moi même ?

faudrait que je trouve un "git pour les nuls" ^^

Il n'est pas recommandé d'utiliser rebase (ou d'une façon générale, la réécriture d'historique) sur des branches publiées. C'est en local que j'utilise rebase.

mater à la main les différence et jouer du copier coller pour faire le véritable mélange des deux forks moi même ?

Si les algorithmes de résolution automatique de Git ne sont pas arrivés à résoudre les conflits, oui.

Attention : comme dit Lionel, rebase ça recrée un patch pour chaque commit "rebasé", sur la branche destination. Ce sont réellement des nouveaux commits, avec un hash différent (puisque partant d'un autre noeud), donc si vous bossez à plusieurs sur cette branche ce n'est probablement pas du tout ce que vous voulez faire.

Utilisez plutôt merge, ou simplement pull, pour créer un commit de merge entre votre version et celle du mec qui a fait la branche qui vous intéresse.

en fait c'est plus ma version perso vs l'officielle

ayant bien vu que git fait pas ce que je veut j'ai limité au minimum les changements dans la version originale, j'ai déplacé une macro qui avais rien à foutre dans le .c pour la caler dans le .h (au passage je l'utilise aussi) j'ai inclus un seul .h à moi, et mis 4 lignes lançant le nécessaire pour mes points d'entrée dans les endroits clef du moteur original, ajouté une ligne au makefile et basta, rien d'autre, je ne comprend pas que git ne s'y retrouve pas :/

git est assez balèze et taffer subitement avec sur un projet à plusieurs ca change des simple git commit -a et git push
seul j'utilisais même pas les branches ^^

Git n'a pas beaucoup d'intérêt si tu n'utilises pas les branches, c'est à peu près sa seule force (mais quelle force !) ; tant qu'on reste seul, SVN marche très bien et il est quand même autrement plus simple d'utilisation