Git 9

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 06/21 15:56 / Filesize : 225 KB / Number-of Response : 900
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 9

1 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:22:20.98 ID:s4x1CSLN]: ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
git-scm.com/

◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/

◆前スレ
Git 8
toro.2ch.net/test/read.cgi/tech/1389701817/
173 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:30:26.82 ID:Vv5x70uz]: いや、初めからブランチ作らないって言ってるし、.my.cnfでも.pgsqlでもなんでもいいが、ブランチ切って修正を分ける必要性を全く感じない
174 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:32:08.93 ID:ztOmzoR+]: ※>>173 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうｗｗｗ
175 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:33:56.04 ID:Z8XCebgD]: なんでこの人こんなに発狂してるの・・・
別に git はゴミ！とか貶してるわけじゃないのに
176 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:34:13.93 ID:Vv5x70uz]: 世の中には.ssh/configをテストファーストで日々更新してる人もいるのかもしれない、そういう人にはリリースと開発でブランチを分けてるのかもしれない
俺はそんなことしてないけど
177 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:35:28.56 ID:ztOmzoR+]: subversion使っている人は、みんな
ブランチ作らないって言ってるんでしょうかね

みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。

実はブランチ作れないの間違いでしょうかねｗ

面白いですねｗｗｗ
178 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:36:05.09 ID:ztOmzoR+]: subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
179 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:39:59.70 ID:iVzDEppp]: >>173
お前がブランチ作らないとかどうでもいいわ。

バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。

それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
180 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:44:23.08 ID:Vv5x70uz]: いや、ホームディレクトリ以下の設定ファイルという前提なんだけど
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
181 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:46:55.41 ID:koYBfWi3]: ホームディレクトリ以下をgitで管理しようと思うのならば、
git initするだけでもう使えるよ。

subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
182 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:51:45.97 ID:Z8XCebgD]: なんか話を一般化して叩いてるけどホームディレクトリ内のファイルの管理ぐらい好きにやらせたれや・・・
183 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:54:06.41 ID:HaseiyYq]: 自由にやっていいよ。面倒な方法だって言っているだけだから
別に面倒な方法だってわかってやってるなら問題ない。

面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。

gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
184 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:54:51.87 ID:Vv5x70uz]: >>181
なんでリポジトリを別の場所に置いたらダメなの？
特にマシン間で設定フィルを共有する場合、中央リポジトリが必要になるのは同じなんだから
185 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:56:09.41 ID:Z8XCebgD]: まあそこら辺は git スレでわざわざ頑張る内容ではないだろな
186 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:56:42.73 ID:HaseiyYq]: >>184
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。

gitでも当然のようにリポジトリを別の場所におけるわｗ

だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。

少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
187 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:59:08.48 ID:Z8XCebgD]: >そういう使い方するとGitよりSubversionが使いやすい
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
188 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 20:01:00.30 ID:HaseiyYq]: >>187
じゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。

お前ん中ではそうなんだろうなｗ
お前ん中では、設定ファイルの管理にぐらいしか使わないんだろうな
189 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 20:14:52.93 ID:7bCdF05U]: まとめ

（俺にとっては）Subversionの方が簡単

俺にとってはって、君、Subversionを何に使ってるの？

設定ファイルの管理だけど？
ブランチは使わない！

でもブランチやタグを使うと面倒だよね？

だから、俺はブランチは使わない！

ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。

gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！

いや、同等って、それ簡単ということになってないじゃん。
190 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 20:38:24.09 ID:knmAOh4a]: ブランチ使わないって前提の話で、subversionはブランチ作るのが面倒とか的外れな反論しておかしくなった
ドットファイルをブランチに分ける事は基本ないわな
191 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 20:42:18.34 ID:7YL+swb1]: >>190
俺はブランチを切りまくって、そいつらをマージしたものをマシン毎につかってるな。
いつのまにか47もブランチできてたわ。
192 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 22:24:36.07 ID:jBTvJ1OX]: Unix系のツールの設定ファイルとか複数の環境で使いまわすことが普通だし
最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合
193 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 23:35:52.72 ID:pkQNyj+N]: >>148,149
たとえば
$ 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するのが普通？
194 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 23:37:58.13 ID:pkQNyj+N]: >>193
$ git rebase --onto master 9d47912 branch1
の間違い、行数削ったときに直すのわすれてた
195 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 23:46:42.24 ID:7YL+swb1]: だからなんでFFに拘るんだよ
196 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 23:47:26.43 ID:7YL+swb1]: >>193
あと、普通は
git rebase master branch1
で済む。
197 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 23:49:50.02 ID:DhTsVAJ/]: FFはCoolだかｒ
198 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 01:10:15.13 ID:TcUJdg0l]: >>196
その通りだね。

やっぱり無駄なことしてるじゃんｗ
onto使う必要がない所でonto使ってた。
199 名前：デフォルトの名無しさん [2014/04/27(日) 05:35:56.46 ID:/n7QikUK]: svnでわざわざtrunk、branches、tagsディレクトリを作ってコミットなんて面倒なこと
ただの一度もしたことねえわ
200 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 06:08:30.59 ID:TcUJdg0l]: まあ、そういう変な人もいる。
201 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 10:01:09.95 ID:YIeV8hDm]: >>198
なくても平気なのかー、単純にrebaseするだけじゃダメな時あったんだけどなぁ、まっいっか。
FFこだわるのは、FF縛りがあるから。
202 名前：デフォルトの名無しさん [2014/04/27(日) 10:13:05.46 ID:+jGSbN4U]: 俺は、FFT派
203 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 14:15:59.24 ID:ijMC55vL]: git覚えたての子が暴れてて凄いなこのスレ
204 名前：デフォルトの名無しさん [2014/04/27(日) 16:48:41.84 ID:/n7QikUK]: git派は自分のやり方以外は認められない原理主義者が多いんだろ
205 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 16:52:16.11 ID:s0HPULD5]: >>201
リモートから取り込んだコミットを
ローカルで改変してたりしないか？
開発用の修正を間に挟んだりとか。
206 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 20:05:48.91 ID:0q81XbwG]: >>205
それでもFFにならないわけはない。
207 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 20:42:56.75 ID:RalmXzvw]: >>9
>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚弘記
>www.amazon.co.jp/gp/product/477416366X/

この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。
208 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 20:56:58.74 ID:37jfUrsD]: Gitについてはさわり中のさわりしか書いてないからまともにGit使おうと思ったら別の入門書買い足すことになるってだけだよ
209 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 21:34:00.25 ID:FuM1UcuM]: >>207
> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。

でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。
210 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 21:39:02.03 ID:FuM1UcuM]: >>201
> FFこだわるのは、FF縛りがあるから。

何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。
211 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 21:46:21.84 ID:0q81XbwG]: まっさきに思いついたのは無能なPMに強制されてるという理由だったが
212 名前：デフォルトの名無しさん mailto:sage [2014/04/27(日) 22:46:45.69 ID:y1TCx0zf]: もうそろそろ2.0リリースされそうだけど使ってる？
213 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 01:24:17.91 ID:r745xiPh]: 2.0は5月の第三週あたり
214 名前：デフォルトの名無しさん [2014/04/28(月) 05:49:30.90 ID:G/O2/oE+]: プロジェクトいくつも首突っ込んでればリポジトリなんてすぐ数十にはなるわけで
手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ
215 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 06:17:16.50 ID:SIdeIE1K]: Gitはリポジトリ数十になってもpullとか手作業でいいと思うが？
216 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 09:59:35.16 ID:ES7XWIWl]: どのプロジェクトが何の言語で書いたのかわかんない
githubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便
217 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 12:04:38.80 ID:UImZVLxS]: どの言語かなんて気にする必要ないだろ。
言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。
218 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 12:26:41.94 ID:ES7XWIWl]: Git 2.0になって.gitconfigも変わる？誰か調べてる人いる？
219 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 12:27:37.63 ID:ES7XWIWl]: Gitインストールするときにタグ指定し忘れて開発版の最新2.0をインストールしたんだけど特に不具合ないんだよね
220 名前：デフォルトの名無しさん mailto:sage [2014/04/28(月) 13:13:07.74 ID:DVYrPedv]: リリースノート読む限り大きな変更はgit pushのデフォルトがsimpleになることくらい？

自分の場合は既にsimpleに設定してたし
git addでパス省略ってやらないし影響なさげ

でも暫くは移行しない
221 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 03:34:15.62 ID:yOn60HCq]: >>210
FFは、利点がーというよりも、うちはリリースの終わったbranch削除しちゃうので一直線にまとまっていないと、都合悪いだけかな？。
btanchは開発工程の作業場所としてわりきってる。
222 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 04:05:17.29 ID:5g+Rsf3h]: >>221
FFじゃない状態でブランチマージしてから、そのブランチを削除すると何が問題になるのですか？
もしかして削除したランチに属していたコミットが消えちゃうのですか？
223 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 04:10:14.41 ID:jiz/CQ6q]: >>221
どういうふうに都合わるいのか詳しく頼む。

mergeコミットが残ってたほうがブランチの情報が残るという認識なんだけど。
224 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 09:19:49.77 ID:wf66nSBF]: 修正履歴を残したいのに履歴をいじるのはおかしい
rebaseなんてGOTOと同じくらいいらない
225 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:11:12.30 ID:gWfSfq0v]: はぁ？
226 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:21:10.13 ID:fjfML7VO]: わざわざログを壊してまで見やすくしようっていうのがいらねえんだよ
コミッターが何をしたのか把握できないだろう
227 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:22:25.29 ID:fjfML7VO]: そういうのはタグで管理するべき
rebaseを使うのは下手くそが使うコマンド
228 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:41:22.64 ID:jiz/CQ6q]: 議論が変な方向に行くのがイヤなんで一応ハッキリさせときたいんだけど、
俺が気にしてるのは rebase && FF マージね。
master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
FF merge するってやり方のこと。これをやりたくなる意味がわからない。
他の目的のrebase自体は問題ないと思ってる。
229 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:50:31.16 ID:2NEMUWta]: masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
意味がないならrebaseしてからのほうがログが読みやすい
230 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 10:58:37.39 ID:fjfML7VO]: どこで作業を行ったかの記録も重要である
余計なことはするな
231 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:14:43.54 ID:jiz/CQ6q]: >>229
> masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
どういう場合にベースを意味がある(または意味がない)くわしくたのむ

俺にとって重要なのはブランチの目的とその目的に向かってコミットがどう積み重ねられたのかであって、
ベースがどこかは明示的にはあんまり気にしないんだが。

FFマージじゃなければ統合ブランチの履歴を log --first-parent で要約できるのと、
マージコミットのログなどに表示される親コミット2つ使って
git log deadbeaf..cafebabe
のようにトピックのログだけ簡単に取り出せるのが便利なのに。

後者は内部で merge-base 使ってるのでベースに意味があるのは確かだが、
だとすれば常に(俺にとっては)意味があると言える。
232 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:21:26.26 ID:LqsKRBzG]: コミッターが行った作業をありのままに記録するべき
はたして捏造された記録に意味があるのか
233 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:33:05.72 ID:EYu9TTok]: >>224
コミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。

コミットして1分後に気づいたタイポの修正なんか
修正の履歴として残す価値はないはない。

レビューを誰かに依頼して見つかったバグの修正なんか
修正の履歴として残す必要はない。

このコミットで何を修正するのかを明確に記録するには
rebaseは必須の機能。rebaseの機能なしで同じことを
やろうとしたら大変すぎて断念するレベル。

反論できる？
234 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:38:42.10 ID:LqsKRBzG]: その修正の裏に気づかずに別の箇所を修正しているかもしれない
不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね
235 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:40:07.95 ID:LqsKRBzG]: >>233
だからそういうのはタグで管理しろ
236 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:49:24.38 ID:EYu9TTok]: >>228
> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。

rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
masterへのmergeで起きたコンフリクトをその場で修正すると
バグを入れる可能性が高くなる。

コンフリクトが起きなければ問題ないが、いざマージしようと思った時に
コンフリクトが起きたら、修正する必要がある。

masterへの追尾が遅れれば遅れるほど、コンフリクトが起きる可能性も高くなるし、
コンフリクトが起きた時の修正も大変になる。だからこまめにmasterへrebaseしておく。

その一環として、最後にrebaseしておくだけのこと。
そうすればレビューアーも安心してレビューを行える。

もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
237 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:51:08.54 ID:EYu9TTok]: >>235
どうタグを使うっていうんだ？

そもそもタグの使い方が間違っている。

タグはある状態に対してつけるもの。
タグがついたらコードフリーズした状態で
それ移行変更してはいけない。
238 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:54:15.32 ID:EYu9TTok]: >>234
gitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。
239 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:57:18.99 ID:jiz/CQ6q]: 俺としては歴史修正ツールとしてのrebaseの使用には賛成なんだが、
やはりそっちの議論にいってしまうか。

いや、本当に全てのrebaseが有害と言ってるヤツもいるのかもしれんけども。

・rebase && FFマージの話
・歴史修正ツールとしてのrebaseの良し悪し

これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。
240 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 11:59:42.78 ID:EYu9TTok]: >>239
じゃあピンポイントで聞くわ。

開発者と、masterへマージ（レビュー）する人が別々の人だとする。

masterへマージする時にコンフリクトが起きました。

この時どうしますか？

1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。
241 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 12:25:05.93 ID:jiz/CQ6q]: >>236
おぉ、そういう主張か。 >>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で書いたやつにさせるように運用するのがお勧めだよ。
242 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 12:27:35.28 ID:jiz/CQ6q]: >>240
> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。

どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。
243 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 12:30:47.09 ID:EYu9TTok]: > ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。

gitlabでmasterにマージするときは、
ウェブの管理画面からボタンを押すだけ
その時勝手にno-ffされる。

というか、ウェブの管理画面からはno-ffでしかマージできない。

> (topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
コンフリクト起きないならrebaseもすぐに終わる。1コマンド入力してあとは自動処理。
コンフリクトするなら、結局どこかで作業するのだから大差ない。

コンフリクトするのかな～？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。
244 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 12:35:19.57 ID:jiz/CQ6q]: >>243
> というか、ウェブの管理画面からはno-ffでしかマージできない。
rebase && FF派じゃねーのかよ (´・ω・`)
245 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 12:38:23.48 ID:EYu9TTok]: rebase派だけど、FF派じゃねーよ？
rebaseのあとはどっちでもいい派。

rebaseすることに異議を唱えてるんじゃないの？
246 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 13:06:53.85 ID:jiz/CQ6q]: >>245
ちがうよ、rebaseはなくてはならない重要なツール。
俺が疑問に思ってるのは rebase && FF だよ。

理由はrebase && FF してしまうと
1 log --first-parent で要約をとれなくなる
2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
から。詳しくは上の方を見てくれ。
247 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 13:21:06.01 ID:GKmjQvWP]: 別にどっちでもいいというか
プロジェクトの性質に合わせて運用するべきで
他人がどうこう言うもんじゃないと思うが

FF派にとっては1と2は大して重要じゃないんでしょ
どうせログなんて参考にしかならんのだから

コードを追うならFFの方が都合がいい場合もあろう
248 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 13:47:07.80 ID:+oyspTjV]: プロジェクトの性質にもよるし、そのブランチで音一連の変更がどの程度の変更量かだったり、変更の意味にもよるし、mergeやrebaseをする人の技量にもよるよな。

merge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
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 の方が先なのに…。」とか意味不明もいいとこ。
249 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 14:26:17.37 ID:jiz/CQ6q]: >>247
> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？

> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？

一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。

「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。

ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
250 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 14:28:32.84 ID:jobIXRFq]: どうでもいい
251 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 14:30:18.99 ID:GcKmP5Zr]: このスレの先輩方の議論のまとめとか入門とかをwikiにまとめませんか？
252 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 14:58:20.39 ID:jiz/CQ6q]: 俺も他人が管理してるプロジェクトであれば「うちではrebase && FFでやるから」って言われても
「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。

だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識

もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
253 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 15:08:09.46 ID:jiz/CQ6q]: 名指しして悪いんだけど例えばこれ
powerful-code.com/blog/2012/11/merge-or-rebase/

mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。

rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
254 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 15:16:46.84 ID:jiz/CQ6q]: 巨大なプロジェクトでも--first-parentで見れば直線的だし、
かなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。

例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。

これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
255 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 15:25:33.99 ID:GKmjQvWP]: イマイチ何を問題としているのかが分からん

> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが

>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの

考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
256 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 15:48:55.09 ID:+oyspTjV]: >>252
rebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
257 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 15:56:19.89 ID:jiz/CQ6q]: >>255
そういうことなの？

トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。

rebase && FFはトピックブランチ使わないってことなのかね。
258 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:01:07.06 ID:jiz/CQ6q]: >>256
なるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。

first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、

って感じかな。

感謝感謝。
259 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:15:23.14 ID:GKmjQvWP]: なぜトピックブランチ使わないって結論に至るの？
FFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの

まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
260 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:17:02.13 ID:EYu9TTok]: さっきからrebase && FFが問題であるかのように言ってるが、
問題なのは「FF only の masterマージ」だろう？

rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。

さらに言えば、masterへのマージ以外には
当てはまらないだろう？
261 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:19:03.64 ID:EYu9TTok]: そしてFF only で masterマージしている（かのようなログをした）
有名なライブラリ例を上げておく。
https://github.com/lodash/lodash/commits/master
262 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:21:51.52 ID:EYu9TTok]: >>258
> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。

ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？

トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
263 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:26:11.71 ID:jiz/CQ6q]: >>259
いや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
264 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:29:31.48 ID:jiz/CQ6q]: >>260
> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？

> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
265 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:30:46.56 ID:+oyspTjV]: >>262
ブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
266 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:30:55.69 ID:jiz/CQ6q]: >>261
> そしてFF only で masterマージしている（かのようなログをした）
> 有名なライブラリ例を上げておく。
> https://github.com/lodash/lodash/commits/master

そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
267 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:31:51.96 ID:EYu9TTok]: >>252
> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、

「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。

さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。

履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
268 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:40:59.32 ID:jiz/CQ6q]: >>267
> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。

うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
269 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:43:19.24 ID:EYu9TTok]: >>266
> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？

トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。

もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。

そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？

と考えていると推測。

俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
270 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:51:05.11 ID:jiz/CQ6q]: >>269
> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、

ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？

俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
271 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:53:09.53 ID:EYu9TTok]: >>270
説明してるじゃねーか。

ライブラリの作者じゃないんだから
作者の本当の考えはわからん。
それは当たり前。

それとは別に推測で
ちゃんと説明してる。
272 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 16:59:55.32 ID:EYu9TTok]: >>270
> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。

意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？

コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。

（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。

大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
273 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 17:07:40.73 ID:EYu9TTok]: ちなみに俺が反論している所を明確にしておくと、

「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。

トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。

履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。

rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。

（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef