gitで同じブランチにコミットする
Gitブランチで作業している2人の人がいて、同時にチェックアウトしているが、1人が最初にコミットし、もう1人が後にコミットするとします。最新のコミットは以前のコミットと引き続きマージされますか、それとも複数の人が同じブランチで同時に作業できますか？
さて、gitリポジトリのクローンを作成すると（「チェックアウト」とはどういう意味ですか？）、新しいブランチを効果的に作成していることになります。 Gitブランチは、グローバルではなく、各リポジトリに対してローカルです。そうは言っても、ブランチへの更新がリポジトリ間でどのように送信されるかについてのプロトコルがあります。たとえば、リモートからプルすると、デフォルトでリモートの「マスター」ブランチが「マスター」ブランチにマージされます。そして、プッシュすると、「マスター」ブランチをリモートのマスターブランチに追加することができます。したがって、マスターとリモートのマスター（「オリジン/マスター」）は異なるブランチですが、慣例により関連付けられています。
要点に戻る---リモートにプッシュすると、マスターブランチが追加になる可能性があることに気付きました。 2人がOrigin/masterのコピーを取り、独立した変更を行った場合（これは、ローカルで2つのブランチに変更を加えるのと同じです）、一方の人が変更をプッシュすると、もう一方の人の変更はOrigin /への単純な追加ではありません。もうマスター---それらはマージされなければなりません。これは、プッシュする場合は発生せず、プルする場合にのみ発生します（紛らわしいことに、「プル」は「プッシュ」の正反対ではありません。「フェッチ」はプッシュの反対です。プルはフェッチとそれに続くマージです（またはリベース））。
したがって、このような状況にある場合、変更をプッシュしようとしている人は、最初に更新されたオリジン/マスターからプルバックし、マスターのバージョンをマージまたはリベースしてから、プッシュする必要があります。デフォルトでは、ブランチへの誰かの変更を削除して自分のものに置き換えることはできません。それを行うには、少なくとも「git Push -f」を実行する必要があります。リモートリポジトリには、設定やフックを設定して、かなり難しくすることができます。
または、2人が事前に協力することもできます。一方が他方の変更をプルし、マージを実行してから、結果をプッシュします。変更が重複したり、相互に影響を及ぼしたりする可能性がある場合は、これを行うとよいでしょう。バージョン管理システムの第一法則を覚えておいてください：VCSは通信の代わりにはなりません。
Gitでは、ブランチは厳密にlocalです。ある開発者が別の開発者のリモートブランチを変更することはできません（下部の注を参照）。ただし、bareリポジトリの場合、変更によって早送りが行われる場合は、リモートリポジトリのブランチを更新するために、変更を「プッシュ」することができます。
ただし、2人の開発者が同じリモートリポジトリにコミットしている場合、最初にブランチを最新の状態に戻さなくても、1人だけがリモートブランチを早送りできます。
たとえば、アリスとボブの両方がローカルリポジトリのマスターブランチで作業していて、それぞれがサーバー上の共有（ベア）リポジトリから複製されているとします。アリスが最初に作業を終了した場合、コミットした変更を共有ベアリポジトリにプッシュすると、ベアリポジトリのマスターブランチが早送りされます。
ボブは、最初にローカルブランチを更新して、アリスが追加したコミットを含めることなく、ベアリポジトリのマスターブランチを早送りすることはできません（彼が追加したコミットは、アリスが作成したコミットの祖先ではないため）。
ボブがこれを行う1つの方法は、アリスがコミットをプッシュした後、ベアリポジトリからプル（またはできればリベース）することです。これにより、アリスの変更がボブのブランチにマージされ、ボブがベアリポジトリのマスターブランチをプッシュで早送りできるようになります。
他のワークフローも可能です。アリスとボブは、共有のベアリポジトリを使用せずに、互いに協力して直接プルすることができます。本当に、ほぼ無限の可能性があります。しかし、一般的に、Gitでのマージはpullingの変更によって行われます。
[注：実際には、ベアでないリポジトリにプッシュして、他の人のブランチを更新することは可能ですが、これはしばしば直感的でない結果をもたらし、典型的なgitワークフローとは見なされず、一般的に推奨されません]
短い答えはこれです：
commit -m "my changes"
共有バージョンを取得する
git fetch sharedrepo
oneこれら2つのうち、ローカルブランチを他のリポジトリと同期します
git merge sharedrepo/sharedbranch
git rebase sharedrepo/sharedbranch
最終的な履歴に多くのブランチが必要ない場合、Rebaseは履歴をシリアル化します。どちらのオプションでも、完了する前に競合を解決する必要がある場合があります。
マージ/リベースして競合を解決した後、リポジトリにプッシュバックします
git Push sharedrepo HEAD:sharedbranch
ここでは-fを使用しないでください。これは、早送りする必要があります。運が悪ければ、他の誰かが新しいバージョンをプッシュした可能性があります。その場合は、この手順を再開してください。
個別に作業することができ、変更をプッシュ/プルする必要があるときはいつでも次のことを行います。
git add --all .
git commit -m "Commit desc"
git pull
git Push
説明：
git add --all .
削除されたファイルを含むすべての変更を追加します
git commit -m "Commit desc"
コミットを宣言する
git pull
マージされる最初のプルでは、競合を修正する必要がある場合があります
git Push
最新のマージされたバージョンをプッシュします[オプション-変更を送信する場合]
複数のローカル/リモートバージョンで同時に作業できるようにするなど、さらに制御が必要な場合は、 ブランチ を参照してください。
提案されたワークフローとして、このシンプルでありながら便利なページをお勧めします http://genomewiki.ucsc.edu/index.php/Working_with_branches_in_Git いくつかの優れた手順をカバーしています。
複数の人が同時に同じブランチで作業できます。あなたがプルする（または他の人にプッシュさせる）と、あなたへの変更はgitによってマージされ、両方の変更を含むブランチが作成されます。