にて、リモートリポジトリとの結びつきを壊さず、かつ、リモートリポジトリを簡潔に保てるような開発手法の必要性を痛切に感じました><。
そこでその投稿でも紹介しました
を参考に、GitHub Flow で開発をしてみてうまくいきましたので、その時に使ったコマンドや流れをノートいたします♪
こちらのページでは、図解に加え、実際に使用するコマンドも例示されており、GitHub Flow を始めてみるのに大変助けとなったページですの♪
なお、参考ページと異なる点として、新規のリポジトリではなくて、既存のリポジトリに GitHub Flow を導入しております。
GitHub Flow 要点
GitHub Flowとは何だろうか?
- masterブランチのものは何であれデプロイ可能である
- 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する(例: new-oauth2-scopes)
- 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
- フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する
- 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
- マージをしてmasterへpushしたら、直ちにデプロイをする
これがフローのすべてだ。
GitHub Flow で使用した覚えておきたいコマンドと解説
<branchname> など変数的な使い方ではなく、master としているのは、GitHub Flow では master ブランチが特別に重要でいつでもデプロイ可能なブランチの位置づけであるためですの。
ですから、master と固定した名前で使用しております。
# 開発を始めるに当たっての準備 # pull してリモートリポジトリの状態にローカルを合わせ、開発可能にする。 git pull <remoterepository> master # ローカルでの開発用ブランチを作成 git checkout -b <developbranch> # 開発中の記録・区切り・バックアップを作る作業 # ローカルでのコミット git add . git commit -m "コミットタイトルメッセージ" # push してリモートにバックアップ&メンバーへ進捗を共有 git push <remoterepository> <developbranch> # リリース (GitHub や GitLab を使用しておらず、ローカルからコマンドで行う場合) git checkout master # マージ時に --no-ff オプションで明示的に新規コミットを生成する。 git merge --no-ff <developbranch> git push <remoterepository> master # 後片付けをして開発を終了するときの作業 # 開発用のローカルブランチを削除 (-D: マージされていないコミットがあるブランチを強制的に削除) git checkout master git branch -D <developbranch> # 開発用リモートブランチを削除 # 旧いコマンド git push master :<developbranch> # 新しいコマンド git push master --delete <developbranch>
GitHub Flow を実践するにあたって、予め決めておいたら楽そうなこと
- 開発用ブランチ命名時、すべて小文字とし、単語間は – でつなげることとする。
GitHub Flow で登場するブランチは、master と開発時に使用するブランチの 2 種類のみですの。
そして、開発時に使用するブランチは、何を行うブランチなのかわかるような名前を付ける、ということでした。
自由!ですけれども、名づけるときの型が毎回バラバラでは収まりが悪いですし、混乱のもとですの。
ですので、簡単に決め事をメモいたしました。
実践するにあたって
本当でしたら、初めはリモートリポジトリをクローンすると存じます。
ですがわたくしたちの場合、すでにローカルにもリモートにもリポジトリがございました。
今まで開発してきたプロジェクトの途中から GitHub Flow を取り入れますの。
実践 1. 開発を始めるまでの準備
ですのでクローンは行わず、まずは pull してローカルとリモートとのつながりを明確に作るところから始めました。
そして、開発用のローカルブランチを作成し、そこにチェックアウトいたします。
$ git pull origin master From http://111.11.1.1/gitremote/origin * branch master -> FETCH_HEAD Already up-to-date. $ git checkout -b add-new-function Switched to a new branch 'add-new-function'
実践 2. 開発中の記録・区切り・バックアップを作る commit、pull 作業
ローカルでのコミットはもちろん、リモートに push することで、バックアップを強固にするとともに他メンバーが fetch した時に自身の進捗を共有していただくことができますわね♪
ローカルへのコミットはなれたものですの。状態と差分を確認しながら慎重にコミットいたします。慣れた作業ですので、コマンドの結果は省略しております。
$ git status $ git difftool -d $ git status $ git commit -m "new-function開発中。" $ git log --all --decorate --graph --oneline
つづいて、リモートへ push いたします。
開発をはじめてリモートリポジトリへはじめて push する場合でも、リモートリポジトリに何もする必要はありません。リモートリポジトリのブランチは push すると自動的に作成されました♪
$ git push origin add-new-function Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1.32 MiB | 0 bytes/s, done. Total 11 (delta 5), reused 0 (delta 0) To http://111.11.1.1/gitremote/origin * [new branch] add-new-function -> add-new-function
さて、開発中の主要な Git コマンドは以上です。
ここからは、確認です。
リモートリポジトリ、HEAD を確認
リモートリポジトリを見てみますと、次のことが確認できました。
- 新しくリモートブランチが作成されたこと
- 新しいローカルブランチから push すると、新しいリモートブランチへ自動的に反映されること
$ git remote show origin * remote origin Fetch URL: http://111.11.1.1/gitremote/origin Push URL: http://111.11.1.1/gitremote/origin HEAD branch: master Remote branches: add-new-function tracked master tracked Local refs configured for 'git push': add-new-function pushes to add-new-function (up to date) master pushes to master (up to date)
続いて、ローカルコミットログを見ますと、HEAD の位置が
- ローカルは作業用ブランチに、
- リモートも作業用ブランチに、
あることが確認できました♪
$ git log --all --decorate --graph --oneline * 79f4b45 (HEAD -> add-new-function, origin/add-new-function) new-function開発中。 ... 略 ...
リリース
開発が完了し、レビューが済み、テストも終わりましたらリモートリポジトリの master ブランチへリリースいたします。
参考ページでは、GitHub ウェブサイトからリモートリポジトリの master ブランチへ merge しておりました。
しかし、わたくしたちは GitHub や GitLab を使用しておりません。
ですので、ローカルからコマンドで行うこととなります。
master にチェックアウトし、--no-ff
オプションで merge いたします。その後、リモートリポジトリへ push する、という手順となります。
$ git checkout master Switched to branch 'master' $ git merge --no-ff add-new-function Merge made by the 'recursive' strategy. ...SampleExcel.xlsm | Bin 1709255 -> 1711460 bytes .../AbcFactory.cls | 1 + .../AbcModel.cls | 12 ++++++++++++ .../AbcWriter.cls | 1 + .../DefModel.cls | 7 + .../TestAbcFactory.bas | 1 - .../TestAbcWriter.bas | 6 ++++-- 7 files changed, 25 insertions(+), 3 deletions(-) $ git push origin master Counting objects: 1, done. Writing objects: 100% (1/1), 345 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To http://111.11.1.1/gitremote/origin 9b5841e..3ef4ae7 master -> master
参考ページ
- ウェブページからではなく、コマンドでリモートリポジトリのブランチをマージする方法を確認できた。
--no-ff
オプションを付けて merge する理由を理解できた。- リモートリポジトリの master ブランチへマージするときは、リモートリポジトリのサーバにログインしてそこで作業をするわけではない。なぜなら、リモートリポジトリは作業ディレクトリを持たない bare リポジトリだから。ということが理解できた。
後片付けをして開発を終了するときの作業
開発用のローカルブランチを削除
git branch -D
とするところを誤って git branch -d
としてしまいました。
コミットログにブランチが残ってしまっても構わないと考えましたため、この誤りは反省材料ですけれども、このままといたしました。
特に問題もないようですし、今後もこちらでよいかもしれません。
$ git checkout master Already on 'master' $ git branch -d add-new-function Deleted branch add-new-function (was b9ca772)
HEAD にマージされていないコミットがある場合、ブランチを削除できません。 マージされていないコミットがあるブランチを強制的に削除するには、 -D オプションを付けて実行します。
ちなみに、誤りは次のページによると、戻せそうですの。→ やらかし12:うっかりブランチを削除したけど元に戻したい時
開発用のリモートブランチを削除
$ git push origin :add-new-function To http://111.11.1.1/gitremote/origin - [deleted] add-new-function
コミットログでのブランチの変化
ブランチ削除前
$ git log --all --decorate --graph --oneline * 3ef4ae7 (HEAD -> master, origin/master) new-function開発が完了したため、add-new-functionをmasterへマージする。 |\ | * b9ca772 (origin/add-new-function, add-new-function) new-function開発完了 | * 79f4b45 new-function開発中 |/ * 9b5841e old-function開発完了 ... 略 ...
ブランチ削除後
$ git log --all --decorate --graph --oneline * 3ef4ae7 (HEAD -> master, origin/master) new-function開発が完了したため、add-new-functionをmasterへマージする。 |\ | * b9ca772 new-function開発完了 | * 79f4b45 new-function開発中 |/ * 9b5841e old-function開発完了 ... 略 ...
おわりに
さらに参考になるページをメモいたします。コマンドの深い理解や、つまづきそうなポイントです。
- プッシュ時に、リモートブランチにつけるコロンについて
- 今後発生しそうな疑問に答えている。素晴らしい!
リモートリポジトリはあるものの、GitHub や GitLab などウェブブラウザから簡単にリモートリポジトリを操作する方法がありませんでした。
ですのでリモートリポジトリの master ブランチへの merge に苦労いたしました><。
そのときに調べたことも、Git をより知ることにつながりました。嬉しく存じます♪
以上です。