補足メモ
■ブランチ操作
理解を深めるために、Gitに慣れてきたら知っておくといい。
master ... 最初にコミットすると作成される、デフォルトのブランチ名。
「master ブランチは本番環境（成果物）と同一」という運用をされることが多い。
なお「master」という名前は差別用語になりうるので、「main」という名前にしようという動きがあり、実際GitHubのデフォルトブランチは「main」に変更された。
origin/xxx ... リモートサーバにある内容をそのまま保持しているブランチ。読み取り専用。
origin/HEAD ... リモートサーバのデフォルトブランチ。基本的に origin/master と同一。
fetch ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する。
Sourcetreeの場合、初期設定では定期的に自動で fetch が行われる。
merge ... ブランチを統合する。
pull ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する。
さらに origin/master の内容を master に merge する。
fetch して内容に問題がなければ pull する…とすれば慎重な運用になる。
■コミットルール
細かなルールは各々や会社によって異なるが、一例として以下のようにするといい。
・GitHubやBitbacket上に課題を作成して、その課題番号をもとにブランチの作成やコミットを行う。
・ブランチ名の先頭には課題番号を付け、それに続いて課題内容を把握できる英数字を付ける。
・コミットのコメントの先頭には、「#」に続けて課題番号を付ける。
具体的には「PostgreSQLでマイグレーションを実行できない #104」という課題を作ったとして、
ブランチは develop から feature/104-pgsql_migrate_error を作成して作業し、
コミットは「#104 PostgreSQLでマイグレーションを実行できない不具合を修正」のようにコメントする。
このようにすることで、GitHub上ではコミットのコメントの「#104」から該当の課題に遷移できるようになり、管理しやすくなる。
課題の管理にBacklogなど外部ツールを使うこともあるが、その場合は一例として以下のようにするといい。
・Backlog上に課題を作成して、その課題キーをもとにブランチの作成やコミットを行う。
・ブランチ名の先頭には課題キーを付け、それに続いて課題内容を把握できる英数字を付ける。
・コミットのコメントの先頭には、課題キーを付ける。
具体的には「DEV-104 PostgreSQLでマイグレーションを実行できない」という課題を作ったとして、
ブランチは develop から feature/DEV-104-pgsql_migrate_error を作成して作業し、
コミットは「[DEV-104] PostgreSQLでマイグレーションを実行できない不具合を修正」のようにコメントする。
（ブランチ名やコミットに「DEV-」という接頭語を含めるか否かは、検討の余地がある。）