これからチーム開発に参加するUIデザイナーがGitHubでの開発フローをまとめた
注意
- (自分用備忘録です)
- (開発初学者です)
前提
- 環境構築が終わっていてローカルホストが立ち上がっている状態
- リモートリポジトリのcloneがローカルに完了している
いつもはじめにやること
0-1.開発が決まったら、作業リボジトリにXDなどのデザインデータのリンクを貼った開発issue を立てる
- issue番号はメモっておき、あとでbranch名に使う
0-2.githubに接続する$ ssh github
0-3.ターミナルでcloneした作業レポジトリ(ローカル)まで移動する
ターミナルでの操作$ cd git$ cd 作業リポジトリ名
準備完了！
フロー
レビュワーがGitHubのPull requestsにrelease noteを切ってるのを確認する
例) master from release/0.0.1
Pull requestsの項目の一番を見る 上のvが最新のrelease note
例) release/0.0.1
リモートのrelease/0.0.1から最新の情報をfetchする
$ git fetch origin release/0.0.1自分が改善するissue/#番号 のbranchを切る
$ git checkout -b issue/#番号今のbranchを確認する
$ git branch今切ったbranchに切り替える
$ git checkout issue/#番号コードを頑張って書き換える
修正したらCommitする(Commit方法は２つある)
commit方法1
Sourcetreeのファイルステージで変更箇所を確認しコメント欄に修正箇所を書き、にコミットボタンを押す
[コミットを直ちにorigin/testプッシュする]を選択すると、プッシュまで行われる。
commit方法2
Sourcetreeのファイルステージで変更箇所を確認し、
$ git commit -m "branch名" -m "コメント"でcommit
9, GitHubにPush$ git push origin branch名でPushする
10, GithubでPull request
自分が作ったbranch を New Pull Requestする
11, PullのURLをSlackに貼ってレビューお願いする！
Pullrequestで気をつけること
- 中規模issueであればプルリクエストは小分けにする
- 一つのissueを自分でタスクを小分けにする
- 小さなタスクissue#1-1をブランチを切り編集しコミット、OKをもらったら、次はまた小さなタスクissue#1-2でプルリクエストするとレビュワーに負担がかからない
- OKをもらったらmergeする
その他
- issueのmilestone項目でフィルタリングすることで同じrelease目標のissueがわかる(リリース権限のある人が設定を行っていたら。)
- ブラウザチェックは ChromeとfirefoxとSafariとか現場で決まったもの
一緒の場所を修正作業してる人が先に変更点をmergeした場合
ローカルを新しい情報に更新する
$ git pull origin release/0.0.1$ merge release/0.0.1マージしようとしてコンフリクトした時にmergetoolで差分を確認する
$ git mergetool
今のmasterブランチの状態と、マージ前の状態とマージしようとしているファイルの状態がわかりやすく表示されるので、差分を編集しマージする。