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) 。

Usually, doing so will cause git status to need to re-read every file in the working tree. Additionally, Git’s security model does not permit sharing a working tree across untrusted users, so it is only safe to sync a working tree if it will only be used by a single user across all machines.

It is important not to use a cloud syncing service to sync any portion of a Git repository, since this can cause corruption, such as missing objects, changed or added files, broken refs, and a wide variety of other problems. These services tend to sync file by file on a continuous basis and don’t understand the structure of a Git repository. This is especially bad if they sync the repository in the middle of it being updated, since that is very likely to cause incomplete or partial updates and therefore data loss.

An example of the kind of corruption that can occur is conflicts over the state of refs, such that both sides end up with different commits on a branch that the other doesn’t have. This can result in important objects becoming unreferenced and possibly pruned by git gc, causing data loss.

Therefore, it’s better to push your work to either the other system or a central server using the normal push and pull mechanism. However, this doesn’t always preserve important data, like stashes, so some people prefer to share a working tree across systems.

If you do this, the recommended approach is to use rsync -a --delete-after (ideally with an encrypted connection such as with ssh) on the root of repository. You should ensure several things when you do this:

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

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

For SSH, Git can support a proxy using OpenSSH’s ProxyCommand. Commonly used tools include netcat and socat. However, they must be configured not to exit when seeing EOF on standard input, which usually means that netcat will require -q and socat will require a timeout with something like -t 10. This is required because the way the Git SSH server knows that no more requests will be made is an EOF on standard input, but when that happens, the server may not have yet processed the final request, so dropping the connection at that point would interrupt that request.

An example configuration entry in ~/.ssh/config with an HTTP proxy might look like this:

Note that in all cases, for Git to work properly, the proxy must be completely transparent. The proxy cannot modify, tamper with, or buffer the connection in any way, or Git will almost certainly fail to work. Note that many proxies, including many TLS middleboxes, Windows antivirus and firewall programs other than Windows Defender and Windows Firewall, and filtering proxies fail to meet this standard, and as a result end up breaking Git. Because of the many reports of problems and their poor security history, we recommend against the use of these classes of software and devices.

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) を参照してください。

You can store the files in the repository with Unix line endings and convert them automatically to your platform’s line endings. To do that, set the configuration option core.eol to native and see the question on recommended storage settings for information about how to configure files as text or binary.

行末からキャリッジリターン(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、ハッシュのみを使用して、アーティファクトサーバーまたはパッケージサーバーに保存するのが最適です。

We also recommend setting a gitattributes(5) file to explicitly mark which files are text and which are binary. If you want Git to guess, you can set the attribute text=auto.

With text files, Git will generally ensure that LF endings are used in the repository. The core.autocrlf and core.eol configuration variables specify what line-ending convention is followed when any text file is checked out. You can also use the eol attribute (e.g., eol=crlf) to override which files get what line-ending treatment.

For example, generally shell files must have LF endings and batch files must have CRLF endings, so the following might be appropriate in some projects:

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