4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【Git】初学者がXcodeプロジェクトでgit-flowを試してみた

Posted at

こんにちはkudpigです。

私はまだまだ駆け出し者ではありますが、其処彼処で「とにかくGitはできるようになっとけ」という声を聞きますので、このたび改めて勉強し直してみました。

その中で、より実践的なgit-flowという運用方法があるということを知り、勉強も兼ねて手を動かして試してみることにしました。
本記事ではその流れを記述していきます。

※この記事は初学者のアウトプットを目的としており、個人的な理解によるものなので、誤った解釈を招く可能性がありますことをご承知下さい。誤りがある場合はご指摘いただければ都度修正させて頂きます。

概要

git-flowの導入〜featureブランチの作成までを実践してみる。
※アプリリリースもままならない初学者のため、ここまでで勘弁してください。(releaseブランチとかが必要な所まで早く到達したいものですorz)

環境

・Xcode - 11.3.1

・git - 2.26.0

・CLI - ターミナル

・GUI - GitHub DeskTop

前語り

私は今までの学習において、gitの操作をCLIであるターミナルとGUIツールであるGitHub DeskTopの2つを併用使用しております。
理由は、細かな設定や操作はターミナルで行うことが望ましいと理解している一方で、変更差分などを視覚的に確認するには上記のようなツールを使用した方が分かり易いと感じているからです。

エンジニアの先輩方には「gitをターミナルで操作しないやつはにわか」と指摘されてしまいそうですが、コミット差分の把握間違いとかで誤ったpushをしてしまうくらいなら、分かり易いツール使っといた方が迷惑かけないかな、と思っていたりもします。

ゆくゆくは使えるようにしますので、生暖かい目で見守って頂けると幸いでございますm(__)m

git-flowをざっくり解説

こんなイメージ
git-flow
git-flowにおけるこのブランチの役割は以下のようになります。

  • master リリース用のブランチ。常にAppStoreに公開されているものと同じ状態を保つ。

  • develop 開発ブランチ。リリースできる状態となったらreleseブランチを作成し、Appleの審査にかける。

  • release リリース前の審査用のブランチ。Appleの審査が通ったらmasterにマージする。リリースが完了したらdevelopにもマージする。また、masterにマージする際にはversion情報などのタグをつけることがある。

  • feature 作業ブランチ。developから作成し、作業が完了したらdevelopにマージする。

  • hotfix 改修用のブランチ。 バグなどが発生した場合はこちらにブランチを切り対応する。

なるほど、developで追加実装がしっかりと動いたことを確認し、さらにreleaseでAppleの審査が通ったもののみmasterにPushできるので安心な設計のように思えます!

実践

①git-flowの準備

まず、事前にgit-flowはインストールしておく必要があります。

$ brew install git-flow

これでインストール出来ます。

②Xcodeプロジェクト作成

練習用のXcodeプロジェクトを作成します。
適当に"xcode-gitflow"とでもしておく。

作成した該当のディレクトリに移動してからgit-flowを導入していきます。

$ cd xcode-gitflow

③git-flowを適用させる

$ git flow init

上記コマンドを打つと次のようなメッセージが表示されます。

# git flow init のあと

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

いくつか確認されますが、とりあえず全てenterします。
聞かれているのはブランチの名前だったり、分岐後の各ブランチのデフォルトの名称設定だったりするので、特にこだわりも無いのでこのままにします。

これで該当ディレクトリがgit-flowによる管理下に置かれます。

# 該当ディレクトリにて

$ ls -a
.			.git			xcode-gitflow.xcodeproj
..			xcode-gitflow

lsコマンドで中身を確認すると、.gitが作られていることがわかります。

さらにブランチもみてみます。

# 該当ディレクトリにて

$ git branch
* develop
  master

今いるブランチがdevelopになっていますね!
これで現在のリポジトリがdevelopとmasterで管理されている状態となりました!

(おまけ)GitHub DeskTopでも確認してみた

GitHub DeskTopでも確認してみます。
右上RepositoryからAddをクリックし"Add Existing Repository"で該当のフォルダを選択します。

qiita02-gui ちゃんと現在のブランチがdevelopになっており、masterブランチも存在していることが確認できます。

④リモートgithubへpushする

とりあえずこの状態で、リモートgithubへpushするところまで行います。
ターミナルからでもGUIツールからでも良いのですが、練習も兼ねてターミナルから行います。(苦手なので・・・)

ターミナルでの操作を行う前に、githubでリポジトリを作成しておきます。
(余談ですが、GitHub DeskTopからpushする場合は作っておかなくてもpushと同時に作成することが出来ます。)

作成したリポジトリのURLを次のコマンドに貼り付けます。

# ターミナル
# 該当ディレクトリにて

$ git remote add origin リポジトリのURL
(git remote add origin https://github.com/ユーザー名/リポジトリ名)

これでリモートgithubと紐づけることが出来ました。

$ git remote -v
origin	https://github.com/ユーザー名/リポジトリ名 (fetch)
origin	https://github.com/ユーザー名/リポジトリ名 (push)

上記のように確認することが出来ます。

では準備が整いましたので、いざpush!

$ git push --all

上記コマンドを打つと次のようなメッセージが表示されます。

# $ git push --all のあと

Enumerating objects: 24, done.
Counting objects: 100% (24/24), done.
Delta compression using up to 8 threads
Compressing objects: 100% (22/22), done.
Writing objects: 100% (24/24), 7.58 KiB | 2.53 MiB/s, done.
Total 24 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/ユーザー名/リポジトリ名
 * [new branch]      develop -> develop
 * [new branch]      master -> master

記載の通り、リモートリポジトリに[new branch]としてdevelopとmasterが作られたことが分かります。

githubでリポジトリを確認すると、しっかりブランチが"initial commit"されていることが確認出来ます。

ちなみにGitHub DeskTopからだとこんな感じで確認できるのでわかりやすいです。

qiita02-gui2

ここまでGitHub DeskTopでの操作は全くしてませんが、ターミナルで操作すれば連動して表示も変わります。
コード差分の確認など、ツールが得意とする部分を活用してケアレスミスを減らしていきたいです。

⑤featureブランチを作る

ここまで来たら、あとは作業用のfeatureブランチを作り実際に開発を行なっていくことになります。

featureブランチはターミナルで、次のコマンドを打つことで作成できます。
とりあえずhogeブランチを作ってみます。

$ git flow feature start hoge

コマンドを打つとこのようなメッセージが表示されます。

Switched to a new branch 'feature/hoge'

Summary of actions:
- A new branch 'feature/hoge' was created, based on 'develop'
- You are now on branch 'feature/hoge'

Now, start committing on your feature. When done, use:

     git flow feature finish hoge

書いてある通りですが、要はdevelopを元にfeature/hogeブランチを作り、
そしてfeature/hogeブランチに移動したよ。

ということです。

難しいコマンドのようですが、
git branch feature/hoge
git checkout feature/hoge
しているだけです。

では今のブランチを確認してみます。

$ git branch
  develop
* feature/hoge
  master

はい、出来ました。
あとはこのブランチで作業を行い、作業完了したらプルリク出すなりしてdevelopにマージするだけです!\(^o^)/

終わりに

こんなだらだらと長いだけのメモ記事を最後までお読みくださりありがとうございます。
この記事を読んだ初学者の方の、git操作に関する困りごとの解決に少しでも役立てたなら幸いです。

では!

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?