Home

提案

• コードフォーマットはarco0922さんのものに合わせて事前にメンバーで統一しておいた方がいいと思う．
• 改行とかで編集扱いされるとdiffとった時にわけわからんくなる．

Git

編集の流れ

1. githubページでfork
2. git clone https://..........(fork先)
3. git branch hoge(自分で適当にブランチを名付ける)
4. git checkout hoge
5. ローカル編集
6. git add
7. git commit
8. 機能がまとまってきたら， git push origin branch名
9. githubページでPullrequest （Pullrequestのメッセージは追加した機能でいい）
10. 誰かがreviewしてapproveされたらmergeされる

注意点

• pushする前に，Pullrequestでmergeする先のfork元のブランチが変更されているとconflictが起きてだるいので，変更がある場合はローカルでmergeなりpullなりしてからpushを推奨．
• cloneするときは，fork元かforkした自分のレポジトリをcloneするかでgit remote -v した時のoriginが変わる．
• それに応じてpush先も適宜変えて欲しい（originじゃなくて自分のgithubのusernameにすべきかも）

branch命名規則

• Pullrequestのメッセージと同じで追加したい機能を書いてくれたらいい
• fork元のメインレポジトリは基本的にmasterにmergeしていくが， 複数人で共同編集しながら進めたくて，いちいちpullrequest送るのもだるい時もあると思うので，そういう際にはdevelop-fugaなりfeature-piyoなり，適当につけて直接pushしながら編集していくのもありだとは思う．
• pullrequestをmergeした後は適当な段階でブランチを削除したらいい

commitメッセージのルール

• 基本的にはココに従って書いてくれたらいい
• 英語
• メインで編集したファイルや機能を見出しで書いておくとよりわかりやすい
  • 以下，例
    • [scripts/hoge.js] feat: support safari
    • [mainpage] fix: change header compact to improve operation UI

各種便利コマンド

• git st
  • 変更したファイルとかaddしたものとかわかる
• git diff ファイル名
  • ファイルの変更内容がわかる

間違えてadd, commit, pushした時

• 金沢君か松浦君を頼ってください
• Gitおじさんは疲れました