スポンサーリンク

初心者用Git入門のすゝめ(2):Gitプロジェクト運用の流れ

こんにちは。みなみです。

前回GitとSVNのバージョン管理についてご紹介しましたが、今回はGitのプロジェクト運用の基本的な流れをご紹介します!

スポンサーリンク

Gitプロジェクト運用の基本的な流れ

実はGitには様々な運用パターンがあり、Gitは必ずこの方法で…という運用方法が決まっているわけではありません。なので今回は初心者でも簡単にGitに慣れやすい運用方法をご紹介します。

Gitでプロジェクト運用を行う場合、一般的にGitHubやGitLabなどのウェブサービスを使います。今回は利用率が最も高いGitHubの例で説明していきますが、基本的にはどのウェブサービスでも同じ流れになります。

それではまずざっくりとプロジェクト初期設定、プロジェクト運用に分けて流れをみてみましょう。色々見覚えない用語が出てきますが、まずはなんとなく「ふーん」ぐらいでみておいてください。

英単語が数多く出てきますが、Gitを扱う上でこれらの用語は必要な知識となります。慣れないうちは大変と思いますが頑張って覚えましょう…。 Gitの用語はいずれ詳しくご紹介します。

プロジェクト初期設定

  1. プロジェクト作成:GitHubにRepository(リポジトリ)を登録する。
  2. PCにプロジェクトを複製:RepositoryをClone(クローン)する。
  3. 作業場所作成:Branch(ブランチ)の基本セットを作成する。

プロジェクト運用

  1. タスクの登録:GitHubにIssue(イシュー)を登録する。
  2. 作業場所作成:Issue用の作業Branchを作成する。
  3. 実開発作業:作業Branchで開発する。
  4. 開発内容をアップロード:変更内容をGitHubにPush(プッシュ)する
  5. 開発内容の取り込み依頼:PullRequest(プルリクエスト)を作成する。
  6. 開発内容を取り込む(1):PullRequestをReview(レビュー)してもらう。
  7. 開発内容を取り込む(2):PullRequestをMerge(マージ)してもらう。
  8. タスクの終了:IssueをClose(クローズ)する

Gitプロジェクト運用手順

それでは1つづつ手順をみていきましょう。

バージョン管理システムを使ったことない方だったり、SVNしか知らない方は始めにイメージを掴むのに苦労すると思うので、まず何も考えなくてもなんとかなるように手順化していきますね。

プロジェクト初期設定

まずプロジェクトを始める際に1度だけ行う作業です。

手順はちょっと面倒ですが、各プロジェクトで1度行えば良い作業なので、慣れないうちは特に覚えなくても大丈夫です。

プロジェクト作成:GitHubにRepository(リポジトリ)を登録する。

GitHubではRepository(リポジトリ)という単位でプロジェクトを管理します。

1プロジェクト毎に1つのリポジトリが必要なので、まずGitHubでリポジトリを登録します。

GitHubのトップページを開き、Newボタンをクリックしてください。

“New”を押下してRepository登録画面へ

すると以下のリポジトリ登録画面が表示されますので、登録したいリポジトリ名を入力して”Create repository”をクリックします。

Repository登録画面

※Description : プロジェクトの紹介文です。あってもなくても大丈夫です。
※Public / Private : プロジェクトの公開設定です。Publicだと全ユーザーが閲覧可能で、Privateは指定したアカウントのみ閲覧できます。
※Initialize this repository with README : チェックするとREADMEファイルを自動生成してくれます。慣れるまでとりあえずデフォルト(オフ)で良いと思います。

Descriptionを設定した場合、以下のようにリポジトリ一覧画面で表示されます。

Repository一覧

お疲れ様です!以下の画面が表示されたらリポジトリの作成は無事完了です!

Repository作成完了!

PCにプロジェクトを複製:RepositoryをClone(クローン)する。

GitHubにリポジトリを作成した後は、開発用のPCに作成したリポジトリを複製します。この作業をClone(クローン)と言います。

クローン作業はコマンドライン上で行うのですが、 クローンするのには「作成したリポジトリのクローン用のURL」が必要です。なので再度先ほど作成したリポジトリを開き、以下のボタンをクリックしてURLをコピーします。

Clone用のURLをコピー

Clone用のURLを取得できたら、早速コマンドラインを起動してCloneしていきましょう。

ただし、その前にGitがPCにインストールされているか確認しましょう。もしインストールされていない場合はGitのインストールが必要です。こちらの公式サイトの手順を参考にGitをインストールしてください。

$ git --version
git version 2.21.0 (Apple Git-122.2)

上記のように”git –version”コマンドを入力し、Gitのバージョン情報が出力されればインストール済みです。バージョンが表示されないかエラーが出力された場合はGitのインストールを行いましょう。

Gitがインストールされていることが確認できた後、プロジェクトを配置したいフォルダに移動した後以下のクローンコマンドを実行します。実行するとGitHubのリポジトリから情報を取得し、リポジトリと同名のフォルダが作成されます。

// クローンコマンドを実行する
// git clone <clone url>
$ git clone git@github.com:tc-minami/test-repository.git
Cloning into 'test-repository'...
warning: You appear to have cloned an empty repository.

今回は”test-repository”というフォルダが作成されていますね。3行目のWarningはリポジトリの中にファイルが存在しないため発生していますが、特に害があるわけではないのでスルーします。

上記コマンド実行後、以下のようにフォルダが作成されていればクローン完了です!

作成されたプロジェクトフォルダ

クローンできたらプロジェクトの初期設定完了まで後少しです!

作業場所作成:Branch(ブランチ)の基本セットを作成する。

最後に開発用のBranch(ブランチ)を用意します。

今までプロジェクトを編集する時、”project_2020/02/01″や”old_project”とか名前を変えてプロジェクトのコピーを取っておく人もいると思います。今回行うブランチの作成はそんな感じでプロジェクトの開発用コピーを作成する作業です。

ブランチを作成するためには1度以上Commit(コミット)という保存処理をしなければいけないので、クローンしたリポジトリに移動した状態でコマンドを実行します。
※これらの内容は後ほど詳しく紹介するため、今のところ詳細はスルーでお願いします。

// 現状フォルダ内が空で、保存する変更差分がないためREADMEファイルを作成
$ touch README

// Commit対象に全ファイルを追加
$ git add .

// Commit処理を行う。保存内容(メッセージ)は"my first commit"とする。
$ git commit -m "my first commit"

// 現在存在するBranchを確認。
// デフォルトでmasterというBranchが存在することを確認する。
$ git branch
* master

// developというBranchを作成する。
$ git checkout -b develop
Switched to a new branch 'develop'

// 現在存在するBranchを確認。
// developが増えて、"*"developについていることを確認する。
$ git branch
* develop
  master

上記コマンドを実行し、masterとdevelopのブランチが表示されればブランチ作成完了です!

これで作業用のブランチ作成が完了しましたので、この変更をGitHubにも反映させましょう。Push(プッシュ)コマンドを実行します。
※この内容も後ほど詳しくご紹介します。

// 作成したmasterブランチをGitHubにアップロードする
$ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:tc-minami/test-repository.git
 * [new branch]      master -> master

// 作成したmasterブランチをGitHubにアップロードする
$ git push origin develop
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for 'develop' on GitHub by visiting:
remote:      https://github.com/tc-minami/test-repository/pull/new/develop
remote: 
To github.com:tc-minami/test-repository.git
 * [new branch]      develop -> develop

// GitHub上にmasterブランチとdevelopブランチが存在することを確認する
$ git branch -r
  origin/develop
  origin/master

以上でプロジェクトの初期設定は完了です!お疲れ様でした!

一度休憩を挟んで、準備ができたらプロジェクトの運用方法もみていきましょう。

プロジェクト運用

それでは続いてプロジェクト運用の流れをご紹介します。

以下の手順を行う前にGit運用したいプロジェクトをクローンしたフォルダに移動する、もしくは新規プロジェクトをクローンしたフォルダ内に作成してください。

タスクの登録:GitHubにIssue(イシュー)を登録する。

GitHubでプロジェクトを運用する場合、タスクは全てIssue(イシュー)という単位で管理します。イシューは今後対応を行うモノのリスト、つまりはTODOリストみたいなものです。

イシューはリポジトリ画面のIssuesタブから確認できます。またNew issueボタンから新規イシューが登録できます。

Issue画面

以下の画面でタイトル、内容を入力してSubmit new issueボタンをクリックすればイシューの登録は完了です。また、今回はイシューの担当者(Assignee)を自分自身に設定しておきましょう。

イシュー登録画面

イシューの登録が無事完了したら以下のような画面が表示されます。

イシュー詳細画面

作業場所作成:Issue用の作業Branchを作成する。

続いて作成したイシューの作業用ブランチを作成します。Gitでは一般的に1イシューに対して1ブランチ作成して対応します

今回はイシューIDが1なので、”feature/1-sample”という名前のブランチを作成します。ブランチの命名規則はプロジェクトによって異なりますが、私は”feature/<issue-id>-<issue-content>”という命名規則をおすすめします。

ここで頭につけてる”feature/”というのは「このブランチは開発用のブランチだよ」ということを表しています。Gitではいくつかブランチの種類が存在し、feature(開発)ブランチ以外にもrelease(リリース管理)ブランチやhotfix(緊急修正)ブランチ、bugfix(バグ修正)ブランチなどが存在します。

// 現状参照しているブランチを確認する。
$ git status
On branch develop
nothing to commit, working tree clean

// feature/1-sampleブランチを作成する。
// その際、新しいブランチには元々参照していたブランチの内容が複製される。
git checkout -b feature/1-sample
Switched to a new branch 'feature/1-sample' 

// 現状参照しているブランチを確認する。
// 新たに作成したブランチを参照していることを確認する。
$ git status
On branch feature/1-sample
nothing to commit, working tree clean

実開発作業:作業Branchで開発する。

通常通りエディタを開いて開発作業を行います。

開発作業が一定程度進んだらCommit(コミット)という変更を保存する作業を行い、サーバー上にPush(プッシュ)して変更を反映させます。

コミットの頻度や粒度に厳密な決まりはありません。なので1日何度コミットしても良いですし、極論1行や1関数を変更する度にコミットしても問題ありません。コミットはいわゆるセーブポイントの作成なので、多すぎて困ることはありません。何かある度にコミットしておきましょう。

また、コミットを行う前にAdd(アド)という作業を行う必要があります。Gitでは差分があるファイルのうち、コミットしたいものを事前に指定する必要があります。この作業をアドと言います。

それでは実際にコマンドをみていきましょう。今回はサンプルとしてREADMEを編集し、コミットします。

// READMEファイルに"This is README"という文字列を追加する。
$ echo "This is README" >> README 

// git statusコマンドで差分があるファイルを確認する。
// 今回はREADMEファイルが変更されていることを確認する。
$ git status
On branch feature/1-sample
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   README

no changes added to commit (use "git add" and/or "git commit -a")

// git addコマンドでコミット対象にREADMEを追加する。
// 全てのファイルをコミット対象に追加する場合は"git add ."でもOK。
$ git add README

// READMDEのステータスを再度確認する。
// Changed to be committedに含まれていればOK。
$ git status
On branch feature/1-sample
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README

// git commitコマンドでコミットする。
// commitメッセージには必ず"#<issue-number>"を入れましょう。
$ git commit -m "update README #1"
[feature/1-sample 03c453f] update README
 1 file changed, 1 insertion(+)

今回はコミットの内容を「update README #1」として指定しています。コミットメッセージに#<イシュー番号>を含めると、自動的にコミットとイシューが紐付けられます。なのでコミットする際は原則イシュー番号をコミットメッセージに含めるようにしましょう

開発内容をアップロード:変更内容をGitHubにPush(プッシュ)する

コミットまで完了したら次はPush(プッシュ)します!

今までは全てPC内での変更でしたが、プッシュをすることでPC内の変更記録をサーバー上にアップロードできます。サーバー上にアップロードすることでGitHub上に変更が反映されたり、他のメンバーも内容を確認できるようになります。

それでは早速やっていきましょう。

// git statusコマンドで現在の作業ブランチを確認します。
// 以下の内容だと現在の作業ブランチはfeature/1-sampleです。
$ git status
On branch feature/1-sample
nothing to commit, working tree clean

// git pushコマンドで現在の作業ブランチをサーバーにアップロード。
// 今回はfeature/1-sample
$ git push origin feature/1-sample 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 257 bytes | 257.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for 'feature/1-sample' on GitHub by visiting:
remote:      https://github.com/tc-minami/test-repository/pull/new/feature/1-sample
remote: 
To github.com:tc-minami/test-repository.git
 * [new branch]      feature/1-sample -> feature/1-sample

プッシュコマンドが無事実行できたらPC内の変更のアップロードは完了です。早速GitHubに変更が反映されたか確認してみましょう。

GitHubのリポジトリにアクセスし、Insightsタブを選択します。そして左のメニューからNetworkを選択します。

Insights画面

するとNetwork graphという画面が表示されます。画面内にプッシュしたブランチfeature/1-sampleブランチが存在すればOKです!

Network graph画面

それでは続いてPull Request(プルリクエスト)に進みましょう!

開発内容の取り込み依頼:Pull Request(プルリクエスト)を作成する。

開発用のブランチで開発が完了した後は、変更内容を開発用のメインブランチ(developブランチ)に取り込んでもらいましょう。

そのためには他の人に変更差分を確認してもらい、取り込んでもらう必要があります。その際他の人に確認してもらうために依頼を出すのですが、この依頼のことをPullRequest(プルリクエスト)といいます。

プルリクエストはGitHubのリポジトリのページ、Pull requestsタブから作成できます。Pull requestsタブを開いたらNew pull requestボタンをクリックしてプルリクエストを作成します。

また、ブランチをプッシュした直後はCompare & pull requestというボタンが表示されます。こちらをクリックしても同じくプルリクエストを作成できます。


Pull request画面

プルリクエスト作成ボタンを押すと以下のComparing changesの画面が表示されます。baseブランチとcompareブランチを設定すると、差分が表示されます。

以下の画像ではbaseにdevelopブランチ、compareにfeature/1-sampleブランチを指定しています。表示された差分に問題がなければCreate pull requestボタンをクリックします。

Pull requestブランチ指定

すると以下の画面が表示されます。プルリクエストを作成するまでの導線はちょっと長いですが、こちらのCreate pull requestボタンをクリックしたらようやくプルリクエスト作成完了です!

Pull requestの内容指定

以下のような画面が表示されたらOKです!

Pull request画面

開発内容を取り込む(1):PullRequestをReview(レビュー)してもらう。

プルリクエストの作成が完了したら、早速変更差分をレビューしてもらいましょう!

変更差分はプルリクエストのFiles changedタブから確認できます。今回ですと差分はREADMEファイルの1行だけですね。

プルリクエスト差分

指摘が必要な差分があれば差分の行番号付近にカーソルを合わせると、コメントを追加できます。

全ての差分のレビューが完了したら、Review changesボタンからレビューを完了しましょう!

開発内容を取り込む(2):PullRequestをMerge(マージ)してもらう。

差分をレビューしてもらい、全ての修正が完了した後はプルリクエストをMerge(マージ)しましょう。マージをすると作業ブランチの内容が取り込み先ブランチに反映されます。今回ですとfeature/1-sampleブランチの変更内容がdevelopブランチに反映されます。

マージが完了後、Graph networkも更新されます。

ちょっと見辛いですがfeature/1-sampleから矢印が伸びてdevelopブランチへと向かっているのが確認できます。これはfeature/1-sampleブランチがdevelopブランチにマージされたことを表しています。

Graph network画面

拡大してみるとこんな感じです。

タスクの終了:IssueをClose(クローズ)する

それではイシューの対応が完了したため、イシューをClose(クローズ)しましょう。イシューにはいくつかステータスがあり、クローズは対応完了、もしくは対応不要というステータスになります。

以下のイシュー画面のClose issueボタンをクリックするとイシューをクローズすることができます。

イシューがクローズできたら1サイクル完了です!あとはイシュー毎に同じ対応をするだけでGitの運用はバッチリです。

Issueをクローズする

まとめ

いかがでしたでしょうか?Gitは慣れるまで手順も多く面倒に感じるかもしれません。

ですがGitは変更差分を詳細に記録することができ、GitHubを使うことでチーム間の連携も非常に簡単に取れます。一度慣れてしまえば非常に便利なので、みなさんも是非Gitを使ってみてください!

コメント

タイトルとURLをコピーしました