Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Basic lecture of Git & GitHub

Basic lecture of Git & GitHub

Explanation of Git & GitHub for who use Git & GitHub for the first time. (in Japanese)

GitとGitHubの用語や使い方の解説。
GitとGitHubに初めて触れる方が対象です。
厳密な表現よりは初心者の理解を優先している旨を理解していただけると助かります(私が理解していないだけ)。
参考文献: https://www.amazon.co.jp/dp/B07JLJSDMJ/

予定していた日に講座が終わらなかったため、最終的に別日に2日かけて、前編後編各1時間程度で講座を行っています。
何か誤り等ございましたらご指摘頂ければ幸いです。
個人・公的機関での学習・講義用途であれば、本スライドはご自由にご利用いただいて構いません。いずれにせよ、利用に際してご連絡をいただけると有難いです。

Kaoru Chisen

August 26, 2018
Tweet

More Decks by Kaoru Chisen

Other Decks in Technology

Transcript

  1. Git/GitHub 基礎講座
    Kaoru @cordx56
    cordx.net

    View full-size slide

  2. 2
    目次 - 前編

    導入
    – Git/ バージョン管理システムとは
    – Git の利点

    Git の仕組み
    – リポジトリ
    – branch
    – merge
    – commit
    – staging
    – pull/push

    View full-size slide

  3. 3
    目次 - 後編

    リモートリポジトリを使った開発
    – clone
    – pull/push
    – 共同開発での利用

    GitHub の活用
    – Fork
    – Issue/Pull Request
    – GitHub Pages を使ってみよう

    View full-size slide

  4. 4
    導入
    Introduction of Git

    View full-size slide

  5. 5
    導入 - Git とは

    バージョン管理システムの一種

    バージョン管理システムとは?
    – コンピュータ上のファイルの変更履歴を管理するための
    システム
    – 場面にもよるが,こういった場で言うときは,大抵
    ソースコードの管理をするためのもの
    バージョン管理システムがあると何が嬉しい?

    View full-size slide

  6. 6
    導入 - バージョン管理システムとは

    プログラミングをしていると,ソースコードの変更を
    細かく記録しておきたいことはよくある
    – 皆さんはもう使わないけど残しておきたいコードや
    新しい実装をする前に念の為確実に動く古いコードを
    コメントアウトで残して可読性を下げたりしたことは
    ありませんか?
    – あるいは,
    ver1.zip ,配布 .zip ,最新 .zip , 08/26 最新 .zip
    とか,ソースコードをまとめて zip ファイルにして
    結局混乱したり,古いバージョンからの変更点が
    わからなくなったことはありませんか?

    View full-size slide

  7. 7
    導入 - バージョン管理システムとは

    バージョン管理システムを活用すると,こういった
    手動でのバージョン管理で消耗する必要がなくなる

    バージョン管理システムのログを叩けば,
    変更点と変更日時,添えられたコメントを
    見ることができる
    – いらないコードをコメントアウトで残す必要がなくなる

    あるいは,一気に過去のソースコードまで遡って,
    過去のソースコードの途中から開発を再開したり,
    変更を細かく追ったりすることもできる
    – よりわかりやすい形で過去の状態を参照できる

    View full-size slide

  8. 8
    導入 - バージョン管理システムとは

    この辺の利点は特に共同開発で強い味方になる

    共同開発だと,コードの同じ部分を同じタイミングで
    編集してしまい,変更がだいぶ蓄積してから,じゃあ
    みんなのコードを一つにまとめましょうという段で,
    とてつもない量のコードがどんな変更を経てそうなった
    のかわからなくなってしまう例もある
    – 締切直前とかに手作業で問題が起きないように大量の
    コードを集約するのは地獄の図

    バージョン管理システムを上手く使うことで,各自の
    変更点が明確になったり,こまめにソースコードを
    集約できたりして,共同開発のコストを減らせる

    View full-size slide

  9. 9
    導入 - バージョン管理システムとは

    ここまでをまとめると
    今日からは
    バージョン管理システムを使って
    上手く開発していこう

    View full-size slide

  10. 10
    Git の仕組み
    Terms and Behaviour of Git

    View full-size slide

  11. 11
    Git の仕組み - リポジトリ (repository)

    ソースコードのバージョンを管理するデータベース単位

    ローカルとリモートの 2 種類がある

    ローカルリポジトリ
    – 開発者のパソコンにある,手元でいじるリポジトリ
    開発者が手元で作業するためのもの

    リモートリポジトリ
    – サーバ上にある,遠隔から管理するリポジトリ
    共同開発で共有して利用できる

    View full-size slide

  12. 12
    Git の仕組み - リポジトリ (repository)

    最初に,開発者はリモートからリポジトリをクローン
    して,あるいはローカルでリポジトリを作成して,
    手元にあるローカルリポジトリとする

    クローンしてきたリポジトリの場合,
    既にリモートリポジトリとの紐づけがされている

    ローカルでリポジトリを作成した場合は,リモートリポ
    ジトリを紐づけをする必要がある
    – リモートリポジトリには,デフォルトで origin
    という名前が使われる

    リモートリポジトリは,複数人で共同で開発を行うとき
    に特に活用する

    View full-size slide

  13. 13
    Git の仕組み - リポジトリ (repository)

    カレントディレクトリでローカルリポジトリ初期化

    リモートリポジトリとの紐づけ
    [email protected]... の部分は適宜変更してください
    ( 後編で説明します )
    $ git init
    $ git remote add origin
    [email protected]:SIT-DigiCre/idrs-slack

    View full-size slide

  14. 14
    Git の仕組み - branch

    本流から分かれる枝のイメージ

    branch 間でコードの変更は共有されない
    – branch を分けることで,本流の開発,
    同時進行するトピックが別の開発に影響を与えずに
    開発を進めることができる

    特に共同開発の場面では,異なるトピックについて
    同時に同じコードをいじると,混乱が発生することは
    容易にわかる
    – トピックごとに branch を分けて,実装が終わった
    段階で本流に merge するのが一般的

    View full-size slide

  15. 15
    Git の仕組み - branch

    ブランチ作成 ( ここではブランチ名を impl-i2c とする )

    ブランチ移動

    ブランチ作成 & 移動 ( 上記 2 ステップを一括実行 )

    ファイルを変更してコミットしてからブランチを
    移動すると,他のブランチではファイル変更の影響を
    受けていない様子が確認できる
    $ git branch impl-i2c
    $ git checkout -b impl-i2c
    $ git checkout impl-i2c

    View full-size slide

  16. 16
    Git の仕組み - merge

    branch 間のコードの差異を吸収し,一つの branch に
    まとめること

    git merge コマンドは,今いる branch に,指定した
    branch の変更を取り込む

    merge commit を作ることができる

    自動で吸収できない差異があった場合 (2 つの branch
    でコードの同じ位置を更新していた場合など ) ,
    conflict が発生し,手動でどちらのコードにまとめるか
    決定して commit する必要がある

    View full-size slide

  17. 17
    Git の仕組み - merge

    master ブランチに impl-i2c ブランチをマージ

    上のコマンドでは,場合によってはマージコミットが
    生成されない
    – 常にマージコミットの生成を強制する
    (Fast-Forward マージをしないようにする ) には
    以下のコマンドを利用する
    $ git checkout master
    $ git merge impl-i2c
    $ git checkout master
    $ git merge --no-ff impl-i2c

    View full-size slide

  18. 18
    Git の仕組み - commit

    ファイルの変更とそれに対するコメントをリポジトリに
    記録すること

    コミットが Git で管理される変更の最小単位
    – 関数の実装や小さなバグ修正など,比較的小さな
    単位の変更に切り分けてコミットをすることが
    推奨される ( コード変更の意図がわかりやすくなる,
    頻繁に pull/push できるなどの理由が挙げられる )

    staging area に登録されている変更を記録
    – stage については次のスライドで解説

    View full-size slide

  19. 19
    Git の仕組み - staging area

    次にコミットする対象となる変更を登録する場所

    git add コマンドを利用して,ファイルの変更を
    staging に乗せる = stage する

    全ての変更の中から特定の変更を staging area に
    乗せる / 乗せないを分けることで,どの変更を
    同じ commit に乗せるかを選択することができる

    View full-size slide

  20. 20
    Git の仕組み - stage & commit

    main.py ファイルの変更をステージする

    ステージされた全ての変更にコメントをつけて
    コミットする
    – -m はコミットメッセージをコマンド中で明示して
    コミットする,というオプション

    -m をつけずにコミットすると,テキストエディタ
    が起動して,長いコミットメッセージを入力する
    ことができる

    message の m
    $ git add main.py
    $ git commit -m “Implement I2C communication”

    View full-size slide

  21. 21
    Git の仕組み - pull/push

    pull
    – 指定したリモートリポジトリのブランチを取得し,
    ローカルリポジトリの今いるブランチに取得した
    ブランチをマージすること

    push
    – ローカルリポジトリのコミットを指定した
    リモートリポジトリのブランチに反映させること

    pull と push は頻繁にしよう
    – 特に共同開発では, pull と push を怠るとトラブルが
    発生しやすくなる

    View full-size slide

  22. 22
    リモートリポジトリを使った開発
    Development with Git remote repository

    View full-size slide

  23. 23
    リモートリポジトリの意義

    Git は「分散型」と呼ばれる仕組みでバージョン管理を
    行う
    – 対するのは「集中型」であり, SVN などがある
    – 集中型ではリポジトリは常にサーバ上にあるもの
    1 つのみであり,開発者は常にサーバと通信をして
    ソースコードの取得,変更をする
    – 分散型ではサーバ上のリモートリポジトリ,手元の
    ローカルリポジトリなど,複数のリポジトリを利用
    して開発を進める

    何故 2 つの方式があるのか?

    View full-size slide

  24. 24
    リモートリポジトリの意義

    集中型ではリポジトリは常にサーバ上にあり,複数の
    リポジトリが存在しないため各種操作が簡単な反面,
    ソースコードの取得,変更に常にサーバとの通信を
    必要とする
    – もしリポジトリを持つサーバが落ちてしまったら?

    GitHub もたまに落ちる

    分散型では複数のリポジトリを利用するため,各種操作
    が複雑になりがちだが,サーバとの通信は最終的に
    変更をリモートリポジトリに反映させたい時のみで良い
    – ローカルで ( サーバが落ちても ) 作業可能
    – 手元の変更をよく検討してからリモートに送れる

    View full-size slide

  25. 25
    リモートリポジトリの意義

    Git は分散型

    開発者は,基本的にローカルで行った変更をローカル
    リポジトリにコミットし,ある程度蓄積したところで
    リモートリポジトリにプッシュする
    – 常に通信が発生するわけではないので,効率が良い
    – リモートとローカルでリポジトリが分散している
    ため,リポジトリ操作等が必要になり,開発者は
    多少複雑な操作をする必要がある
    – Git はブランチを切る,マージするためのコストが
    SVN に比べ非常に低く,気軽にブランチを切って開
    発を進めやすいという利点がある.

    View full-size slide

  26. 26
    リモートリポジトリ - clone

    既存のリモートリポジトリをローカルリポジトリとして
    ダウンロードすること

    既存プロジェクトに参加する場合や,別のコンピュータ
    で作業を開始する時に行う
    – HTTP で clone( 認証不要 )
    – SSH で clone( 要認証 )
    $ git clone https://github.com/SIT-DigiCre/
    idrs-slack/
    $ git clone [email protected]:SIT-DigiCre/
    idrs-slack/

    View full-size slide

  27. 27
    リモートリポジトリ - 新規作成

    13 番スライドと同等の内容

    ローカルリポジトリを作成して,リモートリポジトリに
    origin と名前をつけて結びつける
    $ git init
    $ git remote add origin
    [email protected]:SIT-DigiCre/idrs-slack

    View full-size slide

  28. 28
    リモートリポジトリ - pull/push

    pull
    – 指定したリモートリポジトリのブランチを取得し,
    ローカルリポジトリの今いるブランチに取得した
    ブランチをマージすること
    – pull の後は特定条件下で省略可

    push
    – ローカルリポジトリのコミットを指定した
    リモートリポジトリのブランチに反映させること
    – push の後は特定条件下で省略可
    $ git pull origin master
    $ git push origin master

    View full-size slide

  29. 29
    リモートリポジトリ - pull/push

    pull/push のデフォルト挙動はアップストリームの設定
    で変更可能

    これで, pull/push の後を省略しても,ローカルの
    master ブランチで pull/push を行えば,自動的に
    origin の master へ pull/push されるようになる.

    アップストリームの設定確認は次のコマンドで可能
    $ git branch -u origin/master master
    $ git branch -vv

    View full-size slide

  30. 30
    リモートリポジトリ - 共同開発での利用

    共同開発では,サーバにリモートリポジトリを置いて,
    それを基軸に開発を進める
    – リモートリポジトリからクローンするか,又は
    ローカルリポジトリからリモートリポジトリを作成
    – 開発を進め,ローカルリポジトリにコミットを積む
    – 適切なタイミング(一日の開発の終わりや 1 つの
    機能実装,マージなど)でリモートにプッシュする
    – 次に開発を続きからやるときは,リモートからプル
    することで他の人の開発進捗をローカルにとり込み
    開発を継続する

    このサイクルが Git リモートリポジトリを利用した開発
    の基本的な流れとなる

    View full-size slide

  31. 31
    リモートリポジトリ - 共同開発での利用

    Git で共同開発する典型的な作法のようなものはある
    – コミットは比較的小さい変更単位で行う

    変更履歴の確認など様々な面で利点がある
    – トピックが違う開発を進めるときには,基本的に
    ブランチを切る

    頻繁に変更が衝突したり,実装途中のコードが
    master に混じったりさせないため
    – 頻繁に pull/push を行う

    進捗管理ができ,相互にレビューもしやすくなる
    ため,プロジェクト全体の効率向上に寄与する

    細かい決まりはプロジェクトごとに取り決めると良い

    View full-size slide

  32. 32
    GitHub の活用
    Practical use of GitHub

    View full-size slide

  33. 33
    GitHub の活用 - GitHub とは

    Git 向けリポジトリホスティングサービス

    リモートリポジトリのサーバを提供してくれるサービス

    公開リポジトリであれば,無制限に作成可能
    – 学生であれば非公開リポジトリも作成可能

    簡単に申し込めるのでオススメ

    講座の後に、無料アカウントでも非公開リポジトリを
    作成できるようになりました。やったね!

    これに加えて強力なソーシャル機能が加わる
    – GitHub の前のロゴには「 Social Coding 」とある

    View full-size slide

  34. 34
    GitHub の活用 - Fork

    Fork は既存のリポジトリのコピーを自分のアカウント
    に追加できる

    既存のリポジトリのコピーを自分のリポジトリとして
    扱える
    – 自由にコードの改変ができるようになる

    そのまま元のリポジトリとは別の派生プログラムとして
    開発を続けることも可

    Fork したリポジトリから,元のリポジトリの管理者に
    PullRequest を投げることで,自分の改変を元の
    リポジトリに取り込んでもらうことも可

    View full-size slide

  35. 35
    GitHub の活用 - Issue

    直訳すると「問題」

    GitHub では,ソースコードの行やコミットに対して
    問題点を別に記述し,共有することができる
    – これを Issue と呼ぶ

    共同開発でのコミュニケーションや実装課題の管理に
    非常に便利
    – 個人で ToDo 管理などに利用している例も見る

    GitHub のリポジトリを開いて,上部のタブから Issues
    を開くことで見られる

    View full-size slide

  36. 36
    GitHub の活用 - Issue

    View full-size slide

  37. 37
    GitHub の活用 - Issue

    基本的な利用の流れは次のようになる
    – タイトル,問題点など議論すべきことを書いて,
    必要に応じて Assignees (担当者)と Label を付加
    して, Issue を発行する
    – 以降,この Issue に関係するコミットには Issue 番号
    をコミットメッセージに書いてコミットすると良い
    – 必要に応じて Issue にコメントをつけていくことで,
    議題について話し合うことができる
    – Issue の議題が解消されれば, Close する

    この辺の慣習も詳細はプロジェクトごとに取り決めて,
    開発者全員で共有すると良い

    View full-size slide

  38. 38
    GitHub の活用 - Issue

    コメントに @ アカウント名 /@ 組織名を含めると
    通知を送れる

    Issue の対応が終わるコミットのコミットメッセージを
    – fix #Issue 番号
    – closed #Issue 番号
    – resolved #Issue 番号
    などにすると,自動で Issue を閉じることもできる

    他にも色々な機能があるので,調べてみて欲しい

    View full-size slide

  39. 39
    GitHub の活用 - PullRequest

    PullRequest は Issue にコミットを付加したもの

    リポジトリの管理者に,別ブランチや別リポジトリの
    変更を該当リポジトリに取り込んでもらう為に使う

    基本機能は Issue と一緒

    PullRequest の強い点は,他の人が簡単に開発に関与
    できるようになること
    – 他の人が改善したソースコードを送ってきたり
    – 自分が他の人に改善したソースコードを送ったり

    これらの開発コミュニケーションを円滑にしてくれる

    View full-size slide

  40. 40
    GitHub の活用 - PullRequest

    PullRequest が飛んできたら
    – 飛んできた PR からコミットの変更点をレビュー
    – 必要に応じてコミュニケーションを取る
    – 問題がなさそうであればマージ

    他人のソースコードを変更したくなったら
    – Fork する or ブランチを切る
    – 変更をする
    – 元リポジトリの管理者に対して PullRequest を発行
    – コミュニケーションを取りつつ,マージしてもらう

    View full-size slide

  41. 41
    GitHub の活用

    他にも開発者を支援する機能が沢山あります
    – Projects
    – Wiki
    – Insights

    詳細な説明は省きますが,調べてみてください
    – 活用できるといいですね!

    View full-size slide

  42. 42
    GitHub Pages を使ってみよう
    Try to use GitHub Pages

    View full-size slide

  43. 43
    GitHub Pages を使ってみよう

    ここからは Git/GitHub に触れてみよう!のコーナー
    – 多分 Git は実際に触って慣れたほうが早い
    – 慣れれば便利なので使うようになる

    多分

    ここでは,プロジェクトの Web サイトを公開するのに
    利用できる「 GitHub Pages 」の機能を利用して,
    自分のホームページを作りながら, Git/GitHub に
    親しんでいきましょう

    View full-size slide

  44. 44
    GitHub Pages を使ってみよう

    大まかな手順
    – 「 [ 自分のアカウント名 ].github.io 」という名前で
    リモートリポジトリを作成
    – index.html という名前で HTML ファイルを作成
    – GitHub 上のリモートリポジトリにプッシュ
    – http://[ 自分のアカウント ].github.io/ にアクセス!
               Success!

    View full-size slide

  45. 45
    GitHub Pages を使ってみよう

    詳しい手順例
    $ mkdir [ アカウント名 ].github.io
    $ cd [ アカウント名 ].github.io
    $ git init
    $ echo “Hello, world!” > index.html
    $ git add index.html
    $ git commit -m “init commit”
    $ git remote add origin
    [email protected]:
      [ アカウント名 ]/[ アカウント名 ].github.io
    $ git push origin master

    View full-size slide

  46. 46
    GitHub Pages を使ってみよう

    わからないコマンドはスライドを振り返るとだいたい
    書いてあります
    – ググりをするなどして解決しても良い
    – その方がいいか……

    公式にいい手順紹介ページがあります
    – https://pages.github.com/

    とりあえず使ってみよう!
    – 慣れが大事な印象です

    View full-size slide