2
1

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, GitLabを使うときの開発の流れ(フロー)

Posted at

⚠️このドキュメントっぽいものについて

  • もともとは弊社の社員向けにGitを用いた開発フローを説明するためのドキュメントの目的で作られています
  • このドキュメントで解説するフローはGitHubFlowなどから一部変更をしています
  • これが必ずしも正解であるとは限りません
  • GitHub(GitLab)が有効活用できればそれでOK このドキュメントはその一例として見てください
  • Qiitaかどこかでこのフローの元の記事を見た覚えがありますが見つかりませんでした。もしご存じの方がいらしたらリンク付をしようと考えているのでコメントで教えて頂けると幸いです
  • 既に固定のフローをお持ちの方々はそのフローで大丈夫だと思います

📄tl;dr

  1. 消化しないといけないタスク(バグ、新規実装項目)をIssueに網羅する。実装における質問や議論などもIssueに立てて書くと良き
  2. 実際にコードを書く際は専用のbranchを切る。branch名は必ずAdd_DogeIcon#12のような形にする。(Issueのだいたいの英訳+Issue番号)
  3. 実装が終了したらpush→PR(MR)を発行する。プルリクの名前は割と適当でも良いと思う。ただし必ず概要文に該当Issueのリンクを貼る。
  4. 必要に応じてコードチェックなどをして、最終的に通ればMergeする。

🤔なんでフローを制定するの?

masterに直Pushしてコードを書いていくスタイルをしていると、以下の問題が発生することがある

  • (連休明け)**あれ先週の自分ってどこまでコード書いたっけ……**😅
  • あのひとが書いてるコードって自分のものに影響しそうな気がするんだけど確認できんのかな😫
  • タスクがテキストメッセージで書かれてて確認しようにも探しづらい🤮
  • 前に同じようなことをして実装した気がするけど、どうやってたっけ…覚えてないや🤕

これらは以下の要因に起因する

  1. タスク管理が集約できておらず、テキストメッセージ内に散乱している
  2. 自分が調べたりしたときに覚えておくためのWikiのようなものが存在しない
  3. 他人の実装概要、内容が誰でも見られる状態になっていない

これらの問題点はGitHub(GitLab)をフル活用した開発フローで解決できる。

👩‍💻🧑‍💻実際のフロー

サンプルに使ってるRepos: https://github.com/huequica/soundrop_OtogibaraEra

1. 💬タスクをIssueに網羅する。

Issueを網羅していく

まずは消化しないといけないタスク、バグ報告などをリポジトリのIssueに書き出す。
これによりタスクの集約、及びそれに対しての連絡や相談などが可能になる。
ただし以下の点に気をつけること。

  • Issueは粒度を細かく、目的別で作る。たとえば「ここの文言の記述変更のIssueだけどめんどいから画像差し替えのIssueも同じでええやろw」はアウト

  • 実装においてAssignされたIssueページの使い方は個人の自由にする。メモ帳でもチラシ裏でも本人には重要だからIssueに書いている。ただし議論は別。

2. 🧑‍💻💦branchを切ってコードを書く

Issue内容をコードに実装する際は専用の命名規則を持った上でbranchを作り、そこでコードをいじる。
弊社の場合は Add_DogeIcon#12 のようにIssue概要の英訳+Issue番号(システム側が連番で振ってくる#から始まる番号)で命名をしている。

また、実装を途中で一旦保留にしたりする(連休が来たなど)場合はIssueに「ここまで書けた」という感じで一旦Issueページに加筆してbranchをpushしておくと再開するときにスムーズだと思う

3. 🚀コードが書けたらPushしてPullRequestを出す

まずはコードが書き終わったら一回休憩しよう。適当にコーラとかコーヒーとかでいい。
そうしたらリモートのReposにpushして、PRを出す
PRのタイトルは割と適当だけど概要が分かれば問題ではない。
ただしPRの説明文にIssueへのリンクを貼る。これは必ずしておいて頂きたい。
リンクを貼ることによって元のIssueにも「このPRにリンク付けされたぞ」というメッセージが出てくるので過去の実装を探すときに探しやすくなる。

PRの提出 Issueへのリンクを絶対つけること

あとは適宜コードのレビューをしたりして問題がなければMergeする。


以上の3行程を繰り返すことによって快適かつ安全に開発ができる。Git使いたての人などには非常におすすめ。

👀他の恩恵

  • CIなどを使うことでPRが出た際にテストやLinterを走らせてコードが問題ないかを自動チェックさせることができる。
  • 上記に加え、Mergeしたら自動デプロイをさせるみたいなのもできる
  • Revert(Commitのロールバック)をする際、確実に該当のCommitが探しやすくなる
  • 若干草が盛れる(不純)

🕺まとめ

実際にやってみると大変なように見えてかなり快適です。特にタスク管理を集中させ、そのままコードを書いてPR提出までスムーズに移行することができるのでみなさんもやってみてください。

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

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?