Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a @s_ssk13さん向けGitHub入門
Similar a @s_ssk13さん向けGitHub入門 (20)
Más de Takashi Imagire
Más de Takashi Imagire (20)
Último
@s_ssk13さん向けGitHub入門
- 2. 目的 • GitHub触れるようになりたい – UE4のサブスクリプション版がGitHubだったので – BugFixやフィードバックはどうすればいいの? • 本日のねらい – Gitの概念おさらい • Pull/Pushとかブランチとかリポジトリとか。 – フォークの使い方 – GitHubクライアントを使った時の例 By @s_ssk13
- 3. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 4. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 8. WebSVN ローカルサーバー でのホスティング Subversionでの一例 有償・プライベート リポジトリ 有償・プライベート リポジトリ 無償・パブリック リポジトリ GitHub for Mac/ Windows クライアント バージョン管理ツール Git Subversion Git Bash Assembla SourceForge
- 9. Git Bash • Windows 版のgitのディフォルトクライアント • コンソールアプリケーション – GitHub for Mac/Windows にもShellがある • ブランチ名の表示や色付けの拡張あり
- 10. GitHub for Mac / windows • GitHub のデスクトップ用アプリケーション – GitHubのプロジェクトとのやり取りがしやすい
- 11. • デスクトップアプリケーション – Git-flow ワークフローに乗せやすい – ツリー見やすい
- 13. • GitHub Inc. によるプロジェクトホスティング サービス • プライベート用は GitHub Enterprise • Pull request によるマージ環境の整備 • OSS 公開に多く用いられる
- 14. プラン
- 17. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 18. Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
- 21. バージョン管理ツール （主にソースコードの）履歴を保存 • 集中型バージョン管理システム – 例：Subversion, CVS, Perforce – サーバーに変更履歴を保存するリポジトリを置く • 修正した履歴は中央のサーバーに記録される • 分散バージョン管理システム – 例：Git, Mercurial, Bazaar – 全員が同じリポジトリを所有 • 高速にブランチが作成可能 • クライアントのHDD容量を消費しやすい
- 24. バージョン管理すると • ファイルを間違えて消した時も何とかなるかも • ソースコードが動かなくなっても元に戻せる • 他の人が上書きしても対応できる • 誰が何時どのような変更をしたのか追える
- 25. 種類 分散バージョン管理 集中型バージョン管理 挙動 Commitしても自分のところだ けしか更新されない Commitしたら即反映 利点 ブランチの作成が 高速・ローカル シンプル Git Subversion
- 26. ブランチによる管理 • ブランチの作成が高速 ⇔ブランチが作りやすい ⇔お気軽にブランチを作って作業 • 何かを実装する際には、 とりあえずブランチを切って 進める – 他の人には影響しないので、 好き勝手ブランチを作成・編集 – 完成したら全体のブランチに 上げればよい 主開発 ブランチ 個別機能 ブランチ 1つのストーリー (数日単位) 1つのタスク (数時間単位)
- 27. ブランチの可視化の例
- 28. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 29. git-flow A successful Git branching model • 良い感じで仕事を進めるためのルール http://keijinsonyaban.blogspot.jp/2010/10/success ful-git-branching-model.html
- 30. メインブランチ • リリースされているものと 開発中のブランチを分ける – 何かあっても直前の最新にすぐ戻せる – 最新の本番がすぐに確認できる • 関係するブランチ名 – master: 公開されているバージョン – develop: 開発中のみんなが手を 入れているバージョン • UnrealEngineでは、「4.0」(2014/4時点)
- 31. フィーチャーブランチ • 新機能を作るために、どのブランチ で作っているか（そして進捗はどう か？）を確認するためのブランチ • developブランチから派生 – 最終的にはdevelopブランチへマージ （合流）か破棄 • 関係するブランチ名 – Feature/***: 「***」には機能名
- 32. リリースブランチ • 製品をリリースする直前に作るブランチ – ステージングテストをするために内容を固定する – リリースブランチからデプロイ(出荷)を行う – リリース後はdevelopとmasterにマージ • 関係するブランチ名 – release/***: 「***」には 機能名
- 33. ホットフィックスブランチ • 本番に不具合があった 場合の緊急対応 – developからも簡単なバグを 見つけた時には作成 – developとmasterにマージ (本番と開発中の両方に 修正を取り込む) • 関係するブランチ名 – hotfix/***: 「***」には 不具合の名前 – チケット駆動開発を行っている 場合には、「bug/#チケット番号」 で連携できる場合もある
- 34. 確認 • メインはdevelop • featureブランチ で実装 • 出荷時にrelease ブランチ • リリースしたら masterブランチ • バグを直すのは hotfix
- 35. GitHub-flow • GitHubの開発で用いられているワークフロー – デプロイを頻繁にすることで、大きなバグを出さない 1. masterブランチはデプロイ可能 2. ブランチはmasterから派生 3. 定期的にcommitし、頻繁にpush 4. マージしたいときはプルリク 5. レビューがokならマージし、直ちにデプロイ 6.テスト (自動) 7.デプロイ CI Webサーバー 5.マージmaster feature master feature 1. pull 2. branch 3. push (定期的) 4. プルリク https://gist.github.com/Gab-km/3705015
- 36. プルリクエスト • GitHubの特徴の1つ – コメントをつけあってのディスカッション • ソーシャルコーディング – 承認する人が ボタン1つで統合
- 38. プルリクへのコメント
- 39. 一行ごとにコメントもつけられる
- 40. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 41. 実践 git 入門 • 代表的なコマンド (git コマンド名 <オプション>) – git init: 初期化 – git clone: すでにあるリポジトリのコピーを作る – git status: 変更が加えられたファイルを表示する – git add: コミットするファイルを指定する – git commit: 変更点を履歴に残す – git push: 他のリポジトリに送信する – git branch: ブランチの作成 – git checkout: 地ランチの切り替え – git merge: ブランチの変更の結合 – git pull (git fetch): 他のリポジトリの変更点をマージ(取得) – git revert (git reset): 作業を以前の状態に戻す(履歴を残さないで戻す) – git rebase: ブランチの派生元を変更する – git log: コミットログを閲覧する – git diff: 差分を確認する
- 43. gitに関連するファイル ~ プロジェクト名 .gitignore gitで管理しないファイルを指定(なければ作る) .git (リポジトリの情報を格納) プロジェクトのファイル hooks: commitした時等に走らせられるスクリプト入れ .gitconfig プロジェクト共通の設定ファイル (なければ作る) などなど HEAD: 最新のコミットの位置
- 45. リポジトリの作成 • プロジェクトを作る – .git フォルダとその中に必要なファイルが作られる プロジェクト名 概要 READMEの追加 (プロジェクト名)
- 46. 既にプロジェクトが作られている場合 • git-clone コマンドでリポジトリを取得 git clone git@github.com:imagire/UnrealEngine.git – コマンドを実行した場所に「UnrealEngine」フォルダが 作られ、その中にプロジェクトのソースコードが置かれる • もしくは、「Clone in Desktop」 GitHubなど リポジトリclone 複製が作られる
- 47. ファイルの追加 • git-add で更新ファイルを指定 • git-commitで変更を保存 変更点は、まだローカルにだけ保存されている 適当にファイルを作成 git-add に次いで変更(追加)した ファイルを指定 git-commit でaddした時点の情報を 履歴として保存 -m でどのような中身のコミットを したのかメッセージを残す
- 48. 確認 • git-log でコミットのメッセージを確認 – Commit した分だけ続く – 黄色い文字は、commitを 識別するためのSHA-1 (暗号化手法の種類)のハッシュ値 • -p オプションで変更点の中身も見れる
- 50. 更新を共有 • 「git push 更新先リポジトリ ブランチ名」 GitHubなど リポジトリpush 更新先 ブランチ名
- 52. 更新を取得 (pushの反対) • git-fetch: 差分を確認 • git-pull: 最新の状態に更新（現在のブランチへのマージなので注意） リポジトリ ブランチ
- 53. GitHub for Mac / Windows での更新 • Sync によりoriginのリポジトリをマージ
- 55. コマンドラインでのブランチ • 現在のブランチ(develop)から、 feature/edit_renameというブランチを作成し て、そのブランチに移動 – 「-b」 をつけない：作成済みのブランチに移動 – 生成と移動は別々にも可能 • git branch <新規ブランチ名> • git checkout <新規ブランチ名>
- 58. コンフリクト • Sync (git push) の時に、他の人が先に被る部 分を更新しているとSyncが完了できない
- 60. コンフリクト解消 (2/2) • 際commit & sync(push) すると、枝分かれし たブランチ（それぞれの更新）が1つに合流
- 61. コマンドラインでのコンフリクト
- 62. コマンドラインでの解消 • 修正したら、add, commit, push を実行
- 65. 退避
- 66. リセット • 何かあった時に戻す – Commit していない状態でいろいろとやっていた のをcommit時点に戻す • git reset –hard HEAD “soft”にするとファイル自体は 書き換わらないでgitの情報を戻す 現在のbranchの 最終commit位置
- 67. コミットを打ち消し • git revert: もとに戻すcommitを作成する 戻すのにrevertを使う 樹形図は戻るのではなく進む！
- 68. よくわからなくなったとき 1. Gitでアレを元に戻す 108の方法 – http://labs.timedia.co.jp/20 11/08/git-undo-999.html – 状況に応じた対処方法がま とめられている 2. リポジトリを削除して Clone し直す!!! – 必要ならフォルダに別名を つけて退避しておきましょう
- 70. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 75. 僕たちはUE4を 触りたい！
- 77. Pull できるようになる！
- 81. 触り方の作法 (準備) upstream origin local EpicGames/UnrealEngine imagire/UnrealEngine 4.0 4.0 4.0 featurefeature master 1. fork 2. clone 3. branch 4. add 5. commit 6. push
- 82. 触り方の作法 (更新) upstream origin local EpicGames/UnrealEngine imagire/UnrealEngine 4.0 4.0 4.0 featurefeature master 7. merge (中の人) 1. pull (2. push) 3. rebase 4. push 5. pull req. 6. merge(中の人)
- 86. アカウント承認の中身 • ログイン時に公開鍵の鍵暗号が作成され 公開鍵がGitHubのユーザー情報に送られる 公開鍵: github_rsa.pub 秘密鍵: github_rsa 違うクライアントを使うときは、自分で鍵を登録します
- 87. 公開鍵暗号 公開鍵 秘密鍵 0.b. 公開鍵を送る 0.a. 公開鍵と秘密鍵を作成 1. ログイン 2. 公開鍵を使って適当な キーワードを暗号化して送る 3. 秘密鍵を使って復号化 4. 送られてきたキーワードを照合 5. 承認
- 91. アジェンダ • GitHubについて • Git について • Git-flow • Git のコマンド • GitHubの触り方 • やってみよう!
- 92. 注意 • この後の説明は、GitHubとの連携が密な、Git for Mac / Windows を基に進めさせていただ きます • SourceTreeは進行がわかりやすい際に キャプチャーを使わせていただいたりします • 慣れや、やりたいことで適切なツールをご選択 ください
- 93. 課題1: Organization 作成 • チームを作成してみよう！
- 94. 組織名 課金時連絡先
- 95. 課題2: repository 作成 • プロジェクトを作成してみよう！ – git init と同じ操作
- 97. 課題3: branch 作成 • developブランチを作成してみよう！ – git branch develop
- 103. 課題5: feature branch • develop ブランチからfeatureブランチを作成
- 109. SourceTreeでみると
- 111. 課題8:プルリクエスト • きれいなプルリクを行う – featureブランチを整理 – プルリクエストを投げる
- 112. きれいなプルリクとは • マージした後のコミットが1つ – 途中経過はマージした後は興味がある人はほとん どいないので、まとめたコミットにして統合してもらう これらを消去して統合 rebase –i master http://kik.xii.jp/archives/117
- 114. ブランチの移動
- 115. 大元のmasterの情報をマージ upstream/master→master （ただし、今回は何も起きない） git push origin master をこの後に入れるとなおよいでしょう
- 116. ブランチの移動
- 120. コメントの修正 セーブして閉じる
- 128. 課題10:プルリクの更新 • コメントに対応して修正をする – タイトルの修正 – 本文の修正
- 129. タイトルを修正してみる
- 130. 本文修正
- 132. 課題11:merge
- 136. ブランチの削除 • コンソール – ローカルのブランチの削除 • git branch –d <ブランチ名> – マージされていないコミットがある場合に削除しない • git branch –D <ブランチ名> – マージされていないコミットがあっても強制削除 – Origin のブランチの削除 • git push origin :<ブランチ名>
- 138. D&D
- 141. 課題14:プロジェクトの削除
- 142. リポジトリ名
- 144. 課題∞: UnrealEngine • UE4のアカウント登録しているなら、 Epic/UnrealEngineをforkしてみよう • 手元にcloneしてみよう • 「4.0」ブランチから新しいブランチを派生させ てみよう • Epicに報告したい ことがあれば pull requestを 出してみよう…