共同開発 の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• 共同開発 へ行く。
• 共同開発 の差分を削除

[[TODO]]

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

*下位ページ [#a7e6818d]
-[[バグの上げ方]]

*プラットフォーム [#n728a298]
**チケット [#k9d35232]
-Redmine
--人数無制限だけど、自分でサーバを建てないといけない
-2016年現在、Redmineを使わないと人数制限が無かったり、いろいろダメ。

**バージョン管理 [#n5778dfb]
-gitlab
--マージリクができるので、きちんとした開発フローができる。
--人数制限なくレポジトリを変更できるので嬉しい
-github
--プルリクできるんだっけ？


**開発手順 [#a2e05978]
-[[すごくわかりやすい手順>http://d.hatena.ne.jp/hnw/20110528]]

-手順
--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する





*雑多 [#m6d9e64f]
-http://simplearchitect.hatenablog.com/entry/2016/09/24/113117
Gitの正しい運用方法を学びたい

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