Git协作开发提交合并问题

Question

两个人开发一个项目，用的Git做版本控制，两个人同时都有代码要提交到已有的远端仓库里面，这个步骤应该是怎样的呢？

例如下面一个场景该如何处理？（只用了一个分支master）

开发人员1：git clone ...
开发人员2：git clone ...
开发人员1：编码...
开发人员2：编码...
开发人员1：git add -> git commit -> git push (ok)
开发人员2：git add -> git commit -> git push (失败！)

当一个人push成功后，另一个人再push就不可以了。 现在我们的处理办法是，开发人员2重新Clone一次，手动增加代码，再提交，push。但是这样做太麻烦了，正确的做法应该是怎样呢？

Answer 1

Le clone est à usage unique, pour toute personne en développement ultérieur :

• Modifier le code
• git ajouter, git commit
• git push

Si git push échoue :

• git pull
• Fusionner automatiquement les modifications. S'il ne peut pas être fusionné automatiquement, fusionnez-le manuellement, puis git coomit
• git push

Recommander ce livre : http://git-scm.com/book/zh

Answer 2

Le problème ci-dessus peut être résolu en utilisant git pull ou git fetch Si vous souhaitez mieux utiliser git, Il est recommandé d'utiliser Git Flow, qui est une excellente méthodologie de modèle de branche Git. Le respect de cet ensemble de règles peut éviter les problèmes courants et apporter une expérience de développement fluide. Cela peut être considéré comme une meilleure pratique

github : https://github.com/nvie/gitflow

Articles connexes : Commencez à pratiquer git-flow http://www.jeffkit.info/2010/12/842/
Processus de développement du flux Git http://ihower.tw/blog/archives/5140/
http://nvie.com/posts/a-successful-git-branching-model/
Stratégie de gestion de branche Git http://www.ruanyifeng.com/blog/2012/07/git.html
git flow et github flow http://hooopo.writings.io/articles/fe2b0791

Answer 3

Parlez-moi de deux inconvénients de votre approche.
1. Il n’existe qu’une seule version principale. Habituellement, nous avons deux versions, une version maître et une version de travail. La version principale est équivalente à la version officielle, des dizaines de fichiers sont mis à jour ensemble à chaque mise à jour. La version de travail est équivalente à la version de test, et il est normal de la mettre à jour 20 fois par jour.
2. Vous avez mentionné que deux personnes, a et b, ont soumis des questions en même temps. Dans des circonstances normales, a devrait être soumis, puis b fusionnera (fusionnera) la soumission de a, testera d'abord si votre projet peut toujours fonctionner normalement localement, et enfin b sera soumis.
Le deuxième point est l’âme de git, et c’est aussi quelque chose auquel beaucoup de gens ne sont pas habitués. Le plus grand avantage de la conception de git est qu'elle garantit que chaque version soumise est exécutable, de sorte que même si vous supprimez une certaine version, il n'y aura aucun problème sur toute la ligne de mise à jour. Parce que les futures versions peuvent encore fonctionner.
Par conséquent, il existe une condition préalable par défaut pour utiliser git. Premièrement, la version soumise par chacun doit fonctionner correctement sur sa propre machine. Ce dont je parle ici concernant le fonctionnement correct, ce n'est pas seulement le code que j'ai modifié, mais aussi celui après la fusion des mises à jour d'autres personnes. En d’autres termes, chaque soumission est en réalité un test d’intégrité. Quiconque développe sait que la configuration initiale de l'environnement est indispensable pour tout projet. Si le projet ne peut pas s'exécuter pendant le développement, il n'est fondamentalement pas nécessaire de modifier le code. Il est donc essentiel de maintenir l’intégrité du projet.

Answer 4

Développeur 1 : git add -> git commit ->

Développeur 2 : git add -> git commit -> git pull origin master ->

Answer 5

Ils ne connaissent même pas le processus le plus élémentaire de git, et ils ne savent pas comment lire les invites d'erreur données par git lorsqu'ils rencontrent des problèmes. Comment ont-ils choisi d'utiliser git en premier lieu. ? Suivez-vous la foule ?