比較バージョン

古いバージョン 4

changes.mady.by.user Hirotaka Yamamoto

保存しました

次と比較

新しいバージョン 現在

changes.mady.by.user Hirotaka Yamamoto

保存しました

キー

  • この行は追加されました。
  • この行は削除されました。
  • 書式設定が変更されました。
コメント: Migrated to Confluence 5.3
情報

これは cybozu.com インフラ開発チームが社内で使用しているマニュアルを一部修正したものです。 のインフラ開発チームが社内で使用しているマニュアルを一部修正したものです。
一般的に Git や GitHub の使い方を指南するものではありません。

文中の GitHub はほとんどの場合、サイボウズ社内で利用している GitHub Enterprise のことを指しています。
操作例については Ubuntu 12.04 での動作を前提としています。 での動作を前提としています。フィードバックはこちらにお願いします。

目次
minLevel2

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

...

情報

PULL リクエストは実際には git diff REV1...REV2 を動的に実行して適用するコミットを決めます。cherry-pick のように意図したコミットだけを PULL リクエストで取り込んでもらうには、意図したコミットしか含まないトピックブランチを作成して、そこから送ることになるでしょう。

Gist

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

...

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

簡単な使い方：

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

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

...

アーカイブ

情報

GitHub Enterprise 11.10.300 でアーカイブダウンロード機能が搭載されました。
以下の情報は古いものです。　（2013/02/01 追記） 

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

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

...

  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リクエストをマージせずにクローズすることもあります。
    その場合は、以下のようなフローになります。

    1. まだorigin/masterにマージされたコミットがない場合
      　→　git push origin :INFRA-xxでブランチを消してやり直す。
    2. すでに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 リクエストに反映されるので、再度レビューしてもらう。

    情報

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

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

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

...

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

...

Tips

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

...