- jupyter notebookをgitで管理する例を通して簡単な使い方を学びます。
から自分のOS用のものをダウンロードしてインストール
普通に入れられる、または伝統的なインストールのお作法が好きな方はそっちで入れてください。 macだとbrewで入れたりするといいでしょう。
そうでない人達は データサイエンティストを目指す人のpython環境構築 2016を参考に インストールしてください
python3を入れたほうが良いでしょう。
nameとemail addressの設定はやっておく
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
あとあとのことを考えるとエイリアスは設定しておいたほうが便利
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
このあたりを参考に
http://blog.karky7.com/2012/12/git.html
initialize
mkdir msm11
cd msm11
git init
jupyter notebook
IRISのPCAをやったらコミットします。
余談ですが、GitHubにipynb形式のファイルを アップロードするとフォーマットしてくれます（md/markdown形式も）
git add msm11.ipynb
git ci -m "Add IRIS-PCA" (or git commit -m "Add IRIS-PCA")
status(st)で状態を確認できます。
git st (git status)
コミット履歴は
git log
IRISのLDAをやったらコミットします。
一応変更があるか確認
git status (git st)
ではコミットします。
git add msm11.ipynb
git ci -m "Add LDA-PCA" (or git commit -m "Add LDA-PCA")
またはaオプションをつけるとGit管理下にあって変更のあるものは全てaddされるので 次のように一行でかけます（僕は普段こっち）。
git ci -am "Add LDA-PCA" (or git commit -am "Add LDA-PCA")
コミット履歴を見てみましょう
git log
少し変更を施してコミットします。
一応変更があるか確認
git status (git st)
ではコミットします。
git ci -am "Change plot" (or git commit -am "Add LDA-PCA")
IRISのKernel PCAを追加したらコミットします。
一応変更があるか確認
git status (git st)
ではコミットします。
git ci -am "Add kPCA" (or git commit -m "Add kPCA")
コミットはしたもののkPCAはいまいちだったのでやっぱりなかったことにしたい
消したいコミットIDを確認します
git log
ではrevertします
git revert fd668aea2c08 (idをコピペ)
確認
git log
実際になかったことになっていることを確認します。 プロットが2つ並んでいるコミットまで戻っているはず
そもそもコミットするかどうかわからない実験的な試みの場合、いつでも元に戻せるような 環境で試したいことがあります。それがブランチという枝分かれさせる昨日です。
枝分かれさせておいて破棄したい場合はそのまま削除、本体に取り込める場合にはマージして とりこむということが出来ます。
tSNEで試してみましょう。ブランチを作成するコマンドはbranchですのでtsneというブランチを 作ってみましょう
git branch tsne
git branchでどのブランチがあるのか確認できます。
git branch
* master
tsne
masterが今のブランチなのでcheckoutすることでブランチを移ることが出来ます
git co tsne
Switched to branch 'tsne'
git branch
master
* tsne
アスタリスクがついているのが現在のブランチです。ここでファイルに色々な変更を加えても マスターは影響を受けません。
なお、ブランチをつくりつつそのブランチに移動するショートカットもあって
git co -b tsne
とチェックアウト時に-bオプションを付ければOKです
ではtSNEを試してコミットしましょう。
git ci -am "Add IRIS-tSNE"
ログを確認
git log
先程のtsneブランチの作業は上手くいったので、masterブランチに反映させたいところです。 この取り込み工程をマージするといいます
masterブランチに移ってtsneブランチをマージします
git co master
git branch # masterに移っていることを確認
git log # tsneブランチで作ったコミットがないことを確認
git merge tsne
git log # tsneでのコミットがあることを確認
ブランチさせてマージさせることでmasterを常に綺麗に保つことが出来ます。汚れを溜め込まないのが メンテナンス性を向上させるコツですね。
さていらなくなったtsneブランチはどうしたら良いでしょう？
サクッと消します。
git branch -d tsne
git branch # ブランチ確認
今回はブランチを一つ作りましたが、複数作ることが多いですし、例えばブランチである作業中だった時に 急ぎのべつの割り込みタスクが入ってきた場合、別途ブランチを作って先にそっちをやってからやりかけだった 元のブランチで作業するというようなことはよくあります。
うまくやるコツはマスターではなるべく作業せずにブランチを使ってマスターをできるだけクリーンに保つことです。
コミットにバージョンなどのタグをつけることが出来ます。一人で使うときにはあまり使わないと思います。
git tag # タグ一覧が見れます
git tag v1.0 # タグをセット
一人で一通り使えるようになったら、複数箇所で使うことを考えます。例えば自分のノートパソコンとサーバーで使うといった用途です。
Gitで管理されているディレクトリは簡単に複製を作ることが出来ます。
cd ~
mkdir deb
cd deb
git clone ~/msm11
と打つだけで先程まで行っていたjupyterタスクの複製が作られます。
もちろんホスト間でもcloneは可能で
git clone host:~/msm11
git clone https://host/msm11
のようなこともできます。会社で使う場合は大抵sshをつかったクローンが多くなると思います。
分散管理に関してはこのあたりを読むと良いでしょう。
ただし、複数箇所で使う場合はどこか一箇所で管理したいとか、そこでは開発する必要はなくてバックアップ先として 使いたいというニーズのほうが多いと思います。 そういったプロジェクトの管理専用のGitディレクトリを作成したい場合は、bareオプションをつけてinitします
mkdir ~/anotherrepo
cd ~/anotherrepo
git init --bare
このオプションで作られたディレクトリでは作業が出来ず。pushしたりcloneするだけのディレクトリになります。
ここから cloneすればどこが親だかわかっているのでgit pushでcloneもとにコミットがプッシュされます。
既に手元にあるGitレポジトリを新たに作ったbareのリポジトリにpushするにはどうしたらいいでしょうか？
git remote add origin ~/anotherrepo (absdirのほうがよい)
git push -u origin master
ログを見てチェックアウトしたいバージョンを調べます。
git log
commit 38aaefb7c6d2d228569876dd6648a256a2fa7fdc
Author: Kazufumi Ohkawa <kerolinq@gmail.com>
Date: Fri Sep 22 10:07:01 2017 +0200
Add IRIS-tSNE
commit 72495d9d7c44e4ffc21917ded456e591c23d36d0
Author: Kazufumi Ohkawa <kerolinq@gmail.com>
Date: Fri Sep 22 06:04:03 2017 +0200
Revert "Add kPCA"
This reverts commit fd668aea2c08bf734e968c6d980539dc8f0273f5.
commit fd668aea2c08bf734e968c6d980539dc8f0273f5
Author: Kazufumi Ohkawa <kerolinq@gmail.com>
Date: Fri Sep 22 05:58:55 2017 +0200
Add kPCA
commit e931e56747f4105e84151e1e8d2e988c42889cfa
Author: Kazufumi Ohkawa <kerolinq@gmail.com>
Date: Fri Sep 22 05:08:08 2017 +0200
Change Figure
commit番号を指定してcheckoutします。全部指定しなくても一意に決まればOKです
git co fd668aea2c08bf7
複数箇所で作業するとコンフリクトという現象が発生します。 今回はそこまでやらないので、コンフリクトしたら以下を参照して解決してください☆
http://qiita.com/hkengo/items/f47b9f50ac2dca407d12
このように、普段の仕事ではチームのコードを一箇所にまとめて管理するサーバーを立てることが多いと思います。 もしチームの垣根を超えて、大きなコミュニティーで一つの巨大なリポジトリマネジメントが出来たらどうなるでしょう？ そしてgit init --bareというようなルーティーンもウェブ上から簡単に行えるようになっていたり、チケットや、バグ報告も ウェブの掲示板的な仕組みと連動していたら？
それがGitHubです。
redmineのサーバーと同じホストにGitディレクトリを作ると、redmineと連携させることが出来ます。
- redmine上でコードの差分管理ができる
- チケットとブランチを対応させることで効率的な開発が行える
テンプレートファイルを用意したらgit cloneでクローンして 使い捨てればよいと思います。
- gitk(これはgit入れると使えるようになっているはず)
- sourcetree
- github desktop