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/ 128 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:18:20.71 ID:0H30XzcZ] git init git checkout -b test >Switched to a new branch 'test' git branch >何も表示されない git checkout test >error: pathspec 'test' did not match any file(s) known to git. なんもコミットされてないとこうなるんですがどうしてこうなるんですか？ 129 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:21:42.53 ID:hPYav21o] >>128 その状態だと、HEADはrefs/heads/test向けのsymbolic-refになっているが、 そもそも指すべきコミットがないのでrefs/heads/testは存在しない。 よってbranchも何も表示しないし、checkoutもできない。 130 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:23:42.17 ID:0H30XzcZ] 仕様なんですか 一番最初のコミットが汚れるのがいやですね 131 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:25:13.61 ID:6xlhO1bi] rebaseすればいいじゃんｗ 俺は、とりあえず空コミットを作る。 かもしれないし、作らないかもしれない。 132 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:26:57.87 ID:hPYav21o] >>130 つまりコミット無し状態でブランチを複数作りたいということ？ 133 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:31:15.84 ID:0H30XzcZ] 漢がrebaseなんて許せないタチなんですよ コミットなし状態からブランチを分けて開発したいんです 基本的にmasterは汚したくないのです 134 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:33:01.48 ID:6xlhO1bi] subversionがだめな理由が rebaseできないからなんだけど？ それぐらい、というかそれ以上に よく使う機能だぞ。 汚くしないためにrebaseがある。 135 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:37:44.72 ID:hPYav21o] >>133 129で言ったようにHEADが存在しないrefを参照していればgit initした状態と同じなのだから、 二個目のブランチを作るときにgit checkout -bではなく git symbolic-ref HEAD refs/heads/branch_name してから開発を進めればいいじゃない 136 名前：デフォルトの名無しさん mailto:sage [2014/04/24(木) 23:47:09.80 ID:T/Y/fuz3] >>133 そこまで潔癖ならマージもしないだろうからブランチじゃなくてリポジトリを分けたら？ 137 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 00:27:14.58 ID:kupFdBxu] master汚したくないっていうのが出来たとして、 1つ目のcommitがあって、それがtestブランチだとする。 が、masterはこのcommitから辿れる親コミットも指してないし、どれも指していない。 fast forward mergeできない状態だけどいいの？ どうせmasterはなにかしらコミットした段階で一番汚されてなくたってそのコミットを指してしまうのだから、コミットしてからチェックアウトしてもいいじゃん。 138 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 03:08:01.24 ID:XQM8U6nM] mergeする予定無いのにブランチ切りたいとか意味不明すぎる 139 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 04:07:01.58 ID:zu0sgmwa] 空コミットじゃあかんのか？ つか空の.gitignoreくらい作ってからでも汚れとは思わんぞ 140 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 04:20:32.33 ID:jzYptMLV] 気に入らない部分があってもgitを使わざるをえない人は大変だね 個人の趣味でやってるならVCSは好きなのを使えるのにね 141 名前：デフォルトの名無しさん mailto:sage [2014/04/25(金) 04:23:50.66 ID:4klH39dY] 気に入らない部分が、git以外には多すぎる。 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自体は問題ないと思ってる。

---

---

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

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