2歩戻ったら2.5歩進みたい

関東で働くweb developerのブログ

【git】git初心者がプロジェクトでissueを割り当てられてから正しくmergeされるまでの流れ

この記事について

こんにちは。きゃにすたーです。web系のいわゆるベンチャー企業に就職してから早1ヶ月、 今やgit&Githubは無くてはならない存在になりました。 この記事は僕のようなgit初心者がチーム開発でだいたい初めにやりそうなことの流れをまとめて書いたメモです。

大まかな流れ

  • イシューが割り当てられる

  • 自分で直す

  • コミットしてプッシュする

  • マージされて終わり。

こんな感じです。なお、作業対象のリポジトリは事前にローカルにcloneしているものとします。

実際のコマンドを含めた流れ

  • issueを確認する
    hogeブランチのバグを直す、というissueが割り当てられています。

  • 作業対象のhogeブランチにgit checkout hogeしてからgit pull origin hogeでローカルリポジトリをリモートリポジトリの最新のhogeブランチと同期する

  • hogeブランチからgit checkout -b hoge_fix_bugでブランチを切る

    • 必ず作業対象のブランチ(ここでいうhoge)からブランチを切ってからコーディングを始めること
  • コーディングする。楽しい。

  • 変更し終わったらgit add -Aでステージング(この時点ではまだローカルリポジトリも変更されていない)

  • git commit -m "メッセージ"でコミットする

  • git push origin hoge_fix_bugでコードを直した自分のブランチをプッシュする

    • これでリモートリポジトリにhoge_fix_bugブランチが作成される
    • originはリモートリポジトリのサーバー名。
    • 間違ってもmasterpushしないこと。最悪の場合インターネット集団自決に発展します。

ここから下はGithubの作業。

  • Githubに自分がpushしたブランチが表示されているので、「Compare & Pull Request」を押す。

    • タイトルの変更とかレビュアーの設定とかラベリングとかなんやかんやできるのでなんやかんやする。
    • また、マージ先のブランチはcheckout元のブランチに設定するのが良いでしょう。(ここでいうhoge)
  • 以降はレビュアーにレビューしてもらって何回か直せばめでたくあなたのタスクは終わりです。お疲れ様でした。

まとめ

gitは神。

今の会社でgitを使うまでは「なーーーーーにがgitじゃファイル名管理でもイケるやろ」と思っていたのですが、使ってみるとほんとーに便利です。 今後もちょくちょくgitに限らずちょこちょこ更新したいと思います。ではまた。