Git の基礎勉強〜Git によるバージョン管理を使う〜

Size: px

Start display at page:

Download "Git の基礎勉強〜Git によるバージョン管理を使う〜"

あおいてっちがわら
5 years ago
Views:

1 バージョン管理システム ( 初者向け )

2 Git の基礎勉強 Git によるバージョン管理を使う

3 はじめに最近 Git( ギット ) が多くの開発現場で利されていますこれまでは Subversion を利していたところも分散バージョン管理である git に移していますノート : tracpath は 2011 年 6 のバージョンアップで分散バージョン管理の 2 製品 git / mercurial に対応しましたはじめてバージョン管理システムを利する初学のからすでに開発に使っているまでこれまでのバージョン管理にべ圧倒的に便利だという反バージョン管理の利点と使いはなんとなくわかるが分散バージョン管理はよくわからないという声があります私もgitの利を開始した当初は Index? HEAD? なにそれ? 状態でした流のオープンソースの場合インターネットにたくさんの情報があり有な本語訳も提供されていますでもバージョン管理という新しい概念を学ぶときは初めての語が多くそもそもどのような検索キーワードで検索すればよいのか公式マニュアルも専語の羅列でなんかよくわからないというも多いのではないでしょうか分散バージョン管理も同じように新しい語や概念が存在しておりそれがなんとなくわかっているけどまだよくわからないに繋がっていると思いますこのチュートリアルで分散バージョン管理のモヤモヤを解消できるように解説したいと思います git の基礎勉強ではつまずきやすい分散バージョン管理の考えと git の基本的な使いを解説します考えさえ理解すればあとは実践あるのみですとてもパワフルな分散バージョン管理 git の世界にようこそ Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 3

5 分散バージョン管理の考え git 初めの歩初めの歩として git を運するとき共有リポジトリという考えを理解しておく必要があります共有リポジトリとは複数でリポジトリを共有して開発をうときに開発者全員が参照し開発の元になるリポジトリです中央リポジトリともいいますここで初めて出てきたキーワードリポジトリについて解説するとリポジトリとはファイルの貯蔵庫のことですバージョン管理したいファイル群を格納しておく箱となりますノート : 企業では部などで共有ファイルサーバをつかってオフィス書を共有することがありますこの共有サーバでみんなで共有されるファイルと同じようなものと考えて下さい Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 5

6 分散バージョン管理の考え共有リポジトリの絵をて説明が必要なキーワードがあります作業ディレクトリ作業ディレクトリとは共有リポジトリから取得したローカル環境のリポジトリです Working Directory ともわれますがここでは作業ディレクトリとします作業ディレクトリは共有リポジトリと同じ構成のあなた専のファイル群です由に追加編集しても良いファイルであり git をつかった開発ではこの作業ディレクトリ上で開発を進めることになりますコミットコミットは新規作成したファイルや編集したファイルを保存することを意味しています新しい機能を追加したときやバグを修正したとき作業ディレクトリ上で区切りついた時にコミットしてそれまでの作業を旦保存しますファイルの変更後ファイルを保存した上でコミットをいますここまで共有リポジトリはみんなで共有する切な箱です開発を進めるときは作業ディレクトリをつかって開発していきます作業ディレクトリで開発を進めて区切り毎に保存する操作をコミットといいます Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 6

7 分散バージョン管理の考え git をつかった作業の流れ git を使った開発を進めるために説明しておく必要がある 3 つの重要なキーワードがあります通常の開発は作業ディレクトリ上でうことは説明しました作業ディレクトリでった機能追加やバグ修正を共有リポジトリに反映する必要がありますこの反映する作業のためにいくつかの段階と特殊な語があるため git: 分散バージョン管理の分かりにくい点があります 1. 作業ディレクトリ (Working Directory) 共有リポジトリと同じファイルがローカルに展開されファイルの追加修正をうディレクトリ 2. 索引 (Index) コミットするためにファイルを索引に追加しコミット予定のファイル群を記録しますこのコミット対象のファイルを索引に追加する操作はステージングコミット予定管理対象とわれます 3. 作業最後のコミットを指す HEAD git は作業ディレクトリでコミットがわれると master ブランチと呼ばれる作業ディレクトリを作ります master ブランチは直近のコミットを指しす意味を持っていますこの後コミットを繰り返す度に master ブランチの指しす場所は進んでいきます HEAD とは作業ディレクトリでコミットされた最後のコミットを指すことを意味すると覚えておいて下さい Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 7

9 分散バージョン管理の考えコミットを作業ディレクトリで実し [master] ブランチが新しいコミットに移動しますここまでの流れはすべて作業ディレクトリでいますこの時点では共有リポジトリには反映されていません古いコミット [98ca9] から HEAD として記録されたコミット [c2b9e] までを共有リポジトリに反映するための操作が必要です Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 9

10 分散バージョン管理の考えリポジトリの作成とクローンこれまでの git をつかった作業の流れをコマンドでてみましょう共有リポジトリがない場合リポジトリを作成することができますリポジトリの作成は git init を実しますこれで初期リポジトリが作成出来ます通常は開発メンバーで緒に開発を進めることが想定されるため共有リポジトリを利する場合が多いでしょう共有リポジトリを利して開発を進める場合クローン (clone) して作業ディレクトリをローカルに作成します Subversion などはチェックアウト (checkout) を実していましたが分散バージョン管理 Git はクローン (clone) しますこのクローンはサーバが保持しているデータをほぼすべてローカルにコピーしますこれはプロジェクトのすべてのファイルのすべての履歴が元にコピーされることを意味しています他の開発者に影響を与えずにブランチを作成したりできる分散管理バージョンのメリットです作業ディレクトリを作成するコマンドは git clone を実しますこれで共有リポジトリからローカルに作業ディレクトリを作成します Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 10

11 分散バージョン管理の考えファイルの追加 & コミット作業ディレクトリで変更したファイルを索引に追加します ( コミット準備管理対象にする ) git add <filename> または git add * # 変更があったファイルをすべて索引に追加しますこれで編集したファイルが索引に追加されましたそれでは変更内容をコミットします git commit -m " 初めてのコミット " 変更内容が索引からコミットされ HEAD に格納されましたまだ共有リポジトリには反映されていないことに注意して下さい Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 11

12 分散バージョン管理の考え共有リポジトリにプッシュする編集内容がローカルの作業ディレクトリ内で HEAD に格納されていますあなたの変更を共有リポジトリに反映させる必要があります反映させるために利するコマンドは push( プッシュ ) です git push origin master origin は共有リポジトリを指しす名前ですコマンドの解釈としてマスタブランチにコミットされた HEAD の内容を共有リポジトリに送信するとなりますプッシュ (push) して共有リポジトリに作業ディレクトリのコミットをします HEAD の解説で使った図をもう度てみますプッシュ (push) を実します git push origin Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 12

13 分散バージョン管理の考えプッシュ (push) した所までのコミット [98ca9][34ac2][f30ab][c2b9e] が共有リポジトリに反映されますプッシュ (push) を実した後も開発は継続しますさらにコミットを繰り返した場合作業ディレクトリにまだプッシュ (push) していないコミットが溜まっていくことになります溜まったコミットを共有リポジトリに反映されるためにプッシュ (push) をいますローカルでリポジトリを作成 (git init) や共有リポジトリからクローン (clone) していない場合共有リポジトリを登録することができます git remote add origin <server> 登録後に共有リポジトリにプッシュ (push) してください Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 13

14 分散バージョン管理の考え共有リポジトリから最新をプルしマージする共有リポジトリはあなた以外の開発メンバーもコミットプルします他のメンバーが追加した機能や修正したファイルを分の作業ディレクトリに取り込むことができますこの操作をプル (pull) といますプル (pull) とは他のメンバーがコミットした内容は共有リポジトリに反映されます共有リポジトリの最新情報を取得し (fetch) 分の作業ディレクトリと統合 (merge) することを意味していますあなたの作業ディレクトリを最新のコミットに更新するには git pull を作業ディレクトリで実しますこの操作は共有リポジトリの最新情報を取得し作業ディレクトリの状態に統合 (merge) します Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 14

16 ブランチの考え基本的な流れでマスタブランチを説明しました git をつかった開発ではブランチを必ず利しますこのブランチを理解することが git による分散バージョン管理の特ですブランチを利するのはどのようなときでしょうか通常は最初のコミットで git が動的に作成するマスタブランチ (master branch) を利しますこのブランチが標準のブランチとして機能していますブランチを切り替えて利するタイミングはマスタブランチと関連のない機能を実装するときに利されるのが般的ですブランチはあなたの好きな名前を付けることができますこれはマスタブランチと関連のない機能を開発する場合に何のためのブランチか分かりやすいような名前を付けることができますブランチを作成する例マスタブランチで開発をしていますが過去リリースしたコミット済のある機能について性能向上が期待できるロジックを思いつきましたしかしほんとうにうまくいくのか実際に試してみるまでわかりません試験的に試すだけなので間違っても共有リポジトリに反映させることは検証が終わってからになりますこのようなマスタブランチの開発とは関係ない機能を試す場合に利するのが般的なブランチの利法です Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 16

17 ブランチの考えブランチの基本とマージ開発の現場で発する状況としてはすでに本番稼働しているサービスがあり最初のバージョン (1.0) がエンドユーザに提供されています開発チームは新しい機能 ( バージョン 1.1) を開発している状況を考えてみます 1. リリースされたバージョン 1.0 が稼働 2. 開発チームは新しいブランチを作成しバージョン 2.0 の開発を実施 3. すでにバージョン 2.0 の開発は進んでいる時に本番稼働しているバージョン 1.0 に重な障害がみつかり早急に対応が必要となった 4. バージョン 2.0 のブランチをバージョン 1.0 のブランチに変更する 5. 修正適のためのブランチを 1.0 から作成する 6. 修正ブランチで問題を解決し修正ブランチをバージョン 1.0 のブランチにマージする新しいバージョン 1.1 ができる 7. マージしたバージョン 1.1 を共有リポジトリにプッシュ (push) する 8. 問題の解決後作業途中のバージョン 2.0 ブランチに戻り開発を継続する Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 17

18 ブランチの考え 1. サンプルシステム 1.0 が稼働あなたはサンプルプロジェクトの開発チームです無事サンプルシステム 1.0 がリリースされましたこれから運チームがサンプルシステム 1.0 を管理運していきます 2. 新プロジェクトのスタート早速エンドユーザから要望が挙がってきましたこの要望を機能仕様としてまとめ新プロジェクトサンプルシステム 2.0 の開発がスタートします 2.0 のために 1.0 から新しいブランチ new- 2.0 を作成し開発を進めていきます Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 18

19 ブランチの考え 3. 運チームより重な障害報告サンプルシステム 2.0 の開発は順調に進んでいますが運チームから重な障害報告がバグ管理システムに挙がってきました早急に対処する必要があります ( 開発がスタートした 2.0 のブランチに対してメンバーから新しい機能が追加され何度もコミット / プッシュされている状態をイメージしてください ) Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 19

20 ブランチの考え 4. サンプルプロジェクト 2.0 の開発を旦中断してバグ対応サンプルプロジェクト 2.0 の開発は途中ですが旦ストップして早急にバグに対処する必要がありますバグの対処のためサンプルシステム 1.0 の master ブランチから障害対応のための bugfix ブランチを作成します Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 20

23 ブランチの考え 7. マージした新しいバージョンをリリースそれではバグ対応版 (1.1) をリリースしますこれで運チームから緊急対応依頼された問題は解決しましたお疲れ様でした今回のマージは fast foward( ファストフォワード ) といますこれは bugfix ブランチが master ブランチの親にあたるため master ブランチの指しす場所を前 (C6) に進めただけです 2 つのブランチ master と bugfix は同じバージョンを指していますノート : バグ対応が完了した bugfix ブランチは削除することをオススメします警告 : master ブランチ (bugfix ブランチと同じ ) でったバグ対応の修正は new-2.0 ブランチ ( 新バージョンの開発プロジェクト ) には含まれていませんこの状態のまま new-2.0 ブランチの開発を継続しても良いですがいつか new-2.0 ブランチの内容を master にマージする必要がありますもうつの法として master ブランチの内容を new-2.0 ブランチにマージする法もあります Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 23

24 ブランチの考え 8. new-2.0 ブランチに戻り新プロジェクトの開発を継続 1.1 版としてリリースしましたローカルの作業ディレクトリのブランチを切り替えます master ブランチから new-2.0 ブランチに切り替え新プロジェクトの開発を進めますブランチの利法の例を説明しました git は CUI での操作が多く実際のブランチ作成切り替えマージ処理は図でることができません視覚的にバージョンの遷移をることができればブランチ機能の理解を助けてくれます最近は Windows 向け Mac 向けに優れた git クライアントが数多くリリースされています CUI が苦なは GUI の git クライアントを利することをお勧めしますよく利される git クライアントツールは別のコンテンツで基本的な使いを解説する予定です Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 24

25 ブランチの考えマージの基本もの凄く奥が深いマージすべての機能をいきなり理解することはとても無理と思えるくらいのボリュームがありますマージ (merge/rebase) はよく理解していないが操作したことによって履歴の喪失などのリポジトリを破壊してしまうことがあります操作を間違えてしまいリポジトリを破壊してしまった git でトラブルが発して開発が停してしまったこれはリベース (rebase) コマンドをつかったときに起こりやすいトラブルで git を使っているは経験したことがあるのではないでしょうかそのためマージ / リベース操作を実するユーザを特定ののみに制限し他の開発者はマージ / リベースをしないという針をとっている開発チームも多いと思います規模がきい開発チームの場合技術者のスキルにきな差があるためログの喪失リポジトリの破壊につながる操作は許可しないが賢明ですマージ (merge) の基本について説明しますマージは枝分かれしたブランチを 1 つに統合することをいますコミットされる度にブランチは 1 つずつ版を重ねていくことになりますがコミットは 1 ファイルだけではなく複数のファイルが含まれていますそのためマージ処理とは 1. 同ファイルにわれた変更を統合する 2. コミットに含まれるファイル全体を統合することを意味していますブランチの説明でファストフォワード (fast forward)= 早送りがありますがこれはマージ処理法の説明ですマージ処理は 1. ファストフォワード (Fast-Forward) 2. ファストフォワードしないマージ (Non Fast-Forward) 3. リベース (rebase) きく 3 パターンのマージ処理があります Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 25

26 ブランチの考え 1. ファストフォワード (Fast-Forward) ファストフォワード (Fast-Forward) は早送りという意味ですどういうことか? これまでの例を参考にてみます master をチェックアウトしている状態ですこの状態で bugfix をマージします git merge bugfix c6 が master にマージされて master が c6 に移動しましたマージしたが新しいコミットは作られずブランチの位置が移動しただけですだから早送りといいます Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 26

28 ブランチの考えマージによって新しいコミット c7 ができますファストフォワードしないマージとは早送りと違って新しいコミットを作成し枝分かれした履歴を保持した状態で c7 を作成します同じコマンドを実してもファストフォワードとファストフォワードしないマージと異なる動作をしていますがこのあたりは git が賢く動作してくれます git merge <branch-name> 早送り (Fast-Forward) できればする無理なら普通 (Non Fast-Forward) のマージ git merge --no-ff <branch-name> 普通の (Non Fast-Forward) マージ git merge --ff-only <branch-name> 早送り (Fast-Forward) マージ Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 28

29 ブランチの考え 3. リベース (rebase) リベース (rebase) はマージの 1 種類ですこれまでのコミットグラフをつかって以下の状態をてくださいここでマージを実すると Non ファストフォワードしないマージ (Fast-Forward) になって c7 を成しますではリベース (rebase) をするとどうなるのでしょうか想定シナリオとして本番稼働して master ブランチのバグ対応版である c6 を取り込んだ上で new-2.0 ブランチの開発を継続するです Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 29

30 ブランチの考えリベースによってどうなったか動作をてます 1. c3 の差分をパッチ (3) にする 2. c4 の差分をパッチ (4) にする 3. c5 の差分をパッチ (5) にする 4. new-2.0 ブランチを c2 から c6 に移動 5. パッチ (3) を適して c3ʼ 6. パッチ (4) を適して c4ʼ 7. パッチ (5) を提供して c5ʼ という処理をいます枝分かれしていた c2 から新しい c6 から枝がでてきました枝分かれしている元を再指定しているのでリベース (rebase) となりますリベース (rebase) はローカルにのみ存在するブランチに対して操作するほうがよいです共有リポジトリを使っている場合ブランチ new-2.0 は複数メンバーで共有されている可能性がいためリベース (rebase) してしまうと共有リポジトリに push できなくなります強制的に上書きすることはできますがバージョン管理システムを利している開発では版の履歴がとても重要です共有リポジトリではリベース (rebase) しないというルールを作ることをオススメしますマージとリベースはこちらの情報を参考にしていますこわくない Git Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 30

31 ブランチの考えコンフリクトマージをおこなうとコンフリクト (conflict) = 衝突が発する場合があります衝突とはマージを実したとき同じファイルの同じに違う変更をしていたブランチとブランチをマージした場合をいますこれはどちらの変更 ( ブランチ ) を採するか git はわからないため利者の判断が必要になるためです pull を実したときもコンフリクトは起こる可能性がありますプル (pull) はフェッチ (fetch) とマージ (merge) をっているためですコンフリクトが起こった場合どうすればよいのでしょうか? まずは焦らず落ち着きましょう git はコンフリクトが発したときコンフリクトが解決するまで処理を停します ( マージは正常に終わっていないことになります ) git はコンフリクトが発したときどこのソースコードで発したのか詳細な情報を提してくれます提された内容のどちらを採するのか判断するだけでコンフリクトは解消します 1. git status git status コマンドでマージ失敗したソースコードを確認し作業で修正しましょうこの作業を繰り返しコンフリクトが解決するまで直す必要がありますコンフリクトを解決して安しても作業終了ではありません修正したソースコードに対して索引 (index) に追加する必要があります (git add)index に追加して git にコンフリクトを修正したことを通知します最後にコミットを実してコンフリクトは解決です Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 31

32 最後に分散バージョン管理の概要が理解できたでしょうかクローンからプルしてマージコミットしてプッシュするこれは git の基礎勉強として分散バージョン管理の考えを説明しました git にはブランチタブマージなど開発を強にサポートしてくれる強な機能をたくさん持っていますぜひ git をあなたの開発に取りれて下さい Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 32

33 リンクと資料次に読むことをオススメ Pro git git 簡単ガイドこわくないGit リモートリポジトリを使うなら tracpath( トラックパス ) が便利です! 下記記事をぜひご参照下さい tracpath( トラックパス ) を使って安全に複数名でバージョン管理をう学習サイト LearnGitBranching Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 33

34 tracpath( トラックパス ) のご紹介社内サーバにリモートリポジトリを作るのもつですが開発にまつわる倒事をこの際全部 tracpath( トラックパス ) に任せてみませんか? バージョン管理サービスプロジェクト管理サービスの tracpath( トラックパス ) ではユーザー 5 名リポジトリ数 3つまで永久無料で利可能ですさっそく実務でも使ってましょうらも開発をう会社が作ったからこそ開発チームの作る情熱をえるやるべきことに集中出来るサービスになっていますエンタープライズ利が前提のASPサービスなのでセキュリティも強固です Copyright : 2017 OpenGroove,Inc. All Rights Reserved. 34

はじめの一歩！ソースコード管理に必要なバージョン管理とは

はじめの一歩！ソースコード管理に必要なバージョン管理とはバージョン管理システム ( 初者向け ) はじめの歩! ソースコード管理に必要なバージョン管理とははじめに開発者のにはお馴染みのRCS(Rivision Control System) が1982 年に登場してから 30 年余りが経過しオープンソースソフトウェア (OSS) の Apache Project や FreeBSD Project などを中にさまざまなバージョン管理ソフトウェアが開発されています

Git の基礎勉強 〜Git によるバージョン管理を使う〜

Git の基礎勉強〜Git によるバージョン管理を使う〜