GitHubをちゃんと使おうって話

Transcript

1. GitHubをちゃんと使おうって話 らり
2. 対象者 • Gitを使ったことがある人 • GitHubを使ったことがある人 • ある程度Gitを使った開発をしたことある人 • ある程度Gitの仕組みを知っている人 • なんとな～くコマンドを知っている人
3. ごめんなさい めっちゃ詳しく説明しているわけでなく、上辺だけです もっと詳しい説明が欲しい方はコメントに書いてください
4. Gitって、何 Git（ギット）は、プログラムのソースコードなどの 変更履歴を記録・追跡するための分散型バージョン管理システムである。 ↓ ファイル管理システムじゃないよ https://ja.wikipedia.org/wiki/Git
5. Gitをどうやって入れる? 公式のインストールガイドがあるので、そちらをご覧ください https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
6. 作業の流れ 1. リモートサーバ等にある中心リポジトリをローカルに複製する (git clone)。 2. ローカルでコンテンツの修正・追加・削除を行い、ローカルリポジトリに変更履歴を 記録する (git commit)。必要に応じて過去の状態の閲覧や復元などを行う。場合 によってはこのステップを何度か繰り返す。 3. ローカルの変更内容を中心リポジトリに反映させる (git push)。作業者ごとの変更 内容が衝突することもある。Gitが自動で解決できる場合もあれば、手動での解決 (git merge）が必要なこともある。 4. 更新された中心リポジトリ（他者の作業内容も統合されている）をローカルの複製に も反映する (git pull)。これによりローカル環境のコードも最新の内容になるので、 改めてステップ2の作業を行う。 https://ja.wikipedia.org/wiki/Git
7. git clone 既存のリポジトリをローカル環境に複製するコマンド 大体、1案件に1回しか実行しない cloneする際に、保存するディレクトリやもってくるブランチを指定できたりする
8. git commit git addをした後、ローカルリポジトリにコミットするためのコマンド コミットメッセージと説明を一緒に載せることが出来る コミットメッセージ 説明
9. コミットメッセージって何 そのコミットで何を行ったかを書く また、他人が見たときにそのコミットで何を行ったかがわかるものを残す コミットメッセージだと長文になりそうなときは説明(Discription)に追記する 「何が、どうした」という感じの残し方が多い気がする レビューの修正時、メッセージに「修正」って残すのはやめよう https://gist.github.com/mono0926/e6ffd032c384ee4c1cef5a2aa4f778d7
10. • 戻したい単位 • 正常に動く単位 • ToDoリスト単位 コミットの粒度 https://qiita.com/jnchito/items/40e0c7d32fde352607be
11. 戻したい単位 git revert(コミットを打ち消すコマンド)をしやすい単位 例えばパッケージのバージョンをアップデートした時、package.jsonとyarn.lockが変更さ れる その時に全然関係ないプログラムの修正が入っていると、コミットを戻そうとしたらその 修正も一緒に戻すはめになる あ！この修正やめたい！って思った時に戻せるようにしよう
12. 正常に動く単位 コンポーネントであれば、ちゃんと表示される単位 機能であれば、ビルドが通る単位 関数であれば、返却内容の意味が変わる単位 どこまでを正常動作として区切りをつけるかは人による
13. ToDoリスト単位 issueにToDoリストを用意し、その粒度に合わせてコミットを行う ToDoリストがだめだと全て崩壊するが、ToDoリスト以外のことは行わないはずのため、 実装者は粒度を気にする必要がなく、レビューもしやすい
14. git push リモートリポジトリのブランチ履歴を更新するためのコマンド ただ、リモートリポジトリの子孫である時でないと実行できない git pullし忘れ等
15. git merge 分岐したブランチを統合するコマンド 分岐元のブランチとのコンフリクトがあると行えない
16. git pull リモートリポジトリにある変更を取得できる レビューする時にpullするのを忘れてて、あれ？変更されてない？ってなりがち
17. ソースコードをホスティングするソフトウェア開発のプラットフォーム コードのバージョン管理システムにはGitを使用 ↓ Gitと関係はないよ GitHubって、何
18. プラットフォームを有効活用しよう 例) とある開発フロー 1. issueを立てる 2. assignされた人が修正 3. ブランチを切り、修正をおこなう(ここで先ほどの説明のフローが入る) 4. pull requestを立てて、レビューをしてもらう 5. approveされたらマージ
19. issue 開発中の課題や、発生した問題を書くところ その内容についてディスカッションをすることもOK 共有メモや、ドキュメントを書く場ではない そちらはGitHub上のwikiに記載してください https://docs.github.com/ja/communities/documenting-your-project-with-wikis/about -wikis
20. issue 公式でドキュメントが準備されているのでそちらをご覧ください https://docs.github.com/ja/issues
21. issue issueはテンプレートを用意することが出来る https://docs.github.com/ja/communities/using-templates-to-encourage-useful-issue s-and-pull-requests/about-issue-and-pull-request-templates 「何」を書いてほしいかを考えて用意する issueの作成者はそれに沿って作ることが出来るので、記載漏れを事前に防ぐことがで きる
22. issue(やっておいた方がいいなと思うこと) • assignは実装者を入れる ◦ 誰が管理しているかがわかる • タイトルに角括弧([])で対象ページとかを書かない ◦ issueにはラベルをつけることができ、それで管理する ◦ ソートが出来るため、確認も容易
23. pull request 本開発への変更提案 レビューをすることで、その変更提案が問題ないかを確認してからマージする 人は何かしら間違えるので、「レビューする」ことによって変な修正が入らないように防ぐ ことが目的 ちゃんとレビューしてますか? てきとうに見ただけでOKにしてませんか?
24. pull request 今までマージはしたくないけどPRを立てたい場合(簡易的なコードレビューや、進捗状況 確認のため)には、タイトルにWIPって書くことが多かった 今では「Draft Pull Request」というものがあるので、それを使いましょう 逆に進捗を共有するためにも、毎度Draft Pull Requestを立てて、リーダーが確認しや すい状況にするのも1つだと思います https://github.blog/jp/2019-02-19-introducing-draft-pull-requests/
25. pull request 公式でドキュメントが準備されているのでそちらをご覧ください https://docs.github.com/ja/pull-requests
26. pull request pull requestはテンプレートを用意することが出来る https://docs.github.com/ja/communities/using-templates-to-encourage-useful-issue s-and-pull-requests/about-issue-and-pull-request-templates 「何」を書いてほしいかを考えて用意する pull requestの作成者はそれに沿って作ることが出来るので、記載漏れを事前に防ぐこ とができる
27. pull request それでも人は間違えるため、機械で自動的に確認をする方が望ましい CIをGitHub Actionsで行えるため、入れておくだけでも嬉しい https://knowledge.sakura.ad.jp/23478/ これで確認事項が通らなかった場合、レビューがOKでもマージをすることが出来ないた め、確認漏れによって変な修正が入ることを防ぐことが出来る
28. pull request 確認事項 • 関数のテスト • ちゃんとビルドが通るか • Lintで怒られていないか
29. pull request(やっておいた方がいいなと思うこと) • assignは実装者を入れる ◦ 誰が管理しているかがわかる • issueの番号を記載( - #<issueの番号>) ◦ 何の修正かが分かる • マージされた時に、自動的にブランチを消す ◦ また同じ名前のブランチが作成されても大丈夫なように
30. おわりに GitHubの管理の方法や実装方針は、入った人やプロジェクトの規模感により、ベストプ ラクティスがある訳ではありません そのため、先導者がいないと一瞬で崩壊し、後から入った人が何を行っているのかわか らない、見にくいリポジトリが出来上がります 特に、OPは高速で案件が回るため、急に人を補充した時に状況を説明する時間がな かったりする場合、状況把握のための1つの情報源にもなります なので、プロジェクト内でGitHubを扱う方々(主に実装者)のリーダーになる方は、この辺 りを先導してもらえると助かります
31. 課題 • GitHubの運用時に気を付けていること • 自身で使っているテンプレートやルール ◦ squash and merge • これは導入しておくべきだと思ったシステム ◦ wiki ◦ projects ◦ milestone • みんなが誤解してそうだなと思ったこと • 運用するのに参考になりそうなもの ◦ OSSのリポジトリはしっかりしてる