Git 入門 Part 2
遠隔編
か (@ka_, kaosf)
.gitignore について
●
まともにプロジェクト管理するなら必要
●
.gitignore に指定したものは無視される
– ファイルでもディレクトリでも
– メタキャラクタが指定可能
– 「生成物」は原則無視する
●
*.o ファイルな...
.gitignore の書式
●
一行に一指定
●
メタキャラクタの仕様はシェルスクリプト
のそれと同じ
●
.gitignore のあるディレクトリ以下に適用
●
詳しくは .gitignore でググろう
.gitignore の例
●
とある Andoid アプリのリポジトリ :
https://github.com/kaosf/android-app-template/blob/v1.1.0/.gitignore
●
*.swp は Vim ...
リポジトリの作法
●
ソースコードと目的物の「作り方」のみ管理
●
「作り方」は README に正確に書こう
– 長くなるなら別ファイルに その辺は臨機応変
●
パスワードや秘密鍵に相当するものが
紛れ込まないよう注意
– 環境変数を利用する...
何かあっても何とかなります
●
秘密のファイル入りでコミットが進んだ
– 過去のコミット全てから特定のファイルだけ
削除し尽くすことも出来る
●
.gitignore に追加したけど既に管理下にある
– 普通に削除してその削除をコミットする
–...
聞くは恥ですらない
●
聞かぬは一生の不便
●
でも案外調べれば何とかなる
●
@ka_ に聞いてくれれば
●
濱野純さんの本「入門 Git 」オススメ
– 「基本」ではなく「基礎」を固めるために
いっぱい練習
●
リポジトリを沢山作る
●
コミットを沢山する
●
色んな操作をやってみる
●
以降のリモートリポジトリを扱う操作でも
沢山手を動かしてみる
●
Bitbucket なら private repository 作り放題
リモートリポジトリを扱う
● git remote add <nickname> <URL>
– 大抵 <nickname> は origin
● git push origin <local-br>:<remote-br>
– ブランチ名が同...
fetch についてもう少し詳しく
●
FETCH_HEAD が取得出来たら
– git reset FETCH_HEAD –hard
– これでリモートから取って来たことになる
●
一連の流れ ( 例 )
– git checkout br1...
もうちょっと柔軟に扱う
● git push origin br1 -f
– 歴史が失われても構わない
● git push origin :br2
– origin にある br2 を消し去りたい
– ローカルの「無」をリモートに押し付ける感覚
Win, Mac の人も同じ概念で
●
ダイアログで聞かれていることは同じ
●
何を,何処に,どうやって,を覚える
– <local-br> を origin の <remote-br> に -f で…等
Pull の注意点
●
Pull は Push の反対ではない
– Pull は Fetch と Merge の複合技
Git を多人数で使う
●
リモートリポジトリの公開設定
– Bitbucket はデフォルトでは private になる
– 無料枠では公開人数に制限があるので
public にする
●
Pull Request 実践
まずは Fork
●
Fork ( フォーク ) ?
– スプーンとナイフとフォークのフォーク
●
あの形のように分岐して派生していくイメージ
– リモート上での Clone 動作のこと
– GitHub でも Bitbucket でも出来る
...
開発者二名の定義
●
大元のリポジトリの所有者
( フォークされた側 ) を A とする
●
リポジトリを複製した側
( フォークした側 ) を B とする
フォークしてクローンする
●
B が A のリポジトリをフォークする
●
git clone <B のリポジトリの URL>
クローン出来たらブランチ作成
●
トピックブランチ・フィーチャーブランチ
と言うこともある
– git checkout -b topic-1
●
ブランチ作成したらコミットを重ねる
●
それを origin にプッシュ
– 自分の所なので書き...
プルリクエストを作成
●
B の topic-1 を
A の master に
マージして欲しい
プルリクエストを受理
●
開発者 A側
– git pull <Bのリポジトリ > topic-1
– もしくは
git fetch <B のリポジトリ > topic-1
git merge FETCH_HEAD
●
それを自分のリポジトリに...
実際にやってみよう
プルリクエストを出し合う
●
各人 20130706-git-pr-<username>
というリポジトリを作る
●
自分以外の人のリポジトリをフォーク
●
プルリクエストの手順を行う
Upcoming SlideShare
Loading in …5
×

20130706 git

926 views

Published on

第 2 回 Git ハンズオン・勉強会 in Tokushima 進行資料

  • Be the first to comment

  • Be the first to like this

20130706 git

  1. 1. Git 入門 Part 2 遠隔編 か (@ka_, kaosf)
  2. 2. .gitignore について ● まともにプロジェクト管理するなら必要 ● .gitignore に指定したものは無視される – ファイルでもディレクトリでも – メタキャラクタが指定可能 – 「生成物」は原則無視する ● *.o ファイルなど ● 何が生成物なのかをきちんと知ろう
  3. 3. .gitignore の書式 ● 一行に一指定 ● メタキャラクタの仕様はシェルスクリプト のそれと同じ ● .gitignore のあるディレクトリ以下に適用 ● 詳しくは .gitignore でググろう
  4. 4. .gitignore の例 ● とある Andoid アプリのリポジトリ : https://github.com/kaosf/android-app-template/blob/v1.1.0/.gitignore ● *.swp は Vim が自動生成するもの ● *~ は Emacs が自動生成するもの ● Thumbs.db, .DS_Store は断固無視すべし ● .classpath, .settings は Eclipse が ● bin, gen はアプリ生成の際に作られる
  5. 5. リポジトリの作法 ● ソースコードと目的物の「作り方」のみ管理 ● 「作り方」は README に正確に書こう – 長くなるなら別ファイルに その辺は臨機応変 ● パスワードや秘密鍵に相当するものが 紛れ込まないよう注意 – 環境変数を利用すると楽に隠せる – 環境ごとに逐一ファイルを用意するのもアリ
  6. 6. 何かあっても何とかなります ● 秘密のファイル入りでコミットが進んだ – 過去のコミット全てから特定のファイルだけ 削除し尽くすことも出来る ● .gitignore に追加したけど既に管理下にある – 普通に削除してその削除をコミットする – git rm <some file> – git rm -rf <some directory>
  7. 7. 聞くは恥ですらない ● 聞かぬは一生の不便 ● でも案外調べれば何とかなる ● @ka_ に聞いてくれれば ● 濱野純さんの本「入門 Git 」オススメ – 「基本」ではなく「基礎」を固めるために
  8. 8. いっぱい練習 ● リポジトリを沢山作る ● コミットを沢山する ● 色んな操作をやってみる ● 以降のリモートリポジトリを扱う操作でも 沢山手を動かしてみる ● Bitbucket なら private repository 作り放題
  9. 9. リモートリポジトリを扱う ● git remote add <nickname> <URL> – 大抵 <nickname> は origin ● git push origin <local-br>:<remote-br> – ブランチ名が同じなら :<remote-br> 省略可 ● git pull origin <remote-br> ● git fetch origin <remote-br> – FETCH_HEAD という特殊な参照が出来る
  10. 10. fetch についてもう少し詳しく ● FETCH_HEAD が取得出来たら – git reset FETCH_HEAD –hard – これでリモートから取って来たことになる ● 一連の流れ ( 例 ) – git checkout br1 – git fetch origin br1 – git reset FETCH_HEAD --hard
  11. 11. もうちょっと柔軟に扱う ● git push origin br1 -f – 歴史が失われても構わない ● git push origin :br2 – origin にある br2 を消し去りたい – ローカルの「無」をリモートに押し付ける感覚
  12. 12. Win, Mac の人も同じ概念で ● ダイアログで聞かれていることは同じ ● 何を,何処に,どうやって,を覚える – <local-br> を origin の <remote-br> に -f で…等
  13. 13. Pull の注意点 ● Pull は Push の反対ではない – Pull は Fetch と Merge の複合技
  14. 14. Git を多人数で使う ● リモートリポジトリの公開設定 – Bitbucket はデフォルトでは private になる – 無料枠では公開人数に制限があるので public にする ● Pull Request 実践
  15. 15. まずは Fork ● Fork ( フォーク ) ? – スプーンとナイフとフォークのフォーク ● あの形のように分岐して派生していくイメージ – リモート上での Clone 動作のこと – GitHub でも Bitbucket でも出来る – リポジトリの複製が自分の所有物として出来る ● 自分で好きなように弄れる ● Fork元に影響は一切無い ( だって分散型だもの )
  16. 16. 開発者二名の定義 ● 大元のリポジトリの所有者 ( フォークされた側 ) を A とする ● リポジトリを複製した側 ( フォークした側 ) を B とする
  17. 17. フォークしてクローンする ● B が A のリポジトリをフォークする ● git clone <B のリポジトリの URL>
  18. 18. クローン出来たらブランチ作成 ● トピックブランチ・フィーチャーブランチ と言うこともある – git checkout -b topic-1 ● ブランチ作成したらコミットを重ねる ● それを origin にプッシュ – 自分の所なので書き込みが可能 – git push origin topic-1
  19. 19. プルリクエストを作成 ● B の topic-1 を A の master に マージして欲しい
  20. 20. プルリクエストを受理 ● 開発者 A側 – git pull <Bのリポジトリ > topic-1 – もしくは git fetch <B のリポジトリ > topic-1 git merge FETCH_HEAD ● それを自分のリポジトリにプッシュ ● これで受理したことになる ● Web上でマージを行うことも出来る
  21. 21. 実際にやってみよう
  22. 22. プルリクエストを出し合う ● 各人 20130706-git-pr-<username> というリポジトリを作る ● 自分以外の人のリポジトリをフォーク ● プルリクエストの手順を行う

×