Git はバージョン管理ツールです。Hazama/Forest が開発する成果物はすべて git で管理されています。
GitHub はオープンな git レポジトリのホスティングサービスで、瞬く間に世界中で利用されるほどに広まった優れたサービスです。
サイボウズでは GitHub を社内で利用できる GitHub Enterprise を導入して利用しています。
git は難しいとよく言われます。実際に使ってみてわかったことは、git の仕組みそのものは比較的に単純なのですが、「このように使うべき」という作業の流れ(ワークフロー)が git のコマンド体系には欠けているため、非常にたくさんの機能が乱雑に並んでいるように思え、どう使うのかよくわからないというのが難しさの正体です。
特定のワークフローを規定せずにユーザーの自由に任せているのはおそらく git が意識的にしていることです。ワークフローを確立するまではいろいろと使い方に悩むというデメリットの反面、利用方法が縛られないのでチームレベルのプロジェクトはもちろん、個人での利用や世界各地で行われる分散開発(Linux カーネル開発)と、あらゆる開発プロジェクトで利用できる柔軟性を備えています。
特にブランチとマージの管理が優れているので、ガルーンのように非常に複雑な分岐をしている製品であっても、特定の不具合の修正を他のブランチに取り込むといったことが簡単にできます。
Subversion のことは忘れましょう。利用できる機能は表面上似ているものも多いのですが、それを実現している内部の方式がまったく異なるため、たとえばマージで行われていることは Subversion の知識で理解しようとしてもうまくいきません。マージやチェックアウトやブランチという言葉は共通で使われていますが、Subversion の動作から理解しようとしても無理です。
まずはこの資料を読んでみましょう。
git は分散バージョン管理システムであるのが一番の特徴であるように言われますが、分散して開発されたコードをうまくマージできる内部構造が最大の特徴と理解したほうが良いです。分散開発を可能にする内部構造を知らずして、git の動作を理解することはできません。
内部構造の中心となっているのは、コミットオブジェクトのグラフ(正確には DAG)です。Subversion のコミットはファイル単位の diff に過ぎませんでしたが(Subversion は直線的なリビジョン管理しか存在しないので、それで十分)、git ではコミットはグラフのノードのことで、DAG 構造を示すために1つ以上の親ノードの情報が含まれています。
git ではマージ操作は複数の枝が合流することで、マージコミットオブジェクトで表現されます。マージコミットには二つ以上の親ノードの情報が含まれているわけです。また、コミットグラフには他のレポジトリ(リモートレポジトリ。単にリモートと呼ぶことも多い)のグラフを持ってくることもできます。これらコミットグラフやリモート、タグ、ブランチを図解している良いサイトが以下にありますので、一読してみてください。
コミットグラフの DAG の先端をブランチと呼びます。新たに枝を分岐したいときは、git branch
コマンドでつくります。
ローカルブランチの一覧を見るには、git branch
とします。
$ git branch * INFRA-xx master |
* がついているのが現在作業中のブランチです。
作業ブランチを切り替えるには、git checkout
を使います。
$ git checkout master $ git branch INFRA-xx * master |
新たなブランチは以下のように作ります。
$ git checkout -b new_branch master $ git branch INFRA-xx master * new_branch |
実際に試すとわかりますが、ブランチの作成や切り替えは瞬時に完了します。git では新機能の開発や不具合の改修といったひとつひとつのタスクごとにブランチを作成し、開発が完了してから master にマージするのが定石です。ごく単純な修正以外は、master 上で直接開発するのは避け、ブランチで開発してください。
c.f. A successful Git branching model (翻訳版)
git は空のレポジトリを作って使い始めることもできますが、普通は GitHub や他の開発者のレポジトリをクローンして使い始めることが多いでしょう。クローンしたレポジトリには、クローン元のリモートレポジトリの情報が設定されています。以下を試して確認してください。
$ git clone github:hazama/infra $ cd infra $ git branch -r origin/HEAD -> origin/master origin/INFRA-xx origin/master $ git remote show origin * remote origin Fetch URL: github:hazama/test_infra Push URL: github:hazama/test_infra HEAD branch: master Remote branches: INFRA-xx tracked master tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) |
Local branch configured for ...
という箇所が、ローカルレポジトリのブランチがどのリモートレポジトリのブランチと結びついているかの設定情報です。git pull
や git push
するときに、対象となるリモートブランチの指定が省略可能になります。設定されていない純粋なローカルブランチであっても、別途設定することが可能です。
リモートレポジトリは複数設定することができますが、クローンしたときには origin
という名前でクローン元のリモートレポジトリが追加されています。
リモートレポジトリの更新を手元に持ってくるには、git fetch origin
とします。
$ git fetch origin remote: Counting objects: 24, done. remote: Compressing objects: 100% (11/11), done. remote: Total 16 (delta 10), reused 11 (delta 5) Unpacking objects: 100% (16/16), done. From github:hazama/test_infra * [new branch] INFRA-xxx -> origin/INFRA-xxx aeb7209..8f880da master -> origin/master * [new branch] review_INFRA-xxx -> origin/review_INFRA-xxx |
INFRA-xxx
や review_INFRA-xxx
というリモートレポジトリの情報が追加された情報が表示されています。
リモートレポジトリに対して何か作業をしたいときは、リモートレポジトリを追跡するトラッキングブランチを作成します。単純に、リモートブランチからローカルブランチを作成すればトラッキング情報が設定されます。
$ git checkout -b INFRA-yy origin/master Branch INFRA-yy set up to track remote branch master from origin. Switched to a new branch 'INFRA-yy' $ git remote show origin * remote origin Fetch URL: github:hazama/test_infra Push URL: github:hazama/test_infra HEAD branch: master Remote branches: master tracked Local branches configured for 'git pull': master merges with remote master INFRA-yy merges with remote master Local refs configured for 'git push': master pushes to master (local out of date) |
ローカルで開発したコミットグラフをリモートに反映するには git push
します。
$ git commit -a -m 'finished.' $ git fetch origin $ git rebase $ git checkout master $ git merge --squash INFRA-yy $ git commit -m INFRA-yy $ git push -u origin master |
フォークしているプロジェクトの場合、上流(アップストリーム)レポジトリの変更を取り込んだりパッチや PULL リクエストを送りたくなります。そういうときは、アップストリームレポジトリを追加することができます。以下の例では forest/infra
を stable
という名前のリモートとして追加しています。
$ git remote add stable github:forest/infra $ git fetch stable $ git checkout -b INFRA-yy-for-stable stable/master $ git cherry-pick COMMIT |
|
ファストフォワードという用語がしばしば出てくるので解説しておきます。二つのブランチをマージする際に、マージするコミットがマージ先のブランチに単追加されるだけの状況のとき、ファストフォワードマージという特殊なマージとなります。
一般的にはマージ操作ではマージコミットというコミットオブジェクトが作られます。これは二つのブランチが合流したことを示すもので、親コミットが二つ以上記録されます。一方、ファストフォワードマージではマージコミットオブジェクトは作成されず、単純にマージ元にのみあるコミットオブジェクトがマージ先に追加されるだけです。
具体的には、以下のような操作のときに行われるのがファストフォワードマージです。
$ git checkout -b branch master (branch 上でのみ作業) $ git commit -m 'hoge' $ git checkout master $ git merge branch $ git branch -d branch |
master と branch の違いは branch で追加されたコミットのみなので、branch で追加されたコミットオブジェクトが master に追加されるだけとなります。マージコミットオブジェクトは作成されないので、マージがあったことをあとで確認することはできません。
git merge --no-ff
とすることで、ファストフォワードが可能な場合でもマージコミットオブジェクトを作成することができます。マージしたことを記録に残したい場合に使います。後述する GitHub のプルリクエストを GUI で処理するときも、常にマージコミットオブジェクトが作成されます。
git は利用者が多いのでチュートリアル資料もたくさんあります。以下がおすすめです。
git は基本的には個人で使うための機能しかなく、レポジトリを共有管理する機能は充実していません。
レポジトリの共有管理をするためには gitolite のようなオープンソースツールもありますが、gitolite プロジェクト自体も GitHub でホスティングされているように、git レポジトリホスティング機能としては GitHub がダントツに優れています。
社内の GitHub Enterprise には以下の URL でアクセスできます。
GitHub (Enterprise) ではレポジトリは個々の利用者が自由に作ることができます。共有レポジトリをフォークすることも自由です。
共有レポジトリを管理するために Organization という仕組みがあり、Organization は複数の Owner が共同管理できます。
Organization では Team を複数作成して、それぞれのチームごとに PUSH, PULL の権限を制御できます。
Organization は誰でも作ることができます。社内の GitHub では以下の URL から。
GitHub ではコミットや差分の行単位でコメントをつけることができます。コメントは GitHub の通知機能やメールで通知されます。
メール通知は個人設定で止めることもできます。特定のレポジトリを watch すると、そのレポジトリの変更が通知されます。
ユーザーの顔写真には Gravatar というサービスを利用して表示しています。顔写真がないと誰が操作したのかわかりにくいので、GitHub に登録したら必ず Gravatar を設定しましょう。Gravatar でアバターを指定するメールアドレスは、GitHub で登録されているメールアドレスにしてください(メールアドレスが主キーです)。
あとは "@ユーザー名" と書くとそのユーザーに通知してくれるメンション機能があります。
GitHub で特に有名な機能に PULL リクエストがあります。フォークしたレポジトリ間やブランチ間で、特定の差分を取り込んでもらうように GUI で依頼する機能で、依頼を受けた側はボタン一つでマージできます。差分の行単位でコメントをつけることができるので、レビューツールとしても非常に便利に使えます。
PULL リクエストは担当者を指定できるので、レビューを依頼するユーザーに設定しましょう。
PULL リクエストはフォークしたレポジトリ間でなくとも、ひとつのレポジトリのブランチ間でも投げることができます。 |
PULL リクエストは実際には |
レポジトリ管理とは無関連の、コードスニペットを共有する機能です。
GitHub のおまけ的機能ですが、script タグで他のページに埋め込める等なかなか便利です。
GitHub はマークダウン記法 でコメントやドキュメントを書く機能があります。
各レポジトリにはこのマークダウン記法でページを作成できる Wiki 機能が付属しています。
Wiki システムは Gollum というもので、詳細はリンク先を読んでください。
簡単な使い方:
ページ間リンクは [[
で書く
[[PageName]] [[Title|PageName]] |
レポジトリごとにタスクや不具合を管理する Issues 機能がありますが、非常に簡素なものですので kintone や JIRA の代わりにはなりません。
GitHub 本家と同じ API が利用できます。
API を利用すると PULL リクエストをコマンドラインから送るようなことができます。
レポジトリではなく、ファイルだけを取得する git archive
機能は GitHub では提供されていません。クローンしてください。
毎日のビルドにつかうなら、こんな感じ。svn export
よりむしろ高速です。
$ git clone repo (初回のみ) $ cd repo $ rm -rf * $ git fetch origin $ git reset --hard (これでまっさらな最新のソースが手に入ります) |
Forest, Hazama で共有するレポジトリは GitHub の forest, hazama Organization で管理されています。
共有レポジトリの master ブランチには直接 PUSH してはいけません。 |
forest は install-forest で運用環境にインストールする infra
レポジトリを管理しています。infra レポジトリに PUSH できる(PULLリクエストを処理できる)のは当面森本さんと山本だけです。Forest の人が git に慣れたら、Forest メンバーは PULL リクエストを処理できるようにしようと思います。
hazama は forest/infra
を開発用にクローンしています。また、install-forest に直接関係しない tbs
や js
や ubuntu
はそれぞれ個別のレポジトリとして hazama で管理しています。Forest, Hazama の人は誰でも PULL リクエストを処理できます。
hazama/tools
には開発用のツールがありますので、まずこれを手元にクローンしてください。
手元の Ubuntu 12.04 に git を入れる
$ sudo apt-get install git git-doc |
ユーザー名とメールアドレスを GitHub と同じになるように設定する
$ git config --global user.name morimoto $ git config --global user.email kenji_morimoto@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 hyamamoto $ git config --global kintone.password XXXX |
GitHub 用の ssh キーを生成して設定する
-C で指定するメールアドレスは GitHub と同じにしてください。
$ ssh-keygen -t rsa -C kenji_morimoto@cybozu.co.jp -f $HOME/.ssh/github $ vi ~/.ssh/config # add following lines Host github HostName github.dev.cybozu.co.jp User git IdentityFile ~/.ssh/github |
$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) |
これで infra
レポジトリの開発をする準備は完了です。
他のレポジトリも同様ですが、stable リモートは不要なので単にクローンすれば OK です。
git hazama setup
してもいいですが、単にクローンするだけです。
$ git clone github:hazama/tbs $ cd tbs $ git remote -v show origin github:hazama/tbs (fetch) origin github:hazama/tbs (push) |
いきなり本番の環境を触って壊さないよう、練習用のレポジトリ practice
を用意してあります。
infra
レポジトリと同様の操作ができるので、まずは以下の手順で準備をしてください。
$ git hazama setup practice |
practice
では infra
と同じように下記のワークフローを実行できるので、誰かと一緒に練習してみてください。
forest/practice
は Hazama, Forest の人全員に PUSH 権限を与えているので、PULL リクエストを処理できます。
練習の際には Hazama タスク管理 に練習用のチケットを登録して、そのチケットで練習してください。
kintone の Hazama タスク管理 アプリを使います。
Forest の人も、git の変更を伴うものは必ず Hazama タスク管理で実施するようにしてください。
大まかな流れは以下になります。
hazama/infra
に PULL リクエストを投げる。install-forest dev
し、適用する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 でやらないようにしているので、自分で消す) |
このコマンドでは以下のようなことが実行されます
git merge --squash dev
git push origin INFRA-xx
hazama/infra
に PULL リクエストを作成するレビュワーに PULL リクエストをレビューしてもらう
PULL リクエストは行単位でコメントをつけることができます。
レビュワーは承認したらマージボタンを押してマージしてください。
承認できないときはクローズせず、修正を追加コミットするよう指示します。
大幅改修などが必要の場合は、PULLリクエストをマージせずにクローズすることもあります。
|
レビューが却下されたら、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 checkout master $ git pull (マージ後のソースに更新される) $ git branch -d INFRA-xx (-D で強制しなくても、マージされていたら消せるはず) |
origin/INFRA-xx
からローカルブランチを作成する
$ git checkout -b INFRA-xx origin/INFRA-xx $ git fetch origin $ git merge --no-ff origin/master |
修正してコミットする
$ git commit -a -m "INFRA-xx: fix something." |
git hazama fix
コマンドを実行する
$ git hazama fix xx (xx は実際には INFRA-535 なら 535 を指定します) |
このコマンドでは以下のようなことが実行されます
git push origin INFRA-xx
hazama/infra
に PULL リクエストを作成するマージされたらローカルブランチを消す
(リモートブランチは消さない)
$ git checkout master $ git pull $ git branch -d INFRA-xx |
forest/infra
へのマージhazama/infra
関連のタスクは、試験完了後に forest/infra
にマージする必要があります。
マージしてほしい時期が近付いてきたら、forest に PULL リクエストを投げます。
GitHub の PULL リクエスト機能は投げる先のレポジトリ forest/infra@master
に対して、指定したブランチに存在するコミットをマージするように動作します。すでに作ってある INFRA-xx
トピックブランチは hazama/infra
にある、取り込まれるべきでないコミットも含んでいますので、INFRA-xx
から PULL リクエストを送ってはいけません。以下のように作業する必要があります。
forest/infra@master
からトピックブランチを作成するhazama/infra
でまだあててはいけないコミットを含まないことが保証できますINFRA-xx
作成後に追加されたコミットを git cherry-pick
で適用するINFRA-xx
作成後に追加されたコミットを特定するのは、機械的にやるのはなかなか骨です。git cherry-pick --continue
するforest/infra
に投げる以上のことをやってくれる git hazama pick
と git hazama stage
というコマンドがあります。
使い方は以下の通りです。
git hazama pick
で cherry-pick まで実行する
コンフリクトする場合はエラーで止まりますので、指示される通りに解決してください
$ git hazama pick xx (xx は INFRA-353 なら 353 を指定) (INFRA-xx-forest トピックブランチを作成して cherry-pick します) |
コンフリクトするはずなんてないのにおかしい、といった場合は cherry-pick を中断してください。
|
コンフリクトが解決したら、修正してコミットして 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
forest/infra
に PULL リクエストを作成するマージされたらローカルブランチを消す
$ git checkout master $ git fetch stable $ git branch -d INFRA-xx-forest (-D で強制しなくても、マージされていたら消せるはず) |
.gitignore
を置いておくその他これはというものがあれば、議論して追加しましょう。
svn2git
という Ruby のツールを使います。Ubuntu 12.04 ではこんな感じ。
authors.txt
は GitHub のユーザー名/メールアドレスと同じになるようにしましょう。
$ sudo apt-get install git-svn ruby1.9.1 $ sudo gem install svn2git $ cd $HOME $ cat >authors.txt <<EOF hyamamoto = ymmt <ymmt@cybozu.com> yusuke_kon = kon <yusuke_kon@cybozu.co.jp> toshishige-hagihara = hagihara <toshishige-hagihara@cybozu.co.jp> hidekazu_suzuki = hidekazu <hidekazu_suzuki@cybozu.co.jp> akihiro-kasuya = kasuya <akihiro-kasuya@cybozu.co.jp> ty_c = ty <ty_c@cybozu.co.jp> kotaro-ono = ono <kotaro-ono@cybozu.co.jp> kenji_morimoto = morimoto <kenji_morimoto@cybozu.co.jp> shinnosuke-saito = shinn <shinnosuke-saito@cybozu.co.jp> yuichi_tanaka = yuichi_tanaka <yuichi_tanaka@cybozu.co.jp> teppei_sato = teppei_sato <teppei_sato@cybozu.co.jp> yuki_okada = yuki_okada <yuki_okada@cybozu.co.jp> masanori_matsumoto = masanori_matsumoto <masanori_matsumoto@cybozu.co.jp> yasuharu-sakai = yasuharu-sakai <yasuharu-sakai@cybozu.co.jp> isami_yamada = isami_yamada <isami_yamada@cybozu.co.jp> masaki_oguro = masaki_oguro <masaki_oguro@cybozu.co.jp> jumpei-miyata = jumpei-miyata <jumpei_miyata@cybozu.co.jp> EOF $ mkdir t $ cd t $ svn2git http://svn.dev.cybozu.co.jp/svn/gaia \ --trunk trunk/infra --nobranches --notags --revision 25000 \ --authors $HOME/authors.txt --exclude tbs --exclude dtflib \ --exclude js --exclude ubuntu --verbose (レポジトリを分割するので、不要なものは exclude する) (--revision はここでは今年1月あたり以降の履歴をインポートするように指定しました) $ git log $ git push github:forest/infra master (GitHub に作っておいた空のレポジトリに PUSH する) |
Watch しましょう。すると、ログイン後の News Feed にアクティビティが出てきます。
通知を受け取りたければ、News Feed の RSS (トップページ右上あたり)を購読しましょう。
社内サーバーの RSS なので、社内で使える RSS リーダーが必要です。Chrome を使っていれば Slick RSS 辺りが便利です。
.bashrc の PS1 設定を以下のように変更しましょう。
git_branch() { echo $(git branch 2>/dev/null | sed -rn "s/^\* (.*)$/\1/p") } if [ "$color_prompt" = yes ]; then PS1='\[\033[32m\]\h\[\033[00m\]:\[\033[01;34m\]$(git_branch)\[\033[00m\]:\w\$ ' else PS1='\h:$(git_branch):\w\$ ' fi |
git diff -M
や git log -M -p
のように -M
を指定します。
さもないと、ファイルの削除と新規追加というようにばらばらに表示されてしまい、わかりにくいです。
$ git fetch upstream $ git diff -M ...upstream |
git diff -M COMMIT1...COMMIT2
で COMMIT2 にのみ含まれるコミットが表示されます。
単に差分を確認するだけなら git diff -M ..upsteam
です。
参考:
たとえば forest/infra
にまだ取り込まれていない hazama/infra
のコミットを知るには、以下のように git cherry
を使います。
$ git fetch testing $ git fetch stable $ git checkout testing/master $ git cherry -v stable/master + f10efc4e51b54251fe17968c3585b73718e04ff7 INFRA-398 + 968576c93041f79d570e229f183aae0ebb1d2d21 INFRA-502 + 7d441aff55a641be7a6c48b45af5ba3f6b396d93 INFRA-553 - 7e4723cf1597b9ba8a4095c5fc70290912303d62 INFRA-555 - 390504e8496a6ac5ad4b0d4b5b557e2d07fddc0b INFRA-564 |
行の先頭が "+" がまだ取り込まれていないコミット、"-" は同等の変更がすでに取り込まれたコミットです。
fgrep +
にパイプすれば取り込まれていないコミットだけを確認できます。
git commit --amend
git reset
--soft
git reset --soft HEAD^
です。--mixed
(デフォルト)--hard
git reset --hard
で svn revert
相当です。git rm --cached
git add
でインデックスにステージングされた変更を取り消せます。git reset --mixed
相当。git checkout -- FILE
git checkout COMMIT FILE
参考:http://d.hatena.ne.jp/mrgoofy33/20100910/1284069468
未コミットの修正をまだコミットしたくない時に別のブランチで作業をしたくなることは良くあります。git stash
を使うのも手ではありますが、結構面倒です。
以下のように git new-workdir
を使えるようにしておくととても便利。
$ sudo cp /usr/share/doc/git/contrib/workdir/git-new-workdir /usr/local/bin $ sudo chmod a+x /usr/local/bin/git-new-workdir |
参考:http://subtech.g.hatena.ne.jp/secondlife/20121207/1354854068
$ git show HEAD^:<filename> |
リモートブランチはローカルブランチを PUSH することで作成できます。
$ git checkout -b branch origin/master (適当に編集) $ git push origin branch (これで作られる) $ git remote show origin (PUSH/PULL リモート設定を確認) |
リモートブランチの削除も PUSH することで行います。
$ git push origin :branch |
巻き戻したいコミットの SHA1 サムを特定して、
$ git push origin +SHA1SUM:branch |
とするとリモートブランチが SHA1SUM まで巻き戻ります。SHA1SUM 自体は残ります。
git push origin branch
は実は git push origin branch:branch
の省略記法です。
なので、以下のようにするとリモートの別の名前のブランチに PUSH できます。
$ git push origin local_branch:remote_branch |
こちらを参考に。
git whatchanged --oneline
で一覧できます。
特定のコミットのみ調べたいなら、git show --name-only --oneline COMMIT
です。
git status
を読みやすくしたい$ git status -s M hoge ?? fuga |
ローカルで作って git push --tags
します。
$ git tag v1.1.0 $ git push --tags origin |
$HOME/.gitconfig に [alias] セクションを追加することで作成できます。
以下、記載例です。git l
あたりは便利なのでおすすめ。
[alias] st = status -sb co = checkout ci = commit del = !git checkout master && git branch -D p = push -u br = branch up = fetch --verbose --prune mg = merge --squash so = remote show origin df = diff --find-renames dfc = diff --cached --find-renames dfs = diff --staged --find-renames pick = cherry-pick changed = whatchanged l = log --pretty=format:\"%ci %C(yellow)%H%Creset [%cn] %Cgreen%s %C(cyan)%d%Creset\" -10 lg = log --graph --all --color --pretty='%x09%h %cn%x09%s %Cred%d%Creset' |
エスケープシーケンスで色を付けていますが、うまくできない人は以下を試してください。
$ git config --global core.pager less |
$ git config --global color.ui auto |
git stash
を使うと、変更を一時領域に保存して、あとで取り出すことができます。
$ git branch * master $ git stash $ git checkout -b dev testing/master $ git stash pop $ git diff |
git-hoge
みたいなコマンドを作って PATH の通っているところに置くだけです。
c.f. http://blog.thehippo.de/2012/03/tools-and-software/how-to-create-a-custom-git-command-extension/