何らかのブランチと同じ箇所を指しています。ブランチはその新しいコミットに移動します。(fork)あるリポジトリの歴史をそっくりそのままコピーすることです。食器のフォークのように枝分かれするさまからこの名前が付いていて、この名前があるからにはコピー以上の意味があります。それは、コピー元と全く同じ歴史を共有していることで、あとから自分が加えた変更を元のリポジトリに合流させてもらえるという意味です。フォークを行うのは、所有権がなくプッシュ権限を持たないリポジトリに変更を加えたい時です。管轄するリポジトリに変更を加えたい時はフォークをする必要はありません。詳しくは3章で述べます。変更を提出する流れあるリポジトリの内容の変更は、本質的に言えば「自分が書いた変更差分を歴史に組み込む」が起こると達成します。これから説明する以下のような操作は、流れは異なりますがすべて「自分が書いた変更差分を歴史に組み込む」が生じる点では同じです。提出したいリポジトリに書き込み権限がある場合、有効な方法です。デフォルトブランチは全員に共通であり、誰かの一存でコミットしたり、歴史を改変したりするべき存在ではないため、共同開発向きのやり方ではありません。リポジトリの管理者が特にレビューの必要がない変更を加える場合は、これを省略してコミットすることもよくあります。その場合、「デフォルトブランチにコミットしてプッシュしたから、各自プルしてください」とちゃんとメンバーに連絡する必要があります。提出したいリポジトリに書き込み権限がある場合、有効な方法です。リポジトリのオーナーかコラボレーターであれば書き込み権限があります。提出したいリポジトリに書き込み権限がない場合に使う方法です。メールその他で会話しながら行います。やってどの会話を会話ツールですればよいのかをケース別で紹介します。requestを提出し変更について議論する以下の流れが一般的です。共同開発は複数の人が集まって作業します。その「腕」や知識レベルには必ず差があります。非常に典型的なのは、その中でも技術が低い方の人が負い目を感じたり、チームに悪影響を与えていると妄想してしまうことです。技術が高い方の人も問題のある行動をすることがあります。技術の低いメンバーに対して高圧的に接したり、などです。いずれも、この章にある考え方を学ぶことで改善できます。書いてみて後から改善しよう最初から完全無欠なコードを生み出せる人はいません。自分の技術に自信があるかとか、人に自分のコードを見せるのは恥ずかしいとか、そういう気持ちはまず捨ててとりあえず書いてみましょう。共有して、もっと良くするにはどうすれば良いかを話し合いましょう。仮にバグがあるコードや美しくないコードを書いたとしても、それはまったく悪いことではありません。これから良くしていけばいいからです。本当に悪いのは、それを受け止めずにはねのけたり、次に活かさないことです。これではみんなの気分が下がるし、コードの質も上がりません。今誠実に対話し学ぶことで、コードも、チームも、そしてあなた自信の技術力ももっと良くなります。レビューは文句を言う場所ではなく、より良いコードへと前進する対話の場であるコードレビューでは、コードをもっと良くするにはどうすればよいかを議論します。レビュアーは提出者に対して怒っているわけでも、イジッているわけでも、はたまた蔑みたいわけでもありません。ここはレビュアーも提出者も勘違いしてはいけません。提出者は前向きな気持ちでこれを提出し、指摘を恐れないでください。レビュアーも、極力ナイスな言葉遣いを意識し、前向きな表現になるよう心がけてください。絵文字を積極的に使うとか、語尾を工夫するとかして表現を柔和にするのもよいでしょう。万が一レビュアーが明らかに高圧的あるいは敵対的な場合は、「嫌な思いをした」と声を上げるのも一つの手ですが、そのプロジェクトには関わらず立ち去るのがベターです。人」とは、誠実で、心が開かれていて、いつも笑顔にあふれた人のことです。自己啓発本でも読まされてるのかと思うかもしれませんが、結局の所、こう振る舞う以上に良いものはないです。常に自分の発言や行動を第三者的に振り返って改善しましょう。このページにある用語はもちろん、それ以外の概念についても図解で解説されている。