git - すべてのコミットをプッシュしますか？

Question

誰かがgitとリモートリポジトリの操作についてもっと詳しく教えてくれたらいいのにと思います。私はまだリモートリポジトリを使用していません。

ローカルリポジトリに、世界を壊すほどではないかもしれない小さな変更をコミットします。リモートリポジトリに何がプッシュされますか？すべてのローカルコミット？または、行われた全体的な作業は、他の人の全体的な作業とマージされますか？誰もがすべてのコミットをプッシュする場合、リモートリポジトリのログは混乱しているに違いないと思います。

Answer 1

リモートリポジトリからのプッシュとプルは、ローカルコミットほど重要ではありません。通常、1日に数回押したり引いたりするだけで十分です。@earlonrailsが言ったように、プッシュの頻度が高いほど、変更が競合する可能性が低くなりますが、通常はそれほど大きな問題ではありません。

このように考えると、ローカルリポジトリにコミットすることで、基本的に「このコードを信頼します。完全です。実行されます。テストしました。他の人が見る準備ができています」と言っています。コミットするたびにリモートリポジトリにプッシュする場合は問題ありませんが、定期的にプッシュする限り、それは実際には問題ではありません。

ローカルリポジトリとは、変更を追跡して、実行する作業を保護することです。リモートリポジトリは、すべてのチームメートに作業を配布し、全員の変更を追跡するためのものです。チームメイトはあなたのコードにアクセスする必要がありますが、通常は緊急ではなく、一日の終わりまで、またはあなたがプッシュしたいと思うときはいつでも待つことができます。

Answer 2

都合の良いときにリモートにプッシュできます。一度に大量のコミットをプッシュする場合の唯一の問題は、より多くの競合をより影響を受けるファイルとマージする必要がある場合があることです。gitを初めて使用する場合は、gitreadyをお勧めします。

リモートはローカルリポジトリと同じように機能しますが、他の人とうまく遊ぶ必要があります。あなたがプッシュする前に他の人がリモートにプッシュした場合。次に、プッシュする前に、変更をプルする必要があります。両方が同じファイルに触れる場合、それらの変更が最初に行われたため、2つの変更をマージする必要があります。

Answer 3

私は可能な限りすべてのローカルコミットをプッシュしようとします（私はGitを使用しています）。ローカルで2つ以上のコミットがあることはめったにありません。そうしないと、解決するのがそれほど楽しくない対立のリスクがあります。

履歴をより直線的に保つために、マージではなくリベースを使用することを好みます。ローカルに2つのコミットAとB（Bが古い）があり、Bが今後の変更と競合する場合、リベースで競合を解決した後、Bをチェックアウトし、コンパイルをチェックし、テストを実行してから、Aに切り替えてすべてをプッシュする必要があります。

だから私は自分が持っているものすべてをできるだけ早くプッシュすることを好みます。これらの問題は主に、他の複数の人と大規模なコードベースを処理しているときに発生することに注意してください。

Answer 4

私は一般的にベストアンサーといくつかのコメントに同意しません。コミットもプッシュも、コードの品質に責任を持つ必要はありません。

svn時代では、誰もが同じブランチで働いています。コードの失敗はすぐに他の人に伝播します。この場合、コードの品質を確実に保証する必要があります。これが、多くの企業や組織でsvnがgitに置き換えられている理由です。

典型的なGitワークフローを明確にする必要があります。マスターブランチに、なんらかの形で実行可能なバージョンのソフトウェアがあるとします。マスターブランチをリリースブランチとして使用することを好む人もいれば、開発ブランチとして使用する人もいます。それはどうでもいい事です。機能を追加したりバグを修正したりする必要があるときはいつでも、マスター（または別の）ブランチからブランチを作成します。この機能は、コードベースに大幅な変更を加えることなく処理できるように十分に小さくする必要があります。大規模な変更の場合は、ブランチの最後のレイヤーが十分に小さくなるように、ブランチのレイヤーを作成する必要があります。

各ブランチが小さな機能を追加する場合、同じブランチで多くの人が作業する可能性はほとんどありません。複数の人が1つの機能に取り組んでいる場合、そのグループは非常に小さく、頻繁にコミュニケーションをとる必要があります。したがって、競合は簡単に修正できます。1つのコミットまたはプッシュで問題が発生した場合、問題が発生するのはあなたまたはあなたの小さなチームだけです。

次に、コードの品質を保証する必要があります。私の答えはプルリクエストです。Githubで、コードを変更してプルリクエストを送信します。プルリクエストを送信するまでに、コードがコンパイルされてテストに合格できることを保証する必要があります。Gitlabでは、コードを変更する前にマージリクエストを作成しますが、WIPでマークします（作業中）。次に、コードを変更します。WIPマークを削除する前に、コードの品質が良好であることを保証する必要があります。また、コードレビューアは保護のもう1つの層になります。

競合がブランチで発生することはめったにありませんが、ブランチをベースブランチにマージするときに発生する可能性があります。そのマージが発生する直前に修正する必要があります。

唯一のことはリベースに関連しています。多くの開発者は、マージの競合を送信する前にブランチをリベースして、gitcommit履歴の見栄えを良くすることを好みます。リモートにプッシュし、他の人がコードを使用した場合、リベースによって厄介な問題が修正されます。ただし、小さな機能のみを修正するブランチで常に作業している場合は、とにかくブランチを使用する必要はありません。また、私は個人的にリベースが歴史を変えるのであまり好きではありません。

したがって、私の結論は他の人と似ており、頻繁にコミットし、頻繁にプッシュしますが、理由は異なります。