今回は、GitHubのリポジトリのクローンから、状態確認・ブランチ作成・コミット・マージなどの一連の作業をまとめます。
前提など
リモートリポジトリは、GitHub、クライアント側は「Git for windows」です。
実際にGitコマンドを使って、ブランチの作成・コミット・マージ・リモート(GitHub)へのプッシュなど、一連の作業をやってみます。
さて。
以下で環境設定したところから続きです。
GitHubにリポジトリを作成して、そのページの「clone or download」で、URLを確認したところからやります。
GitBash(Git for windows)でローカルPCにクローンして状態を確認
ローカルPC上にリポジトリを作成する方法は2通り。
今回は当然ながら、GitHubからcloneします。
GitBashで以下のコマンドを入力します。
URLの部分はGitHubのリポジトリによって違うので適宜変更してください。
説明の都合上、リポジトリ名は「bokurepo」にします。
git clone https://github.com/xxxxx/bokurepo.git
クローンできると、カレントフォルダ上に「bokurepo」というリポジトリ名のフォルダができるので、bokurepoフォルダをカレントにします。
cd bokurepo
さて。
まずは、クローンした環境の状態を確認します。
git status
masterブランチにいて、元になってる「origin/master」は最新で、コミットもないよ・・てな感じです。
ついでに、ブランチの状態です。
git branch
当然ながら、masterブランチしかありません。
複数あったら、一覧されて、今カレントになっているものに「*」がつきます。
ついでにリモート(GitHub上)の情報もみときます。
git branch -r
ここで「HEAD」がでてきます。
HEADは、自分が今作業している場所を示すポインタなので、上記だと、今は「origin/master」で作業している・・ということがわかります。
かつ、GitHub上にも今は「origin/master」しかないことが確認できました。
origin/developブランチを作成する
前回に「A successful Git branching model」を参考にまとめた方針にそって、自分は、ブランチモデルをこうしたいわけです。
なので、originに「develop」ブランチが必要なのですが、GitHubでリポジトリを作っただけの状態では「origin」リポジトリには「master」しかありません。
なので、作っておく必要があります。
リモートに「develop」ブランチを作ります。
まず、以下のコマンドを実行します。
-b というオプションがポイントです。
git checkout -b develop
新しいブランチに切り替えたら、リモート「origin」に作成します。
git push origin develop
実行するとGitHubにログインするユーザIDとパスワードの入力を求められます。
うまくいけば、以下のようなメッセージが表示されます。
確認してみます。
OKです。
コミットでエラーにならないように設定する
gitHubの場合だけなのかもしれませんが、GitHubで登録したemailアドレスと、ユーザ名を「--global」で設定をしておく必要があります。
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
これをしておかないと、git commitした時に「 Please tell me who you are、」と怒られます。
あと。
複数人で共有しているリポジトリの場合の注意を2つ。
ひとつは、1日の最初に以下のコマンドを必ず実行しておくことです。
git pull
git pullはリモートリポジトリの変更点をローカルリポジトリに取り込む機能です。
誰かが、リモートリポジトリに変更を加えていても、pullしないとローカルに反映しません。
ひとりの時はいらないですが、そうしてると仕事で必要になった時に「git pull」を忘れる悪い癖がつきますから、自分はひとりの時でもするようにしてます。
もうひとつは、「git branch -r 」で取得できる情報を最新にするために
get fetch
get branch -r
のように「get fetch」で情報を最新化してから確認するようにしたほうがいいです。
get pullを忘れた時ほどのダメージはないですが、とにかく、ひとりでやる癖がついていると、こういうことをわりあい忘れてはまります。
念のため。
あと。
コミットメッセージ入力忘れで、エディタが立ち上がってくることがあります。
デフォルトはVIMなので、他のエディタを使いたい場合は変更もできます。
以下は、さくらエディタの場合の例です。
git config --global core.editor "'C:/Program Files (x86)/sakura/sakura.exe' -CODE=4"
とはいえ、コマンドに「-m」オプションでメッセージを指定すればエディタが立ち上がることはないので、ほんと、念のためです。
featureブランチを作って作業してコミットする
さて。
今度は、開発者が「orign/develop」から「feature」ブランチを作って、開発後にコミット・マージするところをやってみます。
なお、feature,hotfix,releaseのようにローカルに作る作業用のブランチは、名前の重複で困らないよう「-boku20190815」みたいにサブ名称を追加してブランチを作ります。
まず、「origin/develop」から「feature-boku20190815」ブランチを作ります。
git branch feature-boku20190815 origin/develop
feature-boku20190815」ブランチをカレントにします。
git checkout feature-boku20190815
この時点で「git branch」すると、こうなってます。
よしよし。
今回は、フォルダに6個ほどのPythonプログラムをコピーしました。
ファイルやディレクトの追加を、Gitに反映するのは、addです。
まず、1ファイル「logsample.py」をaddします。
git add logsample.py
その状態を確認するのは「git status」です。
やってみると。
てな感じで、あと5ファイル、addされてないよ・・となってます。
ひとつひとつは面倒なので、ここはまとめてやります。
git add -A
addされました。
ちなみに、ファイルの削除は。
git rm [削除したいファイル]
フォルダの削除は。
git rm -r [削除したいディレクトリ]
ファイルの名称変更(リネーム)は。
git mv [変更前ファイル名] [変更後ファイル名]
というようにします。
git statusではこんな感じに表示されます。
ここまでしたら、あとは「commit」です。
git commit -m "first commit from feature-boku20190815"
-mの後ろはコミットメッセージです。
何の変更をしたコミットなのかを、ちゃんと書いといた方がいいですが、今回は最初なのでこんな感じ。
よしよし。
commitしたfeatureブランチをdevelopにマージして、GitHubにpush
feature-boku20190815ブランチで作業してcommitしたものを、「origin/develop」にマージしてやります。
まず、マージするブランチ(今回はdevelop)をカレントにします。
git checkout develop
feature-boku20190815ブランチをdevelopにマージします。
git merge --no-ff feature-boku20190815 -m "first commit "
なお、マージするときに、 -m "first commit "のようにメッセージをオプションでつけないと、エディタが立ち上がってきます。
そちらで入力したほうが楽な人は、-m以降のメッセージをはぶいて実行してもいいです。
マージできたら、「origin/develop」にプッシュします。
git push origin develop
ここまでできたら、作業用の「feature-boku20190815ブランチ」は消しておきます。
git branch -d feature-boku20190815
別においておいても良いのですが・・。
まあ、邪魔になるし、間違いがおきやすくなるので、消した方がベターだと思います。
ちなみに。
こういう機能ブランチをマージしないで、消そうとしても消せません。
こんなエラーメッセージがでます。
error: The branch 'feature-20190815' is not fully merged.
でも、しくじったからマージしないで消したい時もあります。
そんな時は。
git branch -D feature-boku20190815
のように「-D」を大文字にすると消せます。
消せたかどうかは、一応、GitHubにログインして確認しておきます。
branchesタグをみると、developブランチのみにファイルが更新されているのがよくわかります。
releaseブランチで更新し、masterとdevelopにマージする
今度はリリースをやってみます。
流れはだいたい。
- releaseブランチをdevelopから作ってカレントにする
- releaseブランチで作業してcommitする
- マージ先がmasterとdevelopであること
- masterにリリースする時はtagもつけておくこと
こんな感じです。
releaseブランチの名前には「バージョン番号」をつけます。
今回は初回なので「0.1.0」とでもしておきます。
git checkout -b release-0.1.0 develop
README.mdとかを更新して、このバージョンの説明するドキュメントなどを更新してコミットします。
あとはマージですね。
マージしたいブランチをカレントにしてマージして、プッシュを繰り返します。
まずは、masterにマージして、GitHubの「origin/master」にpushします。
あとで検索しやすくするため、Tagをつけておきます。
Tagもpushしないと、リモートには反映しません。
git checkout master
git merge --no-ff release-0.1.0 -m "release version 0.1.0"
git tag -a 0.1.0 -m "release version 0.1.0"
git push origin master
git push origin 0.1.0
git tag も、-mでメッセージを与えていないと、エディタが立ち上がってきます。
これでmasterができたので、続けてdevelopにもマージして、「origin/develop」にpushしておきます。
git checkout develop
git merge --no-ff release-0.1.0 -m "release version 0.1.0"
git push origin develop
WEBで確認すると、masterもdevelopも更新できてます。
Tagをpushすると、GitHubの「release」タグで一覧できます。
上記のタグ名(例だと0.1.0)をクリックすると、そのバージョンのソースがダウンロードできるので、超便利です。
さて。
もう必要ないので、ローカル側のrelease-0.1.0ブランチは消しておきます。
git branch -d release-0.1.0
よしよし。
なくなってますね。
最後にhotfixブランチのケースをやってみます
本番稼働後(masuterにマージ後)に緊急で修正が必要なケースです。
ブランチの名前が「hotfix-?」になるのと、ブランチの元が「origin/master」である以外は、リリースのケースと同じです。
hotfixの名前も「hotfix-0.1.1」みたいに、リリースした時のバージョン(マイナーバージョンアップ)とかにすることが多いみたいです。
git checkout -b hotfix-0.1.0 master
後は、上記のリリースの時と同じなので、あえて繰り返してコマンドは書きません。
コミットした履歴とかをログでみる
ケースごとにGitコマンドでやってみました。
コミットした履歴は
git log
でみることができます。
ただ、これだと量が多くなると見づらいです。
なので。
git tag
これでタグ名を調べて、それを指定してピンポイントで探します。
git show 0.1.0
これでtag0.1.0をつけたログだけが確認できます。
よしよし。
とりあえず、一通りのことはできるので、まず、これで運用してみます。
個人でやるときは簡易版がいいかな
やってみて思ったことがひとつ。
当たり前ですが、A successful Git branching modelでうまく回るには、以下の前提が必要な気がしまう。
- 複数の開発者でひとつのリポジトリを使うチーム開発である
- 開発者全員のスキル・モラルがある程度高い
スキルレベルが不足していたり・うっかりミスの多い人がチームにいて、彼・彼女が間違ったブランチにコミットしてしまうようなミスを、仕組的に防ぐのは困難ですしね。
かつ。
仕事ならともかく、自分がプライベートで色々と勉強を兼ねてコードを書いたりする分には運用が面倒です。
自分の場合。
ブログに掲載した時点のソースは保持しておかないといけないので、そこはtagを売っておきたいわけです。
でも、ひとりなのでdevelopとmasterに分けておく必要性は感じない。
結局、masterからfeatureブランチをきって開発終わったらマージ・・ってな簡易運用にすののが多いだろうな・・などと思ってます。
とはいえ、これで一通りのことはできるようになりました。
今回はこんなところで。
ではでは。