免責事項
「コミット」、「ステージング」ファイル、フォーク、プルリクエスト（ロシア語でGit Manを読んでいる人はいますか？）
Gitは中央サーバーなしで使用できることを知っていますが、私の場合（そしてほとんどの場合）、プロジェクトにはGitHub、BitBucket、またはそれらの類似物があります。
この記事は、おそらくGitに精通している人向けではありません。 むしろ、私はこの記事の著者に自分自身を認識しました。自分のコピーにある地元の枝の束にうんざりしていたら。 そしてその瞬間、私はすでにGitコマンドのニュアンスを十分に理解していたので、ローカルブランチなしで作業しようとする
「ローカルブランチはどのような機能を実行しますか？」という質問から始めましょう。
ほとんどの場合、リモートアナログ（同じ名前かどうか-重要ではありません）のみを監視し、常に同期します。 git pull [--rebase]と入力することにより、リモートの対応物の上にあるローカルの変更を簡単に転送できます。 ただし、まだコミットされていない変更がある場合があります（インデックス化されたファイルとステージングされたファイルの両方にあります）。
あなたがする必要があります：
- サーバーに送信されないコミットを保存する
- コミットされていないファイルを保存します。ステージングとステージングされていないファイルを分離し、これらのファイルを3〜5個の異なるバージョンの変更に分割することもできます。
その結果、通常はgit stashを使用して新しいローカルブランチを作成しますが、これもまたその数を増やします。
元のブランチはリモートに関連付けられたままでしたが、新しく作成されたブランチはこの利点を失いました-そして、まだgit pushコマンドの高度な構文を学ぶ必要があります。 HEAD状態ではないgit pushをどのくらいの頻度で行いますか（タグを使用して
そして、ローカルコミットとは対照的に、ローカルブランチには他に何が役立ちますか？ git pullコマンドを入力するときに「現在のブランチの追跡情報がありません」というエラーが発生したのは誰ですか？ ローカルブランチをリモートブランチにバインドするコマンドを覚える必要があるたびに。 また、ローカルブランチを2つのリポジトリに関連付ける必要がある場合はどうなりますか？ そして、 git merge bでは 、 bが origin / bと一致するかどうかを覚えておく必要があります-すぐにgit merge origin / bを作成する方が良いとは思わないでしょうか？
「しかし、リモートのブランチに結び付けられていないブランチがあります！」
ここでは、次の質問に対する答えを明確に理解する必要があります。
- このスレッドで最後に作業したのはいつですか？
- リモートリポジトリに送信される（またはリポジトリに移動するブランチのいずれかで凍結される）のはいつですか？
- なぜこのブランチは今リポジトリに送られないのですか？
私はいくつかのプロジェクトに取り組んでいます。 ただし、各プロジェクトでは、一度に1つのタスクを実行します。 したがって、HEADはほとんどの場合、まさにそのタスクの状態にあります。 タスクを「後で」延期する場合にのみ、サーバーに送信せずにローカルブランチを作成します。 なぜgit stashではありませんか？ Stashはクレンジングによって簡単に失われます。 「タスクの切り替え」はめったに行われないため、git stashの構文を覚えて、変更の意味のある説明を追加する必要があります（stashが行われたコミットの名前ではありません）。 コミットに変更を加えるだけの方が簡単ではありませんか？その構文は1日に何十回も使用します-説明だけでなく日付も示しますか？ これらのブランチがローカルブランチの一般リストに該当する場合、ローカルブランチのリストをクリアすることはさらに危険になります。 それから、gitブランチでリポジトリにローカルに送信されたすべてのブランチを表示したくないことを自分で決めました-git checkout bの代わりにgit checkout origin / bを常に実行できます。
あなたが病気になった、休暇に入った、または他の何らかの理由で仕事に行かなかったと想像してください。誰かがあなたの仕事（未送信の現地支店）をどこで手に入れることができますか？ それが、私がそれらをできるだけ少なくしたい理由です。
もしも
上記のレシピから、簡単なものがそれを示唆しています：「コミットしますか？ チェック？ -さあ！」
「しかし、チェックする時間がない場合はどうなりますか？」
急に病気になり、誰かがあなたの仕事を必要とする可能性がある場合は、とにかくgit pushを行う方が良いでしょう。 ブランチの安定性の重要性に応じて、異なる名前のブランチに変更を送信できます。
誰もこれらの変更を必要とせず、夜に自宅からこれらの変更に取り組みたくない場合は、この場合のみ、git pushなしで変更を残します。
さて、最後のオプション：「まだコミットされていません。」 それから、私が切り替えようとしているタスクは、たいていの場合非常に重要であり、永続的なデポジットではありません。 これは、すぐに現在の状態に戻ることを意味します。ブランチを作成し、変更をコミットします。 戻ると、目的のブランチが簡単に見つかります（少数しかありません）-ブランチを削除して開発を続けます。
では、git statusに「現在どのブランチにもない」と表示されたらどうなるでしょうか？ git logを適切に使用すると、不足しているポイントが埋められます。 そのため、手順は同じままです：git add、git commit。 git push origin HEADのみが変更されています：b （誰もがすでにgit-autocompleteを使用していることを望みます。これはブランチ名をすばやく入力するのに役立ちますか？）
git pushが承認されたらどうなりますか？ git pull [--rebase]なしで行う方法 長い間git pullを使用していません。別のコマンドの構文を覚えたくありません。gitfetch originや、状況に応じて、git mergeまたはgit rebase、または単にgit checkout origin / b （ローカルコミットがない場合）の方が簡単です。 このアプローチは特に、複数のリモートリポジトリがある場合にすべてのステップを制御するのに役立ちました-それらは絡み合っていなければなりませんでした（どのバージョンがリリース/ bブランチbのバージョンよりも理解しやすい）。
プッシュ後の枝の寿命
それはすべて、チームのワークフローに依存します。 ほとんどの場合、リポジトリサーバーはタスク追跡システム（JIRAなど）と同期されます。 BitBucketなどのシステムには、プルリクエストがそのブランチに基づいてマージされた後にブランチを削除するオプションがあります。 一般に、設定されたルールに従ってすべてがリモートリポジトリに存在し（主なことはgit remote prune originを行うことです）、Gitでの私の作業には影響しません。 ただし、コンソールからプルリクエストをマージできることは、決して害になりません。
あとがきの代わりに
ローカルにあるのはあなたの個人です。 リポジトリにあるローカルブランチの数に誰も関心がありません。チームは、「起動」したものだけを見ることができます（もちろん、プロジェクトのローカルバージョンが他のユーザーのリモートリポジトリでない限り）。 したがって、希望に応じてローカルのGitエンティティで作業を整理します。作業の「押しつぶされた」結果がすべての人に合うまで、これを判断する道徳的権利は誰にもありません。
過去1年間、私の結果はチームに合っています。