- 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/
- 142 名前：デフォルトの名無しさん [2014/04/25(金) 05:28:33.42 ID:cdj1D6xv]
- だねー
俺はローカル全部svnだわ
- 143 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 08:52:14.28 ID:xiFjVo8G]
- ３つ前のコミットに戻ってブランチを分岐したい場合ってどうすればいいのでしょうか
３つ前に巻き戻してからブランチするのでしょうか
最後の２つのコミットも念のために残したいのでブランチにしたいのです
具体的には
最後の２つのコミットの変更が破棄になったけど
念のために残したい
という状況です
- 144 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 11:14:49.10 ID:4klH39dY]
- 三つ前のコミットIDから
ブランチ作ればいいじゃん。
- 145 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 02:05:43.27 ID:pkQNyj+N]
- >>134
rebaseはブランチ取り込むときにontoと組み合わせて使うことの方がおおいなぁ。
コミットログの都合もあるから履歴整理にはほとんど使ってない人がここに。
- 146 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 02:08:06.72 ID:/GEUo84h]
- なんでブランチ取り込む時にontoなんだ？
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。
- 147 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 02:26:05.50 ID:pkQNyj+N]
- やり方がわるいんかな？
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。
- 148 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 02:39:25.28 ID:7YL+swb1]
- >>147
だからなんでFFにするんだよ
- 149 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 02:41:39.49 ID:/GEUo84h]
- onto使ったら必ずほぼ確実にFFできないだろ？
なんか無駄に複雑なことしている気がするな。
- 150 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 13:53:59.32 ID:Vv5x70uz]
- ホームディレクトリ以下の設定ファイルだとか、個人で使ってる自作ツールはSubversionで管理してる
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい
- 151 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 13:58:18.76 ID:/GEUo84h]
- >>150
いや、ディレクトリがわかれるだろ？
subvertionを使うと、
* ファイルがあるディレクトリ
* リポジトリ
と二つにディレクトリがわかれるだろ？
それだけで使いづらいじゃん。
- 152 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 14:05:48.63 ID:Z8XCebgD]
- ?
- 153 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 14:20:33.69 ID:dMJ+hsKf]
- >>151
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。
- 154 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 14:56:15.48 ID:1yS20LQ1]
- リポジトリを1つだけだとさ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ
- 155 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 15:03:43.34 ID:/GEUo84h]
- なぜリポジトリを一つにまとめるのか？
リポジトリを作るのが面倒であるということである。
- 156 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:03:12.98 ID:Vv5x70uz]
- リポジトリをたくさん作るとその数だけcheckoutしてpull/updateしてcommitしないといけない
自分一人で使うだけでそんな面倒なことしない
- 157 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:26:46.44 ID:ztOmzoR+]
- subversionだと、このようにpullやupdateや
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。
gitだと気軽なのにね。
- 158 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:27:44.99 ID:bHDNIx6I]
- cvs使ってた10年以上前は、私もひとつのリポジトリでやってたことがありました。(*ﾉωﾉ)
- 159 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:30:43.24 ID:Vv5x70uz]
- 一人でしか使わないんだからコンフリクトなんかしない
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰
- 160 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:39:48.80 ID:ztOmzoR+]
- >>159
コンフリクトかどうかは
重要じゃないよ。
gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。
追加漏れのファイルを追加
スペルミスの修正
こんなマヌケなコミットを残さないで済む。
- 161 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:42:46.95 ID:ztOmzoR+]
- subversionが残すのは"作業"履歴なんだろうね。
gitが残すとのは"修正"履歴
だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。
gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。
subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。
- 162 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:47:04.31 ID:ztOmzoR+]
- subversionだと作業履歴が残っちゃうから
ちょっと気軽にコミットしようということができない。
gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが
subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。
- 163 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:56:37.43 ID:Vv5x70uz]
- .bashrcや.inputrcが数千行になったらgitの導入を考える
- 164 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 18:57:44.05 ID:ztOmzoR+]
- HAHAHAHA、基準がおかしい奴がいる。
こういう奴がgitに反対しているわけさ。
- 165 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:04:14.03 ID:a+LUSt4b]
- bareめんどくない?
- 166 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:10:57.12 ID:Vv5x70uz]
- だいたい.screenrcに対する特定のコミットを取り消すとか、そんな必要性感じたこと一度もない
- 167 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:12:42.80 ID:ztOmzoR+]
- 面倒くさいなら作らなくていいよ。
bareは必須ではない。
gitを始めるのに必要なのはディレクトリで
git initするだけ。
これでもうすぐにブランチ切り替えも
タグの作成もできる。
某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。
- 168 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:13:48.14 ID:ztOmzoR+]
- >>166
君は.screenrcの管理とかしかしないんだねｗ
えぇ、subversionは面倒だからでしょうね。
気軽に始められないｗ
- 169 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:17:57.35 ID:Vv5x70uz]
- いや、何の事かわからないが、subversionでもgitでもどういうブランチ構成にするかはその人次第だから
- 170 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:22:53.05 ID:ztOmzoR+]
- subversionにおけるブランチの作り方
※ブランチ作るたびに、この長いURLをいちいち入力する必要があります。
svn cp https://www.example.com/svn/trunk \
https://www.example.com/svn/branches/v1p2p3
gitだとこれだけです。
git branch v1p2p3
さてブランチに切り替えてみましょう。
svn sw https://www.example.com/svn/branches/v1p2p3
ぷぷぷぷｗ
なんでsvnはそんな長いURLが必要なんですか？ｗｗｗｗ
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる＝コピー場所を指定しなければいけないんですね。
これを毎回毎回入力して切り替えるんですね。大変ですねぇｗｗｗｗ
git checkout v1p2p3
みじかい！
- 171 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:24:43.18 ID:ztOmzoR+]
- >>169
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。
だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。
こんなの、き・そ・！ です。
- 172 名前：デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:30:14.03 ID:y+As8odQ]
- おっ、そうだな
- 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マージをするのはなんでだぜ？ってこと。
|
 |
