- Git 12©2ch.net
584 ：デフォルトの名無しさん[sage]：2015/06/07(日) 00:12:36.70 ID:5CuOmznL - あとから見てわかるようにコミットを綺麗にしておけ
まとめる とか まとめない とかどちらか一方じゃない
どちらもやって、綺麗にしておけ。
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
144 ：デフォルトの名無しさん[sage]：2015/06/07(日) 02:40:51.60 ID:5CuOmznL - > ちなみにWindows消費者は絶賛ストライキ中。
どこかで大規模なストなんて起きてたっけ？ｗ
皮肉にしても意味不明だし
何がいいたいんだこいつ？
|
- Git 12©2ch.net
587 ：デフォルトの名無しさん[sage]：2015/06/07(日) 02:48:23.33 ID:5CuOmznL - >>585
> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
いないだろｗ
あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。
物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。
コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。
そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。
このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
|
- Git 12©2ch.net
588 ：デフォルトの名無しさん[sage]：2015/06/07(日) 02:52:10.94 ID:5CuOmznL - 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。
俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。
つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね
|
- Git 12©2ch.net
589 ：デフォルトの名無しさん[sage]：2015/06/07(日) 02:54:19.37 ID:5CuOmznL - ということで、何故そうするのか、どんなメリットがあるのかを
しっかりと書いたガイドラインを、俺以外に出すのまってま〜すｗ
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
146 ：デフォルトの名無しさん[sage]：2015/06/07(日) 02:58:05.96 ID:5CuOmznL - それにしてもWindowsの互換性は凄く高いね。
MS-DOS 6.22からWindows 8 Proまで順にアップグレードしていくとどうなるのか？
http://gigazine.net/news/20130605-upgrade-windows-1-0-to-windows-8-pro/
再コンパイルの必要もなく、同じバイナリが動くんだぜ。
|
- Git 12©2ch.net
592 ：デフォルトの名無しさん[sage]：2015/06/07(日) 12:19:13.74 ID:5CuOmznL - >>590
> 545に対して、あなたがどうロンパするかは別に知らないが
論破？ 何故そうするかの理由がないのだから、
まずその理由を言うのが先だろうｗ
|
- Git 12©2ch.net
593 ：デフォルトの名無しさん[sage]：2015/06/07(日) 12:20:45.23 ID:5CuOmznL - >>591
> 全部のコミットをひとつにまとめて周りから怒られなかったなら、
周りの人間がコードを見るということを知らないだけかもしれない。
スキルが低くてソースコード管理ツールすら知らない人もいるのだから。
だからそれは全く参考にならないな。
理由だよ理由。
俺は何故そうするかの理由を書いた。
この俺を論破する理由をかける奴はいないのか？ｗ
|
- Git 12©2ch.net
598 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:12:32.75 ID:5CuOmznL - >>595
> 結局は>>585の言ったとおりになるという、悲しい現実
大丈夫。
俺が言った「ガイドラインを言う時は理由も明確書くこと」
のおかげで、今のところガイドラインは俺が言った一つしかでてない。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
1 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:23:08.66 ID:5CuOmznL - gitのコミットをより意味があるようにするためのガイドライン作成スレです。
なぜコミットはあるのか？ コミットが残っていることで
何の役に立つのかをよく考えましょう。
そしてガイドラインを言う時は、ちゃんと理由も書きましょう。
上司が言ったから絶対なんだ！今までそれでやってきたからそれでいいんだ！
みたいなのは理由ではありません。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
2 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:23:53.40 ID:5CuOmznL - 少しだけガイドライン考えてみた
・一つのコミットで複数の修正を行わない
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
・一つの修正を複数のコミットにわけない（分かれていればまとめる）
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
例外 リリースしてしまったコミットはまとめることは出来ない。
いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。
と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
3 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:24:21.46 ID:5CuOmznL - >>585
> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
いないだろｗ
あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。
物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。
コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。
そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。
このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
4 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:24:51.14 ID:5CuOmznL - 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。
俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。
つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね
|
- Git 12©2ch.net
602 ：デフォルトの名無しさん[sage]：2015/06/07(日) 13:26:15.60 ID:5CuOmznL - >>600
スレ立てておいたよ。
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
>>601
> 誰も関わりたくないんだから
関わりたくないのが理由っていうのはおかしな話だな（笑）
言い返せない時に汎用的に使えそうな言い訳だ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
9 ：デフォルトの名無しさん[sage]：2015/06/07(日) 16:22:05.50 ID:5CuOmznL - >>8
Gitの適切な運用方法を語るスレだよ。
「Gitをよりよく使うための運用ガイドライン」にすればよかったかな。
Gitに問題があるって話じゃない。
Gitのコマンド体系はもう少し改良の余地があるとは思うが
機能自体には問題ないよ。
Gitは運用方法（フロー）をがっちり決めているわけじゃなくて、
git-flowとかgithub-flowとか細かいフローがあるが、
それでも基本的な考え方というのはある。
使いにくいと思ったら、使い方が悪いと考えた方がいい。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
10 ：デフォルトの名無しさん[sage]：2015/06/07(日) 16:23:04.79 ID:5CuOmznL - >>5 >>6
すれ違い。そういう雑談はこっち。
Git 12(c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1427085313/
ここはgit-flowやgithub-flowと言った
gitを使った運用方法を語るスレ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
12 ：デフォルトの名無しさん[sage]：2015/06/07(日) 16:33:20.22 ID:5CuOmznL - ちょっと出かけなきゃならなかったからとりあえずスレを立てたが、
テンプレ作りたいね。Pro Gitは当然として各運用フローのリンク
公式がよくわかんないんだけどこれでいいんだろうか？
・Pro Git
英語 https://git-scm.com/book/en/v2
日本語 https://git-scm.com/book/ja/v1
・git-flow
http://nvie.com/posts/a-successful-git-branching-model/
・github-flow
http://scottchacon.com/2011/08/31/github-flow.html
・gitlab-flow
https://about.gitlab.com/2014/09/29/gitlab-flow/
Qiitaのリンクを貼るのはあまりすきじゃないんだが、簡単にまとまってたので
テンプレに入れるかどうかは別として、とりあえず
Git利用時のフローはどれを使うか
http://qiita.com/tkhm/items/cc7855d32d640687b43c
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
13 ：デフォルトの名無しさん[sage]：2015/06/07(日) 16:34:58.87 ID:5CuOmznL - そしてスレ盛るために転載（笑）
Git Flow
・使用するブランチ
・master マイルストーン用のブランチ
・develop 開発用のブランチ
・feature 機能追加用
・(hot)fix 不具合修正用
・release リリース準備用
・Git Flowの良さ
・fix(不具合)の数が一目瞭然
・masterを見ればマイルストーンの遷移が一目瞭然
・参考：git-flowとプロジェクトの運営
・Git Flowのまずさ
・ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない
・hotfixブランチをdevelop, master共に反映しなければならない点が面倒
・参考：【翻訳】GitLab flowから学ぶワークフローの実践内、Git-flowとその問題点
・参考：GitLab Flow
・GitHub Flowと比べると
・ブランチ間の移動や、複数ブランチへのマージの発生量が多くなりがち
・一定期間終了した後に全ブランチの遷移などを俯瞰すると開発の様子がわかりやすくて良いかもしれない
・一方で、開発中は開発者の負担が少し多くなるかもしれない
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
14 ：デフォルトの名無しさん[sage]：2015/06/07(日) 16:35:55.49 ID:5CuOmznL - GitHub Flow
・使用するブランチ
・master 開発用のブランチ、masterはテスト済で本番環境へのデプロイ可能
・topic 機能追加用/不具合修正用のブランチ
・Git Flow、GitLab Flowと比べた特徴的な点
・masterは常にデプロイ可能という前提
・リリースはmaster更新の都度頻繁に、といったイメージ
・参考：GitHub Flow
・参考：GitLab7.1.1でGitHub Flowを実践してみた！
GitLab Flow
・使用するブランチ
・master 開発用のブランチ
・topic 機能追加用/不具合修正用のブランチ
・production テスト済で本番環境へのデプロイ可能なブランチ(自動テストの対象にしたりする)
・release リリース準備用
・GitLab Flowでのfix(不具合修正)の扱い
・masterから修正用のトピックブランチを切る
・修正内容を実装後、Merge Request(Pull Request)
・masterにマージ(トピックブランチは削除)
・cherry-pickでfix部分のみをreleaseへ反映
|
- Git 12©2ch.net
606 ：デフォルトの名無しさん[sage]：2015/06/07(日) 18:26:22.23 ID:5CuOmznL - いるいるw
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
18 ：デフォルトの名無しさん[sage]：2015/06/07(日) 19:31:57.73 ID:5CuOmznL - >>15
> >>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・
それは当然分けてコミットするべきだよ。
実際の開発でもよくある話で、スペースでインデントするという
規約なのに間違えてタブになっていたりね。
そういうのがバグフィックスに含まれていると、本当にしたかった
バグフィックスのコードは何なのかわからなくなってしまう。
別コミットにした上で、バグフィックスとは分けてマージしてしまうのがいい。
本当に「ちょっとした修正」であればバグフィックスと違って、
レビューはほぼ不要でマージできるはずだからね。
で、聞きたいのはコミットを分割する方法？
Pro gitにも書いてあるけどこんな感じだよ。
コミットの分割
https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88#コミットの分割
1. git rebase -i で edit を指定して修正したいコミットで止める
2. git reset HEAD^ で修正したいコミットを未コミット状態に戻す
3. ちょっとした修正だけコミットする（git add -p などを使って）
4. バグフィックスをコミットする
5. git rebase --continueでrebaseを完了させる
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
19 ：デフォルトの名無しさん[sage]：2015/06/07(日) 19:32:23.65 ID:5CuOmznL - >>16
分かったから、理由ｗ 理由ｗ
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
20 ：デフォルトの名無しさん[sage]：2015/06/07(日) 20:02:06.44 ID:5CuOmznL - >>17
> svnみたく基本master直コミットで、
いやいやｗ svnでもmasterに直コミットなんかしないってｗ
（個人プロジェクトとか超小規模は除くけど）
まだsvn使ってる有名プロジェクトって何があるんだろう？
例としてtracを見つけてきたけどマージのほうが多いでしょ？
http://trac.edgewall.org/log/trunk
> まだ機能がロクにできあがってない完成前の作成中の段階って
疑問なんだけど、その作成中の段階のソースコードってどこにあるの？
まさかローカルのPCにあって、他の人はだれも見れない状態？
その機能を作るのに1日かからない程度の小さい修正なら、他の人が見れない状態でも
たいしてリスク無いと思うけど、数日とか数週間かかるようなものが
他の人が見れなかったらリスク高くなるよね？
作成に数日かかった大作を見せられて、それがクソコードだったとき、全部やり直しになってしまう。
だから少なくとも一日に一回はコードを他の人が見れるようにしないといけない。
そのコードは作成中なのだからmasterに入るわけがない。
ではどこに？ → その答えがブランチでしょ？
> 完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど
ということで「完成前の作成中の段階」と呼べる状態があるのなら、それがブランチになるんだよ。
|
- Git 12©2ch.net
609 ：デフォルトの名無しさん[sage]：2015/06/07(日) 20:06:44.60 ID:5CuOmznL - >>608
はい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。
みなさんも協力してくださいね。
逆に運用以外の雑多な内容はこっちに移動しますよ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
22 ：デフォルトの名無しさん[sage]：2015/06/07(日) 21:04:30.29 ID:5CuOmznL - >>21
> 1個のブランチにみんなで直接コミットしまくったほうがよくない？とも思ってどうしてるのかなあと
（トピック）ブランチを作らないって話をしているんだよね？
1個のブランチにみんなで直接コミットしたら、問題が解決するのはなぜ？
みんなで仕事をしているのであれば、並行で作業が進む。
(1) -> (2) -> (3) ときて、二人の人が (3) から初めて、(4a) と (4b) というコミットを作る。
この時、早く完成した人（仮に4aとする）だけが、(4)にできる。(4b)はそのままコミットできない。
ブランチを作らないならば、(4b)は(4)を元にrebaseしてからじゃないとコミットできないし、
(4b)の人が(4a)のコードが必要ならば、やっぱりrebaseが必要。
で、ここでブランチを作るならば、
(1) -> (2) -> (3)ときて、二人の人が (3) から初めて、(4a) と (4b) というブランチを作る。
この時、早く完成した人（仮に4aとする）だけが、(4)としてマージできる。
(4b)はそのままじゃマージできないから、rebaseしてからマージする。
気づいた？ やっていることは全く同じなんだよ。
違いがあるのはブランチを作れば作業途中であってもpushして
今開発中のブランチコードを他の人に見せることが可能。
(4b)は(4a)のコードが必要なのだから、見たいはずだよね？
でもブランチを作らなければそれができない。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
23 ：デフォルトの名無しさん[sage]：2015/06/07(日) 21:11:03.05 ID:5CuOmznL - >>21
で、なんで君が「1個のブランチにみんなで直接コミットしまくったほうがよくない？」と
思っているのか、その理由はわかってる。
直接コミットをすれば、すぐに他人のコードが「1個のブランチ」に取り込まれて
他の人はそれをすぐに利用できるからいい。と思ってるはず。
逆に言えば、（トピック）ブランチを切っていれば、そのブランチが
「1個のブランチ」に取り込まれるまで時間がかかる。
それぞれの開発者が、それぞれのブランチをずっと成長させていき、
その他人のブランチを、時々取り込まないといけなくなる。と思っているはず。
それはトピックブランチの扱いを間違っているだけだよ。
トピックブランチでやる内容は凄く小さい。
トピックブランチは頻繁に「1個のブランチ」にマージされる。
みんなが直接コミットしまくるのと同じぐらいの頻度で
「1個のブランチ」にマージされるんだよ。
ちなみに「1個のブランチ」がmasterであるか、次期リリース用ブランチであるかは
gitフローなのかgithubフローなのかによって変わる。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
24 ：デフォルトの名無しさん[sage]：2015/06/07(日) 21:19:06.14 ID:5CuOmznL - >>21
君が抱えている問題を解決するヒントを一つ提示しよう。
ある機能を作ることになった。その機能のために1つのブランチを作る。
（ここまではsubversionでも一緒だろう）
そしてそのブランチを作っている間に、ある便利な関数を作った。
その便利な関数は、他の人も使う。
のであれば、君が作っているある機能の完成を待たずして、その便利な関数だけをマージする。
出来上がった所から取り出して、早くマージしてしまえばいいんだよ。
（こういうことがsubversionではやりにくい）
この発想ができるようになれば、中途半端なコードをマージすることもないし、
みんなで直接コミットしまくるのと同じように頻繁にコミットできて
それをするために、自分の作業履歴（コミット）を自由に入れ替えて
歴史を修正することができるgitの重要さが理解できるようになる。
|