Git 2018 新卒エンジニア研修 R&D 菊池ま

アジェンダ ● 研修の目的（3min） ● Gitとは（10min） ● さあGitをはじめよう！（30min） ● Gitの概念（10min） ● さらにGitを使ってみよう（45min） ● 管理したくないファイル！？（10min） ● 歴史の改ざん・・・？（20min） ● GitHubを利用してみよう！（45min） ● ブランチの豆知識（10min）

研修の目的

研修の目的 ● Gitの利用の仕方を一通り体験し、開発時に利用 できるようにする ● モブによる体験をすることにより、各人各所の知 識の差を理解し極力埋めることができる

Gitとは？

ソフトウェアのバージョン管理 バージョン管理システムの最も基本的な機能は、ファイルの作成日時、変更日時、変更 点などの履歴を保管することである。これにより、何度も変更を加えたファイルであって も、過去の状態や変更内容を確認したり、変更前の状態を復元することが容易になる。 更に、多くのバージョン管理システムでは、複数の人間がファイルの編集に関わる状況 を想定している。商業的なソフトウェア開発やオープンソースプロジェクトなどでは、複数 の人間が複数のファイルを各々編集するため、それぞれのファイルの最新の状態が分 からなくなったり、同一ファイルに対する変更が競合するなどの問題が生じやすいが、 バージョン管理システムは、このような問題を解決する仕組みを提供する。ただし、バー ジョン管理システムを個人のファイル管理に使用することも可能であるし、ソフトウェアの ソースコードだけでなく、設定ファイルや原稿の管理などにも使うことも可能である。 出典：Wikipedia

集中型と分散型 分散型（Git）と集中型（SVN）と比較をしてみましょう。 分散型 集中型 両者の大きな違いはリポジトリを複数持てるかどうかです。Gitであれば開発の形態や規 模に合わせて複数のリポジトリを構成でき、システム構成を柔軟に作り上げることができ ます。 ＠IT：ガチで5分で分かる分散型バージョン管理システム Git (3/6) http://www.atmarkit.co.jp/ait/articles/1307/05/news028_3.html より引用

Git Git（ギット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散 型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるために リーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されて いる。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が 置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。 Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製 が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリに アクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うこ とができる。これが「分散型」と呼ばれる理由である。 Wikipedia：Git https://ja.wikipedia.org/wiki/Git より引用

さあGitをはじめよう！

基本操作 1. Gitで管理するディレクトリを作る 2. Gitで管理する 3. テキストファイルを作成（何か書き込む） 4. ファイルの変更をGitに伝える 5. 変更した内容を記録する 6. ファイルの内容を変更する 1 7. 変更したファイルの変更をGitに伝える 8. 変更した内容を記録する 9. ファイルの内容を変更する 2 10. 変更したファイルの変更をGitに伝える 11. 変更した内容を記録する 12. 変化があることを知る 13. --onelineオプションを使ってみる 14. ファイルを削除する 15. 最新の一つ前の状態に復元する 16. 最新の状態に復元する

みんなの環境を確認してみよう 1. 全員の環境を確認してみよう。 a. バージョン b. 名前とメールアドレス 2. 名前とメールアドレスが設定されていないかったら設定しよう

Gitの概念

大切な３つの領域 Gitには「作業フォルダ」「インデックス」「リポジトリ」の３つの領域がある。それぞれの領 域がどのように変化するのか正確に想像できると捗ります。 ● 作業フォルダ ○ OSが管理するファイルシステムのデータ保存場所で実際にターミナルなどから操作する。 ● インデックス ○ `git add` したときにGit形式のフォーマットで変更されたファイル情報を一時的に保存しておく場所。 ● リポジトリ ○ Gitが変更の歴史を蓄えている場所。コミットすると、Gitはそお時点のインデックスの状態を歴史の1 ページとしてリポジトリに追加する。 [導入メモ] GitHubを使うために、SVNユーザーがGitを調べた https://havelog.ayumusato.com/develop/others/e185-github-practice.html より引用

大切な1つの目印 Gitには「HEAD」という目印があり、HEADは最新の歴史の1ページ。最新のコミットIDを追 跡している。コミットIDとはコミットを管理するための40桁のコード番号。 1. HEADのコミットIDを取得する 2. ログと差異がないことを確認する

さらにGitを使ってみよう

さらに操作してみる 1. ファイル名を指定しないでコミットする 2. addとcommitを同時に行う 3. 新しいファイルを作成しコミットをする（-mオプションを利用しない） 4. コミットを中止する 5. インデックスの余分な変更をなかったことにする 6. 2つめのファイルを削除する 7. ファイルを変更する 8. 変更したファイルを最新のコミットに戻す 9. ヘルプを利用してみる 10. 最新のコミットメッセージを編集する 11. ファイルを変更する 12. 同じような編集なのでコミットログを増やさないでコミットしたい 13. ファイル名を変更してコミットする 14. 元のファイル名に戻す

管理したくないファイル！？

特殊なファイル Gitの管理下におきたくないファイルは、管理から除外する必要があります。例えばMac でfinderでファイルを操作したときに生成される.DS_Storeなど。 除外する方法は3つ 1. project/.gitignore a. プロジェクトを共有するメンバー全員が無視するべきファイルを設定できる。メンバー全員に関わる ものはここに登録する。 2. project/.git/info/excude a. 自分の環境のみに影響があるファイルはこちらに設定する 3. git config --global core.excludesfile $HOME/.gitexcludeと設定して $HOME/.gitexcludeに登録する a. ログイン中のユーザー全てで無視するファイルとして登録する

歴史の改ざん・・・!?

改ざんには注意して！ 1. いくつか前のコミットを打ち消す 2. いくつか前のコミットを削除したい 過去の歴史の変更が許されるかどうかは、基準が必要ですよね。基準がなく各自が勝 手に変更してしまうと歴史がめちゃくちゃになってしまいます。 次のように覚えておき、あとはチームで相談しましょう ● 他人が作ったコミットを含む歴史の変更はNG ● いったん公開したコミットを含む歴史の変更はNG ● つまり、未公開の自分が作ったコミットしかない歴史の変更はOK ● 所謂、git push前！

GitHubを利用してみよう！

GitHubとは？ GitHubは、その名の通り、「Git」の「ハブ：拠点・中心・集まり」です。 GitHubは、Gitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデ ザインデータなど)を保存、公開することができるようにしたウェブサービスの名称です。 GitHubはGitHub社という会社によって運営されており、個人・企業問わず無料で利用す ることができます。 GitHubに作成されたリポジトリ（保存庫のようなもの）は、基本的にすべて公開されます が、有料サービスを利用すると、指定したユーザーからしかアクセスができないプライ ベートなレポジトリを作ったりすることができます。

GitHubとの連携と基本的な操作 1. GitHubでレポジトリを作成 2. ローカルのレポジトリとリモートのレポジトリを連携させる 3. GitHubからコードを取得する 4. 他のメンバーがファイルを変更する 5. 他のメンバーの変更を取り込む 6. 競合状態を作り出し、その解消をする

歴史の分岐 Gitでは歴史の流れをいくつも分岐できます。その歴史の流れをブランチと呼びます。特 に指定しないかぎり、最初のコミットはmasterブランチにコミットされます。 1. 現在のブランチを確認してみる 2. 新しいブランチを作成する 3. 作成したブランチに移動する 4. ファイルを更新し、コミットする 5. 歴史を確認する 6. masterブランチに戻る 7. 歴史を確認する 8. 他のメンバーがファイルを変更する 9. ファイルの変更と取り込む

歴史の合流 1. 先ほど作成したブランチに移動する 2. masterブランチで取り込んだ変更を現在のブランチに取り込む 3. 現在のブランチでファイルをさらに変更してコミットする 4. 新しいブランチの変更をmasterブランチに合流させる

プルリクエスト 1. あらたにブランチを作成してファイルを更新する 2. ブランチをリモートブランチにpushする 3. プルリクエストを作成する 4. プルリクエストをapprouvedしマージする

ブランチの豆知識

ブランチの豆知識 ブランチとは、開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機 能のことです。このブランチの管理形式（ルール）のことをブランチモデルと呼び代表的 なモデルに下記の2つがあります。このほかにもチーム内で形成されたモデルなどがあ りますが、ルールに縛られて開発の足かせになっては本末転倒ですので、しっかり検討 し運用していく必要があります。 git-flow GitHub Flow

git-flow Git flowでは、それぞれ役割が振られているmaster, release, develop, feature, hot-fixの 5つのブランチを使い分けて、開発を進めていきます。 ● feature ○ 開発をおこなうためのブランチで、個々の機能 の実装やバグの解決をおこなう ● develop ○ 開発をおこなうためのブランチ ● release ○ リリース前に準備、微調整をおこなうブランチ ● master ○ リリースしたデータを置いておくブランチ ● hot-fix ○ リリースされているデータに、緊急の修正対応 をするためのブランチ LIG：Gitを最大限に活用できる 「Git flow」で、効率よく開発を進めよう！ https://liginc.co.jp/248864 より引用

GitHub Flow ● masterブランチのものは何であれデプロイ可能である ● 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: new-oauth2-scopes） ● 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定 期的に作業内容をpushする ● フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プル リクエスト を作成する ● 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへ マージすることができる ● マージをしてmasterへpushしたら、直ちにデプロイをする