未経験でも使い方がわかる! Git & GitHub 入門|研修コースに参加してみた
今回参加したコースは 未経験でも使い方がわかる! Git & GitHub 入門 です。
以前、 SE カレッジのウェビナーで登壇された星野リゾートのプロダクトオーナーの方も開発未経験ながら GitHub で Issue を書いて開発に参加しているなど、どんどん GitHub の利用の垣根が下がってきています。
星野リゾートがこだわった「内製化」-現場出身メンバーが躍進するプロダクトオーナーチーム|SEカレッジ ウェビナーレポート
開発者の GitHub でのやり取りを見ていると、とてもオープンで楽しそうな雰囲気があり、参加してみたくなってしまいます。 とはいえ、 GitHub を使う前に Git です。
今回はその Git と GitHub の使い方を、ナント開発未経験からでもわかるというコースでした。 果たしてド文系の私でもプルリクエストのデビューができたのでしょうか!?
では、どのような内容だったのか、レポートします!
もくじ
コース情報
想定している受講者 | 基本的なパソコンの操作(スムーズに文字入力をする、ブラウザを使う、指定したソフトウェアでファイルを編集する)ができること |
---|---|
受講目標 |
|
講師紹介
この「参加してみた」レポートでは初登場となる よこな さんこと、 横田 紋奈 さんが登壇されました。
横田 紋奈ihcomega
JFrog Japan 株式会社 デベロッパーアドボケイト
規模、カルチャー、業種の全く異なる 3 社にてバックエンドエンジニアを務めた経験をいかし、技術的な広報や啓蒙、レクチャーなどを担当。
プライベートでは IT エンジニア向けコミュニティを運営。「 Java 女子部」運営スタッフ、「日本 Java ユーザーグループ」幹事として、イベント開催や登壇を行う。
「 Software Design 2022 年 4 月号 特集 堂々と使える! 人に教えられる! 本質から学ぶ Git 」(共著 技術評論社 刊)
「いちばんやさしい Git & GitHub の教本 第 2 版 人気講師が教えるバージョン管理&共有入門」(インプレス 刊)
なぜ、バージョン管理?
まずはバージョン管理がなぜ必要なのか、というところからです。 ここは以前、別のレポートでも触れているので軽く紹介します。
- バージョン管理をする理由
- リリース後、バグがあっても前のバージョンに戻すことができる
- 共同作業で競合してもバージョンを変えて作業しやすくする
- バージョン管理ツールを使う理由
- 人間が行うと、例えば、ファイル名の命名は好き勝手なルールになる
- バージョン管理の仕組み
- リポジトリにバージョンを記録する
- リポジトリ = 保管庫のようなもの
- 分散バージョン管理と集中バージョン管理がある
- 集中: リモートのサーバにリポジトリがある ex. Subversion
- 分散: リモートと各マシンに自分専用のリポジトリがある ex. Git
- 分散バージョン管理のメリット
- 人のリポジトリに干渉しない
- ローカルでも作業できる
- リポジトリにバージョンを記録する
ファイル名での管理、本当に好き勝手になってしまいますよね。
また Git を 2 週間で開発したリーナスさん ( Linux の開発者でもある) は Subversion がオフラインで開発できないのが嫌で、 Git を開発したという逸話があります。
Git のバージョン管理でやっていることは主に 2 つ
では、具体的に Git ではどのようにバージョン管理をしているのでしょうか。
- やっていることは主に 2 つ
- 自分のローカルリポジトリからリモートリポジトリに自分の変更内容を送る
- 自分のローカルリポジトリにリモートリポジトリから他の変更を取り込む
- リポジトリの作成
- ディレクトリで指定する
- .git というディレクトリができ、そこに情報が保存される
- コミットという単位でバージョン管理する
- コミット = (変更を)記録すること
- コミットするとローカルのリポジトリに記録される
- つまり作業しているディレクトリ( = ワークツリー)とローカルリポジトリがわかれている
- ローカルリポジトリに変更を送ったり、ローカルリポジトリから変更を受け取っている
なるほど、ローカルにもリポジトリがあり、それとワークツリーがやり取りするようなイメージなのですね。
また、 よこな さんからはコミットはできるだけ小さくしたほうがよいと、現場でのアドバイスとその理由をいただきました。
コミットまでの流れ
続いて、先程の “コミット” までの進め方です。
- 変更したファイルからコミットするものを選ぶ
- ローカルリポジトリの 3 つの場所
- ワークツリー: 作業場所
- ステージングエリア: 変更対象待機場所
- Git ディレクトリ: コミット
- ファイルの 4 つの状態
- untracked: 新規作成
- staged: ステージングエリアに入れた状態
- unmodified: staged からコミットした状態( unmodified はまだ前回から修正されてない という意味)
- ローカルリポジトリの 3 つの場所
- Git コマンドで場所とファイルの状態を変える
- どこに戻したいかわらなくなったら、見よう
場所とファイルの状態を変える Git コマンドを一覧できるスライドが非常に重宝するものでした! 同じようなことをするように見えるコマンドが割りと多いので、これは慣れないうちは手放せないものです。 ぜひコースに参加してゲットしてください!
続いて、よくやってしまいがちなこととして、 .gitignore の使い方を紹介いただきました。
-
.gitignore
- Key やパスワードなどの共有しない情報は .gitignore ファイルに入れる
- ファイルとディレクトリで指定できる
GitHub にホストしたリポジトリに key やパスワードが発見されると GitHub からアラートがきますが、それでも時々、事故になっていますので、気をつけねばなりませんね。
【 50 種類以上のクラウドサービスに対応】 GitHub のセキュリティ機能 Secret Scanning を実際にキーを流出させて試してみた | DevelopersIO
リポジトリの作成からコミットまで演習
では、ここまで学んだことをもとに演習しましょう!
- git の設定情報を登録
-
git config
を使う- 名前
git config --global user.name "名前"
- メールアドレス
git config --global user.email "メールアドレス"
- 名前
- 登録情報を確認
$ git config --list
- 削除するときは –unset オプションをつける
git config --global --unset user.name
-
- 作業ディレクトリ git-practice を作成して移動
- git ディレクトリにする
$ git init Initialized empty Git repository in /home/user/learn_git/git-practice/.git/
git status
で状態を確認$ git status ブランチ master No commits yet nothing to commit (create/copy files and use "git add" to track)
ここまででリポジトリが作成できました!
続いて、ファイルをつくり、実際コミットしてみましょう!
- 作業用ファイル memo.txt を作成 / 自由に書き込み / 保存
- ファイルであればよいので、ソースコードじゃなくても OK
- ステータスを確認
$ git status ブランチ master No commits yet 追跡されていないファイル: (use "git add
..." to include in what will be committed) .history/ memo.txt nothing added to commit but untracked files present (use "git add" to track) git add
でステージングエリアに追加$ git add memo.txt $ git status ブランチ master No commits yet コミット予定の変更点: (use "git rm --cached
..." to unstage) new file: memo.txt git commit
でローカルリポジトリにコミット$ git commit
- vi エディタが立ち上がる
- “initial commit” とコミットメッセージを書いて保存
$ git commit [master (root-commit) 016b855] Initial Commit 1 file changed, 1 insertion(+) create mode 100644 memo.txt
git log
でコミットを確認$ git log commit 016b8550fd276604f9a13f0a05f8bb17363ebd38 (HEAD -> master) Author: my_account
Date: Mon Aug 29 15:17:42 2022 +0900 Initial Commit
コミットできました! 先に 3 つの場所を教えてもらっていたので、何をしているのかとてもわかりやすいですね。
ブランチ
ブランチは開発者でなくとも、一度は聞いたことがある開発用語ですね! これも基本から解説いただきます。
- ブランチとは枝分かれしたバージョンのこと
- リポジトリ作成すると main ( or master ) ができる
- Git / GitHub では master という呼称をやめて main を使うようになった( Git は 2.28 以降のバージョンから)
- ブランチをつくって、ブランチにコミットを追加する
- ブランチをつくることを “ブランチを切る” という
- 使用中のブランチを HEAD という
- ブランチを統合するときには マージ merge と リベース rabase がある
- マージ: ブランチを main に取り込む
- コミット履歴が見にくい
- リベース: ブランチを main にする
- コミット履歴が見やすい
- マージ: ブランチを main に取り込む
リベースをするとコミットハッシュが変わってしまうため、もとに戻せないことが発生します。
# コミットハッシュ
commit 016b8550fd276604f9a13f0a05f8bb17363ebd38 (HEAD -> master)
マージとリベースどちらがよいかは開発チームの方針によって変わるとのことでした。 これは以前にも同じような論争が起こっていましたね。
記事
[あなたは merge 派? rebase 派?綺麗な Git ログで実感したメリット – BIGLOBE Style | BIGLOBE の「はたらく人」と「トガッた技術」]
記事へのコメントも分かれ気味
[[B! git] あなたは merge 派? rebase 派?綺麗な Git ログで実感したメリット – BIGLOBE Style | BIGLOBE の「はたらく人」と「トガッた技術」]
コンフリクト
そして、 Git 初めての人がビビってしまうコンフリクトです。
- 複数のブランチで同じファイルの同じ箇所を変更すると起こるのがコンフリクト
- マージやリベース、プルしたときに起きがち
- 機械的には判断できないので、どうするかは人が決める
ただし、 よこな さんからは「何も怖いことはなにもありません」とフォローがありました。 … 本当ですか !?
ブランチ作成からマージまで演習
では、ここでも学んだことを演習してみましょう。 ブランチを切ってコミットまでやってみます。
git branch
でブランチの確認$ git branch * master
*
は自分がいるところ
git branch
でブランチ first-branch を作成して確認$ git branch first-branch $ git branch first-branch * master
git checkout
でブランチを移動して確認$ git checkout first-branch Switched to branch 'first-branch' $ git branch * first-branch master
- 作業ファイル memo.txt を編集して保存
git status
->git add
してステージングに追加git commit -m
でコミットメッセージをつけてコミット$ git commit -m "add Learn Git" [first-branch 3566a0b] add Learn Git 1 file changed, 2 insertions(+), 1 deletion(-)
- git commit に -m オプションをつけると、 vi を開かずにコミットメッセージをつけられる!
- ログを確認
$ git log commit 3566a0b501d38fed298fec9b321951ccf8e004d2 (HEAD -> first-branch) Author: my_account
Date: Mon Aug 29 15:46:36 2022 +0900 add Learn Git commit 016b8550fd276604f9a13f0a05f8bb17363ebd38 (master) Author: my_account Date: Mon Aug 29 15:17:42 2022 +0900 Initial Commit - master との差分を確認
$ git diff master diff --git a/memo.txt b/memo.txt index 5e1c309..795beaf 100644 --- a/memo.txt +++ b/memo.txt @@ -1 +1,2 @@ -Hello World \ No newline at end of file +Hello World +Learn Git \ No newline at end of file
ブランチにコミットするまでできました。
ここから行う作業は例の “コンフリクト” を体験する準備です。 別のブランチを作って、こちらもコミットします。
- ブランチを新たに追加するため master に戻る
$ git checkout master Switched to branch 'master'
- ブランチ second-branch を作って移動
$ git checkout -b second-branch Switched to a new branch 'second-branch'
- git checkout に -b オプションをつけるとブランチを作って移動する
- ステージング -> コミットまでを行う
$ git commit -am "change history" [second-branch ab37e0d] change history 1 file changed, 2 insertions(+), 1 deletion(-)
- git commit の -am オプションで git add してコミットメッセージをつけられる
- ただ git add 時にコミットするファイルを選ぶことが多いので、現場ではあまり使わないかもしれない
コンフリクトの準備ができたところで、先に first branch のマージをやってみましょう!
- master に移動して first-branch をマージする
$ git checkout master Switched to branch 'master' $ git merge first-branch Updating 016b855..3566a0b Fast-forward memo.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
- ログを確認
$ git log commit 3566a0b501d38fed298fec9b321951ccf8e004d2 (HEAD -> master, first-branch) Author: my_account
Date: Mon Aug 29 15:46:36 2022 +0900 add Learn Git commit 016b8550fd276604f9a13f0a05f8bb17363ebd38 Author: my_account Date: Mon Aug 29 15:17:42 2022 +0900 Initial Commit
まずはマージを体験しました!
コンフリクトの解消を演習
いよいよコンフリクトです!
- second-branch をマージ -> コンフリクトが発生
$ git merge second-branch Auto-merging memo.txt CONFLICT (content): Merge conflict in memo.txt Automatic merge failed; fix conflicts and then commit the result.
- memo.txt を見てみる
<<<<<<< HEAD Hello World Learn Git ======= Hello Git It's Memo >>>>>>> second-branch
- memo.txt を編集
Hello World Learn Git It's Memo
- 状態を確認
$ git status ブランチ master You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add
..." to mark resolution) both modified: memo.txt no changes added to commit (use "git add" and/or "git commit -a") - both modified がコンフリクトの決まり言葉
- master のまま git add / git commit してマージ
よこな さんがおっしゃられた通り、冷静にただ整理すればよいだけのことなのでした。 ビビらずいけ。
GitHub とは
今度は GitHub です。 まずは GitHub の基礎的な事項を学びます。
- GitHub ができること
- リモートリポジトリを作成できる Web サービス
- 他開発者と共同作業できる
- そのほか、 Issue 管理や CI/CD などができる
- GitHub のリポジトリ
- パブリックとプライベートが選べる
- お決まりのファイルが作成できる
- .gitignore や README など
- 利用するコマンド
git push
でローカルからリモートへgit fetch
でリモートからローカルへ-
git pull
は作業ブランチまで取ってくる
-
- リモートリポジトリは origin という名前がつく
GitHub フロー
では、 GitHub を使って、どのように開発を進めるのか見てみましょう。
git clone
でリモートリポジトリをローカルにコピーする- 作業するための専用ブランチ(トピックブランチ)をローカルに作る
- トピックブランチを main にプッシュする
- GitHub 上でプルリクエストにする
- (慣習的にブランチの他の開発者によるレビューが行われる)
- レビュー <-> 修正が完了後、マージ
そういえば、 git-flow というのもあったな、と見てみると、こちらはちょっと腰を据えて勉強しないといけないものでした。
プルリクエスト (Pull Request (PR) 、プルリク) とは
これまた一度は聞いたことがある開発用語、 プルリクエスト です。
- マージできるかレビューするための GitHub の機能
- プルリクエスト画面上のコメントを通して議論する
- マージだけでなく他の統合ができる
- リベースやスカッシュ (squash)
- スカッシュ とはブランチのコミットを一つにすること
スカッシュは開発に慣れてない人にはありがたいですね。
プルリクエストというと、使っている OSS でエラーがあって調べていると、よく GitHub の Issue やプルリクエストでとっても長ーーーーーいコメントのやり取りを見ることがありますよね。 そのやり取りの中には、こういうワークアラウンドがあるよ、とかコメントしている開発者もいて、とても助かります。 開発者はやっぱりオープンな人が多いなと思います。
いつか私もプルリクエストを出して OSS 開発デビューをしたいですね。
フォーク ( fork )とは?
先程は git clone で自分のローカルにコピーしてきましたが、同じような機能でフォークがあります。
- GitHub の機能で、リポジトリを自分のアカウントにコピーする(ローカルコピーではない)
- オリジナルにプルリクエストを送ることもできる
「え、これ何か意味がある?」と思っていると、 よこな さんからこれは OSS 開発に参加するときによく使われるとのことでした。 なるほど! コピー元の OSS に何の影響も与えないので、確かに安心です !!
GitHub でリモートリポジトリを作成~プルリクエストデビューしてみよう
では、これまた学んだことをもとに、実際に GitHub でリポジトリ作成 ~ プルリクエスト ~ マージまでしてみましょう!
- github.com で [ + ] ボタンを押してリモートリポジトリ作成画面を開く
- 名前などオプションを選択
- 作成
いえい、できました!
続いてローカルにコピーしてプッシュするまでやってみます。
- github.com のリポジトリ画面の右上 [Code ▼] ボタンから Web URL をコピー
git clone
でローカルにコピー$ git clone https://github.com/sezemiadmin/practice-github-repo.git Cloning into 'practice-github-repo'... remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (5/5), done. remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (5/5), 3.94 KiB | 310.00 KiB/s, done.
- README.md を編集
- コミットして git push でリモートリポジトリにプッシュ
$ git push origin edit_README Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 377 bytes | 377.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), completed with 1 local object. remote: remote: Create a pull request for 'edit_README' on GitHub by visiting: remote: https://github.com/sezemiadmin/practice-github-repo/pull/new/edit_README remote: To https://github.com/sezemiadmin/practice-github-repo.git * [new branch] edit_README -> edit_README
では、 GitHub でリモートブランチを開いてみましょう。
- github.com のリポジトリの画面からプルリクエストを開く
- プルリクエストを編集・作成する
- プルリクエストをいろいろ見てみる
- diff など
- diff など
- マージする
プルリクエストデビューできました!
では、変更をローカルリポジトリに反映してみましょう。
- main に移動して差分を確認後、
git pull
で変更を取り込む$ git checkout main Switched to branch 'main' Your branch is up to date with 'origin/main'. $ git diff origin/main $ git pull remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), 658 bytes | 219.00 KiB/s, done. From https://github.com/sezemiadmin/practice-github-repo fd60f16..8ff9d1f main -> origin/main Updating fd60f16..8ff9d1f Fast-forward README.md | 2 ++ 1 file changed, 2 insertions(+)
- git log で確認
$ git log --oneline 8ff9d1f (HEAD -> main, origin/main, origin/HEAD) Merge pull request #1 from sezemiadmin/edit_README f358ca6 (origin/edit_README, edit_README) プルリクエストの練習 fd60f16 Initial commit
- –oneline オプションでコミットが一行で表示される
ここまで進めたところで、このコースは修了しました。
まとめ
このコースでは Git の使い方を学んで演習というのを繰り返し、最後は GitHub のリポジトリにプルリクエストを出しました。
ボリュームのある内容だったので、プルリクエストできるのだろうかと少し心配になったのですが、 よこな さんが開発現場での話もポンポン入れながらテンポよく進められ、最後のプルリクエストまでできました。 プルリクエストデビューができて、大満足です!
DX 時代は開発者だけでなく、開発者出身ではないプロダクトマネージャも Git / GitHub を使う時代です。 このコースは Git 未経験はもちろん開発未経験の方でも、しっかりプロダクト開発の進め方がわかるものでした! LGTM 👍👍
label SEカレッジを詳しく知りたいという方はこちらから !!
IT専門の定額制研修 月額 28,000 円 ~/ 1社 で IT研修 制度を導入できます。
年間 670 講座をほぼ毎日開催中!!
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。