Git 入門 研修コース に参加してみた

今回参加したコースは Git 入門です。
SE カレッジでは 2013 年に 「はじめての Git 」 というコースを開催しましたが、当時は参加人数がコンスタントに集まらず、開催を休止していた時期がありました。
それから数年、DX ( Developer Experience [開発体験] ) の盛り上がりをうけ、この 2019 秋冬のコースで復活です!
おかげさまで、3 回開催全てで満員です。ようやく Git や GitHub がエンタープライズ領域でも使われるようになってきたのかも知れません。
このコースでは、 Git 入門として、 Git の誕生背景、特に Subversion との違い、基本コマンドを CUI / GUI で演習しました。
では、コースの内容をレポートします。
もくじ
コース情報
想定している受講者 |
|
---|---|
受講目標 |
|
講師紹介
以前のレポートでも登場された 藤丸 卓也 さん が講師です。

またコースの冒頭で、藤丸さんから現在使っているバージョン管理システムは何か、受講者にアンケートしたところ、
- Subversion が 6 割
というところでした。また藤丸さんの印象としても大手は Subversion を使っている印象があるとのことで、 Git の導入はこれからなのかも知れませんね。
バージョン管理システムとは
まずは、「バージョン管理システムとは何か」からスタートです。
- バージョン管理システムとは?
- ファイルの作成日時、変更日時、変更点などの履歴を管理
- 以前のバージョンに復元可能
- ソースコードだけでなくドキュメントや設定ファイルなどの管理も可能
- ↑ この集まりをリポジトリという
- 管理の流れ
- 管理したいファイルをリポジトリ(データベース)に登録
- ファイルをリポジトリからローカルに取得(チェックアウト、クローン)
- ローカルでファイルを修正
- リポジトリに反映(コミット、プッシュ)
- 管理方式は大きく「集中型」と「分散型」の 2 種類
集中型、分散型それぞれのメリット、デメリット
メリット | デメリット | |
---|---|---|
集中型 | 管理がシンプル 作業を把握しやすい | サーバ障害時の影響が大きい |
分散型 | サーバ障害時でも作業を継続可能 ローカルで試行できる |
学習コストがかかる |
Git とは
Git の誕生から開発フロー、Git リポジトリのホスティングサーバなどを紹介いただきました。
- Git は分散型
- Linux の開発者 linus が 2 週間で開発したと言われる
- Subversion が嫌いで開発
- ネットワーク接続してないと開発できないなど柔軟性がないのがイヤだったとか・・・
- Subversion が嫌いで開発
- リビジョン管理はユニークな 40 桁のハッシュ値
- Subversion は 1, 2 ・・・ と連番
- Git は大まかに言うと差分管理を保管していない
- 差分を含めてファイルそのものを保管
- リンクで差分をつなげる
- これによりコミットの diff が見やすくなる
- Subversion は diff しか見れない
- このため容量が大きくなる
Git のアーキテクチャは 3 層
- 作業ディレクトリ
- ローカル (開発者) のリポジトリ
- ステージングエリア
- コミットするファイルを配置し、.git ディレクトリにコミット
- .git ディレクトリ (リモートにある)
- OK なら本番などの環境にプッシュする
Git の開発フロー
- ローカルでリポジトリを作成
- すでにあるディレクトリを .git にする
git init
- すでにあるディレクトリを .git にする
- or リモートにあるリポジトリをコピー
- ローカルにコピーする
git clone
- ローカルにコピーする
- ローカルリポジトリを変更
- 変更したいファイルをステージングエリアに追加
git add
- .git リポジトリに追加したいファイルを確定
git commit
- ここでコミットメッセージを入れる
git commit -m "メッセージ"
- ここでコミットメッセージを入れる
- 変更したいファイルをステージングエリアに追加
- リモートリポジトリに追加
- ステージングでコミットしたファイルをプッシュ
git push
- ステージングでコミットしたファイルをプッシュ
- 変更された .git リモートリポジトリを取得
-
git pull
-
変更のやり方
- ブランチを切って変更を行う
- .git リモートリポジトリにあるものが master
- リビジョン番号 ( 40 桁のハッシュ値)
- master から変更したいときにブランチ作成
git branch
- .git リモートリポジトリにあるものが master
- プッシュされた変更を反映する
git merge
Git サーバ
- .git リポジトリを保管するところ
- いろいろあるが GitHub がよく使われる
- GitLab もある
- ツールを入れると、開発効率が上がる
- テスト自動化フロー ( CI ) ツール
- 変更察知・取り込み -> ビルド -> テスト
- バグ管理まで含めることも出来る
Git コマンド
いよいよ Git コマンドを使って演習します!
このコースでは Alice と bob が Git を使って開発するというシーンを想定して演習します。
環境構築と演習準備
今回は Git for Windows を使います。
- 初期設定
$ git config global user.name "(ユーザー名)" $ git config global user.email "(メールアドレス)" $ git config global color.ui auto $ git config global list
- アリスとボブの作業用ディレクトリ( /work )を作成
- その中に /remote, /alice, /bob を作成
$ mkdir work $ cd work $ mkdir remote alice bob
- その中に /remote, /alice, /bob を作成
- /remote ディレクトリ内に /git-ex.git を作成 -> remote リポジトリとして初期化
cd remote $ mkdir git-ex.git $ cd git-ex.git $ git init --bare --shared # --bare は空のリモートリポジトリ, --shared は共有のオプション Initialized empty shared Git repository in c:\Work\remote\git-ex.git\
- /alice ディレクトリに /remote/git-ex.git を git-ex.alice として git clone
$ cd ..\..\alice $ git clone ..\remote\git-ex.git git-ex.alice Cloning into 'git-ex.alice'... warning: You appear to have cloned an empty repository. done.
ファーストコミット!
ディレクトリと Git の準備が整ったところで、いよいよ開発開始です!
- alice が空の README.txt を作成 -> ローカルリポジトリにファーストコミット
$ cd git-ex.alice $ copy nul README.txt $ git status ブランチ master 最初のコミット 追跡されていないファイル: (use "git add
..." to include in what will be committed) README.txt nothing added to commit but untracked files present (use "git add" to track) $ git add README.txt $ git status ブランチ master 最初のコミット コミット予定の変更点: (use "git rm --cached ..." to unstage) new file: README.txt $ git commit -m "first" [master (root-commit) 51cdbb1] first 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.txt $ git status ブランチ master Your branch is based on 'origin/master', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working directory clean $ git log commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名" Date: Tue Feb 04 10:06:25 2020 +0900 first $ git branch * master - alice が master ブランチをリモートにプッシュ
$ git push origin master # 慣習的に origin と表現されます Counting objects: 3, done. Writing objects: 100% (3/3), 207 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To c:\Work\alice\..\remote\git-ex.git * [new branch] master -> master $ git remote -v # -v で remote の状態を確認 origin c:\Work\alice\..\remote\git-ex.git (fetch) origin c:\Work\alice\..\remote\git-ex.git (push)
チーム開発!
今度は bob がファイルを修正して、チーム開発を開始です!
- その前に git clone
$ cd ..\..\bob $ git clone ..\remote\git-ex.git git-ex.bob Cloning into 'git-ex.bob'... done. $ cd git-ex.bob $ git branch * master $ git log commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名"
Date: Tue Feb 04 10:06:25 2020 +0900 first $ git status ブランチ master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean - トピックブランチ issues/#1 を作成
$ git checkout master # master ですが慣例的に。実行すると すでに master にいると表示されます $ git pull # 何もコミットされていませんが慣例的に。実行すると すでに up-to-date と表示されます $ git checkout -b issues/#1 # -b をつけると、ブランチを作って、そのブランチに移動します Switched to a new branch 'issues/#1' $ git branch * issues/#1 master
- bob がトピックブランチでファイルを変更 -> コミットメッセージ change1 でコミット
$ echo change1 > README.txt # change1 というテキストを表示して README.txt に書き加えます $ type README.txt # ファイルの中身を確認 change1 $ git status ブランチ issues/#1 Changes not staged for commit: (use "git add
..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: README.txt no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m "change1" # -a ですべての変更をコミット。なおファイルを追加した場合は入りません (注意) [issues/#1 57ac8c7] change1 1 file changed, 1 insertion(+) $ git log # --oneline でコミットが 1 行で表示され、--graph を使うと、ブランチがどこで切られたか視覚的に確認できます commit 57ac8c749c05bdfbf51ad2d06169b53801f29e61 Author: "ユーザー名" Date: Tue Feb 04 10:39:49 2020 +0900 change1 commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名" Date: Tue Feb 04 10:06:25 2020 +0900 first - bob がリモートにトピックブランチ issues/#1 をプッシュ -> alice にレビューを依頼
git push origin issues/#1 Counting objects: 3, done. Writing objects: 100% (3/3), 246 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To c:\Work\bob\..\remote\git-ex.git * [new branch] issues/#1 -> issues/#1
- alice がトピックブランチを git pull
cd ..\alice\git-ex.alice $ git branch * master $ git pull remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From c:\Work\alice\..\remote\git-ex * [new branch] issues/#1 -> origin/issues/#1 Already up-to-date. $ git branch -a # リモートも含めてブランチを全表示 * master remotes/origin/issues/#1 remotes/origin/master $ git checkout -t origin/issues/#1 3 # -t オプション (track(追跡)という意味) でブランチを取得して移動 Branch issues/#1 set up to track remote branch issues/#1 from origin. Switched to a new branch 'issues/#1' $ git branch * issues/#1 master $ git log commit 57ac8c749c05bdfbf51ad2d06169b53801f29e61 Author: "ユーザー名"
Date: Tue Feb 04 10:39:49 2020 +0900 change1 commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名" Date: Tue Feb 04 10:06:25 2020 +0900 first - 変更内容を確認
$ type README.txt change1
- LGTM 👍 だったので alice がローカルの master へ merge
$ git checkout master $ git pull Switched to branch 'master' Your branch is up-to-date with 'origin/master'. $ git log # master にはブランチがまだ取り込まれていない状態 commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名"
Date: Tue Feb 04 10:06:25 2020 +0900 first $ git merge issues/#1 Updating 51cdbb1..57ac8c7 Fast-forward README.txt | 1 + 1 file changed, 1 insertion(+) $ git log commit 57ac8c749c05bdfbf51ad2d06169b53801f29e61 Author: "ユーザー名" Date: Tue Feb 04 10:39:49 2020 +0900 change1 commit 51cdbb1ace28d2c4c689207b17503153d2b8f279 Author: "ユーザー名" Date: Tue Feb 04 10:06:25 2020 +0900 first - トピックブランチ issues/#1 を merge した master をリモートにプッシュ (ここは開発チームにおいて誰が merge するか分かれるところです)
$ git push origin master Total 0 (delta 0), reused 0 (delta 0) To c:\Work\alice\..\remote\git-ex.git 51cdbb1..57ac8c7 master -> master
Git におけるブランチのマージ
ここで、いったんGitの操作から離れ、先程のマージ merge について補足いただきました。
git merge
には 2 種類ある- Fast-Forward
- Git のデフォルト
- Non-Fast-Forward
- 実際に使う場合は Non-Fast-Forward の方がよい
- Fast-Forward
前の git コマンド演習でも出てきていましたね。
$ git merge issues/#1
Updating 51cdbb1..57ac8c7
Fast-forward
README.txt | 1 +
1 file changed, 1 insertion(+)
エクスプローラ上での Git の操作
続いて、エクスプローラと GUI ツールを使ってみます。
- Git の GUI ツール
- Git に標準で付属する Git GUI
- ちょっと使いにくい
- Source Tree
- GitHub や Google のアカウントが必要
- Tortoise Git
- Git に標準で付属する Git GUI
- 今回は Tortoise Git を使用
なお、 Tortoise Git は、Tortoise SVN と同じ UI のため、 Tortoise SVN を利用したことがある人なら、あまり違和感なく使えるそうです。
GUI で操作
Turtoise Git を使って先の演習でやったコマンドをやってみましたが、ここでは簡単にどんな雰囲気だったのか、キャプチャで紹介します。
- git clone
- git commit
- git push
- git pull
コンフリクトの発生と解消
チーム開発していると宿命的に発生するのがコンフリクト (競合) です。
- コンフリクトとは
- 複数人が同じファイルに対して異なる変更 -> プッシュ -> 齟齬が発生する
実際に先の GUI ツールを使って、コンフリクトを発生させ、解消してみました。
- コンフリクト発生 ( README.txt で発生)
- コンフリクトを確認
- コンフリクトを解消 (alice のコミットに変更)
チーム開発を行なっているとコンフリクトは常なので、こまめにローカルリポジトリを更新する習慣が必要のように見えます。
この Tortoise Git に加えて、Eclipse から Git を利用できるプラグイン EGit でもやってみたところで、このコースは修了しました。
まとめ
このコースでは、およそ 3 時間で Git の基本的な使い方を学びました。
冒頭の通り、Git にはコマンドがたくさんあり、オプションも多く学習コストが高い ( = やらかしも多い) のですが、このコースでは主要なコマンド絞にり、また視覚的に理解しやすい GUI ツールを使って、とにかくハードル低く入門できるようにしました。
今回の GUI ツールをはじめ GitHub for Desktop など GUI ツールは、とにかく敷居を下げてくれるので、GUI で出来ないことを徐々に CUI でやって慣れていくのも一つなのだなぁと感じました。
次は GitHub などを使って、実際に Pull Request -> Merge して、コンフリクトもバシバシ発生させたあと、日常的に git rebase するようなチーム開発編、受講してみたいですね。
label SE カレッジの無料見学、資料請求などお問い合わせはこちらから!!
label SEカレッジを詳しく知りたいという方はこちらから !!

IT専門の定額制研修 月額28,000円 ~/ 1社 で IT研修 制度を導入できます。
年間 670 講座をほぼ毎日開催中!!

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。