SourceTreeで始めよう! Gitへの乗り換え指南
16 likes12,401 views
SourceTreeで始めよう! Gitへの乗り換え指南 - Atlassian User Group NAGOYA 第3回 ユーザーミーティング http://www.kekyo.net/2015/07/23/5241
SourceTreeで始めよう! Gitへの乗り換え指南
- 1. SourceTreeで始めよう！ Gitへの乗り換え指南 Atlassian User Group NAGOYA 第3回 2015/07/23 Kouji Matsui @kekyo2 A B C F D E G H I J perf-run2939 2.0.3 master
- 2. 自己紹介 Kouji Matsui / けきょ (@kekyo2) CenterCLRのオーガナイザー 会社やってます Microsoft MVP for .NET (2015.04～) 認定スクラムマスター
- 3. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 4. SourceTreeの前に… Git知ってますか？ Git使ってますか？ あるいは、Subversion知ってますか？ VSSとかCVSとか？ 本日は、Gitの使い方というよりも、Gitの考え方を共有したいと 思います。 Gitの使い方についてのHow-toは、初心者向けサイトがいっぱい あると思うので、そちらで押さえて下さい。 本家「Pro Git」 http://progit-ja.github.io/ Nulabさん「サルでもわかるGit入門」 http://www.backlog.jp/git-guide/ ばぃ
- 5. どうやら世の中のソースコード管理はGitでほぼ確定 何がスタンダードになるか、昔からずっと注視していました。 Subversionと思えたこともあった（ソースに貢献し掛けた事も あったけど、あまりにアレでやめちゃった）。 Gitをホスティングするサービスが増えた。特にGitHubと Bitbucketの存在が大きい。エコシステムが確立されつつある。
- 6. GitとSourceTreeの関係 Gitは、ソースコード管理システムの一種で、Gitの公式サイトで配布 されているソースコードやバイナリパッケージが、Gitのすべてです。 バイナリパッケージには、Gitのコマンドラインで使用するツールが 含まれています。 SourceTreeは、Gitプロジェクトの成果物を使用して、グラフィカルな ユーザーインターフェイスに仕立て上げた、Atlassianの製品です。 製品ですが、無償で提供されています（登録は必要です）。
- 7. GitとBitbucketの関係 AtlassianのBitbucketサービスは、Git のサーバーとして、ソースコードの 管理を行います。 つまり、Gitのコマンドラインや SourceTreeの接続先です。 Git自体は公開された技術なので、 Bitbucket以外にもGitのサーバーは沢 山あります（GitHub、Visual Studio Online等）、SourceTreeからこれらに 接続することも、勿論可能です。 これら同様、Atlassian Stashにも接続 可能です。
- 8. GitとSubVersionの利点とか欠点とか 本日は、Gitへの乗り換え指南という事で、暗黙にSubversionをター ゲットにしていますが、両者の比較については.... ググって下さい（笑） 統合型とか分散型の利点・欠点とか、多分眠くなりますよね？ その辺の話題は、ググれば腐るほど出てきますが、 今から使おうって人にはあまり関係のない話題 移行したいと思ってる人は、大体分かってる 今日のセッションとして強いて挙げるなら、 「共同作業での混乱を軽減してくれる、強力な武器がGit」
- 9. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 10. 移行しよう！
- 11. 移行をサクッと考える！ 移行って事で、とりあえず、Subversionからの移行を考えます！！ （注：初めて触る方にはあまり関係ない話です） 移行のポイントは2つ。 物理面の移行。SubversionのソースコードをGitに移行する方法。 論理面（精神面）の移行。SubversionとGitの違いを把握する。
- 12. 物理面の移行 ググったりすると、SubversionのリポジトリをGitのリポジトリ に移行する方法がいろいろ見つかります。 Bitbucketを使う場合、Bitbucketの機能で簡単にSubversionリポ ジトリをインポート出来ます。 コマンドラインのGitクライアントを使って、git-svnでインポー トする方法が（多分ググると）ありますが、実用的ではないの で、お勧めしません。
- 13. デモ
- 14. SourceTreeで行こう！ Subversionを使っていたなら、 TortoiseSVNとかのクライアントが有 名ですが、Gitの場合は？ グラフィカルで全体の見通しの良い 「SourceTree」をお勧めします。 http://www.sourcetreeapp.com/ しかし、これはあくまでGitの使い方 を知っていないと、まともに使えま せん。見た目のフレンドリーさに騙 されないように！！
- 15. 念のため SourceTreeは、コマンドラインで出来る事 の「全て」はカバーしていません。 そのため、コマンドラインでもGitが使え るようにしておいた方が良いのですが、 SourceTreeにも内蔵されているので、最初 は内蔵版をそのまま使えば良いでしょう。 コマンドラインでの操作は、ググったりし て得られる情報がそのまま使えることも利 点です。
- 19. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 20. Gitのブランチって何？ 知るべきはコレ！ Gitのブランチは、 「動かせる目印」です。 Gitのタグは、 「動かせない目印」です。 Subversionで言う所のブランチは、 敢えて言うなら、 Gitでの「コミット樹形のサマ」です。 Subversionで「ブランチが移動」とか 言わないですよね？ この一つ一つが「コミット」。 この時点で保存したソースコードの スナップショット sb-onmessage perf-run2939 2.0.3 bug-2993 Gitのブランチ。 特定のコミットを指している「ポインタ」。 ブランチを選択してコミットする事で、ポインタが「移動」する Gitのタグ。一度付けたら別のコ ミットに移動する事は出来ない 放置されているブランチ
- 23. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 25. なぜGitはブランチしまくるのか？ ブランチを作るのが非常に簡単です。 なので、ちょっとした変更もブランチして行います。 そうすると、変更点を安全にGitに保管できます。 たわいもない変更でも、あとでまた確認したくなることがあり ますよ。 リモートに保管しなくても済む方法があります。 リモートに送る前なら取り消す事も 出来なくはない 仕掛かりの変更がある状態でもOK！あらか じめブランチを切っておかなくても良い
- 26. なぜGitはブランチしまくるのか？ テストのためにブランチを切ります。 リファクタリングが成功するかどうか自信が無い。 新しい何かを試すために、既存コードを改造したい。 それがうまくいったら、正式に採用したいが失敗するかも知れない… 作業単位に紐づけておきたい。 そうすれば、後で作業の推移を確認できる。 他の人との作業分担でバッティングする事が無い。 一旦は完了した作業を、あとから継続できる。
- 29. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 30. なぜGitはブランチをマージしまくるのか？ そんなわけで、Gitではブランチを沢山切ります。そのままだと成果 がばらばらです。 ある時点でOKとなった変更を、本採用したい。 そこで、本流と見なしたブランチにマージする事で、正式採用します。 本流を示すブランチを、慣例で「master」ブランチと呼びます。 これがmasterブランチ。 SourceTree上で見ると、大体樹形図の先頭にある が、必ずしも先頭にあるわけではない デモ
- 32. なぜGitはブランチをマージしまくるのか？ 更には、Gitにおいての「本流」の定義はあいまいです。 「master」がデフォルトのブランチ名なので、ここに成果を集約 する使い方が一般的ですが、Gitは機能的にどのブランチが「本 流」かなどと言う事は一切関知しません。 そのため、「oreore」というブランチ名を使い、これを本流とし て運用しても、何ら問題はありません。 勿論、masterを本流とした方が、新しいメンバーに意志疎通しやす いというような、チーム運営上の一般論はあります。 逆に、本流のブランチと言う物を決めないで、試行錯誤した結果 のどれかのブランチを、そのまま発展させるという使い方も誤り ではありません。 Subversionではtrunkを引退させるのは、勇気のいる事かも知れま せん。
- 33. なぜGitはブランチをマージしまくるのか？ と、いう事は？ ブランチをどのように作っても、いつでもマージできるし、ど のブランチを継続利用するかという選択肢も含めて、運用方法 は開発者にゆだねられています。 Subversionと異なり、ブランチを切るタイミングも、マージす るタイミングも、開発者自身でやりたいように考える事が出来 るわけです。 日々のちょっとしたタイミングで、ちょっとした事に、ちょっ とした道具としてGitのブランチを使います。 ソースコード管理の重苦しい制約を課すために、Gitのブラン チがある訳ではありません。 もちろん、延長線としてソースコード管理まで含めて使っても いい。そういう柔軟性があります。
- 34. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 35. どうやってGitは複数のリポジトリを管理するのか？ Subversionのような中央集約型 の管理では、単一のサーバー にソースコードを保存します。 Gitは分散管理なので、複数の サーバーでソースコードを管 理できます。 更には、サーバーが無くても、 ローカルだけでも管理できま す。
- 37. リモートサーバーを使う Gitで直接操作できるのは、あくまで「ローカ ルリポジトリ」のみです。なので、基本は ローカルリポジトリ運用をそのまま実践すれ ばOK。 「プッシュ」という操作で、ローカルのコ ミット情報がリモートに送信されます（デー タベース的に言えば、レプリケートされる）。 逆に「フェッチ」という操作で、リモートか らローカルにコミット情報が取り込まれます。 フェッチしただけでは、ローカルリポジトリ が更新されるだけである事に注意。作業中の コードには影響しません。 Repo Repo 非常に重要
- 42. コミット情報伝搬の基礎 A B C F D E G H I J A B G H I マージ作業はあくまでもローカルの 手動操作でのみ可能。 マージを試みて初めてコンフリクト が発生する可能性がある。
- 51. タグ情報の伝搬 プッシュ 2.0.3 2.0.3 A B C F D E G H I J A B C F D E G H I J タグ情報も、プッシュやフェッ チでレプリケートされるorigin/master master origin/master
- 53. 複数のサーバーとのやりとり プッシュしたサーバー に伝搬する P Q R T S A B C E D P Q R T S J K L プッシュ to A (origin) リモートA リモートB （変化なし） A B C E D P Q S J K L origin/master master origin/master B/master B/master ブランチの形成に不要な コミットは伝搬しない
- 54. 「origin/master」とは？ 「origin」について説明出来る所まで来ました。 「origin」という単語を聞いた事があるかもしれません。これはGit 上でのリモートサーバー名と考えて下さい。 ブランチでの「master」同様に、「origin」もまた慣例でしかあり ません。リモートサーバーが省略されるときに、「origin」という 名前を使うというだけです。 また、このリモートサーバー名自体が別名と言う扱いです。本当 はサーバーを特定するURLを使いますが、これに別名を付けて簡便 に指定出来るようにしたものです。 例：「https://github.com/kekyo/CenterCLR.SgmlReader」→「origin」 なので、「oreore」という名前のリモートサーバー名でもOKです。
- 55. 複数のリモートサーバーの核心 そして、複数のリモートリポジトリを 同時に扱う場合は、それぞれに異なる リモートサーバー名を付けて呼び分け たりします。 • リモートサーバーから初回にレプリケート（clone）した場合、そのURL が自動的に「origin」という名前でローカルリポジトリに記憶されます。 • なので、次回以降、フェッチするだけで、リモートから変更点を取り込 むことが出来るわけです。
- 56. アジェンダ 今日のお話 移行のお話 Gitのブランチとタグとコミット なぜなにGit なぜGitはブランチしまくるのか？ なぜGitはブランチをマージしまくるのか？ どうやってGitは複数のリポジトリを管理するのか？ どうしてGitはソースの差分を保存しないのか？
- 57. ソースコードの差分を保存「しない」Git • Subversionは、直前のコミットと今回のコミットのソースコード の差分を記憶します。 • 多くの場合、ソースコードの差分のデータ量は少なくなる事、そし て、ソースコード管理システムの伝統（SCCSやCVS）に従ってそ うなったのではないかと思います。 • しかし、Gitは、変更のあるファイル全体をそのまま保存します。 ファイルの中身の差分については（コミット時には）確認しません。 注意：個人的解釈を含 みます
- 58. ソースコードの差分を保存「しない」Git • 当然、コミット毎のデータ量は増大します。Gitはこれを（zipのよ うに）圧縮して保存する事で、リポジトリデータベースのサイズを 軽減しています。 • どうしてこのようにしているのか？ • リポジトリが一部破損した場合でも、データを復旧できる可能性が高 い。差分を保存していると、合成して復元しなければならず、途中の データが壊れていると復元不能となる。 ちなみに、Gitのリポジトリデータベースは、ファイルベースのキーバ リューストア形式なので、SQLiteのように一部破損で読み取り不能と いう可能性は低くなります。 • 差分を保存していると、人間による追跡が容易ではありません。
- 59. 人間による追跡？ • あるブランチ同士をマージしようとします。 • Subversionは、過去のソースコードの差分を論理演算して、現在のバージョン なら「このファイルのこの行の変更」が「こっちのファイルのここの行に相当す る」などの、人間離れした判定を行います。 • この計算のため、ソースコード内の差分だけではなく、ファイル単位のファイル 名変更・ファイル移動といった事も記録します。 （なぜ、TortoiseSVNがエクスプローラーのメニューに、似て異なるコマンドを いくつも追加しているのかの理由に当たります） • 判定がうまく行っている分には素晴らしいのですが、行内が微妙に変更されてい るなど、機械的に判定できなかった（失敗した）場合の、競合メッセージが意味 不明になる可能性があります。 • 例：競合、と指摘されている箇所が、競合で問題が発生しているようには見えない • このような場合、競合の真の原因がどこにあるのかの調査はかなり困難です。
- 60. 人間による追跡？ • Gitでは、コミット時の目の前にあるファイルが全てです。差分はファイ ル単位で、しかもファイル名の変更やファイルの移動の追跡もありません。 • 仮にマージ作業で競合が発生した場合、「目の前にあるファイル一式が正 しいもの」と信じられる場合、そのままコミットしてかまいません。 • ファイル名変更・ファイル移動・コードの追加・削除・修正など、全ては そのままの前提で、リポジトリに保存されます。 • では、マージの際のブランチ毎の追跡計算はいつ行われるのでしょうか？ この計算は異なるブランチをマージするなら避けられない作業ですが： • Subversionは前述のとおりコミット時に保存した情報を使います。 • Gitはマージ時に毎回計算しなおします。
- 61. 人間による追跡？ • Gitの方式は、変更について正確に記録されていないため、ヒューリスティック 解析を行っています。つまり： • 似たファイルを探し、似ていたらファイル名が変更されたか移動されたと推察する。 • ソースコード内の移動についても、似たブロックの移動がないかどうかを判定する。 • もちろん、これは不正確で完全ではありません。ですが： • Subversionの方式は、元々正確ではないのです。ファイル名の変更を記録するには、 TortoiseSVNのようなトリッキーな方法を使うしかなく、しかもユーザーがその機能 を使わなかったらもうお手上げです。同様にソースコード内の変更も、エディタ操作 を全て記録しなければ、不正確となります。この前提条件はおおよそ守られるとは思 えません。 • Gitの差分計算アルゴリズムは、アルゴリズム強化で改善しています。また、異なる アルゴリズムをプラグインすることも可能です。
- 62. アジェンダ おみやげ SourceTreeには、マージツールがありません。いくつかのサード パーティツールが使えますが、今日はお土産として 「TortoiseMerge」を切り出したツールを持ってきました。 TortoiseMergeは、TortoiseSVNに内蔵されているマージツールです。 そこ、 嫌な顔しないw 使い勝手はそこそこですが、使うにはTortoiseSVNを インストールする必要がありました。 これを使えば、TortoiseSVNをインストールしないで、 TortoiseMergeを使えます。 https://github.com/kekyo/TortoiseMergePortable
- 63. 質疑応答 ご清聴ありがとうございました！ 取り上げていませんが、その他のトピック： リベース コミットの取り消し プルリクエスト 消えたコミットの謎 スライドはブログに掲載します。 http://www.kekyo.net/