Git 9
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2014/04/12(土) 13:22:20.98ID:s4x1CSLNGit - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
0174デフォルトの名無しさん
2014/04/26(土) 19:32:08.93ID:ztOmzoR+0175デフォルトの名無しさん
2014/04/26(土) 19:33:56.04ID:Z8XCebgD別に git はゴミ！とか貶してるわけじゃないのに
0176デフォルトの名無しさん
2014/04/26(土) 19:34:13.93ID:Vv5x70uz俺はそんなことしてないけど
0177デフォルトの名無しさん
2014/04/26(土) 19:35:28.56ID:ztOmzoR+ブランチ作らないって言ってるんでしょうかね
みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。
実はブランチ作れないの間違いでしょうかねｗ
面白いですねｗｗｗ
0178デフォルトの名無しさん
2014/04/26(土) 19:36:05.09ID:ztOmzoR+ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
0179デフォルトの名無しさん
2014/04/26(土) 19:39:59.70ID:iVzDEpppお前がブランチ作らないとかどうでもいいわ。
バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。
それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
0180デフォルトの名無しさん
2014/04/26(土) 19:44:23.08ID:Vv5x70uz個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
0181デフォルトの名無しさん
2014/04/26(土) 19:46:55.41ID:koYBfWi3git initするだけでもう使えるよ。
subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
0182デフォルトの名無しさん
2014/04/26(土) 19:51:45.97ID:Z8XCebgD0183デフォルトの名無しさん
2014/04/26(土) 19:54:06.41ID:HaseiyYq別に面倒な方法だってわかってやってるなら問題ない。
面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。
gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
0184デフォルトの名無しさん
2014/04/26(土) 19:54:51.87ID:Vv5x70uzなんでリポジトリを別の場所に置いたらダメなの？
特にマシン間で設定フィルを共有する場合、中央リポジトリが必要になるのは同じなんだから
0185デフォルトの名無しさん
2014/04/26(土) 19:56:09.41ID:Z8XCebgD0186デフォルトの名無しさん
2014/04/26(土) 19:56:42.73ID:HaseiyYq> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。
gitでも当然のようにリポジトリを別の場所におけるわｗ
だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。
少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
0187デフォルトの名無しさん
2014/04/26(土) 19:59:08.48ID:Z8XCebgDこれは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
0188デフォルトの名無しさん
2014/04/26(土) 20:01:00.30ID:HaseiyYqじゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。
お前ん中ではそうなんだろうなｗ
お前ん中では、設定ファイルの管理にぐらいしか使わないんだろうな
0189デフォルトの名無しさん
2014/04/26(土) 20:14:52.93ID:7bCdF05U（俺にとっては）Subversionの方が簡単
俺にとってはって、君、Subversionを何に使ってるの？
設定ファイルの管理だけど？
ブランチは使わない！
でもブランチやタグを使うと面倒だよね？
だから、俺はブランチは使わない！
ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。
gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！
いや、同等って、それ簡単ということになってないじゃん。
0190デフォルトの名無しさん
2014/04/26(土) 20:38:24.09ID:knmAOh4aドットファイルをブランチに分ける事は基本ないわな
0191デフォルトの名無しさん
2014/04/26(土) 20:42:18.34ID:7YL+swb1俺はブランチを切りまくって、そいつらをマージしたものをマシン毎につかってるな。
いつのまにか47もブランチできてたわ。
0192デフォルトの名無しさん
2014/04/26(土) 22:24:36.07ID:jBTvJ1OX最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合
0193デフォルトの名無しさん
2014/04/26(土) 23:35:52.72ID:pkQNyj+Nたとえば
$ git log --color=never --all --graph --pretty="[%h] %d %s"
* [6a1c481] (HEAD, master) 2
* [523984e] (branch2) branch2-2
* [6554768] branch2-1
| * [05c389f] (branch1) branch1-2
| * [6b85c6d] branch1-1
|/
* [9d47912] 1
ここから、 branch1をFFなるように取り込もうとしたら
$ git rebase --onto master 3829497 branch1 として 分岐なくしてからマージしない？
それとも履歴にはこだわらず、 rebaseで1世代だけにしてからcherry-pickするのが普通？
0194デフォルトの名無しさん
2014/04/26(土) 23:37:58.13ID:pkQNyj+N$ git rebase --onto master 9d47912 branch1
の間違い、 行数削ったときに直すのわすれてた
0195デフォルトの名無しさん
2014/04/26(土) 23:46:42.24ID:7YL+swb10196デフォルトの名無しさん
2014/04/26(土) 23:47:26.43ID:7YL+swb1あと、普通は
git rebase master branch1
で済む。
0197デフォルトの名無しさん
2014/04/26(土) 23:49:50.02ID:DhTsVAJ/0198デフォルトの名無しさん
2014/04/27(日) 01:10:15.13ID:TcUJdg0lその通りだね。
やっぱり無駄なことしてるじゃんｗ
onto使う必要がない所でonto使ってた。
0199デフォルトの名無しさん
2014/04/27(日) 05:35:56.46ID:/n7QikUKただの一度もしたことねえわ
0200デフォルトの名無しさん
2014/04/27(日) 06:08:30.59ID:TcUJdg0l0201デフォルトの名無しさん
2014/04/27(日) 10:01:09.95ID:YIeV8hDmなくても平気なのかー、単純にrebaseするだけじゃダメな時あったんだけどなぁ、まっいっか。
FFこだわるのは、FF縛りがあるから。
0202デフォルトの名無しさん
2014/04/27(日) 10:13:05.46ID:+jGSbN4U0203デフォルトの名無しさん
2014/04/27(日) 14:15:59.24ID:ijMC55vL0204デフォルトの名無しさん
2014/04/27(日) 16:48:41.84ID:/n7QikUK0205デフォルトの名無しさん
2014/04/27(日) 16:52:16.11ID:s0HPULD5リモートから取り込んだコミットを
ローカルで改変してたりしないか？
開発用の修正を間に挟んだりとか。
0206デフォルトの名無しさん
2014/04/27(日) 20:05:48.91ID:0q81XbwGそれでもFFにならないわけはない。
0207デフォルトの名無しさん
2014/04/27(日) 20:42:56.75ID:RalmXzvw>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚 弘記
>http://www.amazon.co.jp/gp/product/477416366X/
この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。
0208デフォルトの名無しさん
2014/04/27(日) 20:56:58.74ID:37jfUrsD0209デフォルトの名無しさん
2014/04/27(日) 21:34:00.25ID:FuM1UcuM> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。
0210デフォルトの名無しさん
2014/04/27(日) 21:39:02.03ID:FuM1UcuM> FFこだわるのは、FF縛りがあるから。
何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。
0211デフォルトの名無しさん
2014/04/27(日) 21:46:21.84ID:0q81XbwG0212デフォルトの名無しさん
2014/04/27(日) 22:46:45.69ID:y1TCx0zf0213デフォルトの名無しさん
2014/04/28(月) 01:24:17.91ID:r745xiPh0214デフォルトの名無しさん
2014/04/28(月) 05:49:30.90ID:G/O2/oE+手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ
0215デフォルトの名無しさん
2014/04/28(月) 06:17:16.50ID:SIdeIE1K0216デフォルトの名無しさん
2014/04/28(月) 09:59:35.16ID:ES7XWIWlgithubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便
0217デフォルトの名無しさん
2014/04/28(月) 12:04:38.80ID:UImZVLxS言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。
0218デフォルトの名無しさん
2014/04/28(月) 12:26:41.94ID:ES7XWIWl0219デフォルトの名無しさん
2014/04/28(月) 12:27:37.63ID:ES7XWIWl0220デフォルトの名無しさん
2014/04/28(月) 13:13:07.74ID:DVYrPedv自分の場合は既にsimpleに設定してたし
git addでパス省略ってやらないし影響なさげ
でも暫くは移行しない
0221デフォルトの名無しさん
2014/04/29(火) 03:34:15.62ID:yOn60HCqFFは、利点がーというよりも、うちはリリースの終わったbranch削除しちゃうので一直線にまとまっていないと、都合悪いだけかな？。
btanchは開発工程の作業場所としてわりきってる。
0222デフォルトの名無しさん
2014/04/29(火) 04:05:17.29ID:5g+Rsf3hFFじゃない状態でブランチマージしてから、そのブランチを削除すると何が問題になるのですか？
もしかして削除したランチに属していたコミットが消えちゃうのですか？
0223デフォルトの名無しさん
2014/04/29(火) 04:10:14.41ID:jiz/CQ6qどういうふうに都合わるいのか詳しく頼む。
mergeコミットが残ってたほうがブランチの情報が残るという認識なんだけど。
0224デフォルトの名無しさん
2014/04/29(火) 09:19:49.77ID:wf66nSBFrebaseなんてGOTOと同じくらいいらない
0225デフォルトの名無しさん
2014/04/29(火) 10:11:12.30ID:gWfSfq0v0226デフォルトの名無しさん
2014/04/29(火) 10:21:10.13ID:fjfML7VOコミッターが何をしたのか把握できないだろう
0227デフォルトの名無しさん
2014/04/29(火) 10:22:25.29ID:fjfML7VOrebaseを使うのは下手くそが使うコマンド
0228デフォルトの名無しさん
2014/04/29(火) 10:41:22.64ID:jiz/CQ6q俺が気にしてるのは rebase && FF マージね。
master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
FF merge するってやり方のこと。これをやりたくなる意味がわからない。
他の目的のrebase自体は問題ないと思ってる。
0229デフォルトの名無しさん
2014/04/29(火) 10:50:31.16ID:2NEMUWta意味がないならrebaseしてからのほうがログが読みやすい
0230デフォルトの名無しさん
2014/04/29(火) 10:58:37.39ID:fjfML7VO余計なことはするな
0231デフォルトの名無しさん
2014/04/29(火) 11:14:43.54ID:jiz/CQ6q> masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
どういう場合にベースを意味がある(または意味がない)くわしくたのむ
俺にとって重要なのはブランチの目的とその目的に向かってコミットがどう積み重ねられたのかであって、
ベースがどこかは明示的にはあんまり気にしないんだが。
FFマージじゃなければ統合ブランチの履歴を log --first-parent で要約できるのと、
マージコミットのログなどに表示される親コミット2つ使って
git log deadbeaf..cafebabe
のようにトピックのログだけ簡単に取り出せるのが便利なのに。
後者は内部で merge-base 使ってるのでベースに意味があるのは確かだが、
だとすれば常に(俺にとっては)意味があると言える。
0232デフォルトの名無しさん
2014/04/29(火) 11:21:26.26ID:LqsKRBzGはたして捏造された記録に意味があるのか
0233デフォルトの名無しさん
2014/04/29(火) 11:33:05.72ID:EYu9TTokコミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。
コミットして1分後に気づいたタイポの修正なんか
修正の履歴として残す価値はないはない。
レビューを誰かに依頼して見つかったバグの修正なんか
修正の履歴として残す必要はない。
このコミットで何を修正するのかを明確に記録するには
rebaseは必須の機能。rebaseの機能なしで同じことを
やろうとしたら大変すぎて断念するレベル。
反論できる？
0234デフォルトの名無しさん
2014/04/29(火) 11:38:42.10ID:LqsKRBzG不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね
0235デフォルトの名無しさん
2014/04/29(火) 11:40:07.95ID:LqsKRBzGだからそういうのはタグで管理しろ
0236デフォルトの名無しさん
2014/04/29(火) 11:49:24.38ID:EYu9TTok> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。
rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
masterへのmergeで起きたコンフリクトをその場で修正すると
バグを入れる可能性が高くなる。
コンフリクトが起きなければ問題ないが、いざマージしようと思った時に
コンフリクトが起きたら、修正する必要がある。
masterへの追尾が遅れれば遅れるほど、コンフリクトが起きる可能性も高くなるし、
コンフリクトが起きた時の修正も大変になる。だからこまめにmasterへrebaseしておく。
その一環として、最後にrebaseしておくだけのこと。
そうすればレビューアーも安心してレビューを行える。
もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
0237デフォルトの名無しさん
2014/04/29(火) 11:51:08.54ID:EYu9TTokどうタグを使うっていうんだ？
そもそもタグの使い方が間違っている。
タグはある状態に対してつけるもの。
タグがついたらコードフリーズした状態で
それ移行変更してはいけない。
0238デフォルトの名無しさん
2014/04/29(火) 11:54:15.32ID:EYu9TTokgitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。
0239デフォルトの名無しさん
2014/04/29(火) 11:57:18.99ID:jiz/CQ6qやはりそっちの議論にいってしまうか。
いや、本当に全てのrebaseが有害と言ってるヤツもいるのかもしれんけども。
・rebase && FFマージの話
・歴史修正ツールとしてのrebaseの良し悪し
これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。
0240デフォルトの名無しさん
2014/04/29(火) 11:59:42.78ID:EYu9TTokじゃあピンポイントで聞くわ。
開発者と、masterへマージ（レビュー）する人が別々の人だとする。
masterへマージする時にコンフリクトが起きました。
この時どうしますか？
1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。
0241デフォルトの名無しさん
2014/04/29(火) 12:25:05.93ID:jiz/CQ6qおぉ、そういう主張か。 >>239 はとりあえず忘れてくれ。
> rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
> masterへのmergeで起きたコンフリクトをその場で修正すると
> バグを入れる可能性が高くなる。
主題から少しはなれるがここはおかしい。
masterにマージする人間とtopicを作ってる人間が別人ならその場で修正なんかせず、topic 作ってるやつに一旦 merge か rebase させるべき。
topic 側から master をマージした直後なら、その topic を master にマージするときはコンフリクトは起きない。このときは master 側からは no-ff でマージすべきだが、topic作ってくれたやつがmergeした方向による。
もちろん topic 作ってる人間は rebase してもいい。たぶん君が取ってる戦略はこっちなんだろう。
ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
もう一度言うが、俺が気にしてるのは rebase && FFマージだからね？
rebase後にno-ffでマージしてるなら大きな疑問はないよ。(topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
> レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
やっぱ他人なんだよな。mergeする場合はコンフリクトの解消はmerge/rebaseで書いたやつにさせるように運用するのがお勧めだよ。
0242デフォルトの名無しさん
2014/04/29(火) 12:27:35.28ID:jiz/CQ6q> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。
どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。
0243デフォルトの名無しさん
2014/04/29(火) 12:30:47.09ID:EYu9TTokgitlabでmasterにマージするときは、
ウェブの管理画面からボタンを押すだけ
その時勝手にno-ffされる。
というか、ウェブの管理画面からはno-ffでしかマージできない。
> (topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
コンフリクト起きないならrebaseもすぐに終わる。1コマンド入力してあとは自動処理。
コンフリクトするなら、結局どこかで作業するのだから大差ない。
コンフリクトするのかな〜？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。
0244デフォルトの名無しさん
2014/04/29(火) 12:35:19.57ID:jiz/CQ6q> というか、ウェブの管理画面からはno-ffでしかマージできない。
rebase && FF派じゃねーのかよ (´・ω・`)
0245デフォルトの名無しさん
2014/04/29(火) 12:38:23.48ID:EYu9TTokrebaseのあとはどっちでもいい派。
rebaseすることに異議を唱えてるんじゃないの？
0246デフォルトの名無しさん
2014/04/29(火) 13:06:53.85ID:jiz/CQ6qちがうよ、rebaseはなくてはならない重要なツール。
俺が疑問に思ってるのは rebase && FF だよ。
理由はrebase && FF してしまうと
1 log --first-parent で要約をとれなくなる
2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
から。詳しくは上の方を見てくれ。
0247デフォルトの名無しさん
2014/04/29(火) 13:21:06.01ID:GKmjQvWPプロジェクトの性質に合わせて運用するべきで
他人がどうこう言うもんじゃないと思うが
FF派にとっては1と2は大して重要じゃないんでしょ
どうせログなんて参考にしかならんのだから
コードを追うならFFの方が都合がいい場合もあろう
0248デフォルトの名無しさん
2014/04/29(火) 13:47:07.80ID:+oyspTjVmerge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
http://blog.layer8.sh/ja/2013/04/08/best-git-commands-for-the-lonely-programmer/ (ちょっと違う例だけど)
こういうのって、ケースバイケースでしかないのに、mergeは悪！rebaseは正義！みたいに思っていそうで、
しかもこういうのを読んでmergeやrebaseの利点欠点について理解してない人たちがまたmergeは悪！rebaseは正義！と思い込んでしまって、害しかないと思うんだよな。
pullしてマージが発生したら「これでは自分が持っていたコミットの方が正統としているようなものです。origin へ push したのは a と b の方が先なのに…。」とか意味不明もいいとこ。
0249デフォルトの名無しさん
2014/04/29(火) 14:26:17.37ID:jiz/CQ6q> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？
> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？
一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。
「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。
ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
0250デフォルトの名無しさん
2014/04/29(火) 14:28:32.84ID:jobIXRFq0251デフォルトの名無しさん
2014/04/29(火) 14:30:18.99ID:GcKmP5Zr0252デフォルトの名無しさん
2014/04/29(火) 14:58:20.39ID:jiz/CQ6q「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。
だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識
もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
0253デフォルトの名無しさん
2014/04/29(火) 15:08:09.46ID:jiz/CQ6qhttp://powerful-code.com/blog/2012/11/merge-or-rebase/
mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。
rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
0254デフォルトの名無しさん
2014/04/29(火) 15:16:46.84ID:jiz/CQ6qかなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。
例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。
これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
0255デフォルトの名無しさん
2014/04/29(火) 15:25:33.99ID:GKmjQvWP> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが
>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの
考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
0256デフォルトの名無しさん
2014/04/29(火) 15:48:55.09ID:+oyspTjVrebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
0257デフォルトの名無しさん
2014/04/29(火) 15:56:19.89ID:jiz/CQ6qそういうことなの？
トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。
rebase && FFはトピックブランチ使わないってことなのかね。
0258デフォルトの名無しさん
2014/04/29(火) 16:01:07.06ID:jiz/CQ6qなるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、
って感じかな。
感謝感謝。
0259デフォルトの名無しさん
2014/04/29(火) 16:15:23.14ID:GKmjQvWPFFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの
まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
0260デフォルトの名無しさん
2014/04/29(火) 16:17:02.13ID:EYu9TTok問題なのは「FF only の masterマージ」だろう？
rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。
さらに言えば、masterへのマージ以外には
当てはまらないだろう？
0261デフォルトの名無しさん
2014/04/29(火) 16:19:03.64ID:EYu9TTok有名なライブラリ例を上げておく。
https://github.com/lodash/lodash/commits/master
0262デフォルトの名無しさん
2014/04/29(火) 16:21:51.52ID:EYu9TTok> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
0263デフォルトの名無しさん
2014/04/29(火) 16:26:11.71ID:jiz/CQ6qいや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
0264デフォルトの名無しさん
2014/04/29(火) 16:29:31.48ID:jiz/CQ6q> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
0265デフォルトの名無しさん
2014/04/29(火) 16:30:46.56ID:+oyspTjVブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
0266デフォルトの名無しさん
2014/04/29(火) 16:30:55.69ID:jiz/CQ6q> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> https://github.com/lodash/lodash/commits/master
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
0267デフォルトの名無しさん
2014/04/29(火) 16:31:51.96ID:EYu9TTok> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
0268デフォルトの名無しさん
2014/04/29(火) 16:40:59.32ID:jiz/CQ6q> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
0269デフォルトの名無しさん
2014/04/29(火) 16:43:19.24ID:EYu9TTok> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
0270デフォルトの名無しさん
2014/04/29(火) 16:51:05.11ID:jiz/CQ6q> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
0271デフォルトの名無しさん
2014/04/29(火) 16:53:09.53ID:EYu9TTok説明してるじゃねーか。
ライブラリの作者じゃないんだから
作者の本当の考えはわからん。
それは当たり前。
それとは別に推測で
ちゃんと説明してる。
0272デフォルトの名無しさん
2014/04/29(火) 16:59:55.32ID:EYu9TTok> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
0273デフォルトの名無しさん
2014/04/29(火) 17:07:40.73ID:EYu9TTok「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
■ このスレッドは過去ログ倉庫に格納されています