"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

GitHub&Git for windowsのGitコマンドで作業を一通りする/自己流チュートリアル(3)

Gitをプライベートでも真面目に使う目的で整理する第三回目です。

今回は、GitHubリポジトリを元に、Git for windowsで状態を確認したり、ブランチを作ったり、コミット・マージなどの一連の作業をやってみます。

f:id:arakan_no_boku:20190811144704p:plain

GitHubとGitの使い方を3回にわけて整理します。

 

GitHubとGitをもう少し真面目につかうべく、以下の3回にわけて整理しています。

  1. インストールと環境設定
  2. A successful Git branching modelの理解
  3. Gitコマンドを使って一連の作業を実践する

リモートリポジトリは、GitHub、クライアント側は「Git for windows」です。

今回は、その3回目です。

実際にGitコマンドを使って、ブランチの作成・コミット・マージ・リモート(GitHub)へのプッシュなど、一連の作業をやってみます。

さて。

第一回目で環境設定したところから続きですが、GitHubリポジトリを作成して、そのページの「clone or download」で、URLを確認したところからやります。

f:id:arakan_no_boku:20190811160024p:plain

 

GitBash(Git for windows)でローカルPCにクローンして状態を確認

 

ローカルPC上にリポジトリを作成する方法は2通り。

今回は当然ながら、GitHubからcloneします。

GitBashで以下のコマンドを入力します。

URLの部分はGitHubリポジトリによって違うので適宜変更してください。

説明の都合上、リポジトリ名は「bokurepo」にします。

git clone https://github.com/xxxxx/bokurepo.git

f:id:arakan_no_boku:20190811171037p:plain

クローンできると、カレントフォルダ上に「bokurepo」というリポジトリ名のフォルダができるので、bokurepoフォルダをカレントにします。

cd bokurepo

さて。

まずは、クローンした環境の状態を確認します。

git status 

 f:id:arakan_no_boku:20190815122319p:plain

masterブランチにいて、元になってる「origin/master」は最新で、コミットもないよ・・てな感じです。

ついでに、ブランチの状態です。

git branch 

f:id:arakan_no_boku:20190815122624p:plain

当然ながら、masterブランチしかありません。

複数あったら、一覧されて、今カレントになっているものに「*」がつきます。

ついでにリモート(GitHub上)の情報もみときます。

git branch -r 

f:id:arakan_no_boku:20190815123845p:plain

ここで「HEAD」がでてきます。

HEADは、自分が今作業している場所を示すポインタなので、上記だと、今は「origin/master」で作業している・・ということがわかります。

かつ、GitHub上にも今は「origin/master」しかないことが確認できました。

 

origin/developブランチを作成する

 

前回に「A successful Git branching model」を参考にまとめた方針にそって、自分は、ブランチモデルをこうしたいわけです。

f:id:arakan_no_boku:20190815130254p:plain

なので、originに「develop」ブランチが必要なのですが、GitHubリポジトリを作っただけの状態では「origin」リポジトリには「master」しかありません。

なので、作っておく必要があります。

リモートに「develop」ブランチを作ります。

まず、以下のコマンドを実行します。

-b というオプションがポイントです。 

git checkout -b develop

f:id:arakan_no_boku:20190815141131p:plain

新しいブランチに切り替えたら、リモート「origin」に作成します。

git push origin develop

実行するとGitHubにログインするユーザIDとパスワードの入力を求められます。

うまくいけば、以下のようなメッセージが表示されます。

f:id:arakan_no_boku:20190815140849p:plain

確認してみます。

f:id:arakan_no_boku:20190815141515p:plain

おーー、できてます。

 

コミットでエラーにならないように設定する

 

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」ブランチを作って、開発後にコミット・マージするところをやってみます。

f:id:arakan_no_boku:20190815165152p:plain

なお、feature,hotfix,releaseのようにローカルに作る作業用のブランチは、名前の重複で困らないよう「-boku20190815」みたいにサブ名称を追加してブランチを作ります。

まず、「origin/develop」から「feature-boku20190815」ブランチを作ります。

git branch feature-boku20190815 origin/develop

f:id:arakan_no_boku:20190815145227p:plain

feature-boku20190815」ブランチをカレントにします。

git checkout feature-boku20190815  

f:id:arakan_no_boku:20190815145855p:plain

この時点で「git branch」すると、こうなってます。

f:id:arakan_no_boku:20190815150748p:plain

よしよし。 

今回は、フォルダに6個ほどのPythonプログラムをコピーしました。

ファイルやディレクトの追加を、Gitに反映するのは、addです。

まず、1ファイル「logsample.py」をaddします。

git add logsample.py

その状態を確認するのは「git status」です。

やってみると。 

f:id:arakan_no_boku:20190815153637p:plain

てな感じで、あと5ファイル、addされてないよ・・となってます。

ひとつひとつは面倒なので、ここはまとめてやります。

git add -A

f:id:arakan_no_boku:20190815153834p:plain

addされました。

ちなみに、ファイルの削除は。

git rm [削除したいファイル]

フォルダの削除は。

git rm -r [削除したいディレクトリ]

ファイルの名称変更(リネーム)は。

git mv [変更前ファイル名] [変更後ファイル名]

というようにします。

git statusではこんな感じに表示されます。

f:id:arakan_no_boku:20190822221144p:plain

ここまでしたら、あとは「commit」です。

git commit -m "first commit from feature-boku20190815"

 -mの後ろはコミットメッセージです。

何の変更をしたコミットなのかを、ちゃんと書いといた方がいいですが、今回は最初なのでこんな感じ。

f:id:arakan_no_boku:20190815160241p:plain

よしよし。

 

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 "

f:id:arakan_no_boku:20190815162837p:plain

なお、マージするときに、 -m "first commit "のようにメッセージをオプションでつけないと、エディタが立ち上がってきます。

そちらで入力したほうが楽な人は、-m以降のメッセージをはぶいて実行してもいいです。

マージできたら、「origin/develop」にプッシュします。

git push origin develop

f:id:arakan_no_boku:20190815163616p:plain

ここまでできたら、作業用の「feature-boku20190815ブランチ」は消しておきます。

git branch -d feature-boku20190815

f:id:arakan_no_boku:20190815164109p:plain

別においておいても良いのですが・・。

まあ、邪魔になるし、間違いがおきやすくなるので、消した方がベターだと思います。

ちなみに。

こういう機能ブランチをマージしないで、消そうとしても消せません。

こんなエラーメッセージがでます。

error: The branch 'feature-20190815' is not fully merged.

でも、しくじったからマージしないで消したい時もあります。

そんな時は。

git branch -D feature-boku20190815

のように「-D」を大文字にすると消せます。

消せたかどうかは、一応、GitHubにログインして確認しておきます。

f:id:arakan_no_boku:20190815164407p:plain

branchesタグをみると、developブランチのみにファイルが更新されているのがよくわかります。

 

releaseブランチで更新し、masterとdevelopにマージする

 

今度はリリースをやってみます。

f:id:arakan_no_boku:20190815170158p:plain

流れはだいたい。

  • releaseブランチをdevelopから作ってカレントにする
  • releaseブランチで作業してcommitする
  • マージ先がmasterとdevelopであること
  • masterにリリースする時はtagもつけておくこと

こんな感じです。

releaseブランチの名前には「バージョン番号」をつけます。

今回は初回なので「0.1.0」とでもしておきます。

git checkout -b release-0.1.0 develop

f:id:arakan_no_boku:20190815171028p:plain

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も更新できてます。

f:id:arakan_no_boku:20190815175357p:plain

Tagをpushすると、GitHubの「release」タグで一覧できます。

f:id:arakan_no_boku:20190815185650p:plain


上記のタグ名(例だと0.1.0)をクリックすると、そのバージョンのソースがダウンロードできるので、超便利です。

さて。

もう必要ないので、ローカル側のrelease-0.1.0ブランチは消しておきます。

git branch -d release-0.1.0

 よしよし。

なくなってますね。

f:id:arakan_no_boku:20190815183202p:plain

 

 最後にhotfixブランチのケースをやってみます

 

本番稼働後(masuterにマージ後)に緊急で修正が必要なケースです。

f:id:arakan_no_boku:20190815182932p:plain

ブランチの名前が「hotfix-?」になるのと、ブランチの元が「origin/master」である以外は、リリースのケースと同じです。

hotfixの名前も「hotfix-0.1.1」みたいに、リリースした時のバージョン(マイナーバージョンアップ)とかにすることが多いみたいです。

git checkout -b hotfix-0.1.0 master

 後は、上記のリリースの時と同じなので、あえて繰り返してコマンドは書きません。

 

コミットした履歴とかをログでみる

 

ケースごとにGitコマンドでやってみました。

 

コミットした履歴は

git log

でみることができます。

ただ、これだと量が多くなると見づらいです。

なので。

git tag

f:id:arakan_no_boku:20190815185952p:plain

これでタグ名を調べて、それを指定してピンポイントで探します。

git show 0.1.0

これでtag0.1.0をつけたログだけが確認できます。 

よしよし。

とりあえず、一通りのことはできるので、まず、これで運用してみます。

 

個人でやるときは簡易版がいいかな

 

やってみて思ったことがひとつ。

当たり前ですが、A successful Git branching modelでうまく回るには、以下の前提が必要な気がしまう。

  • 複数の開発者でひとつのリポジトリを使うチーム開発である
  • 開発者全員のスキル・モラルがある程度高い

スキルレベルが不足していたり・うっかりミスの多い人がチームにいて、彼・彼女が間違ったブランチにコミットしてしまうようなミスを、仕組的に防ぐのは困難ですしね。

かつ。

仕事ならともかく、自分がプライベートで色々と勉強を兼ねてコードを書いたりする分には運用が面倒です。

自分の場合。

ブログに掲載した時点のソースは保持しておかないといけないので、そこはtagを売っておきたいわけです。

でも、ひとりなのでdevelopとmasterに分けておく必要性は感じない。

結局、masterからfeatureブランチをきって開発終わったらマージ・・ってな簡易運用にすののが多いだろうな・・などと思ってます。

とはいえ、これで一通りのことはできるようになりました。

今回はこんなところで。

ではでは。