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

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

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.

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

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 ?