两个人开发一个项目，用的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。但是这样做太麻烦了，正确的做法应该是怎样呢？
PHPz2017-04-22 09:01:27
クローンは 1 回限りであり、その後の開発で誰でも使用できます:
git Push が失敗した場合:
この本をお勧めします: http://git-scm.com/book/zh
巴扎黑2017-04-22 09:01:27
git をより良く使いたい場合は、git pull 或者 git fetch を使用して上記の問題を解決できます。
優れた Git ブランチ モデル手法である Git Flow を使用することをお勧めします。この一連のルールに従うことで、一般的な問題を回避し、スムーズな開発エクスペリエンスを実現できます。 これはベストプラクティス
github: https://github.com/nvie/gitflow
関連記事:
git-flow の練習を始めましょう http://www.jeffkit.info/2010/12/842/
Git フロー開発プロセス http://ihower.tw/blog/archives/5140/
http://nvie.com/posts/a- success-git-branching-model/
Git ブランチ管理戦略 http://www.ruanyifeng.com/blog/2012/07/git.html
git flow と github flow http://hooopo.writings.io/articles/fe2b0791
高洛峰2017-04-22 09:01:27
あなたのアプローチの欠点を 2 つ教えてください。
1. マスター バージョンは 1 つだけです。通常、マスター バージョンと作業バージョンの 2 つのバージョンがあります。
マスター版は正式版に相当し、基本的には更新のたびに数十個のファイルがまとめて更新されます。作業版はテスト版に相当し、1日20回更新するのが通常です。
2. a と b の 2 人が同時に質問を提出したと述べました。通常の状況では、a が送信され、次に b が a の送信をマージ (マージ) し、最初にプロジェクトが引き続きローカルで正常に動作するかどうかをテストし、最後に b が送信されます。
2 番目のポイントは git の魂ですが、これも多くの人が慣れていないものです。 git の設計の最大の利点は、送信されたすべてのバージョンが確実に実行可能であるため、特定のバージョンを削除しても、更新ライン全体に問題が発生しないことです。将来のバージョンでも引き続き実行できるためです。
したがって、git を使用するにはデフォルトの前提条件があり、まず、全員が送信したバージョンが自分のマシンで正しく実行される必要があります。ここで正しく実行することについて話しているのは、私が変更したコードだけではなく、他の人の更新をマージした後のコードも含みます。言い換えれば、すべての提出物は実際には完全性テストです。開発を行う人であれば、どのようなプロジェクトでも初期環境構成が不可欠であることは知っていますが、開発中にプロジェクトを実行できない場合でも、基本的にコードを変更する必要はありません。したがって、プロジェクトの整合性を維持することが非常に必要です。
PHP中文网2017-04-22 09:01:27
開発者 1: git add -> git commit ->
開発者 2: git add -> git commit -> git pull オリジンマスター -> git commit -m 'merge' ->
天蓬老师2017-04-22 09:01:27
彼ら 2 人は、git の最も基本的なプロセスさえ知らず、問題が発生したときに git が出力するエラー メッセージの読み方も知りません。そもそも、なぜ彼らは git を使用することになったのでしょうか?群衆に従っていますか？
