今日からわかった気になれるGitHub入門🌙

今日からわかった気になれる GitHub入門🌙

$ Whoami > ryu-ch どうもりゅーちゃんです 界隈では生きニキとか言われてます AzureとLoLと謎解きを広めることを生きがいにしています 心の奥底で企業間LoL大会を画策しております フレンド募集中🤝 X：@ryuuu_ch

$ Whois github.com ⚠界隈だとGitHubと書かないと取締りの対象なので要注意 ・GitとGitHubは別物ね ・そもそもGitはバージョン管理システムでありGitHubはリモートリポジトリの一種である

🤔

Git とは branch 1 v0.1 v0.2 v0.3 v1.0 v1.1 branch 2 Gitはバージョン管理ツール v0.1’ v0.3’ branch 3 Repository：追跡対象のフォルダ/ファイル Commit：ファイルの変更履歴 v0.1” v0.3” Branch：ファイルの並行変更 Merge：あるbranchのファイルの変更を別のbranchのファイルの変更に取り込むこと Commitを遡って過去の変更まで時間を戻すことも、 いきなり元のデータは弄りたくないけどコピーを作ってうまくいったら元のデータを変更したいときに超便利 REF：GitHub Flow

• https://docs.github.com/ja/get-started/using-github/github-flow

別に ・過去に戻りたいならCtrl+z連打で良くない？ ・コピー作りたいならファイルをコピーすれば良くない？

おい、その先は地獄だぞ ITリテラシ試験（2021年過去問/一般 前期） [問題] 一番新しいと思われるファイルを選びなさい。 1.資料.ppt 2.資料_最新.ppt 3.資料_20221008.ppt 3.資料_20221005_最新版.ppt 4.資料_更新版.ppt 5.資料_更新版.ppt のコピー 6.【最新】資料_20220930.ppt https://x.com/beConjuror/status/1578564467096694784

• https://x.com/beConjuror/status/1578564467096694784

現実は1人で仕事をしない Webアプリケーションとしての GitHubが現れた PullRequest：mergeをGitHub上でレビューを依頼してから行うこと merge 👍 merge 👍 merge 👍 main branch v0.1 v0.2 v0.1’ v0.3 v1.0 v0.3’ REF：PullRequestについて v0.1” REF：小規模開発チームのブランチ戦略。 GitHub Flowの導入 ※forkというrepository自体をコピーして行う開発フローもあるが割愛 REF：forking workflow bugfix branch merge ❌ v0.3” feature branch

• https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
• https://techblog.insightedge.jp/entry/branch-strategy-github-flow
• https://www.atlassian.com/ja/git/tutorials/comparing-workflows/forking-workflow

GitHubはコラボレーションのためのツール

変更には調査やら課題やらが付きまとう 変更は ”こういうことがしたい！ ”や、”こういうことで困っている！ ” が発端となる そういうときはGitHub Issuesで管理しよう 現実ではファイルの変更をする前に何をどう変更するか 変更による影響調査などが含まれることが多い こういうことがしたい！！を叶えるために何をしたのか実際にどのような変更をしたのかをコメントにして残すことができる！ Issue（課題や修正依頼、改善要求）があって PullRequest（ファイル変更）を出す、というケースが多い e.g.) 「オミクロン株情報」ボタンの設置 REF：GitHubのIssueの活用方法

• https://github.com/Tokyo-Metro-Gov/covid19/issues/6976
• https://book.st-hakky.com/hakky/github-issue

変更をする前に意思決定がある Issueはファイル変更にあたっての調査やら課題をテキストで残すところ ではなぜその変更をしようと決めたのか、前段に意思決定があるはず それを管理するのがGitHub Discussions e.g.) next.js discussions REF：GitHub Discussions について

• https://github.com/vercel/next.js/discussions/categories/ideas
• https://docs.github.com/ja/discussions/collaborating-with-your-community-using-discussions/about-discussions#github-discussions-について

DiscussionしてたくさんIssue出てきたんだけど カンバンボードで管理できるGitHub Projectsを使おう！ REF：Projectsのベストプラクティス

• https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects

まとめ 例えばこんな使い方 Discussions ・提案 ・投票 ・Q&A Issues ・課題タスク ・改善タスク ・バグ修正 PullRequest ・コード修正 Projects ・カンバンボード

もう一歩踏み込んでみる

で、このコード大丈夫そ？ エンジニアはファイルの変更のほとんどがコード変更になるわけで コードは変更しただけでは世の中に価値提供することができず、これを本番環境に適用 して初めて価値提供したと言える そこで出てくるキーワードがContinuous integration / Continuous Deployment （CI/CD）と呼ばれるプラクティス（方法論） REF：CI/CDとは何かをわかりやすく図解、具体的なツールや取り組み方とともに紹介す る

• https://www.sbbit.jp/article/cont1/81640

GitHub Actions 本番 / production(prod) PullRequestがMergeされると 動作を検証したくなる！ 検証 / staging(stg) / test 実態は特定のトリガーで動く自動化スクリプト e.q.) main / master branch PullRequest が Mergeされたら（これがトリガー） テスト環境に変更を反映 v0.1 v0.2 v0.3 v1.0 問題がないことを確認したら本番環境にも反映（これがスクリプト） v0.1’ v0.1” REF：GitHub Actions を理解する bugfix branch v0.3’ feature branch v0.3”

• https://docs.github.com/ja/actions/get-started/understand-github-actions

GitHubはコラボレーションのためのツールである 他にもコラボレーションのための機能がある ・GitHub Wiki ・GitHub Pages

• https://docs.github.com/ja/communities/documenting-your-project-with-wikis/about-wikis
• https://docs.github.com/ja/pages/getting-started-with-github-pages/what-is-github-pages