Salut,

Concernant Git, juste pour clarifier les choses, quelle est la séquence d'opérations à exécuter dans le cas classique où deux développeurs travaillent sur le même projet, avec chacun un repository pushé vers un repository sur un serveur ?

Car au début, je pensais travailler sur la même branche master, mais cela a généré des erreurs, des modifs de l'un ont écrasés celles de l'autre. Alors j'ai introduit une branche pour chacun, et on a fait une fusion à chaque fois qu'on voulait intégrer le travail de l'autre, et là il n'y a plus eu de problème. Mais je suis bien conscient que ce n'est pas la solution, c'est évident qu'on peut travailler sur la même branche.

Alors, où se situe mon erreur, et pour faire simple, deux développeurs travaillant sur la même branche, quelle est la séquence d'opération à exécuter lorsqu'un développeur veut publier son travail, et lorsqu'un développeur veut updater son repository ?

Ce que je faisais avant, c'est : commit, push. et pull de l'autre côté. Il manque sans doute quelque chose.

Edit, réponse : commit, push, et pull, c'est tout à faire correct. Le GUI ne permet pas de faire un pull directement.

Ban non, à la limite tu peux faire un git pull --rebase histoire de pas avoir un merge, mais normalement git pull va aller chercher les modifs remote et va les merger avec les locales

Hélas ça ne marche pas impeccablement, je viens de faire un test :
 
Repository 1 : contient un fichier texte fichier.txt
Repository 2 : identique à Rep1
Repository Serveur : référentiel
 
Scénario :
1) Repository 2 : Ajout d'une ligne à la fin de fichier.txt. Commit + Push (via le GUI)
2) Repository 2 : Ajout d'une ligne à la fin de fichier.txt, mais sans avoir fait de pull auparavant (oubli ! ça peut arriver). Commit : OK. Mais Push : Erreur : "[rejected]        master -> master (non-fast forward)". Normal. Alors Pull : OK. Mais Push : même erreur. On fait quoi maintenant ?

Ok je crois avoir compris : dans mon exemple, après le dernier pull, on se retrouve avec un historique de branches qui contient master sur une branche, et remotes/origin/master sur une autre. On ne peut pas pusher master car master est dans un état incohérent par rapport au référentiel (remotes). Il suffit alors de faire un merge local de master avec remotes/origin/master, puis ensuite pusher.
 
Donc la séquence devrait être :
1) commit,
2) push,
et de l'autre côté :
 
1) pull,
2) merge éventuel (systématique si le pull introduit des modifs), (un merge automatique avec pull serait pratique... je ne retrouve pas comment on fait, j'en avait discuté sur ce topic, mais ça ne marche pas finalement)
3) commit,
4) push
 
Par contre, je n'arrive plus à reproduire un cas où les modifs postérieures de quelqu'un annulerait les modifs antérieures de l'autre si le premier n'a pas pullé auparavant. Peut-être que ce n'est pas censé arriver...

C'est très clairement pas censé arriver non

 
Et sinon pour mon problème cité ci-dessus :
 
"un merge automatique avec pull serait pratique... je ne retrouve pas comment on fait, j'en avait discuté sur ce topic, mais ça ne marche pas finalement"
 
J'ai trouvé l'explication. Tout simplement, la commande que je supposais être un pull via le GUI (en VF : "Récupérer de > origin", je ne sais pas ce que ça donne en VO), n'est pas un vrai pull. En revanche, la commande bash "git pull" fait bien le merge (git fetch && git merge comme tu avais dit, Masklinn), contrairement au GUI Il semble que le pull n'a pas encore été intégré au GUI.

Ou alors, plus simplement, git gui utilise la commande plus bas niveau "git fetch" et laisse à l'utilisateur le choix entre merge et rebase (ça a un sens dans la mesure où il n'est pas possible de donner l'argument "rebase" via la GUI, je présume)
 
Note: j'utilise pas souvent git, et d'autant moins git gui, donc je peux me tromper

Oui c'est cohérent ce que tu dis.
 
En outre, j'ai trouvé un message de quelqu'un qui réclame cette feature :

http://groups.google.com/group/msy [...] 9f1242902e (30 juillet 2008)