gitfaq(7) Manual Page

この構成は、リモートサービスへの認証には影響しません。 そのためには、 git-config(1) の credential.username を参照してください。

リモートサーバーまたは中間のプロキシが、(チャンク転送エンコーディングを導入している) HTTP/1.1 をサポートしていないか、チャンクデータが壊れていることがわかっている場合を除いて、この値をデフォルトサイズのままにしておくことは問題ありません。これは一般的なプッシュ問題の解決策として、(誤って)提案されることがよくありますが、ほとんどすべてのサーバーとプロキシが少なくとも HTTP/1.1 はサポートしているため、この値を上げてもほとんどのプッシュ問題は解決されません。 HTTP/1.1 とチャンク転送エンコーディングを正しくサポートしていなかったサーバーまたはプロキシは、大量のトラフィックを遮断するため、今日のインターネットでは無用の長物です。

注意: この値を増やすと、GitがHTTPまたはHTTPSを介して行うすべての関連プッシュで使用されるメモリが増えることに注意してください。これは、すべてが使用されているかどうかに関係なく、バッファ全体が割り当てられるためです。したがって、別の値が必要であることが確実でない限り、デフォルトのままにしておくことをお勧めします。

エディタを必要とするプログラム用に、あなたがエディタを構成したい場合、シェル構成(つまり、 ~/.bashrc とか ~/.zshenv)を編集して、 EDITOR または VISUAL 環境変数に適切な値に設定する行を含めることができます。たとえば、エディタ nano が必要な場合は、以下のように記述できます:

あなたがGit専用のエディタを構成したい場合は、 core.editor 構成 または GIT_EDITOR 環境変数を設定できます。これらのオプションが参照される順序の詳細については git-var(1) を参照してください。

注意: いずれの場合も、エディタの値はシェルに渡されるため、スペースを含む引数は適切に引用符で囲む必要があることに注意してください。さらに、エディタが呼び出されたとき、通常ターミナルからデタッチするタイプのエディタ場合は、それを行わないようにする引数を指定して指定する必要があります。そうしないと、Gitはエディタでの変更を認識しません。 Windowsでこれらの問題の両方に対処する構成の例は、構成 "C:\Program Files\Vim\gvim.exe" --nofork です。これは、空白を含んだファイル名をクォートし、プロセスのバックグラウンド実行を回避するため --nofork オプションを指定します。

さらに、ホームディレクトリのファイルに保存する store 資格情報マネージャー、または資格情報を永続的に保存しないが、特定の時間、資格情報の入力を求められないようにする cache 資格情報マネージャーを使用できます。

プロンプトが表示されたら、パスワードを入力することもできます。 URLにパスワード(パーセントエンコードする必要があります)を配置することは可能ですが、これは全然安全じゃ無く、誤って資格情報が公開される可能性があるため、お勧めしません。

このようなシェルコマンドは、オプション値を感嘆符(!)で開始することで指定できます。パスワードまたはトークンが GIT_TOKEN に保存されている場合は、以下のコマンドを実行して資格情報ヘルパーを設定できます:

ほとんどのホスティングプロバイダーは、プッシュに単一のSSHアカウントを使用します。つまり、すべてのユーザーが git アカウント(例: git@git.example.org)にプッシュします。プロバイダーの場合は、SSHで複数のエイリアスを設定して、使用するキーペアを明確にすることができます。たとえば、以下のようなのを ~/.ssh/config に記述して、適切な秘密鍵ファイルに置き換えることができます:

こうすれば、あなたはプッシュURLを調整して、 git@example.org の代わりに git@example_author または git@example_committer を使用できます(例: git remote set-url git@example_author:org1/project1.git) 。

git update-index の特定の機能、つまり、assume-unchangedビットとskip-worktreeビットを使おうとするのは魅力的ですが、これらはこの目的には適切に機能しないため、このように使用しないでください。

あなたの目的が構成ファイルを変更することの場合は、テンプレートまたはデフォルトのセットであるファイルをリポジトリにチェックインして、一緒にコピーして必要に応じて変更できると便利なことがよくあります。この場合の変更されたファイルは、誤ってコミットすることを防ぐために、通常は無視されます。

Gitが2つのブランチ間で通常のマージを行う場合、正確に3者が考慮されます。2つのブランチと、通常は2つのコミットの共通の祖先である「マージベース」(merge base)と呼ばれる3番目のコミットです。マージの結果は、マージベースと各headの間の変更の合計です。2つのブランチを通常のマージコミットでマージすると、新しい共通の祖先を持つ、新しいコミットが発生し、再度マージされるときはそれが最終的なマージベースになります。そうすると、Gitは、マージベースの前に発生した変更を考慮する必要がないため、以前に解決した競合を再解決する必要がありません。

スカッシュマージを実行する場合、マージコミットは作成されません。代わりに、一方の側からの変更は、もう一方の側への通常のコミットとして適用されます。つまり、これらのブランチのマージベースは変更されないため、Gitが次のマージを実行するときに、前回考慮したすべての変更と新しい変更が考慮されます。つまり、競合を再解決する必要があるかもしれません。 同様に、 git diff または git log またはGUIで ... 表記を使用すると、元のマージベース以降のすべての変更が表示されます。

結果として、2つの長期間有効なブランチを繰り返しマージする場合は、常に通常のマージコミットを使用するのが最善です。

その結果、両方の側に変更があり、一方の側がその変更を元に戻した場合、結果には変更が含まれます。 これは、コードが一方の側で変更され、もう一方の側では正味の変更がないためです。このシナリオでは、Gitが変更を採用します。

これが問題になる場合は、代わりにリベースを実行して、ブランチを他のブランチに戻すことでリベースすることができます。このシナリオでのリベースは変更を元に戻します。これは、リベースが元に戻すことを含め、個々のコミットを適用するためです。リベースは書き換え履歴(rewrite history)をリベースするため、問題がない場合を除いて、公開されたブランチのリベースは避けてください。詳細については、 git-rebase(1)のNOTESセクションを参照してください。

pre-commit フック(または、コミットメッセージの場合は commit-msg フック)を使用してこれらをチェックするのが一般的です。これは、単独の開発者として作業していて、ツールが役立つことを望んでいる場合に最適です。ただし、開発者のマシンでフックを使用することは、ユーザーが(他のさまざまな方法の中でも)気付かれることなく --no-verify でこれらのフックをバイパスできるため、ポリシーコントロールとしては効果的ではありません。 Gitは、ユーザーがローカルリポジトリを管理していることを前提としており、これを防止したり、ユーザーを攻撃したりすることはありません。

さらに、一部の上級ユーザーは、「pre-commit」フックが、一時的なコミットを使用して進行中の作業をステージングしたり、修正コミットを作成したりするワークフローの障害であると感じているため、とにかくこれらの種類のチェックはサーバーに押しやることをお勧めします。

これを行うには、 working-tree-encoding 属性を使用して gitattributes(5) パターンを指定できます。たとえば、以下のパターンは、Windowsで一般的なエンコーディングである UTF-16LE-BOM を使用するようにすべてのC言語ファイルを設定します:

これを有効にするには、 git add --renormalize を実行する必要があります。プラットフォーム間で使用されるプロジェクトでこれらの変更を行う場合は、ユーザーごとの構成ファイルまたは $GIT_DIR/info/attributes の構成ファイルで行う必要があることに注意してください。リポジトリ内の .gitattributes ファイルは、リポジトリのすべてのユーザーに適用されます。

行末の正規化については以下のエントリを参照してください。属性ファイルの詳細については、gitattributes(5) を参照してください。

ファイルをUnixの行末でリポジトリに保存し、プラットフォームの行末に自動的に変換できます。 これを行うには、構成オプション core.eol を native に設定し、以下のエントリで、ファイルをテキストまたはバイナリとして構成する方法について確認してください。

行末からキャリッジリターン(CR;\x0d)を削除したくない場合は、 core.whitespace 設定を使用してこの動作を制御することもできます。

ファイルが1つだけになるように、ファイルの1つを削除することをお勧めします。これは、以下のようなコマンド(2つのファイル AFile.txt と`afile.txt` を想定)を使用して、他の点ではクリーンな作業ツリーで実行できます:

これにより、ディスクへの変更は回避され、追加のファイルは削除されます。プロジェクトでは、この問題が再発しないように、すべて小文字の名前などの命名規則を採用することをお勧めします。このような規則は、 pre-receive フックを使用して、または継続的インテグレーション(CI)システムにてチェックできます。

システムでスマッジまたはクリーンフィルター(a smudge or clean filter)が使用されているが、スマッジまたはクリーンフィルターを実行せずにファイルが以前にコミットされた場合、任意のプラットフォームで永続的に変更されたファイルが発生する可能性もあります。これを修正するには、他の点ではクリーンな作業ツリーで以下を実行します:

さらに、テキストベースまたは非テキストベースのストレージ形式を選択できる場合は、ファイルをテキスト形式で保存し、必要に応じて他の形式に変換することをお勧めします。たとえば、1行に1つのレコードを持つテキストベースのSQLダンプは、実際のデータベースファイルよりも差分とマージにはるかに適しています。同様に、MarkdownやAsciiDocなどのテキストベースの形式は、MicrosoftWordやPDFなどのバイナリ形式よりもうまく機能します。

同様に、バイナリ依存関係(共有ライブラリやJARファイルなど)を格納したり、リポジトリに製品をビルドしたりすることは、通常はお勧めしません。依存関係とビルド製品は、リポジトリに保存されている参照、URL、ハッシュのみを使用して、アーティファクトサーバーまたはパッケージサーバーに保存するのが最適です。

また、 gitattributes(5) ファイルを設定して、どのファイルがテキストでどのファイルがバイナリであるかを明示的にマークすることをお勧めします。Gitに推測させたい場合は、属性 text=auto を設定できます。 たとえば、一部のプロジェクトでは以下の設定が適切な場合があります:

これらの設定は、ツールがパッチなどの出力に適切な形式を選択するのに役立ち、プラットフォームに適切な行末コードでファイルがチェックアウトされます。