僕の中でのGithub運用方針

公開日:2019-06-27
最終更新:2019-06-27

はじめに

僕はエンジニアとして実務経験を積み始めて1年弱のいわゆる駆け出しエンジニアと呼ばれる存在です。
そんな僕が1年間のチーム開発を経験して得た拙い知見を書き下して行きます。
皆さんの参考になれば幸いです。

ブランチについて

・master
本番環境でリリース・動作するブランチ。最後はここにマージしてデプロイします。

・develop
開発用のブランチ。
基本的にエンジニアはここから作業用ブランチ(ex. feature/create_login_page)を切って開発を行います。


コミットの粒度

基本的に同じようなファイル、修正ごとに分類してcommitを行います。
commitがあまりにも多くなることが予想される場合は作業ブランチを複数本用意した上で最終的に1本のブランチにmergeするのが理想的。そのほうがcommit履歴が綺麗になりレビューがしやすくなるのでオススメです。
よく初心者が初めてチーム開発に参加したときにやりがちですがくれぐれも

git add .  

なんてコマンドを打たないよう注意してください(笑)!


Pull Requestを送るまでの流れ

  1. git branch: 今自分がどのブランチにいるのかチェック
  2. git checkout -b ブランチ名: 作業用ブランチを切って移動
    ~なんやかんやで作業を行う...~
  3. git status -s: 変更・追加・削除したファイルを確認
  4. git add ファイル名: ステージングするファイルを指定
  5. git commit -m "コミットメッセージ": commitメッセージと共にcommitを実行。
  6. git pull --rebase origin develop: push前にこのコマンドは必ず実行して下さい。これを実行することで最新のdevelopブランチからブランチを切ったことになります。(便利!)
  7. git push origin ブランチ名: pushを行う。

諸注意

  • masterに直接pushはしない!
  • 基本的に-fオプションは使わない!使わざるを得ない状況になったらslackで確認を取る!
  • pushする前にgit diffで変更点を確認!余計な改行・空白やデバッグコードは削除!
  • conflictが起きても焦らない!落ち着いてGitHub上で確認して変更を適用するのか決める。(特にgit pull --rebase origin developはconflictが生じやすいです。しかしそれは仕方ないことなので焦らず変更点を追って解消しましょう。)

便利コマンド集(黒魔術有り)

ローカルで作業していてぐちゃぐちゃになってしまった。。。
作業内容を全て削除してやり直したい。。。
そんなときは

git reset --hard origin/ブランチ名  

でリモートリポジトリの作業ブランチの状態に強制的に変更!

あとよく挙げられるのが

git stash  

ですね。
これを使う機会は

  1. 変更ファイルがある状態で別ブランチに移動しなければならない時
  2. 間違ったブランチで作業してしまっていた時

でしょうか。
2については僕自身経験があります(笑)
ブランチを切らずにmasterブランチでそのまま作業を行いcommit直前にその事実に気づきました。どうしよう、また最初からやり直さなきゃいけないの?そう絶望した時にこのコマンドを先輩社員から教えていただきました。
流れとしては

git stash  

で変更ファイルを一時的に回避して

git checkout ブランチ名  

でブランチを移動。

 $ git stash list  
[email protected]{0}: WIP on develop: 426c867 バグ修正  
[email protected]{1}: WIP on develop: 9dee2ec 新規機能追加  

でstashした履歴を確認。
復活させたいstash名がわかったら次のコマンドで取り出します。

$ git stash apply [email protected]{0}  

おそらく皆さんも一度はこのコマンドに助けられると思います(笑)
もちろんこんな場面に遭遇しないのが一番であることに間違いはないのですが。。。


備考

Pull Requestを送るまでの流れ
$ git pull origin develop
から
$ git pull --rebase origin develop
に変更した理由ですが通常の
$ git pull origin develop
だと開発者の意図と異なる挙動を起こす可能性があるからです。
以前僕が引き起こした事件でPull Requestを送ってから半年経ってから
「このままこのブランチをdevelopにmergeしてもconflictが起こるからgit pull origin developでdevelopの変更点を作業ブランチに持ってこよう」
と考えgit pull origin developを実行しました。
どうなったと思います?
結果は恐ろしいことにdevelopで進んでいた変更点が時系列順に作業ブランチに取り込まれ変更ファイルが50以上、変更コード1000行以上となる大規模開発ブランチになってしまったのです!
つまり何が言いたいかというとmergeは時系列順に行われるということ。
git pullgit fetch + git mergeの合わせ技なので変更点が時系列順に作業ブランチに取り込まれます。これを回避するため--rebaseオプションをつけて最新のdevelopブランチからブランチを切ってやったことにする、つまりrebaseするのです。
「うーん、この説明読んでもわかんない。。。」
そう思う方もいらっしゃるかと思います。
それでも大丈夫です。
僕も実際に経験して覚えました。
とりあえず全てを理解できなくてもgit pullは危険なんだなあくらいに思っていただければ結構です。
余裕が出て来てから僕に聞くなりググルなりしていただければ大丈夫です。


最後に

とりあえず書きなぐって見ました。ご指摘等ございましたらお願いします。
コマンドの意味がわからなかったり、「こっちの方がいいよ!」というご指摘等ございましたらコメント欄でご指摘していただければと思います!

記事が少しでもいいなと思ったらクラップを送ってみよう!
62
+1
日々の業務で得た知見を共有していきます。

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする