最も重要なのは、決して「POSIXにあるのだから、システムがそれに準拠していなくても、あなたの要求は喜んで無視する」とは言わないことです。私たちは現実の世界に生きています。

しかし、「その構成は避けるべきだ、POSIXにもない」と言うことはよくあります。

上記の2つのルールにもかかわらず、時には「これはPOSIXにはないが、（非常に便利である | コードをはるかに読みやすくする | 他の優れた特性がある）そして、私たちが気にしているほとんどすべてのプラットフォームがそれをサポートしているので、それを使おう」と言うことがあります。

Again, we live in the real world, and it is sometimes a
judgement call, the decision based more on real world
constraints people face than what the paper standard says.

実際の変更に取り組んでいる際に、準備的なクリーンアップステップとしてスタイル違反を修正するのは良いことですが、それ以外のスタイルに合わせるための無駄なコードの変更は避けてください。

"Once it _is_ in the tree, it's not really worth the patch noise to
go and fix it up."
Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/

変更を説明するログメッセージは、変更自体と同じくらい重要です。明確に書かれたコードとコード内のコメントは、コードがどのように機能し、周囲のコンテキストから何が想定されているかを説明します。ログメッセージは、変更が達成しようとしたことと、変更が必要だった理由を説明します（これについては、付属のSubmittingPatchesドキュメントで詳しく説明します）。

インデントにはタブを使用します。

caseアームは、caseとesac行と同じ深さでインデントします。例えば、

case "$variable" in
pattern1)
	do this
	;;
pattern2)
	do that
	;;
esac

リダイレクト演算子は、その前にスペースを入れますが、後にはスペースを入れません。言い換えれば、echo test >"$file" と記述し、echo test> $file や echo test > $file とは記述しません。変数内のリダイレクトターゲットを二重引用符で囲むことは（上記のように）POSIXでは必須ではありませんが、bashの一部のバージョンでは引用符がないと警告を発するため、我々のコードではそうしています。

(incorrect)
cat hello > world < universe
echo hello >$world

(correct)
cat hello >world <universe
echo hello >"$world"

コマンド置換には $( ... ) を使用します。`` とは異なり、適切にネストします。これは最初から Bourne が綴るべき方法でしたが、残念ながらそうではありませんでした。

コマンドがユーザーの$PATHで利用可能かどうかを確認したい場合は、which の代わりに type を使用してください。which の出力は機械的に解析できず、その終了コードはプラットフォーム間で信頼できません。

POSIX準拠のパラメータ置換を使用し、bashismを避けます。具体的には、

${parameter-word} とその [-=?+] の兄弟、およびコロン付きの「未設定またはヌル」形式を使用します。

${parameter#word} とその [#%] の兄弟、および二重の「最長一致」形式を使用します。

「Substring Expansion」 ${parameter:offset:length} は使用しません。

シェル配列は使用しません。

パターン置換 ${parameter/pattern/string} は使用しません。

算術展開 $…​ を使用します。

プロセス置換 <(list) または >(list) は使用しません。

セミコロンで区切られた単一行に制御構造を記述しないでください。「then」はif文の場合次の行に、「do」はwhileおよびforの場合次の行に記述してください。

(incorrect)
if test -f hello; then
	do this
fi

(correct)
if test -f hello
then
	do this
fi

&&、||、| で結合されたコマンドシーケンスが複数行にわたる場合、各コマンドを別々の行に置き、&&、||、| 演算子は各行の末尾に置くようにしてください。行の先頭には置かないでください。これは、上記の演算子がシーケンスが終了していないことを意味するため、行を結合するために \ を使用する必要がないことを意味します。

(incorrect)
grep blob verify_pack_result \
| awk -f print_1.awk \
| sort >actual &&
...

(correct)
grep blob verify_pack_result |
awk -f print_1.awk |
sort >actual &&
...

「test」を「[ …​ ]」よりも好みます。

シェル関数の前に「function」というノイズワードは記述しません。

関数名と括弧の間にスペースを入れ、括弧の内側にはスペースを入れないことを好みます。開始の「{」も同じ行に配置する必要があります。

(incorrect)
my_function(){
	...

(correct)
my_function () {
	...

grepの使用については、移植性のためにBREのサブセット（すなわち、\{m,n\}、[::]、[==]、または[..]なし）に固執してください。

我々は \{m,n\} を使用しません。

? や + (これらはBREではそれぞれ \{0,1\} と \{1,\} です) は使用しませんが、これらはERE要素でありBREではないため言うまでもありません ( \? と \+ はBREの一部でさえなく、BREからアクセス可能にするのはGNU拡張であることに注意してください)。

ユーザーインターフェースを翻訳可能にするために、git-sh-i18n の Git の gettext ラッパーを使用します。po/README の「Marking strings for translation」を参照してください。

私たちは「test」コマンドを「-a」や「-o」で記述せず、代わりに「&&」や「||」を使って複数の「test」コマンドを連結します。なぜなら、「-a/-o」の使用はしばしばエラーの原因となるからです。例：

test -n "$x" -a "$a" = "$b"

is buggy and breaks when $x is "=", but

test -n "$x" && test "$a" = "$b"

does not have such a problem.

「local」はPOSIXの一部ではありませんが、テストスイートでは多用しています。スクリプト化されたPorcelainsでは使用せず、関係するすべてのシェルがそれをサポートするまで（特にAT&T Researchのkshはまだサポートしていません）誰も「local」を使い始めないことを願っています。

一部のバージョンのシェルは「export variable=value」を理解しないため、「variable=value」と記述し、その後に「export variable」を2つの別々の行に記述します。

dash の一部のバージョンでは、「local」、「export」、「readonly」を接頭辞とする変数代入が壊れており、割り当てられる値が引用符で囲まれていない限り、$IFS でフィールド分割されてしまいます。

(incorrect)
local variable=$value
local variable=$(command args)

(correct)
local variable="$value"
local variable="$(command args)"

一般的な構文

VAR=VAL command args

to temporarily set and export environment variable VAR only while
"command args" is running is handy, but this triggers an
unspecified behaviour according to POSIX when used for a command
that is not an external command (like shell functions).  Indeed,
dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T
ksh all make a temporary assignment without exporting the variable,
in such a case.  As it does not work portably across shells, do not
use this syntax for shell functions.  A common workaround is to do
an explicit export in a subshell, like so:

(incorrect)
VAR=VAL func args

(correct)
(
	VAR=VAL &&
	export VAR &&
	func args
)

but be careful that the effect "func" makes to the variables in the
current shell will be lost across the subshell boundary.

printf フォーマット文字列では、16進エスケープシーケンスは移植性がないため、16進（例: "\xc2\xa2"）ではなく8進エスケープシーケンス（例: "\302\242"）を使用してください。

インデントにはタブを使用し、タブは8スペースとして解釈します。

ネストされたCプリプロセッサディレクティブは、ハッシュの後にネストレベルごとに1スペースでインデントされます。

#if FOO
# include <foo.h>
# if BAR
#  include <bar.h>
# endif
#endif

1行あたり最大80文字を維持するように努めています。

Git開発者として、私たちはあなたが比較的新しいコンパイラを持っていると仮定し、私たちが気にするすべてのコンパイラ警告からパッチがクリアであることを確認するために、例えば「echo DEVELOPER=1 >>config.mak」のようにDEVELOPER makefile ノブを有効にすることをお勧めします。

DEVELOPER=1 モードを使用すると、コンパイラから「error: unused parameter *foo* [-Werror=unused-parameter]」のような警告が表示される場合があります。これは、関数が引数を無視していることを示します。未使用のパラメータを削除できない場合（例えば、関数がコールバックとして使用され、特定のインターフェースに一致する必要があるため）、個々のパラメータを UNUSED（または MAYBE_UNUSED）キーワードで注釈付けすることができます。例えば、「int foo UNUSED」のようにします。

古いものを含め、幅広いCコンパイラでGitをコンパイルできるように努めています。Git v2.35.0以降、GitはC99を必要とします（「__STDC_VERSION__」をチェックします）。コンパイラがそれらを理解しても、新しいC標準の機能を使用すべきではありません。

New C99 features have been phased in gradually, if something's new
in C99 but not used yet don't assume that it's safe to use, some
compilers we target have only partial support for it. These are
considered safe to use:

変数は、ブロックの先頭、最初のステートメントの前に宣言する必要があります（つまり、-Wdeclaration-after-statement）。宣言の終わりとブロックの最初のステートメントの間に空行を挟むことが推奨されます。

NULLポインタはNULLと記述し、0とは記述しません。

ポインタを宣言する際には、アスタリスクは変数名と並べます。つまり、「char *string」であり、「char* string」や「char * string」ではありません。これにより、「char *string, c;」のようなコードが理解しやすくなります。

演算子とキーワードの周りには空白を使用しますが、括弧の内側や関数の周りには使用しません。つまり、

      while (condition)
func(bar + 1);

and not:

      while( condition )
func (bar+1);

二項演算子 (「,」以外) と三項条件演算子「?:」は、オペランドと区別するために、演算子の両側にスペースを入れます。例: 「A + 1」であり、「A+1」ではありません。

単項演算子 (「.」と「->」以外) は、それとオペランドの間にスペースを入れません。例: 「(char *)ptr」であり、「(char *) ptr」ではありません。

整数値を定数0または\0と比較したり、ポインタ値を定数NULLと比較したりしてはなりません。例えば、カウントされた配列が初期化されているが要素がないことを検証するには、以下のように記述します。

if (!ptr || cnt)
	BUG("empty array expected");

and not:

if (ptr == NULL || cnt != 0);
	BUG("empty array expected");

私たちは不必要にブレースを使用することを避けます。つまり、

if (bla) {
	x = 1;
}

is frowned upon. But there are a few exceptions:

文が数行にわたる場合（例：埋め込み条件付きのwhileループ、またはコメント）。例：

while (foo) {
	if (x)
		one();
	else
		two();
}

if (foo) {
	/*
	 * This one requires some explanation,
	 * so we're better off with braces to make
	 * it obvious that the indentation is correct.
	 */
	doit();
}

条件文に複数の分岐があり、その一部がブレースを必要とする場合、整合性のために単一行のブロックでもブレースで囲みます。例：

if (foo) {
	doit();
} else {
	one();
	two();
	three();
}

「if」文の条件内で代入を行うことは避けるようにしています。

コードを理解しやすくするように努めてください。コメントを入れることもできますが、コメントは、それが記述しているコードが変更されると、必ずと言っていいほど古くなってしまいます。関数を2つに分割することで、コードの意図がはるかに明確になることがよくあります。

複数行コメントは、テキストとは別の行に区切り記号を記述します。例えば、

/*
 * A very long
 * multi-line comment.
 */

Note however that a comment that explains a translatable string to
translators uses a convention of starting with a magic token
"TRANSLATORS: ", e.g.

/*
 * TRANSLATORS: here is a comment that explains the string to
 * be translated, that follows immediately after it.
 */
_("Here is a translatable string explained by the above.");

二重否定は、全く否定しないよりも理解しにくいことがよくあります。

比較、特にループ内での比較については、2つの考え方があります。不安定な値を左側に、安定した値を右側に置くことを好む人もいます。例えば、変数iを下限までカウントダウンするループがある場合、

while (i > lower_bound) {
	do something;
	i--;
}

Other people prefer to have the textual order of values match the
actual order of values in their comparison, so that they can
mentally draw a number line from left to right and place these
values in order, i.e.

while (lower_bound < i) {
	do something;
	i--;
}

Both are valid, and we use both.  However, the more "stable" the
stable side becomes, the more we tend to prefer the former
(comparison with a constant, "i > 0", is an extreme example).
Just do not mix styles in the same part of the code and mimic
existing styles in the neighbourhood.

長い論理行を複数行に分割する場合、2つの考え方があります。タブを使って2行目以降を十分に右に押し込み、揃える人もいます。

      if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
              ...

while other people prefer to align the second and the subsequent
lines with the column immediately inside the opening parenthesis,
with tabs and spaces, following our "tabstop is always a multiple
of 8" convention:

   if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
           ...

Both are valid, and we use both.  Again, just do not mix styles in
the same part of the code and mimic existing styles in the
neighbourhood.

長い論理行を分割するとき、二項演算子の前で改行し、90度反時計回りに頭を傾けると解析ツリーのように見えるようにする人もいます。

   if (the_beginning_of_a_very_long_expression_that_has_to
|| span_more_than_a_single_line_of_the_source_text) {

while other people prefer to leave the operator at the end of the
line:

   if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of_the_source_text) {

Both are valid, but we tend to use the latter more, unless the
expression gets fairly complex, in which case the former tends to
be easier to read.  Again, just do not mix styles in the same part
of the code and mimic existing styles in the neighbourhood.

長い論理行を分割する場合、他のすべてが同じであれば、解析ツリーでより高いレベルの演算子の後に分割する方が望ましいです。つまり、こちらの方が望ましいです。

if (a_very_long_variable * that_is_used_in +
    a_very_long_expression) {
	...

than

if (a_very_long_variable *
    that_is_used_in + a_very_long_expression) {
	...

!! 演算子を算術構造体と組み合わせて使用するような巧妙なトリックは、他の人にとって極めて紛らわしい場合があります。説得力のある理由がない限り、それらの使用は避けてください。

APIを使用してください。本当にです。strbuf（可変長文字列）、ALLOC_GROW()マクロを使用するいくつかの配列、ソートされた文字列リスト用のstring_list、その他にも「struct decorate」という名前のハッシュマップ（structオブジェクトのマッピング）があります。

APIを考案したら、そのAPIを呼び出し元に公開するヘッダーファイルに関数と構造体を記述してください。「strbuf.h」の内容を、適切なトーンと詳細レベルのモデルとして使用してください。

Cファイルの最初の #include は、プラットフォーム固有のcompat/実装とsha1dc/を除き、 でなければなりません。このヘッダーファイルは、他のヘッダーファイルとソースファイルから、どのシステムヘッダーファイルをどのような順序でインクルードすべきか、システムに期待する特定の機能をトリガーするためにどのCプリプロセッサ機能マクロを定義すべきか、といったプラットフォーム間の違いを隔離します。この結果、Cファイルはシステムヘッダーファイルを直接インクルードすべきではありません。

There are some exceptions, because certain group of files that
implement an API all have to include the same header file that
defines the API and it is convenient to include <git-compat-util.h>
there.  Namely:

cmd_foo() プロトタイプ定義のために「builtin.h」をインクルードする「builtin/」ディレクトリ内の組み込みコマンドの実装、

cmd__foo() プロトタイプ定義のために「t/helper/test-tool.h」をインクルードする「t/helper/」ディレクトリ内のテストヘルパープログラム、

xdiffの内部機構のために「xdiff/xinclude.h」をインクルードする「xdiff/」ディレクトリ内のxdiff実装、

単体テストフレームワークを提供する「t/unit-tests/test-lib.h」をインクルードする「t/unit-tests/」ディレクトリ内の単体テストプログラム、および

reftable の内部構造のために「reftable/system.h」をインクルードする「reftable/」ディレクトリ内の reftable を実装するソースファイル、

are allowed to assume that they do not have to include
<git-compat-util.h> themselves, as it is included as the first
'#include' in these header files.  These headers must be the first
header file to be "#include"d in them, though.

Cファイルは、以前のルールによってインクルードする必要があるヘッダーファイルのうち、そのヘッダーファイルによって利用可能になる関数と型を除き、使用する関数と型を宣言するヘッダーファイルを直接インクルードしなければなりません。

新しいコマンドを計画している場合は、まずシェルまたはPerlで記述することを検討してください。そうすれば、セマンティクスの変更を容易に変更および議論できます。多くのGitコマンドはそのように始まり、いくつかはまだスクリプトです。

Gitに新しい依存関係を導入することは避けてください。これは通常、Gitコアコマンドセットですでに使用されていないスクリプト言語を使用しないことを意味します（コマンドがそれとは明らかに分離されている場合、例えばランダム-scm-XリポジトリをGitに変換するインポーターなど）。

関数にペアを渡す場合、その順序で渡すように努めるべきです。

ユーザーインターフェースを翻訳可能にするために、Gitのgettextラッパーを使用してください。po/READMEの「Marking strings for translation」を参照してください。

特定のソースファイルにローカルな変数と関数は「static」とマークする必要があります。他のソースファイルから見える変数は、ヘッダーファイルで「extern」と宣言する必要があります。ただし、関数宣言は「extern」を使用すべきではありません。なぜなら、それはすでにデフォルトだからです。

省略形の GIT_DEBUGGER を使用して、プログラムの周りで gdb を起動できます。GIT_DEBUGGER=1 ./bin-wrappers/git foo を実行して gdb をそのまま使用するか、GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo を実行して独自のデバッガと引数を使用します。例：GIT_DEBUGGER="ddd --gdb" ./bin-wrappers/git log （bin-wrappers/wrap-for-bin.sh を参照）。

サブシステム S が扱う主要なデータ構造は struct S と呼ばれます。struct S を操作する関数は S_<verb>() と命名され、通常は struct S へのポインタを最初のパラメータとして受け取ります。例：

struct strbuf;

void strbuf_add(struct strbuf *buf, ...);

void strbuf_reset(struct strbuf *buf);

is preferred over:

struct strbuf;

void add_string(struct strbuf *buf, ...);

void reset_strbuf(struct strbuf *buf);

構造体 S で特定のタスクを実行する関数には、いくつかの一般的な慣用的な名前があります。

S_init() は、構造体自体を割り当てずに構造体を初期化します。

S_release() は、構造体を解放せずに構造体の内容を解放します。

S_clear() は S_release() の後に S_init() を実行することと同等で、構造体はクリア後すぐに使用可能になります。S_clear() が提供されている場合、S_init() は再度解放する必要のあるリソースを割り当ててはなりません。

S_free() は、構造体の内容を解放し、構造体を解放します。

関数名は明確で記述的であり、その目的や動作を正確に反映している必要があります。意味のあるコンテキストを追加しない任意の接尾辞は、特にコードベースの初心者にとって混乱を招く可能性があります。

Historically, the '_1' suffix has been used in situations where:

関数は、同様の処理を必要とするグループ内の1つの要素を処理します。

再帰関数は、そのセットアップフェーズから分離されました。

The '_1' suffix can be used as a concise way to indicate these specific
cases. However, it is recommended to find a more descriptive name wherever
possible to improve the readability and maintainability of the code.

上記のCのガイドラインのほとんどが適用されます。

Perl 5.8.1 以降 ("use Perl 5.008001") をサポートするよう努めています。

use strict と use warnings は強く推奨されます。

ステートメント修飾子を過度に使用しないでください。ただし、それらを使用することで結果が理解しやすくなる場合は例外です。

「if ()」条件内での代入は避けるようにしています。

その機能が必要な場合は、Git.pm を学習して使用してください。

PEP-8 (https://peps.python.org/pep-0008/) に従っています。

最低でも Python 2.7 との互換性を目指しています。

必要なライブラリがPython 2に制限されない場合、Python 3.1以降との互換性も確保するように努めています。

一文のエラーメッセージをピリオドで終わらせないでください。

メッセージの最初の単語だからといって、その単語を大文字にしないでください（「unable to open *%s*」であり、「Unable to open *%s*」ではありません）。しかし、「SHA-3 not supported」は問題ありません。なぜなら、最初の単語が大文字になっている理由は、文の先頭にあるからではなく、文の途中に出てきてもその単語が大文字で表記されるからです。

最初にエラー内容を述べてください（「cannot open *%s*」であり、「%s: cannot open」ではありません）。

エラーの主題を単一引用符で囲みます。例：die(_("unable to open %s'"), path)。

よほどの理由がない限り、ポーセリンコマンドからのエラーメッセージは翻訳用にマークされるべきです。例：die(_("bad revision %s"), revision)。

配管コマンドからのエラーメッセージは、機械処理を目的としている場合があり、翻訳用にマークすべきではありません。例: die("bad revision %s", revision)。

BUG("message")は開発者に特定のエラーを伝えるためのものなので、翻訳すべきではありません。

設定変数名については、既存の慣例に従ってください。

簡潔さを好み、抽象的な機能について客観的に記述する。例：

このスタイルに固執するのが不自然になる場合、仮定のユーザーに言及する際には「あなた (you) 」を、プログラムがユーザーにどのように反応するかを議論する際には「私たち (we) 」を好む。例：

You can use this option instead of `--xyz`, but we might remove
support for it in future versions.

while keeping in mind that you can probably be less verbose, e.g.

Use this instead of `--xyz`. This option might be removed in future
versions.

三人称単数の架空の人物を参照する必要がある場合は、「彼/彼女/彼を/彼女を」を避けるために「単数形のthey」に頼ることができます。例：

A contributor asks their upstream to pull from them.

Note that this sounds ungrammatical and unnatural to those who
learned that "they" is only used for third-person plural, e.g.
those who learn English as a second language in some parts of the
world.

Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
conventions.