共同開発

TODO

概要 †

• バージョン管理、プルリク、gitlab、チケットなど
• コードが先。バージョン管理は後。
  • 人はバージョン管理をするためにコードを書いているのではなくてコードを書くためにバージョン管理をしている。
  • Gitを最初から完璧に運用する必要はなくて、「とりあえずひたすらmasterにコミットする」という単純なルールから始めて、なんか問題が発生したら、詳しい人がいじって修正すればいい
  • 最小限のルールで運用せよ

下位ページ †

• バグの上げ方

プラットフォーム †

チケット †

• Redmine
  • 人数無制限だけど、自分でサーバを建てないといけない
• 2016年現在、Redmineを使わないと人数制限が無かったり、いろいろダメ。

バージョン管理 †

• gitlab
  • マージリクができるので、きちんとした開発フローができる。
  • 人数制限なくレポジトリを変更できるので嬉しい
• github
  • プルリクできるんだっけ？

開発手順 †

• すごくわかりやすい手順

• 手順
  • GitHub内部で、https://github.com/octocat/Spoon-Knifeをfork
  • できたforkをローカルにclone

# 取ってくる
git clone git@github.com:hnw/Spoon-Knife.git
cd Spoon-Knife

# masterで作業するとウルトラギルティなので、自分用ブランチを作る
git checkout -b myFeatureSpike

# 作業する
# 作業1
git commit -a -m '作業1'
# 作業2
git commit -a -m '作業2'

# コミットを1つにまとめないと、マージ担当者に怒られるのでまとめる
git checkout myFeatureSpike
git checkout -b myFeature
git rebase -i master

# 作業中にmasterが変わってる可能性があるので、確認する
# 一回だけやる
# git remote add upstream git://github.com/octocat/Spoon-Knife.git
git stash
git checkout master
git pull upstream master # 同期
git checkout myFeatureSpike
git rebase master myFeatureSpike
git push origin master
git push -f origin myFeatureSpike
git checkout myFeatureSpike
git stash pop
# 最後のコミットのpickをsquash = ぺちゃんこにする、にして保存

# myFeatureをgithubにpush
git push origin myFeature

• 最後、GitHubからpull requestする

雑多 †

• http://simplearchitect.hatenablog.com/entry/2016/09/24/113117 Gitの正しい運用方法を学びたい

仕事ではSVNの進化系みたいなの使っていて，やはり人類に優しいのはSVN的なものだと思ってやまない．ブランチ切って数ヶ月開発とかどう考えてもマージ絶対大変だし，細かな単位でマージするならmasterに直接pushでよくない？主にgitのコマンドが非直感的なのが不満ではあるけど． コードレビュー，皆が自分のタスクよりも優先的にやってくれるので時間かかる感覚はないし，間違いを見つけられるだけではなく，知識（バグを減らす書き方とか，C++11ではこう書くのが良いとか，社内の新しいスタイルとか）を共有して議論でき学べる場でもあるのでとても良いですよ