Git(26)EclipseのGit Flowの運用方法

ラベル: ,
Git Flowはとても便利ですが、手順を誤るとコンフリクトばかりで収集がつかなくなるので、手順を決めました。開発者は一人、開発PCは2台、PC間はGitHubを介してリポジトリを同期する運用環境です。

前の関連記事:Git(25)すでにEclipseのGit Flowで管理しているリポジトリの.gitignoreを変更する


常にfeatureブランチをチェックアウトしておく


以前間違えてmasterブランチにコミットしてしまって、戻せなくなったのでブランチの作業をしたら常にfeatureブランチをチェックアウトしておくことにしました。

featureブランチ名は、これから開発機能が何かはブランチを作成するときはわからないのと、ブランチの新旧を知りたいので、年月日時分の12桁の数値にしました。

ブランチを切り替える前にコミットをする



現在のリポジトリの状態はGit Repositoriesビューでみるとこのようになっています。

201703261136というfeatureブランチはリモートにもありますが、ローカルのブランチはすでに何回かコミットされていてリモートの同名のブランチとハッシュ値が異なっています。


リポジトリ名の右に表示されている[feature/201703261136↑2]というのはfeature/201703261136とうブランチがチェックアウトされていること、↑2はローカルリポジトリからリモートリポジトリにプッシュすべきコミットが2個あることを示しています。


まだコミットしていない変更箇所があるときはリポジトリ名の先頭に>がついています。


変更箇所をコミットしないままに他のブランチをチェックアウトしようとするとCheckout Conflictsのダイアログがでてきます。

「Commit」ボタンをクリックすると変更箇所を現在のブランチにコミットします。

「Stash」ボタンをクリックするとコミットするべき変更を一時的に避難させておくことができます。

StashについてはGit(20)Git入門の発展編をEclipse4.6でやる:その2でやりました。

まだコミットしたくないけど、他のブランチの内容を確認したいときなどに使っています。

「Reset」ボタンをクリックすると変更箇所が破棄されてしまいます。

「Cancel」ボタンをクリックするとチェックアウト自体がキャンセルされます。

Git Repositoriesのコンテクストメニュー


Git Repositoriesでリポジトリやブランチを右クリックしてでてくるコンテクストメニューは、実行できない項目もでてくるので注意しないといけません。

リポジトリ名を右クリックしてでてくるメニューの、操作対象は原則的にチェックアウトしているブランチに対してのみになります。


リポジトリ名を選択して右クリックしてでてくるメニューのうちよく使うのはCommit、Push to Upstream、Fetch from Upstream、Pullです。

Commitはチェックアウトしているブランチに対してのみ作用し、Commitするものがないときは最後のコミットをamendするかと聞いてきます。

Push to UpstreamもPullも同様にチェックアウトしているブランチのみに作用します。

それに対してFetch from Upstreamはすべてのブランチのリモートリポジトリを更新してくれます。

ただし、リモートリポジトリから消去されたブランチがあっても消去してくれません。


チェックアウトしているブランチを右クリックしたときのメニューでもCommitできますが、MergeするかとかRebaseするかとか聞かれますので、普段は先ほどのリポジトリ名のコンテクストメニューを使っています。

なので、このメニューで使うのはGit FlowのサブメニューとあとはShow In→Historyです。

チェックアウトしているブランチは削除できないので、Delete Branchの項目はチェックアウトしていないブランチのコンテクストメニューにしかでてきません。

ブランチをマージしたいときは、チェックアウトしていないブランチを選択して右クリック→Merge、とするといろいろ聞かれずにチェックアウトしているブランチにマージできます。

Git Flowを規則通り運用している限りはMergeを使わないで済みます。

featureブランチでの開発が一区切りついたときfeatureブランチをFinishする



featureブランチでの開発が一区切りついたときは、featureブランチを右クリック→Git Flow→Finish Feature、とします。


SquashにもKeep branchにもチェックを付けずにOKします。


feature/201703261136ブランチが消えて、developブランチにマージされました。


Historyビューを見ると新たにマージコミットが作成されてそこにdevelopブランチが移動したことがわかります。

リモートリポジトリもローカルリポジトリと同じにするためにリモートリポジトリのfeature/201703261136ブランチを選択して右クリック→Delete Branchで削除します。

さらにGitHubのfeature/201703261136ブランチも削除しないといけません。

この二つの削除作業が面倒なところです。


GitHubで3branchesをクリックします。


ブランチ一覧がでてくるので、feature/201703261136ブランチの右端にあるごみ箱ボタンをクリックしてGitHubからもこのブランチを削除します。

masterブランチにまだマージしないときは、Git Repositoriesビューでdevelopブランチを右クリック→Git Flow→Start Feature、として新たに年月日時分を名前としたfeatureブランチを作成して、それをPublish FeatureしてGitHubにプッシュします。

今回はfeatureブランチを作成する前に、masterブランチにマージすることにします。

masterブランチへのマージはまずバージョン番号名のReleaseブランチを作成する


developブランチを右クリック→Git Flow→Start Realease。


releaseブランチ名はmasterブランチのTagに使われるのでバージョン番号にします。


これでreleaseブランチが作成できました。

releaseブランチをFinishしてmasterブランチにマージする


ReadmeなどをGitHub上で編集したあとローカルにFetchし忘れて、masterブランチにマージしてから気が付いて、コンフリクトに四苦八苦したことがあるので、念のためにまずmasterブランチをリモートブランチからPullしておきます。

まずローカルのmasterブランチをチェックアウトします。

リポジトリ名を右クリック→Pull。


今回はマージし忘れていたものはありませんでした。

再度releaseブランチをチェックアウトします。

releaseブランチを右クリック→Git Flow→Finish Release。


releaseブランチが消えてdevelopブランチがチェックアウトされています。

git-flow cheatsheetによるとreleaseブランチがdevelopブランチにマージされて、masterブランチにタグが付けられることになっていますが、releaseブランチではコミットしていないのでdevelopブランチのハッシュ値は変わっていません。

新たにv0.1.0のTagが作られていることがわかります。

このTag名はFinishしたreleaseブランチと同じ名前です。

次の開発に備えて新たにfeatureブランチをStartする


チェックアウトしているdevelopブランチを右クリック→Git Flow→Start Feature。


featureブランチ名は年月日時分にしました。


これでローカルリポジトリは次の開発に向けての環境が整いました。

もう一つのPCでも同じ環境が再現できるようにすべてのブランチをGitHubにプッシュする


まずfeatureブランチを右クリック→Git Flow→Publish Feature。

これでfeatureブランチをリモートリポジトリにプッシュできました。

もう一つのPCで作業するときはTrack Featureでリモートリポジトリのこのfeatureブランチをプルします。

developブランチとmasterブランチはGit Flowにプッシュする項目はないので、それぞれチェックアウトしてPushします。

作業が終わったら忘れずにfeatureブランチをチェックアウトしておきます。


これでローカルリポジトリとリモートリポジトリのブランチのハッシュ値が揃いました。

タグはmasterブランチをプッシュしてもプッシュされない


masterブランチをプッシュしてもタグはローカルリポジトリには反映されません。

タグをプッシュするにはTagsを選択して右クリック→Push Tags。


プッシュするタグにチェックをつけてNext→Finish。

どのタグをプッシュしたかはGit Repositoriesを見てもわかりません。


GitHubのリポジトリを見ると1 releaseとなっているのがわかります。

これをクリックするとタグがプッシュされていることがわかります。


v0.1.0というタグがあり、その状態のリポジトリのファイルをzipやtar.gzファイルとしてダウンロードできます。

いまのところ上記の運用でコンフリクトが起こらなくなりました。

(2017.4.9追記。FetureブランチをFinishしてからMasterブランチへマージするまでの一連の操作をするとなぜかPyDev Package ExplorerのPyDevプロジェクトの中身がみれなくなってしまうときがあります。そのときはlinuxBean14.04(156)Eclipse4.6にGit管理のプロジェクトを取り込むの「ローカルリポジトリからPyDevプロジェクトをインポートする」のようにしてPyDevプロジェクトを復元しようとしてもSome or all projects cannot be imported because they already exist in the workspaceと言われて復元できません。これは単にプロジェクトがCloseになっているだけなので、プロジェクトをPyDev Package Explorerで選択して右クリック→Open Project、で解決しました。)

次の関連記事:Git(27)EclipseでローカルリポジトリをGitHubのリモートリポジトリにするまで

PR

0 件のコメント:

コメントを投稿