git - なぜ最初にコミットし、次にプルし、最後にプッシュするのでしょうか?コミットしてから直接プッシュするのではなく?

Question

私には本当に理解できません。インターネット上にもこれについての明確な説明はありません。
状況は次のようになります。現在、リモート倉庫があり、マスターであるブランチが 1 つだけあります。次に、ローカルの倉庫がリモートマスターから複製されます。誰もがそれをクローンし、ローカルで変更し、コミットし、プルしてプッシュします。これは誰もが行うことです。そこで次の質問が来ます:

＃＃＃１、では私の地元の支店は支店とみなしてよいのでしょうか？それとも単なる地元の倉庫ですか？

2. 新しいブランチをリモートで作成してプルした場合、ローカルにブランチは存在しますか?私のローカル ブランチは、新しく作成されたリモート ブランチと同じですか?

3. 現地の倉庫と現地の支店の違いは何ですか?

4. コミットはローカル ウェアハウスに送信されてからプッシュされますが、このプッシュではすべてのコードがリモート ウェアハウスにプッシュされますか、それともコミットだけがリモート ウェアハウスにプッシュされますか?

##5 では、なぜ最初にコミットし、次にプルし、次にプッシュする必要があるのでしょうか? プルした場合、変更したすべてのコードが上書きされることを意味するのではないでしょうか? リモートで変更したコードがないためです。プルしたら上書きされてしまうんじゃないでしょうか? 私のローカルな変更の良い部分は見つかりましたか?ではどうすれば押せるのでしょうか？

＃＃＃６ ＡとＢの２つの分岐がありますが、ＡはＢと合併、ＢはＡと合併しますが何か違いはありますか？

Answer 1

洞察

1. ローカル コンピューターはクローンとみなされます。

2. はい、リモートにブランチ dev がある場合、オリジン dev をプルすると、ローカルに dev ブランチが存在します。

3. 倉庫はプロジェクト全体であり、支店は生産ラインの 1 つです。アリババグループがタオバオを一つだけ持っているわけではないのと同じように

4. プッシュはすべてを分析するわけではありませんが、自分でテストしていくつかの大きなファイルを取得することはできます。数キロバイトのテキストを追加すると、転送が非常に遅くなります。とても早くしてください

5. コミットにより、リモートがローカルを直接上書きすることがなくなります。プルするように求められるのは、リモートの最新の内容がローカルと矛盾しているためです。リモートブランチにあるものは破棄できないので、それをプルしてローカルに保存し、ローカルのものが最新になるようにし、最後にローカルのものが最新の場合はプッシュアップします。リモートのものを変更します。

回答完了、わかりました

Answer 2

1. 最初にpull不会把你本地代码覆盖掉，而是提醒merge冲突，需要你手动merge;

2. なぜ内部でテストする必要があるのですか? ブランチに最新のコードがあることを確認する必要があります。pull？因为对你来说你本地可能有个分支，你在这个分支上面工作，那么也有可能存在其他人和你一样的做法，也许你们的代码有依赖又或是有冲突，你肯定不能在master

3. ローカル ブランチ コードは、ローカル ウェアハウスに保存される前にローカル コードを送信する必要があります。これは、ローカル ブランチが開発のプラットフォームであることと同等ですが、開発された出力はローカルの倉庫にあります

両方とも可能ですが、ほとんどの人は、他のパートナーによるコードの変更を理解できるように、最初に実行することを選択します

pull，因为你没提交你的代码，别人提交了，这时候git会自动merge，而如果你提交了，有时候git自动merge会报冲突，选择先pull就是图一个方便和省事，当然也有人选择先push在pull平たく言えば、何が必要で何が不必要かを理解していないため、

は失敗することがわかります

master的代码快照是1，你的同伴改了提交了是2，你的提交代码是3，如果你先pull，那么就是3和1merge，而3包含1，git选择最新代码3覆盖1，不存在冲突关系，而你先push在pull，那就是2和3merge，这是git自动merge

マージ問題

a と b のマージは、2 つのブランチに必要なコードが保持され、全員が同意するコードに統合されます。
唯一の違いは、マージプロセスが少し異なることです。これは状況によって異なりますが、基本的には同じです。

Answer 3

1. ローカルとリモートの関係は2つのブランチに相当します。set-upstream..balbalagit pull

   を実行すると、対応する関係が自動的にバインドされるため、同じように感じます。
2. リモートで新しいブランチを作成してローカルにプルする理由は同じですが、ローカルブランチとリモートブランチは別のものです
   。
3. ローカルブランチはローカル倉庫に属しており、タグであれば複数のブランチが存在する可能性があります
   。
4. 完全にリモートにプッシュされるわけではありません。ローカルがリモートよりも上位である場合は、追加の

   を追加して、送信時刻に従って並べ替えて新しいものを作成します。コミットレコードをマージしてアップロードします commit 给怼上去,如果本地的这几个 commit 和远程的 commit 有冲突的部分就merge

5. 最初にコミットし、次にプルし、次にプッシュするこの状況は、複数の人が開発をマージする状況に対処するためのものです。

   1. は、この送信で何を変更したかを git に伝えることです。そうでない場合は、変更しただけですが、git は変更したことを認識しないため、判断して比較する方法がありません。commit

   2. これらの 3 つの連続ラウンドでは、交渉中に他の人が別のバージョンを送信するのを防ぐために、このプロセスを繰り返します。競合がなければ、通常は直接マージされます。コードは上書きされませんpull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和你冲突的那个人拉过来问问保留谁的代码,然后在 git add && git commit && git pull

   3. コード カバレッジまたは損失が発生する: たとえば、A と B がコードをプルすると、バージョンは両方とも 1 になります。A は 2 と 3 をローカルで送信し、B が変更を加えたとき、

      操作は行われませんでした。最初は自分で何かを書きました、そしてcommit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push この時点で、Bのローカルバージョンは3になりました。ローカルバージョンが3のときにAが書いたコードをBが変更し、git commit && git Pushを実行したとき、その後リモートバージョンで 答えは 4 で、A のコードがカバーされているため、全員が最初にコミットしてからプルする必要があります。そうしないと、コードが実際にカバーされてしまいます