2
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.

🔰GitHubのissue機能と複数ブランチ(main, develop, feature)を用いたGit開発の流れ

Last updated at Posted at 2021-10-31

はじめに

はじめまして、プログラミング初学者の@kat_logと申します。

プログラミングの勉強をする中で、

  • 「実務ではmainブランチに直コミットはしない」
  • 「GitHubのissue機能をタスク管理に使うと良い」

という情報を度々見かけ、自分なりに開発手順をまとめました。

※実務未経験者が書いております。
実務経験の先輩方、違和感がある部分等ありましたら、ぜひご教示いただければと思います!

前提

GitとGitHubの連携は済んでいるという前提で書いております。
(ローカルリポジトリとリモートリポジトリに「main」ブランチのみがある状態と仮定し記述しております。)

手順

developブランチの作成

mainブランチでは作業しないため、developブランチを切ります

git switch -c develop

新しいブランチの作成はgit checkout -b ブランチ名でも可能です!
switchの方が比較的新しく追加されたコマンドのようで、こちらで記載しました!

developブランチをリモートリポジトリに反映

git push -u origin develop

GitHubにてissue発行

Screen Shot 2021-10-30 at 19.11.23.png
Screen Shot 2021-10-30 at 19.26.30.png

作業前にリモートのdevelopブランチをローカルに反映

1人で1台で開発する場合不要そうですが、、ローカルのdevelopブランチをリモートに合わせておきます
(記事1周目の場合も、先程developブランチをローカルからリモートに反映したばかりなので不要ですね)

git switch develop #①developブランチへ移動
git fetch #②リモートのdevelopをローカルのリモート追跡ブランチorigin/developに持ってきてます
git merge origin/develop #③ローカルのdevelopに、ローカルのリモート追跡ブランチorigin/developを反映させます

featureブランチの作成

developブランチから、実際に作業をするfeatureブランチを切ります

git switch -c ブランチ名(例:feature/#1_add_〇〇)

ブランチ名のところに#数字という形でGitHubのissue番号を入れておくと、どのissueの作業を行うブランチなのか分かりやすくなります

featureブランチをリモートリポジトリに反映

git push -u origin 先程作ったブランチ名

〜 ファイル編集 〜

  • 細かい粒度でコミットする
  • pushも定期的に行う

と良いみたいです!

編集後

git diff #編集内容の確認
git status #編集したファイルの確認
git add -A #編集したファイルをインデックス(ステージングエリア)に追加
git commit -m "#issue番号 コミットメッセージ" #コミットメッセージに「#issue番号」を含めましょう!

コミットメッセージの中に「#1」のように「#issue番号」を入れることでGitHubのissueと結びつけることができます!

push前にdevelopの最新状態を取得

git switch develop #developブランチへ移動
git fetch
git merge origin/develop

(こちらも1人で1台で開発する場合不要とは思います)
(競合があれば、(チーム開発の場合、修正したメンバと)確認しながら修正することになると思います)

リモートにpush

git switch featureブランチ
git push -u origin featureブランチ

GitHub上でプルリクエスト&マージ

(featureブランチをdevelopにマージするための)プルリクエストを作成

Screen Shot 2021-10-30 at 21.04.35.png
Screen Shot 2021-10-30 at 21.08.14.png
Screen Shot 2021-10-30 at 21.07.47.png

マージの実行

Screen Shot 2021-10-30 at 21.19.50.png
Screen Shot 2021-10-30 at 21.20.15.png
Screen Shot 2021-10-30 at 21.21.10.png

GitHub上で対象issueをclose

Screen Shot 2021-10-30 at 21.29.49.png
Screen Shot 2021-10-30 at 21.33.02.png
Screen Shot 2021-10-30 at 21.35.08.png

ローカルのdevelopをリモートと同じ状態にする

git switch develop
git fetch -p
git merge origin/develop

git fetch -pについて補足]

  1. git fetch-pオプションを付けることで、(git fetchしつつ)リモートに存在しないブランチをローカルのリモート追跡ブランチから削除することができます。

  2. GitHubでは、マージされたタイミングでマージ元のブランチが削除される設定がデフォルトのようです。

  3. (今回の場合、リモートのfeatureブランチがマージによって無くなっているのでローカルのリモート追跡ブランチにあるorigin/featureブランチがgit fetch -pにより消えます)

ローカルのfeatureブランチを削除

ローカルのリモート追跡ブランチfeatureは削除できましたが、ローカルの作業ブランチfeatureが残っているので削除しておきます。

git branch -a #ブランチ一覧の表示
git branch -d featureブランチ

〜 一連の流れ完了 〜

これにて一連の作業が完了となります!🎉
次の作業に移るには、再び「GitHubにてissue発行」から行う形になります。

おわりに

お読みいただきありがとうございました。
自分と同じく初学者の参考になれば嬉しいです。
また、実務未経験者が調べながらたどり着いた流れになりますので、実務的にはこうした方が良い等アドバイスありましたら、ご教示いただければと思います。
↓に参考にさせていただいたページの一覧を付けております。
初学者の方々、一緒に頑張っていきましょう〜😄

参考

2
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
2
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?