1001コメント321KB

Git 9

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2014/04/12(土) 13:22:20.98ID:s4x1CSLN

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - 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/

0145デフォルトの名無しさん

2014/04/26(土) 02:05:43.27ID:pkQNyj+N

>>134
rebaseはブランチ取り込むときにontoと組み合わせて使うことの方がおおいなぁ。
コミットログの都合もあるから履歴整理にはほとんど使ってない人がここに。

0146デフォルトの名無しさん

2014/04/26(土) 02:08:06.72ID:/GEUo84h

なんでブランチ取り込む時にontoなんだ？
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。

0147デフォルトの名無しさん

2014/04/26(土) 02:26:05.50ID:pkQNyj+N

やり方がわるいんかな？
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。

0148デフォルトの名無しさん

2014/04/26(土) 02:39:25.28ID:7YL+swb1

>>147
だからなんでFFにするんだよ

0149デフォルトの名無しさん

2014/04/26(土) 02:41:39.49ID:/GEUo84h

onto使ったら必ずほぼ確実にFFできないだろ？
なんか無駄に複雑なことしている気がするな。

0150デフォルトの名無しさん

2014/04/26(土) 13:53:59.32ID:Vv5x70uz

ホームディレクトリ以下の設定ファイルだとか、個人で使ってる自作ツールはSubversionで管理してる
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい

0151デフォルトの名無しさん

2014/04/26(土) 13:58:18.76ID:/GEUo84h

>>150
いや、ディレクトリがわかれるだろ？

subvertionを使うと、

* ファイルがあるディレクトリ
* リポジトリ

と二つにディレクトリがわかれるだろ？

それだけで使いづらいじゃん。

0152デフォルトの名無しさん

2014/04/26(土) 14:05:48.63ID:Z8XCebgD

0153デフォルトの名無しさん

2014/04/26(土) 14:20:33.69ID:dMJ+hsKf

>>151
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。

0154デフォルトの名無しさん

2014/04/26(土) 14:56:15.48ID:1yS20LQ1

リポジトリを1つだけだとさ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ

0155デフォルトの名無しさん

2014/04/26(土) 15:03:43.34ID:/GEUo84h

なぜリポジトリを一つにまとめるのか？

リポジトリを作るのが面倒であるということである。

0156デフォルトの名無しさん

2014/04/26(土) 18:03:12.98ID:Vv5x70uz

リポジトリをたくさん作るとその数だけcheckoutしてpull/updateしてcommitしないといけない
自分一人で使うだけでそんな面倒なことしない

0157デフォルトの名無しさん

2014/04/26(土) 18:26:46.44ID:ztOmzoR+

subversionだと、このようにpullやupdateや
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。

gitだと気軽なのにね。

0158デフォルトの名無しさん

2014/04/26(土) 18:27:44.99ID:bHDNIx6I

cvs使ってた10年以上前は、私もひとつのリポジトリでやってたことがありました。(*ﾉωﾉ)

0159デフォルトの名無しさん

2014/04/26(土) 18:30:43.24ID:Vv5x70uz

一人でしか使わないんだからコンフリクトなんかしない
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰

0160デフォルトの名無しさん

2014/04/26(土) 18:39:48.80ID:ztOmzoR+

>>159
コンフリクトかどうかは
重要じゃないよ。

gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。

追加漏れのファイルを追加
スペルミスの修正

こんなマヌケなコミットを残さないで済む。

0161デフォルトの名無しさん

2014/04/26(土) 18:42:46.95ID:ztOmzoR+

subversionが残すのは"作業"履歴なんだろうね。
gitが残すとのは"修正"履歴

だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。

gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。

subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。

0162デフォルトの名無しさん

2014/04/26(土) 18:47:04.31ID:ztOmzoR+

subversionだと作業履歴が残っちゃうから
ちょっと気軽にコミットしようということができない。

gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが

subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。

0163デフォルトの名無しさん

2014/04/26(土) 18:56:37.43ID:Vv5x70uz

.bashrcや.inputrcが数千行になったらgitの導入を考える

0164デフォルトの名無しさん

2014/04/26(土) 18:57:44.05ID:ztOmzoR+

HAHAHAHA、基準がおかしい奴がいる。
こういう奴がgitに反対しているわけさ。

0165デフォルトの名無しさん

2014/04/26(土) 19:04:14.03ID:a+LUSt4b

bareめんどくない?

0166デフォルトの名無しさん

2014/04/26(土) 19:10:57.12ID:Vv5x70uz

だいたい.screenrcに対する特定のコミットを取り消すとか、そんな必要性感じたこと一度もない

0167デフォルトの名無しさん

2014/04/26(土) 19:12:42.80ID:ztOmzoR+

面倒くさいなら作らなくていいよ。
bareは必須ではない。

gitを始めるのに必要なのはディレクトリで
git initするだけ。

これでもうすぐにブランチ切り替えも
タグの作成もできる。

某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。

0168デフォルトの名無しさん

2014/04/26(土) 19:13:48.14ID:ztOmzoR+

>>166
君は.screenrcの管理とかしかしないんだねｗ

えぇ、subversionは面倒だからでしょうね。
気軽に始められないｗ

0169デフォルトの名無しさん

2014/04/26(土) 19:17:57.35ID:Vv5x70uz

いや、何の事かわからないが、subversionでもgitでもどういうブランチ構成にするかはその人次第だから

0170デフォルトの名無しさん

2014/04/26(土) 19:22:53.05ID: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

みじかい！

0171デフォルトの名無しさん

2014/04/26(土) 19:24:43.18ID:ztOmzoR+

>>169
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。

だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。

こんなの、き・そ・！です。

0172デフォルトの名無しさん

2014/04/26(土) 19:30:14.03ID:y+As8odQ

おっ、そうだな

0173デフォルトの名無しさん

2014/04/26(土) 19:30:26.82ID:Vv5x70uz

いや、初めからブランチ作らないって言ってるし、.my.cnfでも.pgsqlでもなんでもいいが、ブランチ切って修正を分ける必要性を全く感じない

0174デフォルトの名無しさん

2014/04/26(土) 19:32:08.93ID:ztOmzoR+

※>>173 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうｗｗｗ

0175デフォルトの名無しさん

2014/04/26(土) 19:33:56.04ID:Z8XCebgD

なんでこの人こんなに発狂してるの・・・
別に git はゴミ！とか貶してるわけじゃないのに

0176デフォルトの名無しさん

2014/04/26(土) 19:34:13.93ID:Vv5x70uz

世の中には.ssh/configをテストファーストで日々更新してる人もいるのかもしれない、そういう人にはリリースと開発でブランチを分けてるのかもしれない
俺はそんなことしてないけど

0177デフォルトの名無しさん

2014/04/26(土) 19:35:28.56ID:ztOmzoR+

subversion使っている人は、みんな
ブランチ作らないって言ってるんでしょうかね

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

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

面白いですねｗｗｗ

0178デフォルトの名無しさん

2014/04/26(土) 19:36:05.09ID:ztOmzoR+

subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ

0179デフォルトの名無しさん

2014/04/26(土) 19:39:59.70ID:iVzDEppp

>>173
お前がブランチ作らないとかどうでもいいわ。

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

それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？

0180デフォルトの名無しさん

2014/04/26(土) 19:44:23.08ID:Vv5x70uz

いや、ホームディレクトリ以下の設定ファイルという前提なんだけど
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった

0181デフォルトの名無しさん

2014/04/26(土) 19:46:55.41ID:koYBfWi3

ホームディレクトリ以下をgitで管理しようと思うのならば、
git initするだけでもう使えるよ。

subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。

0182デフォルトの名無しさん

2014/04/26(土) 19:51:45.97ID:Z8XCebgD

なんか話を一般化して叩いてるけどホームディレクトリ内のファイルの管理ぐらい好きにやらせたれや・・・

0183デフォルトの名無しさん

2014/04/26(土) 19:54:06.41ID:HaseiyYq

自由にやっていいよ。面倒な方法だって言っているだけだから
別に面倒な方法だってわかってやってるなら問題ない。

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

gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。

0184デフォルトの名無しさん

2014/04/26(土) 19:54:51.87ID:Vv5x70uz

>>181
なんでリポジトリを別の場所に置いたらダメなの？
特にマシン間で設定フィルを共有する場合、中央リポジトリが必要になるのは同じなんだから

0185デフォルトの名無しさん

2014/04/26(土) 19:56:09.41ID:Z8XCebgD

まあそこら辺は git スレでわざわざ頑張る内容ではないだろな

0186デフォルトの名無しさん

2014/04/26(土) 19:56:42.73ID:HaseiyYq

>>184
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。

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

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

少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。

0187デフォルトの名無しさん

2014/04/26(土) 19:59:08.48ID:Z8XCebgD

>そういう使い方するとGitよりSubversionが使いやすい
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。

0188デフォルトの名無しさん

2014/04/26(土) 20:01:00.30ID:HaseiyYq

>>187
じゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。

お前ん中ではそうなんだろうなｗ
お前ん中では、設定ファイルの管理にぐらいしか使わないんだろうな

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

ブランチ使わないって前提の話で、subversionはブランチ作るのが面倒とか的外れな反論しておかしくなった
ドットファイルをブランチに分ける事は基本ないわな

0191デフォルトの名無しさん

2014/04/26(土) 20:42:18.34ID:7YL+swb1

>>190
俺はブランチを切りまくって、そいつらをマージしたものをマシン毎につかってるな。
いつのまにか47もブランチできてたわ。

0192デフォルトの名無しさん

2014/04/26(土) 22:24:36.07ID:jBTvJ1OX

Unix系のツールの設定ファイルとか複数の環境で使いまわすことが普通だし
最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合

0193デフォルトの名無しさん

2014/04/26(土) 23:35:52.72ID: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するのが普通？

0194デフォルトの名無しさん

2014/04/26(土) 23:37:58.13ID:pkQNyj+N

>>193
$ git rebase --onto master 9d47912 branch1
の間違い、行数削ったときに直すのわすれてた

0195デフォルトの名無しさん

2014/04/26(土) 23:46:42.24ID:7YL+swb1

だからなんでFFに拘るんだよ

0196デフォルトの名無しさん

2014/04/26(土) 23:47:26.43ID:7YL+swb1

>>193
あと、普通は
git rebase master branch1
で済む。

0197デフォルトの名無しさん

2014/04/26(土) 23:49:50.02ID:DhTsVAJ/

FFはCoolだかｒ

0198デフォルトの名無しさん

2014/04/27(日) 01:10:15.13ID:TcUJdg0l

>>196
その通りだね。

やっぱり無駄なことしてるじゃんｗ
onto使う必要がない所でonto使ってた。

0199デフォルトの名無しさん

2014/04/27(日) 05:35:56.46ID:/n7QikUK

svnでわざわざtrunk、branches、tagsディレクトリを作ってコミットなんて面倒なこと
ただの一度もしたことねえわ

0200デフォルトの名無しさん

2014/04/27(日) 06:08:30.59ID:TcUJdg0l

まあ、そういう変な人もいる。

0201デフォルトの名無しさん

2014/04/27(日) 10:01:09.95ID:YIeV8hDm

>>198
なくても平気なのかー、単純にrebaseするだけじゃダメな時あったんだけどなぁ、まっいっか。
FFこだわるのは、FF縛りがあるから。

0202デフォルトの名無しさん

2014/04/27(日) 10:13:05.46ID:+jGSbN4U

俺は、FFT派

0203デフォルトの名無しさん

2014/04/27(日) 14:15:59.24ID:ijMC55vL

git覚えたての子が暴れてて凄いなこのスレ

0204デフォルトの名無しさん

2014/04/27(日) 16:48:41.84ID:/n7QikUK

git派は自分のやり方以外は認められない原理主義者が多いんだろ

0205デフォルトの名無しさん

2014/04/27(日) 16:52:16.11ID:s0HPULD5

>>201
リモートから取り込んだコミットを
ローカルで改変してたりしないか？
開発用の修正を間に挟んだりとか。

0206デフォルトの名無しさん

2014/04/27(日) 20:05:48.91ID:0q81XbwG

>>205
それでもFFにならないわけはない。

0207デフォルトの名無しさん

2014/04/27(日) 20:42:56.75ID:RalmXzvw

>>9
>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚弘記
>http://www.amazon.co.jp/gp/product/477416366X/

この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。

0208デフォルトの名無しさん

2014/04/27(日) 20:56:58.74ID:37jfUrsD

Gitについてはさわり中のさわりしか書いてないからまともにGit使おうと思ったら別の入門書買い足すことになるってだけだよ

0209デフォルトの名無しさん

2014/04/27(日) 21:34:00.25ID:FuM1UcuM

>>207
> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。

でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。

0210デフォルトの名無しさん

2014/04/27(日) 21:39:02.03ID:FuM1UcuM

>>201
> FFこだわるのは、FF縛りがあるから。

何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。

0211デフォルトの名無しさん

2014/04/27(日) 21:46:21.84ID:0q81XbwG

まっさきに思いついたのは無能なPMに強制されてるという理由だったが

0212デフォルトの名無しさん

2014/04/27(日) 22:46:45.69ID:y1TCx0zf

もうそろそろ2.0リリースされそうだけど使ってる？

0213デフォルトの名無しさん

2014/04/28(月) 01:24:17.91ID:r745xiPh

2.0は5月の第三週あたり

0214デフォルトの名無しさん

2014/04/28(月) 05:49:30.90ID:G/O2/oE+

プロジェクトいくつも首突っ込んでればリポジトリなんてすぐ数十にはなるわけで
手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ

0215デフォルトの名無しさん

2014/04/28(月) 06:17:16.50ID:SIdeIE1K

Gitはリポジトリ数十になってもpullとか手作業でいいと思うが？

0216デフォルトの名無しさん

2014/04/28(月) 09:59:35.16ID:ES7XWIWl

どのプロジェクトが何の言語で書いたのかわかんない
githubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便

0217デフォルトの名無しさん

2014/04/28(月) 12:04:38.80ID:UImZVLxS

どの言語かなんて気にする必要ないだろ。
言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。

0218デフォルトの名無しさん

2014/04/28(月) 12:26:41.94ID:ES7XWIWl

Git 2.0になって.gitconfigも変わる？誰か調べてる人いる？

0219デフォルトの名無しさん

2014/04/28(月) 12:27:37.63ID:ES7XWIWl

Gitインストールするときにタグ指定し忘れて開発版の最新2.0をインストールしたんだけど特に不具合ないんだよね

0220デフォルトの名無しさん

2014/04/28(月) 13:13:07.74ID:DVYrPedv

リリースノート読む限り大きな変更はgit pushのデフォルトがsimpleになることくらい？

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

でも暫くは移行しない

0221デフォルトの名無しさん

2014/04/29(火) 03:34:15.62ID:yOn60HCq

>>210
FFは、利点がーというよりも、うちはリリースの終わったbranch削除しちゃうので一直線にまとまっていないと、都合悪いだけかな？。
btanchは開発工程の作業場所としてわりきってる。

0222デフォルトの名無しさん

2014/04/29(火) 04:05:17.29ID:5g+Rsf3h

>>221
FFじゃない状態でブランチマージしてから、そのブランチを削除すると何が問題になるのですか？
もしかして削除したランチに属していたコミットが消えちゃうのですか？

0223デフォルトの名無しさん

2014/04/29(火) 04:10:14.41ID:jiz/CQ6q

>>221
どういうふうに都合わるいのか詳しく頼む。

mergeコミットが残ってたほうがブランチの情報が残るという認識なんだけど。

0224デフォルトの名無しさん

2014/04/29(火) 09:19:49.77ID:wf66nSBF

修正履歴を残したいのに履歴をいじるのはおかしい
rebaseなんてGOTOと同じくらいいらない

0225デフォルトの名無しさん

2014/04/29(火) 10:11:12.30ID:gWfSfq0v

はぁ？

0226デフォルトの名無しさん

2014/04/29(火) 10:21:10.13ID:fjfML7VO

わざわざログを壊してまで見やすくしようっていうのがいらねえんだよ
コミッターが何をしたのか把握できないだろう

0227デフォルトの名無しさん

2014/04/29(火) 10:22:25.29ID:fjfML7VO

そういうのはタグで管理するべき
rebaseを使うのは下手くそが使うコマンド

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

masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
意味がないならrebaseしてからのほうがログが読みやすい

0230デフォルトの名無しさん

2014/04/29(火) 10:58:37.39ID:fjfML7VO

どこで作業を行ったかの記録も重要である
余計なことはするな

0231デフォルトの名無しさん

2014/04/29(火) 11:14:43.54ID:jiz/CQ6q

>>229
> 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

>>224
コミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。

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

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

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

反論できる？

0234デフォルトの名無しさん

2014/04/29(火) 11:38:42.10ID:LqsKRBzG

その修正の裏に気づかずに別の箇所を修正しているかもしれない
不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね

0235デフォルトの名無しさん

2014/04/29(火) 11:40:07.95ID:LqsKRBzG

>>233
だからそういうのはタグで管理しろ

0236デフォルトの名無しさん

2014/04/29(火) 11:49:24.38ID:EYu9TTok

>>228
> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。

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

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

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

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

もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。

0237デフォルトの名無しさん

2014/04/29(火) 11:51:08.54ID:EYu9TTok

>>235
どうタグを使うっていうんだ？

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

タグはある状態に対してつけるもの。
タグがついたらコードフリーズした状態で
それ移行変更してはいけない。

0238デフォルトの名無しさん

2014/04/29(火) 11:54:15.32ID:EYu9TTok

>>234
gitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。

0239デフォルトの名無しさん

2014/04/29(火) 11:57:18.99ID:jiz/CQ6q

俺としては歴史修正ツールとしてのrebaseの使用には賛成なんだが、
やはりそっちの議論にいってしまうか。

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

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

これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。

0240デフォルトの名無しさん

2014/04/29(火) 11:59:42.78ID:EYu9TTok

>>239
じゃあピンポイントで聞くわ。

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

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

この時どうしますか？

1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。

0241デフォルトの名無しさん

2014/04/29(火) 12:25:05.93ID: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で書いたやつにさせるように運用するのがお勧めだよ。

0242デフォルトの名無しさん

2014/04/29(火) 12:27:35.28ID:jiz/CQ6q

>>240
> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。

どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。

0243デフォルトの名無しさん

2014/04/29(火) 12:30:47.09ID:EYu9TTok

> ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。

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

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

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

コンフリクトするのかな～？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。

0244デフォルトの名無しさん

2014/04/29(火) 12:35:19.57ID:jiz/CQ6q

>>243
> というか、ウェブの管理画面からはno-ffでしかマージできない。
rebase && FF派じゃねーのかよ (´・ω・`)

0245デフォルトの名無しさん

2014/04/29(火) 12:38:23.48ID:EYu9TTok

rebase派だけど、FF派じゃねーよ？
rebaseのあとはどっちでもいい派。

rebaseすることに異議を唱えてるんじゃないの？

■ このスレッドは過去ログ倉庫に格納されています