既存のissueに取り組む場合

1. issueを探す (※1)
2. ローカルのマシンでdevelopブランチをpullする
3. developブランチをcheckoutする
4. ローカルのマシンでブランチをdevelopの最新コミットから作成する (※2)
5. 必要な改変を加える (※3)
6. gitでcommitする (※4)
7. 必要なだけ繰り返して、sbtでビルドを走らせる
8. ビルドが通ったら自分のGitHubのレポジトリへpushする (※5) (※6)
9. Pull Requestを作成する (※7)
10. GitHub側のビルドが通ることを祈る (※8)
11. レビュワーがレビューするのを待つ。

• Approvedされたらほとんど何もしなくて良い。
• Change Requestedされたら指摘された部分の修正を加える。

※1: :bulb: good first issueは簡単と判定されたissueのラベルです。初めて取り組まれる方はこちらからとりくまれると良いかもしれません。

※2: featureという名前でブランチを作成したと仮定しますが、名前は何でも良いです。ただし、わかりやすい名前であることが推奨されます。

※3: 例えばREADMEの誤字修正や、新規機能の実装など

※4: コミットメッセージは記入することが必須なので、わかりやすい要約など (例: [fix] アイテムが増えるバグの修正) を記してください。ただし、コミット履歴についている[fix]、[update]、[delete]など (正規表現で言えば^\[[a-z]+\](?=.*)$) の部分はつけなくても構いません。

※5: 例えばKisaragiEffectiveならKisaragiEffective/SeichiAssist

※6: ただし、GiganticMinecraft/SeichiAssistに書き込み権限を持っている場合は、GiganticMinecraft/SeichiAssistにpushすることもできます。

※7: バグ修正を含む場合は close #12345 などをつけるほうが望ましい。

※8: 通常はローカルのビルドが成功したならGitHubのビルドも成功する。