だから Linuxであるかどうか、Windowsであるかどうかにかかわらず、すべてのプログラマーは、常にそれぞれWindowsまたはLinuxのプログラマーの輪の中を回転します。 マイクロソフトとWindowsの世界のプログラマーがいます。 そのような人々がオープンソースとGitに向かって動き始めたことは賞賛に値します。 しかし、今はそれについてではありません。
物語の中で、私は時々スコット・チャコン（スコット・チャコン）によって書かれた有名な本Pro Gitに頼っています。
ケース1：なぜgit commit -m
悪いのですか？
インターネットでの会話の1つで、Gitの初心者向けの記事、つまりこの記事が言及されました。 また、「Gitを準備する方法」という記事には、後で悪い習慣として取り除くのが難しいニュアンスが含まれていると誰かが提案しました。 それでも、私は怠け者ではなく、記事を読みました。 そして、私は与えられた意見に同意することを敢えてします。
順番に、 多くの有用なヒント以外に記事で提案されているものは何ですか？ 特に、そのような瞬間：
-
git commit -m "Commit message"
-
git reset --hard
失敗したgit merge
を中断する手段として -
git rebase bar
複雑な表現ですが、それについては説明しません
これらのヒントがあまり良くないと思うのはなぜですか？
第一に、
git commit -m "Commit message"
間違いなくwip（work in progress）の変更に役立ちます（
git stash
を使用すると概念はよくトレースされます）が、パブリックブランチの実際の変更には有害です。 。 原則として、多くの場合50〜60文字に制限されているメッセージの最初の行（および多くの場合、ユーザーは
git log --oneline
ように最初の行のみを見ることができます）でのみ、変更の本質を理解できます。 より詳細な説明が必要な場合は、1行後に1行スキップして説明を追加してください。
変更の処理方法のテンプレートの例を次に示します。
要約：短い、通常は最大66文字の、この変更の機能の説明 <空行> 説明：詳細、 おそらく複数行 エラーログなどを使用して、変更の実行内容の説明 <空行> タグ：オプションのタグ、タイプ サインオフ：First Last <cool@email.com> レビュー担当者：First Last <cool@email.com>
そして、これは本からの対応する抜粋です
一般的に、良いコミットメッセージを書くことは非常に重要です。 オープンソースプロジェクトの場合、通常、メッセージをこの形式で多かれ少なかれ書くことがルールです。
変更の短い（50文字以下）要約
必要に応じて、より詳細な説明テキスト。 約72に包みます
文字かそこら。 一部のコンテキストでは、最初の行は
メールの件名と本文としての残りのテキスト。 空白
要約を本文から分離する行は重要です（省略しない限り）
体全体）; いくつかのgitツールを実行すると混乱する可能性があります
一緒に2つ。
空白行の後にさらに段落が続きます。
-箇条書きも大丈夫です
-通常、箇条書きにはハイフンまたはアスタリスクが使用されますが、
単一のスペースが先行し、空白行が
間にありますが、ここでは慣習が異なります
変更の短い（50文字以下）要約
必要に応じて、より詳細な説明テキスト。 約72に包みます
文字かそこら。 一部のコンテキストでは、最初の行は
メールの件名と本文としての残りのテキスト。 空白
要約を本文から分離する行は重要です（省略しない限り）
体全体）; いくつかのgitツールを実行すると混乱する可能性があります
一緒に2つ。
空白行の後にさらに段落が続きます。
-箇条書きも大丈夫です
-通常、箇条書きにはハイフンまたはアスタリスクが使用されますが、
単一のスペースが先行し、空白行が
間にありますが、ここでは慣習が異なります
例として、GitHubで任意のプロジェクトを開きます。コメントは、
git commit -m
スタイルで1行で作成されます。 この行は分割されてメッセージの本文に取り込まれます。これは、詳細な説明のみを意味します。 Web上の他のリポジトリマッピングユーティリティについても同様です。
第二に、多くのGitコマンドラインコマンドには
--abort
オプションがあります。 この場合、
git reset --hard
を適用すると、結果は正しいものの、スズメを撃つことに相当します。
git reset --hard
は、ステージングされていないデータベースとステージングされたデータベースをクリーン
git reset --hard
し、リポジトリ全体に行き、ファイルが変更された場合はインデックスからファイルを復元し、指定されたIDへのポインターをリセットします。
git merge --abort
は、何が変更され、どこで変更され、どこに戻るかを知っているため、より簡単です。
本に目を向ける
git merge --abortオプションは、マージを実行する前の状態に戻ろうとします。 これを完全に実行できない唯一のケースは、実行時に作業ディレクトリに隠されていないコミットされていない変更があった場合です。そうでない場合は正常に動作します。
何らかの理由で恐ろしい状態に陥り、最初からやり直したい場合は、git reset --hard HEADまたは任意の場所に戻ることもできます。 繰り返しますが、これは作業ディレクトリを吹き飛ばしてしまうので、そこに変更を加えないようにしてください。
何らかの理由で恐ろしい状態に陥り、最初からやり直したい場合は、git reset --hard HEADまたは任意の場所に戻ることもできます。 繰り返しますが、これは作業ディレクトリを吹き飛ばしてしまうので、そこに変更を加えないようにしてください。
ケース2：廃止された機能ブランチにrebase
する方法
すでに記事の冒頭で述べた会話の中で、他に気づいたことがあります。 これは、人々が使用するプロセス、つまり次の一連のアクションです。
# rebase myFeature origin/master # (, master ) git checkout master git pull # git rebase git rebase origin/master myFeature # git checkout master git merge --no-ff myFeature # ,
今と比較してください：
git remote update git rebase --onto origin/master <our old origin> # git push myFeature:master # , master
または：
git remote update origin git merge origin/master # git push myFeature:master # , master
最初のケースでは、作業ツリーにマスターのローカルコピーが必要です。ファイルシステムを操作する必要があるため、切り替え-
checkout
-は高価な操作です。たとえば、テンプレートから何かを変更した数万のファイルのリポジトリをすでに提示している場合
2番目の方法では、インデックスを更新できます。すべてのリモートに対してすぐに実行でき、1回の操作で機能分岐を更新し、3番目をマスターまたは他の場所で入力できます。 マスターの実際の更新を除いて、最初の方法にはこれがありませんでした。
ケース3：-- --squash
適切な場合
さらに、一部の開発チームは
merge --squash
使用
merge --squash
、個人的な変更でストーリー全体が乱雑にならないようにします。 しかし、これが一般に公開された場合（オープンソース！）、すみません、すべての変更は共通であり、個人的な選択はありません。 修正
fixup
squash
同様に
fixup
squash
送信する一連の変更を準備する場合にのみ役立ちます。
したがって、最初は自分でローカルに変更を行い、それらに対処し、通常のシリーズでそれらを配置し、これがすべて公開されていることを考慮して、さらにアップロードすることを提案します。 他方、たとえそれが内部リポジトリであっても、ある種の問題の終わりを見つけることは、どれほど難しいでしょう。 どうやら、職場で実際に何が起こっているのかを想像する人はあまりいないようです。
ボーナス
ボーナスとして、このようなコマンド（
--list
オプションに注意してください）：
git branch -a --list myremote*
特に、Linuxカーネルと複数のサブシステムを一度に1つのツリーに配置した場合の評価の有用性：linux-pm、linux-tty、...
はい。GoogleはGoogleコードを閉じます。