TL;DR Jupyter Notebook で分析を進める際、バージョン管理をしたいと思いGitで管理をしてみましたが、普通に進めるとNotebook のメタデータによって差分がとても見づらかったので、JupyterLab の jupyterlab-gitと nbdimeエクステンションを利用し、差分を見やすく表示できるようにしてみました。 JupyterLab 環境を構築 今回の記事では、下記の環境を利用します。 docker-compose を使用 docker-compose のインストールは こちら を参照 コンテナイメージのベースは kaggle-images を利用 Jupyter notebook のバージョンコントロールに必要な JupyterLab エクステンションは下記になります。 jupyterlab-git nbdime こちらは jupyterlab-git をインストールすると一緒にインストールされる 環境構築 下記２ファイルを作成します。 Dockerfile docker-compose.yml Dockerfile FROM gcr.io/kaggle-images/python:v74 RUN apt-get update && \ apt-get install -y git \ curl RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - &&\ apt-get install -y nodejs RUN pip install -U pip \ jupyterlab && \ pip install jupyterlab-git RUN jupyter lab build docker-compose.yml version: "3" services: jupyter: build: . volumes: - $PWD:/tmp/work working_dir: /tmp/work ports: - 8888:8888 command: jupyter lab --ip=0.0.0.0 --allow-root --no-browser Docker イメージのビルド 上記２ファイルを作成後、同ディレクトリにてビルドします。 $ docker-compose build コンテナを起動 ビルド後コンテナを起動します。 $ docker-compose up 起動後は http://localhost:8888/ にアクセスし、token を入力して JupyterLab にアクセスできます。 token とは起動後に出力される、例：http://acb729d0c5ce:8888/?token=45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d の 45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d にあたる箇所です。 Extension Manager を Enable 起動後は Exxtension Manager を Enable します。 ２つのエクステンションがインストールされています。 Notebook を Git でバージョン管理をする Git リポジトリ を Clone 必要なリポジトリをクローンします。すでに Notebook などがある場合は git init などをします。 リポジトリの URL を入力 Notebook (test.ipynb) を作成して first commit します。 $ git config --global user.email "you@example.com" $ git config --global user.name "Your Name" $ git add test.ipynb $ git commit -m "first commit" first commit 後、 Notebook で分析を進めたとします。例えば df.head() というコードを追加したとします。 git diff での差分表示 まず、git diff コマンドで確認した場合は、下記のように Notebook のメタデータなどの差分が表示されてしまいとてもわかりづらいです。 # git diff diff --git a/test.ipynb b/test.ipynb index f6c1f17..5af6074 100644 --- a/test.ipynb +++ b/test.ipynb @@ -2,7 +2,7 @@ "cells": [ { "cell_type": "code", - "execution_count": 1, + "execution_count": 6, "metadata": {}, "outputs": [], "source": [ @@ -21,7 +21,7 @@ }, { "cell_type": "code", - "execution_count": 4, + "execution_count": 7, "metadata": {}, "outputs": [], "source": [ @@ -30,12 +30,164 @@ }, { "cell_type": "code", - "execution_count": 5, + "execution_count": 8, "metadata": {}, "outputs": [], "source": [ "df = pd.read_csv(data_dir + \"train.csv\")" ] + }, + { + "cell_type": "code", : JupyterLab nbdime での差分表示 JupyterLab にて nbdime を利用して diff を確認した場合は下記になります。ピンクの左側は変更前、緑の右側は変更後になります。 とても見やすく差分が表示されていると思います。 参考 Jupyter Notebook Manifesto: Best practices that can improve the life of any developer using Jupyter notebooks
Jupyter Notebook で分析を進める際、バージョン管理をしたいと思いGitで管理をしてみましたが、普通に進めるとNotebook のメタデータによって差分がとても見づらかったので、JupyterLab の jupyterlab-gitと nbdimeエクステンションを利用し、差分を見やすく表示できるようにしてみました。
jupyterlab-git
nbdime
今回の記事では、下記の環境を利用します。
Jupyter notebook のバージョンコントロールに必要な JupyterLab エクステンションは下記になります。
下記２ファイルを作成します。
FROM gcr.io/kaggle-images/python:v74 RUN apt-get update && \ apt-get install -y git \ curl RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - &&\ apt-get install -y nodejs RUN pip install -U pip \ jupyterlab && \ pip install jupyterlab-git RUN jupyter lab build
version: "3" services: jupyter: build: . volumes: - $PWD:/tmp/work working_dir: /tmp/work ports: - 8888:8888 command: jupyter lab --ip=0.0.0.0 --allow-root --no-browser
上記２ファイルを作成後、同ディレクトリにてビルドします。
$ docker-compose build
ビルド後コンテナを起動します。
$ docker-compose up
起動後は http://localhost:8888/ にアクセスし、token を入力して JupyterLab にアクセスできます。 token とは起動後に出力される、例：http://acb729d0c5ce:8888/?token=45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d の 45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d にあたる箇所です。
http://acb729d0c5ce:8888/?token=45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d
45d10c660d2e85f0c8d59995a04667c154542ae79f27f65d
起動後は Exxtension Manager を Enable します。
２つのエクステンションがインストールされています。
必要なリポジトリをクローンします。すでに Notebook などがある場合は git init などをします。
リポジトリの URL を入力
Notebook (test.ipynb) を作成して first commit します。
test.ipynb
$ git config --global user.email "you@example.com" $ git config --global user.name "Your Name" $ git add test.ipynb $ git commit -m "first commit"
first commit 後、 Notebook で分析を進めたとします。例えば df.head() というコードを追加したとします。
まず、git diff コマンドで確認した場合は、下記のように Notebook のメタデータなどの差分が表示されてしまいとてもわかりづらいです。
git diff
# git diff diff --git a/test.ipynb b/test.ipynb index f6c1f17..5af6074 100644 --- a/test.ipynb +++ b/test.ipynb @@ -2,7 +2,7 @@ "cells": [ { "cell_type": "code", - "execution_count": 1, + "execution_count": 6, "metadata": {}, "outputs": [], "source": [ @@ -21,7 +21,7 @@ }, { "cell_type": "code", - "execution_count": 4, + "execution_count": 7, "metadata": {}, "outputs": [], "source": [ @@ -30,12 +30,164 @@ }, { "cell_type": "code", - "execution_count": 5, + "execution_count": 8, "metadata": {}, "outputs": [], "source": [ "df = pd.read_csv(data_dir + \"train.csv\")" ] + }, + { + "cell_type": "code", :
JupyterLab にて nbdime を利用して diff を確認した場合は下記になります。ピンクの左側は変更前、緑の右側は変更後になります。
とても見やすく差分が表示されていると思います。
問題 Gitのブランチはリモートリポジトリでマージされても自動的に削除されないので自分で削除する必要があります。 環境 $ git --version git version 2.26.2 予備知識 マージ済みのブランチを表示 $ git branch --merged 補足: マージしてないブランチを表示 $ git branch --no-merged 補足: リモートリポジトリも含めてすべてのブランチの一覧を表示 $ git branch --all $ git branch -a ブランチを削除する $ git branch -d feature/issue-xxx $ git branch -D feature/issue-xxx -d オプションはマージされていないブランチは削除されません。 -D オプションはマージされていないブランチも強制的に削除します。 リモートリポジトリで削除されているブランチを削除する git featch する際に prune オプションを付けると削除済みのブランチを削除してくれます。 $ git fetch --prune $ git fetch -p 補足: 常にpruneオプションを有効にする $ git config --global fetch.prune true 本題 git fetch --prune でリモートリポジトリで削除済みのブランチを削除したあと git branch --merged で出てきたブランチを削除すれば良いわけです。 注意点としては、 master や development といった特定のブランチは削除対象外にしたいところです。 git alias を使っても大丈夫なのですが、 .gitconfig ファイルを管理するのが少し面倒だなと感じたのでシェルスクリプトを書きたいと思います。 zsh でも bash でも動作しますが、 zsh の例で進めます。 ~/.zshrc に以下のコードを追加します。 ~/.zshrc PROTECT_BRANCHES='master|development' git-delete-merged-branch() { git fetch --prune git branch --merged | egrep -v "\*|${PROTECT_BRANCHES}" | xargs git branch -d } 保護したいブランチは PROTECT_BRANCHES の環境変数に | 区切りで追加してください。 シェルの設定ファイルを読み直します。 $ exec $SHELL -l コマンドを実行します。(Gitが管理しているディレクトリ内で実行してください) $ git-delete-merged-branch 試しに実行するとこんな感じです。 補足: .gitconfig のエイリアスでやる場合 ~/.gitconfig の alias 設定でやりたい場合は下記のようにします。 [alias] delete-merged-branch = !git branch --merged | egrep -v '\\*|master|development' | xargs git branch -d $ git delete-merged-branch Git関連の記事まとめ Git関連の記事一覧
Gitのブランチはリモートリポジトリでマージされても自動的に削除されないので自分で削除する必要があります。
$ git --version git version 2.26.2
$ git branch --merged
$ git branch --no-merged
$ git branch --all $ git branch -a
$ git branch -d feature/issue-xxx $ git branch -D feature/issue-xxx
-d オプションはマージされていないブランチは削除されません。 -D オプションはマージされていないブランチも強制的に削除します。
-d
-D
git featch する際に prune オプションを付けると削除済みのブランチを削除してくれます。
git featch
prune
$ git fetch --prune $ git fetch -p
$ git config --global fetch.prune true
git fetch --prune でリモートリポジトリで削除済みのブランチを削除したあと git branch --merged で出てきたブランチを削除すれば良いわけです。
git fetch --prune
git branch --merged
注意点としては、 master や development といった特定のブランチは削除対象外にしたいところです。 git alias を使っても大丈夫なのですが、 .gitconfig ファイルを管理するのが少し面倒だなと感じたのでシェルスクリプトを書きたいと思います。
master
development
git alias
.gitconfig
zsh でも bash でも動作しますが、 zsh の例で進めます。
zsh
bash
~/.zshrc に以下のコードを追加します。
~/.zshrc
PROTECT_BRANCHES='master|development' git-delete-merged-branch() { git fetch --prune git branch --merged | egrep -v "\*|${PROTECT_BRANCHES}" | xargs git branch -d }
保護したいブランチは PROTECT_BRANCHES の環境変数に | 区切りで追加してください。 シェルの設定ファイルを読み直します。
PROTECT_BRANCHES
|
$ exec $SHELL -l
コマンドを実行します。(Gitが管理しているディレクトリ内で実行してください)
$ git-delete-merged-branch
試しに実行するとこんな感じです。
~/.gitconfig の alias 設定でやりたい場合は下記のようにします。
~/.gitconfig
[alias] delete-merged-branch = !git branch --merged | egrep -v '\\*|master|development' | xargs git branch -d
$ git delete-merged-branch
移行後 prのリポジトリに直接ブラウザで開けるようになった after hub browse 移行前 prのmasterリポジトリをブラウザで開いていた before gh-open $(pwd) 結果 一覧からprを探す必要がなくなった 備考 これも便利だが、prナンバーがわからないとブラウザを開けない hub browse -- pull/PR_NUMBER 一応下記で番号がわかるが、やや手数が増える。。 gh pr list gh コマンドの記事 https://qiita.com/kajirikajiri/items/c18726e3831b27ba943f ghコマンド公式 https://github.com/cli/cli hubコマンド公式 https://github.com/github/hub
prのリポジトリに直接ブラウザで開けるようになった
hub browse
prのmasterリポジトリをブラウザで開いていた
gh-open $(pwd)
一覧からprを探す必要がなくなった
これも便利だが、prナンバーがわからないとブラウザを開けない
hub browse -- pull/PR_NUMBER
一応下記で番号がわかるが、やや手数が増える。。
gh pr list
gh コマンドの記事 https://qiita.com/kajirikajiri/items/c18726e3831b27ba943f
ghコマンド公式 https://github.com/cli/cli
hubコマンド公式 https://github.com/github/hub
$ start . https://stackoverflow.com/questions/35811533/git-bash-bash-open-command-not-found
$ start .
https://stackoverflow.com/questions/35811533/git-bash-bash-open-command-not-found
ターミナルにブランチ名を表示 いいかげんgit branchって打ちたくないのでターミナルでブランチ確認できるように設定追加するようにしました。 $ sudo vim ~/.bash_profile # Git branch in prompt. parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' } export PS1="\W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ " 最後に$ source ~/.bash_profileで更新すれば良い。 参考URL https://gist.github.com/joseluisq/1e96c54fa4e1e5647940 余談 ちなみにユーザ名とホスト名も表示したかったら以下のように書けば良い。 \uはユーザ名で\hはホスト名らしいです。長いので自分は表示しない。 export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "
いいかげんgit branchって打ちたくないのでターミナルでブランチ確認できるように設定追加するようにしました。
$ sudo vim ~/.bash_profile
# Git branch in prompt. parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/' } export PS1="\W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "
最後に$ source ~/.bash_profileで更新すれば良い。
$ source ~/.bash_profile
https://gist.github.com/joseluisq/1e96c54fa4e1e5647940
ちなみにユーザ名とホスト名も表示したかったら以下のように書けば良い。 \uはユーザ名で\hはホスト名らしいです。長いので自分は表示しない。
export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "
記事にした経緯 以前、とあるIT企業で開発のアルバイトをしていました。 当時はgitやgithubの基本的な操作は知っていたのですが、 「結局、業務の中でどんな風に使えばいいの？」となっていました。 そこで、「gitやgithubの業務（開発）フローの記事があったら、役に立つ人いるんじゃね？?」思い、記事を執筆しました。 対象 gitの基礎はわかる人 gitを使った開発フロー 自分の作業場所を最新状態にする ブランチ名を作成,作成したブランチに移動する ソースコードの修正、追加などを行う 修正、追加したソースコードをステージングに追加する ステージングに追加したファイルをローカルリポジトリに追加する Githubのリモートブランチを更新する GithubでPR（pull request）作成する レビューをもらう 3へ 全て修正すれば、マージしてもらう(する) マージし終わったら、作成したブランチを削除する 1. 自分の作業場所を最新状態にする まずは、自分自身の作業場所を最新状態にします。 最新状態する方法は主に以下の三つです。 $ git pull or $ git fetch & git rebase origin リモートブランチ名 or $ git fetch & git merge origin リモートブランチ名 個人的には二番目のgit fetch & git rebase origin リモートブランチ名を使っています。 2. ブランチ名を作成,作成したブランチに移動する 自分の作業をするためにブランチを作成し（切って）、作成したブランチに移動します。 ブランチの作り方は主に二通りあります。 $ git branch ブランチ名 & git checkout ブランチ名 or $ git branch -b ブランチ名 -b: ブランチを作成し、チェックアウトする 会社によってブランチ名の命名規則にはルールがあると思いますが、 基本的にはgitflowにしたがった命名規則でブランチ名をつけていました。 参照 https://nvie.com/posts/a-successful-git-branching-model/ 3. ソースコードの修正、追加などを行う 機能追加や修正するためにソースコードを追加、修正を行います。 4. 修正、追加したソースコードをステージングに追加する 3.で修正や追加したソースコードをgithubに反映させるために、まずはステージングにあげてやる必要があります。 コードをステージングに追加するためにはaddコマンドを使用します。 $ git add 修正したソースコード1, 修正したソースコード2, ・・・ 自分自身はgitコマンドを打つことは少なく、tigを使ってやっていました。 5. ステージングに追加したファイルをローカルリポジトリに追加する 次にステージングにあげたソースコードをローカルリポジトリに追加します。 コマンドは以下の通りです。 $ git commit -m "コミットメッセージ" コミットメッセージは何をしたのかがわかるようにしっかりと書きましょう。 commitについてもaddコマンドと同様にtigを使用していました。 コミットメッセージを間違えた場合など コミットメッセージを間違えたり、ソースコードをローカルリポジトリに上げ忘れたりする時があると思います。 そういったときは以下のコマンドでコミットを取り消すことができます。 git commit --amend 6. Githubのリモートブランチに更新する 修正したソースコードをローカルリポジトリに上げ終わったら、次はgithubのリモートリポジトリにその内容を反映してやる必要があります。 その場合はpushコマンドを使用します。 $ git push origin ブランチ名 7. GithubでPR（Pull Request）作成する pushし終わったら、修正したソースコードをレビュアーの方々に見てもらうためにプルリクエストを作成します。 プルリクエストの作成方法は以下を参考にしてください。 プルリクエストの作成方法 8. レビューをもらう プルリクエストを出すと、レビュアの人が自分が修正したコードに対して、コメントや修正依頼が入ります。 9. 3へ 修正依頼をもらった場合は、またソースコードの修正を行います。 10. 全て修正すれば、マージしてもらう(する) 修正依頼が全て終われば、レビュアーの方が出したプルリクエストを承認(approve)してくれます。 レビュアー全員の承認が降りれば、そのプルリクエストがdevelopブランチにマージされます。 （レビュアーの方か自分自身でマージを行います。） developブランチ - 次のリリースのための最新の開発作業の変更が反映されているブランチ 11. マージし終わったら、作成したブランチを削除する マージされたら、作業していたブランチを削除して、作業は終了です。 他のブランチ(developブランチなど)に移動して、以下のコマンドで作成したブランチを削除します。 $ git branch -d ブランチ名 まとめ gitの開発の流れ 自分の作業場所を最新状態にする ブランチ名を作成,作成したブランチに移動する ソースコードの修正、追加などを行う 修正、追加したソースコードをステージングに追加する ステージングに追加したファイルをローカルリポジトリに追加する Githubのリモートブランチを更新する GithubでPR（pull request）作成する レビューをもらう 3へ 全て修正すれば、マージしてもらう(する) マージし終わったら、作成したブランチを削除する さいごに 今回は、git,githubの開発の流れについて書きました。 何かわからないことなどありましたらコメントよろしくお願いいたします。
以前、とあるIT企業で開発のアルバイトをしていました。 当時はgitやgithubの基本的な操作は知っていたのですが、 「結局、業務の中でどんな風に使えばいいの？」となっていました。 そこで、「gitやgithubの業務（開発）フローの記事があったら、役に立つ人いるんじゃね？?」思い、記事を執筆しました。
まずは、自分自身の作業場所を最新状態にします。
最新状態する方法は主に以下の三つです。
$ git pull
or
$ git fetch & git rebase origin リモートブランチ名
$ git fetch & git merge origin リモートブランチ名
個人的には二番目のgit fetch & git rebase origin リモートブランチ名を使っています。
git fetch & git rebase origin リモートブランチ名
自分の作業をするためにブランチを作成し（切って）、作成したブランチに移動します。 ブランチの作り方は主に二通りあります。
$ git branch ブランチ名 & git checkout ブランチ名
$ git branch -b ブランチ名
-b
参照 https://nvie.com/posts/a-successful-git-branching-model/
機能追加や修正するためにソースコードを追加、修正を行います。
3.で修正や追加したソースコードをgithubに反映させるために、まずはステージングにあげてやる必要があります。 コードをステージングに追加するためにはaddコマンドを使用します。
$ git add 修正したソースコード1, 修正したソースコード2, ・・・
自分自身はgitコマンドを打つことは少なく、tigを使ってやっていました。
次にステージングにあげたソースコードをローカルリポジトリに追加します。 コマンドは以下の通りです。
$ git commit -m "コミットメッセージ"
コミットメッセージは何をしたのかがわかるようにしっかりと書きましょう。 commitについてもaddコマンドと同様にtigを使用していました。
コミットメッセージを間違えたり、ソースコードをローカルリポジトリに上げ忘れたりする時があると思います。 そういったときは以下のコマンドでコミットを取り消すことができます。
git commit --amend
修正したソースコードをローカルリポジトリに上げ終わったら、次はgithubのリモートリポジトリにその内容を反映してやる必要があります。 その場合はpushコマンドを使用します。
$ git push origin ブランチ名
pushし終わったら、修正したソースコードをレビュアーの方々に見てもらうためにプルリクエストを作成します。 プルリクエストの作成方法は以下を参考にしてください。 プルリクエストの作成方法
プルリクエストを出すと、レビュアの人が自分が修正したコードに対して、コメントや修正依頼が入ります。
修正依頼をもらった場合は、またソースコードの修正を行います。
修正依頼が全て終われば、レビュアーの方が出したプルリクエストを承認(approve)してくれます。 レビュアー全員の承認が降りれば、そのプルリクエストがdevelopブランチにマージされます。 （レビュアーの方か自分自身でマージを行います。）
developブランチ - 次のリリースのための最新の開発作業の変更が反映されているブランチ
マージされたら、作業していたブランチを削除して、作業は終了です。 他のブランチ(developブランチなど)に移動して、以下のコマンドで作成したブランチを削除します。
$ git branch -d ブランチ名
gitの開発の流れ
今回は、git,githubの開発の流れについて書きました。 何かわからないことなどありましたらコメントよろしくお願いいたします。
はじめに この記事では、初学者の私が学んでいることをメモとして残します。 Git(version 2.24.1)を使用しています。 Gitコマンド gitを使用する上で一番最初にしなければならないのが、 リポジトリの作成です。(.gitが作られる) Gitリポジトリの管理ファイル等がここに作成されます。 リポジトリの新規作成 git init ワークツリーからステージへ変更を追加。 変更をステージに追加 git add 'ファイル名' git add 'ディレクトリ名' git add . ステージからリポジトリに記録 コメントは変更点が分かるようにする。 git commit -m の場合、変更内容と要点をまとめる。 変更を記録 git commit git commit -m 'コメント' git rm はリポジトリとワークツリーから削除される git rm --cachedはリポジトリのみ削除 ファイルの削除を記録 git rm 'ファイル名' git rm -r 'ディレクトリ名' git rm --cached 'ファイル名' リモートリポジトリのURLをoriginに登録する リモートリポジトリを追加 git remote add origin https://github.com/~ ローカルリポジトリの内容をリモートリポジトリに送信 リモートリポジトリを追加 git push 'リモート名' 'ブランチ名'
この記事では、初学者の私が学んでいることをメモとして残します。 Git(version 2.24.1)を使用しています。
gitを使用する上で一番最初にしなければならないのが、 リポジトリの作成です。(.gitが作られる) Gitリポジトリの管理ファイル等がここに作成されます。
git init
ワークツリーからステージへ変更を追加。
git add 'ファイル名' git add 'ディレクトリ名' git add .
ステージからリポジトリに記録 コメントは変更点が分かるようにする。 git commit -m の場合、変更内容と要点をまとめる。
git commit git commit -m 'コメント'
git rm はリポジトリとワークツリーから削除される git rm --cachedはリポジトリのみ削除
git rm 'ファイル名' git rm -r 'ディレクトリ名' git rm --cached 'ファイル名'
リモートリポジトリのURLをoriginに登録する
git remote add origin https://github.com/~
ローカルリポジトリの内容をリモートリポジトリに送信
git push 'リモート名' 'ブランチ名'
