Download to read offline
More Related Content
私が複数人開発で感じている Git・GitHubのうまみ
- 1.
- 2. 自己紹介(*´ω｀*) ● @sinamon129 ● Pyladiesstaff o しかしながらrubyとphpばっかり ● モバイルアプリのサーバサイドエンジニア ● バージョン管理ツールはGitから ● 社会人二年目
- 3. 今日話すこと ● 複数人での開発でGitがあると便利★ ● 並行して作業を進める時Gitがあると便利♪ ●開発フローに則ると捗る♥ ● こういう時にたまに困る(´・ω・｀) ● 楽しくGithubを使うtips
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. Gitあるある ● どのブランチに本番環境にデプロイしてい いものを置こう？ o master？ ●ブランチのルール o どういう名前をつけるか o どういう時にブランチを作成するか o どういう時にブランチを削除するか ● 自由にし過ぎると迷うしややこしくなる o ツールあるある
- 13. そういう時に開発フロー ● 開発する時にどういう手順でするとよいみ たいなフレームワークみたいなもの o それに従うと開発のスタイルが綺麗で、ツールの使 い方的な部分での迷いがすくない oGitを使った開発フロー Gitフロー Githubフロー etc…
- 14. Githubフロー ● ブランチ構成 o master：デプロイ可能なもの o作業の説明的な名前のブランチをmasterから作る fix-hogehoge みたいな ● 流れ o ブランチを切ってローカルで開発してリモートに pushする o masterにマージしてもよい！とおもったらPR(pull request)を作成する o レビューを受けてOKになったらPRをmasterブラン チにマージする
- 15. Githubフローをベースに実際の開発例 ● 作業内容はissueを作成して概要を書く ● ブランチ構成 omaster：デプロイ可能なもの o develop：PRを通って開発機で確認するもの o issues/issue番号-作業の内容 という名前のブランチ を作成 ● 流れ o ブランチを切ってローカルで開発してリモートにpushする o masterにマージしてもよい！とおもったらPR(pull request)を作成する o レビューを受けてOKになったらPRをdevelopブラン チにマージする o リリースするタイミングでgit-pr-releaseでdevelop とmasterの差分をチェックしmasterにマージして tagを切っておいてリリース
- 16.
- 17.
- 18. 困るかもしれないこと ● Conflictした＞＜ o 沢山conflictしたら直すのに時間がかかる o衝突して、直しづらい時って... ブランチを切ったのがずいぶん前だったり、変 更が多い場合など 粒度は小さめに ● なんかpushできない o 自分のpushしようとしているブランチに、自分以外 の人が変更を加えていた時など o 変更分を取り込んでからpushする（-f ダメ絶対）
- 19.
- 20. PR（pull request） ● LGTM oLooks good to me わたしゃあんたのコードそれでいいとおもう！ o レビュー時に自分は特に指摘することがない場合と かはLGTMって書くと良い
- 22. LGTM画像を探す ● LGTM画像chrome拡張 o https://chrome.google.com/webstore/detai l/lgtm/oeacdmeoegfagkmiecjjikpfgebmalof ?hl=ja&gl=JP ●lgtm.in o http://www.lgtm.in/
- 23. その他 ● おblameさせていただきます o blameするときに使う o何でこうなってるんだ＞＜ってコードを見つけた時 に、書いた人に聞きたいけどけっして責めてないよ ＞＜みたいなスタンスで使う しょうがなかったかもしれないし... めっちゃ昔のコードかもしれないし...