ページの比較

Git とは

Git は分散バージョン管理システムと呼ばれるものの一つです。Subversion と比較すると、高機能だが複雑で難しいと言えます。「分散」とついているのは Subversion のように中央レポジトリがあるのではなく、各個人が手元に所有する分散したレポジトリを同期して使うモデルを採用しているためです。とはいえ、現実的にはほとんどのチームで GitHub でホストする共有の中央レポジトリを持つことになるでしょう。こうした場合 git の最大の特徴は後述するブランチとマージの管理が優れていることです。例えば、特定の不具合の修正を他のブランチに取り込むといったことが簡単にできます。

...

1. リモートレポジトリのクローンを手元に作成する方法 

   書式設定済み
   $ git clone https://github.com/ymmt2005/hazama-tools $ cd hazama-tools $ git remote show origin

2. ローカルレポジトリにリモートレポジトリの情報を追加する方法

   書式設定済み
   $ git remote add teststable https://github.com/ymmt2005/test.git $ git fetch teststable $ git remote show origin teststable

git clone は origin という名前でリモートレポジトリを手元に取り寄せます。実際には以下のような操作と同等のことをしています。

...

origin に master, INFRA-1000 と stable に master ブランチがあることがわかります。
origin/master に対してなにかフィーチャーを実装することにしたとしましょう。次にやることは、ローカルブランチを origin/master から分岐して作ることです。

$ git checkout -b INFRA-1001 origin/master
INFRA-1001
$ git branch
* INFRA-1001
  master
$ git remote show origin
* remote origin
  Fetch URL: github:hazama/infra
  Push  URL: github:hazama/infra
  HEAD branch: master
  Remote branches:
    INFRA-1000        tracked
    master            tracked
  Local branches configured for 'git pull':
    INFRA-1001 merges with remote master
    master     merges with remote master
  Local refs configured for 'git push':
    master     pushes to master

...

このコマンドを実行すると、リモートレポジトリにも INFRA-1001 というブランチが作成されます。
すでに INFRA-1001 ブランチがある場合は、差分のみ送信されます。差分はファストフォワードマージできる状態でなければなりません。 

チュートリアル

...

チュートリアル

git は利用者が多いのでチュートリアル資料もたくさんあります。以下がおすすめです。

• サルでもわかるGit入門
  いろいろ見た中で一番とっつきやすいと思いました。
• こわくない Git
  merge と rebase の違いなどを丁寧に解説しています。必読。
• ぎっとぎとにしてやんよ
  @teppeis 作の tips 集。必読。
• コミットメッセージの書き方
  現在形の英語で書くとか。
• Git Cheat Sheet
  レポジトリ、インデックス（ステージングエリア）、ワーキングコピー、スタッシュの関係が図示されています。
• man 7 gitrevisions
  revision の指定方法。HEAD~3 や :/text といった便利記法の使い方がわかります。
• ProGit
  Official, PDF
• Git From the Bottom Up
  PDF, 日本語訳(html)

GitHub 概説

...

git は基本的には個人で使うための機能しかなく、レポジトリを共有管理する機能は充実していません。レポジトリの共有管理をするためには は基本的には個人で使うための機能しかなく、レポジトリを共有管理する機能は充実していません。レポジトリの共有管理をするためには gitolite のようなオープンソースツールもありますが、gitolite プロジェクト自体も GitHub でホスティングされているように、git レポジトリホスティング機能としては レポジトリホスティング機能は GitHub がダントツに優れています。社内の GitHub Enterprise には以下の URL でアクセスできます。

• https://github.dev.cybozu.co.jp

 

レポジトリ管理

...

GitHub (Enterprise) ではレポジトリは個々の利用者が自由に作ることができます。共有レポジトリをフォークすることも自由です。
共有レポジトリを管理するために Organization という仕組みがあり、Organization は複数の Owner が共同管理できます。

Organization では は複数の Team を複数作成して、それぞれのチームごとに を持つことができ、チームごと所属するメンバー、レポジトリ、および PUSH, PULL の権限を制御できます。
Organization は誰でも作ることができます。社内の GitHub では以下の URL から。

• https://github.dev.cybozu.co.jp/account/organizations/new

コミュニケーション

GitHub ではコミットや差分の行単位でコメントをつけることができます。コメントは GitHub の通知機能やメールで通知されます。
メール通知は個人設定で止めることもできます。特定のレポジトリを watch すると、そのレポジトリの変更が通知されます。

は誰でも作ることができます。

コミュニケーション

GitHub ではコミットや差分の行単位でコメントをつけることができます。コメントは GitHub の通知機能やメールで通知されます。
メール通知は個人設定で止めることもできます。特定のレポジトリを watch すると、そのレポジトリの変更が通知されます。

ユーザーの顔写真には Gravatar というサービスを利用して表示しています。顔写真がないと誰が操作したのかわかりにくいので、GitHub に登録したら必ず Gravatar を設定しましょう。Gravatar でアバターを指定するメールアドレスは、GitHub で登録されているメールアドレスにしてください（メールアドレスが主キーです）。

...

Gist

レポジトリ管理とは無関連の、コードスニペットを共有する機能です。レポジトリ管理とは無関係の、コードスニペットを共有する機能です。
GitHub のおまけ的機能ですが、script タグで他のページに埋め込める等なかなか便利です。

...

GitHub はマークダウン記法でコメントやドキュメントを書く機能があります。
各レポジトリにはこのマークダウン記法でページを作成できる Wiki 機能が付属しています。
Wiki システムは Gollum というもので、詳細はリンク先を読んでください。 というものです。詳細はリンク先を読んでください。

簡単な使い方：

1. ページ間リンクは [[ で書く

   書式設定済み
   [[PageName]] [[Title|PageName]]

2. Git レポジトリの中は好きなようにディレクトリを作っていい
   ページもどう配置してもいいが、幅優先探索で最初にみつかったものが表示される。
3. マークダウン記法の使い方は以下を参照
   1. Broken!
   2. Markdown Cheatsheet

...

レポジトリごとにタスクや不具合を管理する Issues 機能がありますが、非常に簡素なものですので kintone や JIRA の代わりにはなりません。

API

GitHub 本家と同じ API が利用できます。
API を利用すると PULL リクエストをコマンドラインから送るようなことができます。

• API v3
• GitHub Enterprise supports the same, powerful API available on GitHub.com

アーカイブ

レポジトリではなく、ファイルだけを取得する git archive 機能は GitHub では提供されていません。クローンしてください。では提供されていません。クローンしてください。

毎日のビルドにつかうなら、こんな感じ。svn export よりむしろ高速です。

$ git clone repo
  (初回のみ)
$ cd repo
$ rm -rf *
$ git fetch origin
$ git reset --hard
  (これでまっさらな最新のソースが手に入ります)

共有レポジトリ

Forest, Hazama で共有するレポジトリは GitHub の forest, hazama Organization で管理されています。

forest

• https://github.dev.cybozu.co.jp/forest

forest は install-forest で運用環境にインストールする infra レポジトリを管理しています。infra レポジトリに PUSH できる（PULLリクエストを処理できる）のは当面森本さんと山本だけです。Forest の人が git に慣れたら、Forest メンバーは PULL リクエストを処理できるようにしようと思います。

hazama

• https://github.dev.cybozu.co.jp/hazama

hazama は forest/infra を開発用にクローンしています。また、install-forest に直接関係しない tbs や js や ubuntu はそれぞれ個別のレポジトリとして hazama で管理しています。Forest, Hazama の人は誰でも PULL リクエストを処理できます。

hazama/tools には開発用のツールがありますので、まずこれを手元にクローンしてください。

最初にやること

...

 git fetch origin
$ git reset --hard
  (これでまっさらな最新のソースが手に入ります)

最初にやること

1. GitHub にログインしてパスワードを変更する

   招待メールが届いているはずですので、処理してください

2. Gravatar でアバターを登録する
   登録メールアドレスは GitHub と同じものにしてください

3. 手元の Ubuntu 12.04 に git を入れる

   書式設定済み
   $ sudo apt-get install git git-doc

4. ユーザー名とメールアドレスを GitHub と同じになるように設定する

   書式設定済み
   $ git config --global user.name morimotoymmt $ git config --global user.email kenji_morimoto@cybozuxxxx@cybozu.co.jp

5. おまじないをしておく

   書式設定済み
   $ git config --global merge.ff false $ git config --global pull.rebase true

6. (オプション) GitHub のパスワードを $HOME/.gitconfig に保存する
   保存しておくと、git hazama review のときに GitHub パスワードを聞かれずに済みます

   書式設定済み
   $ git config --global user.password XXXX $ chmod 600 $HOME/.gitconfig

7. kintone のユーザー名とパスワードを $HOME/.gitconfig に保存する
   パスワードはオプションですが、以下略。

   書式設定済み
   $ git config --global kintone.user hyamamotoXXXX $ git config --global kintone.password XXXX

8. GitHub 用の ssh キーを生成して設定する
   -C で指定するメールアドレスは GitHub と同じにしてください。

   書式設定済み
   $ ssh-keygen -t rsa -C kenji_morimoto@cybozuxxxx@cybozu.co.jp -f $HOME/.ssh/github $ vi ~/.ssh/config # add following lines Host github HostName github.dev.cybozu.co.jplocaldomain User git IdentityFile ~/.ssh/github

9. GitHub に SSH の公開鍵を登録する
   $HOME/.ssh/github.pub の中身を設定画面で登録してください。 の中身を設定画面で登録してください。

10. hazama/tools レポジトリをクローンして PATH を設定する

    書式設定済み
    $ git clone github:hazama/tools $ echo "export PATH=$(pwd)/tools/bin:\$PATH" >> $HOME/.bashrc $ . $HOME/.bashrc $ git hazama (動作確認)

11. レポジトリをクローンする
    git hazama setup で適切にリモートレポジトリ（stable）を設定してくれます

    書式設定済み
    $ git hazama setup infra $ cd infra $ git remote -v show origin github:hazama/infra (fetch) origin github:hazama/infra (push) stable github:forest/infra (fetch) stable github:forest/infra (push)

...

practice では infra と同じように下記のワークフローを実行できるので、誰かと一緒に練習してみてください。
forest/practice は Hazama, Forest の人全員に は全員に PUSH 権限を与えているので、PULL リクエストを処理できます。

練習の際には Hazama タスク管理 kintone に練習用のチケットを登録して、そのチケットで練習してください。

アンカー
workflow workflow

ワークフロー

タスク管理の方法

kintone の Hazama タスク管理 のタスク管理 アプリを使います。 Forest の人も、git の変更を伴うものは必ず Hazama タスク管理で実施するようにしてください。

大まかな流れは以下になります。

1. (PG1) タスクを登録する
2. (PG1) 開発し、Development Review にする
   Development Review にする際に、GitHub の hazama/infra に PULL リクエストを投げる。
   PULLリクエストの担当者にはレビュワーの PG2 を指定する。
3. (PG2) リクエスト内容をレビューし、不備があればコメントする（クローズはしない）
4. (PG1) レビュワーに差し戻されたら、トピックブランチに修正コミットを追加して PUSH する
5. (PG2) レビュー OK なら PULL リクエストをマージし、Testing にする
6. (PG1) マージされたのを確認して install-forest dev し、適用するマージされたのを確認して、開発用データセンターに適用する
7. (QA) 試験をし、不具合があれば Reopen する
8. (PG1) リオープンされたら修正をトピックブランチに PUSH し、再度 PULL リクエストを投げる
9. (PG2) ditto
10. (QA) 試験合格したらステータスを Staging にする
11. (PG1) Staging になった関連タスクを運用環境への期日の直前に PULL リクエストを投げるになった関連タスクの PULL リクエストを forest/infra に投げる。
    PULL リクエストを投げたら、タスクは Close する。
12. (ForestOP) forest/infra にマージする。
    マージしたら適用手順に従い install-forest prod, install-forest bk する。 にマージする
    マージしたら適用手順に従い運用データセンターに適用する。

開発レビューまでの作業

1. 一時ブランチを作る

   書式設定済み
   $ git hazama dev Branch dev set up to track remote branch master from upstream. Switched to a new branch 'dev'

2. 開発する
   途中で何度コミットしても構いません。最低１日に１回はコミットして origin/master をマージしましょう。
   途中のコミットはあとで捨てるので、コミットコメントは適当で構いません。

   書式設定済み
   $ git commit -a -m 'blur blur' $ git fetch origin $ git merge --no-ff origin/master (コンフリクトしたら修正して commit する) (git rebase は間違うと痛いので、使わないこと)

3. 開発が完了したら git hazama review コマンドを実行する

   書式設定済み
   $ git hazama review dev xx (xx は実際には INFRA-535 なら 535 を指定します) $ git branch -D dev (ブランチ削除は意図的に hazama review でやらないようにしているので、自分で消す)

   このコマンドでは以下のようなことが実行されます

   1. トピックブランチ INFRA-xx を作成
   2. git merge --squash dev
   3. git push origin INFRA-xx
   4. GitHub API で hazama/infra に PULL リクエストを作成する
   5. kintone に PULL リクエストの URL を追記する
4. GitHub 上で PULL リクエストを確認する
   レビュー担当者を指定できるので、指定しておきましょう

5. レビュワーに PULL リクエストをレビューしてもらう
   PULL リクエストは行単位でコメントをつけることができます。
   レビュワーは承認したらマージボタンを押してマージしてください。
   承認できないときはクローズせず、修正を追加コミットするよう指示します。

   情報
   大幅改修などが必要の場合は、PULLリクエストをマージせずにクローズすることもあります。大幅に改修が必要な場合は、PULLリクエストをマージせずにクローズすることもあります。 その場合は、以下のようなフローになります。 まだorigin/masterにマージされたコミットがない場合 　→　git push origin :INFRA-xxでブランチを消してやり直す。 すでにorigin/masterにマージされたコミットがある場合（試験後に差し戻されたときなど） 　→　「試験で不具合がみつかったときの作業」と同じ

6. レビューが却下されたら、INFRA-xx ブランチから dev ブランチを作り開発を続ける
   ちょっとした修正なら dev 作らず INFRA-xx で直接作業しても構いません。

   書式設定済み
   $ git checkout -b dev INFRA-xx (開発) $ git commit -m 'hoge' $ git checkout INFRA-xx $ git merge --ff --squash dev $ git commit -m 'INFRA-xx: fix a bug.' $ git push origin INFRA-xx $ git branch -D dev

   トピックブランチに PUSH すると、以前の PULL リクエストに反映されるので、再度レビューしてもらう。

   $ git fetch origin $ git merge --no-ff origin/master

   マスターが更新されたため、レビュー承認後に PULL リクエストのマージが行えない場合があります。
   この場合は origin/master を手元でマージして PUSH することで、PULL リクエストのマージが行えるようになります。

   情報
   マスターが更新されたため、レビュー承認後にマージが行えない場合があります。 この場合は、マスターを merge して、コンフリクトを解決してください。
   書式設定済み

7. レビューが通ってマージされたら、ローカルブランチを消す
   (リモートブランチは消さない)

   書式設定済み
   $ git checkout master $ git pull (マージ後のソースに更新される) $ git branch -d INFRA-xx (-D で強制しなくても、マージされていたら消せるはず)

...

1. git hazama pick で cherry-pick まで実行する
   コンフリクトする場合はエラーで止まりますので、指示される通りに解決してください

   書式設定済み
   $ git hazama pick xx (xx は INFRA-353 なら 353 を指定) (INFRA-xx-forest トピックブランチを作成して cherry-pick します)

   情報
   コンフリクトするはずなんてないのにおかしい、といった場合は cherry-pick を中断してください。 書式設定済み $ git cherry-pick --abort $ git checkout master $ git branch -D INFRA-xx-forest

2. コンフリクトが解決したら、修正してコミットして continue します

   書式設定済み
   $ vi ... $ git add ... $ git cherry-pick --continue

   コミットメッセージには'INFRA-xx: fix conflicts.'と入れます。

3. git hazama stage でトピックブランチを PUSH して PULL リクエストを投げます

   書式設定済み
   $ git hazama stage xx

   このコマンドでは以下のようなことが実行されます

   1. git push origin INFRA-xx-forest
   2. GitHub API で forest/infra に PULL リクエストを作成する
   3. kintone に PULL リクエストの URL を追記する
4. GitHub 上で PULL リクエストを確認

5. マージされたらローカルブランチを消す

   書式設定済み
   $ git checkout master $ git fetch stable $ git branch -d INFRA-xx-forest (-D で強制しなくても、マージされていたら消せるはず)

ベストプラクティス

...

Git 編

1. master で作業しない
   必ずブランチを作って作業しましょう。
2. git pull は基本的に使わない は基本的に使わない
   git fetch して、適宜  して、適宜 merge しましょう。
   作業しない master ブランチは、git ブランチは git pull で更新して構いません。 で更新して構いません。
3. 一度 PUSH したブランチは rebase してはいけない
   PUSH したあと、PUSH した履歴を書き換えちゃうことになるので、ダメ、絶対。
4. むしろ git rebase しない しない
   以下参考に。
   • http://togetter.com/li/407277
   • rebaseにまつわる 3 つの誤解
5. トップディレクトリには .gitignore を置いておく
   こうすれば、他の人と add したくないファイルの設定を共有できます。

...

1. レポジトリは小分けにする
   GitHub では誰でも自由にレポジトリを作れるので、関連性の薄いモジュールをひとつのレポジトリで管理する必要はありません。
   小分けにしている方が、フォークやクローンが速くて良いです。
2. 共有レポジトリの変更は PULL リクエストで
   いきなり master に PUSH するのは止しましょう。
   ブランチから PULL リクエストを投げて、レビューを受けるようにしてください。
3. むやみに共有レポジトリをフォークしない
   リソースがもったいないので、大きなレポジトリはむやみにフォークしてはいけません。
   PUSH 権限がない別のチームのレポジトリに PULL リクエストを投げるようなときに、フォークしましょう。

...

Tips

共有レポジトリの変更（PULLリクエストとか）を追いたい

...

$ git show HEAD^:<filename>

• get a file from a specific revision

リモートブランチを作りたい / 消したい

リモートブランチはローカルブランチを PUSH することで作成できます。

$ git checkout -b branch origin/master
(適当に編集)
$ git push -u origin branch
(これで作られる)

$ git remote show origin
(PUSH/PULL リモート設定を確認)

...

git-hoge みたいなコマンドを作って PATH の通っているところに置くだけです。
c.f. http://blog.thehippo.de/2012/03/tools-and-software/how-to-create-a-custom-git-command-extension/

References

• gitこんなときどうするGit & GitHub & kintone でウルトラハッピー！
• Git and GitHub Secrets
  一読の価値あり。