...
このコマンドを実行すると、リモートレポジトリにも 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 でアクセスできます。
レポジトリ管理
GitHub (Enterprise(Enterprise) ではレポジトリは個々の利用者が自由に作ることができます。共有レポジトリをフォークすることも自由です。
共有レポジトリを管理するために Organization という仕組みがあり、Organization は複数の Owner が共同管理できます。
Organization では は複数の Team を複数作成して、それぞれのチームごとに を持つことができ、チームごと所属するメンバー、レポジトリ、および PUSH, PULL の権限を制御できます。
Organization は誰でも作ることができます。社内の GitHub では以下の URL から。
...
は誰でも作ることができます。
コミュニケーション
GitHub ではコミットや差分の行単位でコメントをつけることができます。コメントは GitHub の通知機能やメールで通知されます。
メール通知は個人設定で止めることもできます。特定のレポジトリを watch すると、そのレポジトリの変更が通知されます。
...
レポジトリごとにタスクや不具合を管理する Issues 機能がありますが、非常に簡素なものですので kintone や JIRA の代わりにはなりません。
API
GitHub 本家と同じ API が利用できます。
API を利用すると PULL リクエストをコマンドラインから送るようなことができます。
...
書式設定済み |
---|
$ git clone repo
(初回のみ)
$ cd repo
$ rm -rf *
$ git fetch origin
$ git reset --hard
(これでまっさらな最新のソースが手に入ります)
|
...
最初にやること
Forest, Hazama で共有するレポジトリは GitHub の forest, hazama Organization で管理されています。
警告 |
---|
共有レポジトリの master ブランチには直接 PUSH してはいけません。 |
forest
forest は install-forest で運用環境にインストールする infra
レポジトリを管理しています。infra レポジトリに PUSH できる(PULLリクエストを処理できる)のは当面森本さんと山本だけです。Forest の人が git に慣れたら、Forest メンバーは PULL リクエストを処理できるようにしようと思います。
hazama
hazama は forest/infra
を開発用にクローンしています。また、install-forest に直接関係しない tbs
や js
や ubuntu
はそれぞれ個別のレポジトリとして hazama で管理しています。Forest, Hazama の人は誰でも PULL リクエストを処理できます。
hazama/tools
には開発用のツールがありますので、まずこれを手元にクローンしてください。
最初にやること
- GitHub にログインしてパスワードを変更する
GitHub にログインしてパスワードを変更する
招待メールが届いているはずですので、処理してください
- Gravatar でアバターを登録する
登録メールアドレスは GitHub と同じものにしてください 手元の Ubuntu 12.04 に git を入れる
書式設定済み $ sudo apt-get install git git-doc
ユーザー名とメールアドレスを GitHub と同じになるように設定する
書式設定済み $ git config --global user.name morimotoymmt $ git config --global user.email kenji_morimoto@cybozuxxxx@cybozu.co.jp
おまじないをしておく
書式設定済み $ git config --global merge.ff false $ git config --global pull.rebase true
(オプション) GitHub のパスワードを
$HOME/.gitconfig
に保存する
保存しておくと、git hazama review
のときに GitHub パスワードを聞かれずに済みます書式設定済み $ git config --global user.password XXXX $ chmod 600 $HOME/.gitconfig
kintone のユーザー名とパスワードを
$HOME/.gitconfig
に保存する
パスワードはオプションですが、以下略。書式設定済み $ git config --global kintone.user hyamamotoXXXX $ git config --global kintone.password XXXX
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
- GitHub に SSH の公開鍵を登録する
$HOME/.ssh/github.pub
の中身を設定画面で登録してください。 の中身を設定画面で登録してください。 hazama/tools
レポジトリをクローンして PATH を設定する書式設定済み $ git clone github:hazama/tools $ echo "export PATH=$(pwd)/tools/bin:\$PATH" >> $HOME/.bashrc $ . $HOME/.bashrc $ git hazama (動作確認)
レポジトリをクローンする
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 に練習用のチケットを登録して、そのチケットで練習してください。
アンカー | ||||
---|---|---|---|---|
|
タスク管理の方法
kintone の Hazama タスク管理 のタスク管理 アプリを使います。 Forest の人も、git の変更を伴うものは必ず Hazama タスク管理で実施するようにしてください。
大まかな流れは以下になります。
- (PG1) タスクを登録する
- (PG1) 開発し、Development Review にする
Development Review にする際に、GitHub のhazama/infra
に PULL リクエストを投げる。
PULLリクエストの担当者にはレビュワーの PG2 を指定する。 - (PG2) リクエスト内容をレビューし、不備があればコメントする(クローズはしない)
- (PG1) レビュワーに差し戻されたら、トピックブランチに修正コミットを追加して PUSH する
- (PG2) レビュー OK なら PULL リクエストをマージし、Testing にする
- (PG1) マージされたのを確認して
install-forest dev
し、適用するマージされたのを確認して、開発用データセンターに適用する - (QA) 試験をし、不具合があれば Reopen する
- (PG1) リオープンされたら修正をトピックブランチに PUSH し、再度 PULL リクエストを投げる
- (PG2) ditto
- (QA) 試験合格したらステータスを Staging にする
- (PG1) Staging になった関連タスクを運用環境への期日の直前に PULL リクエストを投げるになった関連タスクの PULL リクエストを
forest/infra
に投げる。
PULL リクエストを投げたら、タスクは Close する。 - (ForestOP)
forest/infra
にマージする。
マージしたら適用手順に従いinstall-forest prod
,install-forest bk
する。 にマージする
マージしたら適用手順に従い運用データセンターに適用する。
開発レビューまでの作業
一時ブランチを作る
書式設定済み $ git hazama dev Branch dev set up to track remote branch master from upstream. Switched to a new branch 'dev'
開発する
途中で何度コミットしても構いません。最低1日に1回はコミットしてorigin/master
をマージしましょう。
途中のコミットはあとで捨てるので、コミットコメントは適当で構いません。書式設定済み $ git commit -a -m 'blur blur' $ git fetch origin $ git merge --no-ff origin/master (コンフリクトしたら修正して commit する) (git rebase は間違うと痛いので、使わないこと)
開発が完了したら
git hazama review
コマンドを実行する書式設定済み $ git hazama review dev xx (xx は実際には INFRA-535 なら 535 を指定します) $ git branch -D dev (ブランチ削除は意図的に hazama review でやらないようにしているので、自分で消す)
このコマンドでは以下のようなことが実行されます
- トピックブランチ INFRA-xx を作成
git merge --squash dev
git push origin INFRA-xx
- GitHub API で
hazama/infra
に PULL リクエストを作成する - kintone に PULL リクエストの URL を追記する
- GitHub 上で PULL リクエストを確認する
レビュー担当者を指定できるので、指定しておきましょう レビュワーに PULL リクエストをレビューしてもらう
PULL リクエストは行単位でコメントをつけることができます。
レビュワーは承認したらマージボタンを押してマージしてください。
承認できないときはクローズせず、修正を追加コミットするよう指示します。情報 大幅改修などが必要の場合は、PULLリクエストをマージせずにクローズすることもあります。
その場合は、以下のようなフローになります。- まだorigin/masterにマージされたコミットがない場合
→ git push origin :INFRA-xxでブランチを消してやり直す。 - すでにorigin/masterにマージされたコミットがある場合(試験後に差し戻されたときなど)
→ 「試験で不具合がみつかったときの作業」と同じ
- まだorigin/masterにマージされたコミットがない場合
レビューが却下されたら、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 リクエストに反映されるので、再度レビューしてもらう。
情報 マスターが更新されたため、レビュー承認後にマージが行えない場合があります。
この場合は、マスターを merge して、コンフリクトを解決してください。 $ git fetch origin $ git merge --no-ff origin/master書式設定済み マスターが更新されたため、レビュー承認後に PULL リクエストのマージが行えない場合があります。
この場合はorigin/master
を手元でマージして PUSH することで、PULL リクエストのマージが行えるようになります。レビューが通ってマージされたら、ローカルブランチを消す
(リモートブランチは消さない)書式設定済み $ git checkout master $ git pull (マージ後のソースに更新される) $ git branch -d INFRA-xx (-D で強制しなくても、マージされていたら消せるはず)
...
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
コンフリクトが解決したら、修正してコミットして continue します
書式設定済み $ vi ... $ git add ... $ git cherry-pick --continue
コミットメッセージには'INFRA-xx: fix conflicts.'と入れます。
git hazama stage
でトピックブランチを PUSH して PULL リクエストを投げます書式設定済み $ git hazama stage xx
このコマンドでは以下のようなことが実行されます
git push origin INFRA-xx-forest
- GitHub API で
forest/infra
に PULL リクエストを作成する - kintone に PULL リクエストの URL を追記する
- GitHub 上で PULL リクエストを確認
マージされたらローカルブランチを消す
書式設定済み $ git checkout master $ git fetch stable $ git branch -d INFRA-xx-forest (-D で強制しなくても、マージされていたら消せるはず)
ベストプラクティス
...
Git 編
- master で作業しない
必ずブランチを作って作業しましょう。 git pull
は基本的に使わない は基本的に使わないgit fetch
して、適宜 して、適宜 merge しましょう。
作業しない master ブランチは、git ブランチはgit pull
で更新して構いません。 で更新して構いません。- 一度 PUSH したブランチは rebase してはいけない
PUSH したあと、PUSH した履歴を書き換えちゃうことになるので、ダメ、絶対。 - むしろ
git rebase
しない しない
以下参考に。 - トップディレクトリには
.gitignore
を置いておく
こうすれば、他の人と add したくないファイルの設定を共有できます。
...
書式設定済み |
---|
$ git show HEAD^:<filename> |
リモートブランチを作りたい / 消したい
リモートブランチはローカルブランチを 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/