[表示 : 全て 最新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/

121 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 13:18:49.88 ID:QakcezKL]
最新のコミットだけプッシュする方法と
最新のタグをつけたコミットだけプッシュする方法
2つおしえてください

122 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 13:19:34.50 ID:QakcezKL]
なぜかというとコミットログからニートがバレるのでコミットログを全部プッシュしたくないからです

123 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 13:22:26.51 ID:V8z90YIW]
>>121
sqush

124 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 13:47:51.32 ID:JOpp0cve]
githubのコミットログからニートを検索するツールはよ

125 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 19:02:31.15 ID:yOTIc0ZO]
その前に日本人を探すツールが必要だ

126 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 21:18:41.68 ID:hPYav21o]
>>122
git filter-branch --env-filter 'GIT_COMMITTER_DATE="Thu, 01 Jan 1970 09:00:00 +0900
"; GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE' --all

127 名前:デフォルトの名無しさん mailto:sage [2014/04/24(木) 22:02:19.45 ID:6xlhO1bi]
コミットログに日時変えればいいだけじゃん。

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すればいいじゃんw

俺は、とりあえず空コミットを作る。
かもしれないし、作らないかもしれない。

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]
3つ前のコミットに戻ってブランチを分岐したい場合ってどうすればいいのでしょうか
3つ前に巻き戻してからブランチするのでしょうか
最後の2つのコミットも念のために残したいのでブランチにしたいのです

具体的には
最後の2つのコミットの変更が破棄になったけど
念のために残したい
という状況です

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の管理とかしかしないんだねw

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

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

ぷぷぷぷw

なんでsvnはそんな長いURLが必要なんですか?wwww
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる=コピー場所を指定しなければいけないんですね。

これを毎回毎回入力して切り替えるんですね。大変ですねぇwwww

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 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうwww

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使っているだけで、アホとみなして良さそうですね。

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

面白いですねwww

178 名前:デフォルトの名無しさん mailto:sage [2014/04/26(土) 19:36:05.09 ID:ztOmzoR+]
subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか?www

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でも当然のようにリポジトリを別の場所におけるわw

だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションである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
じゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。

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

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だかr

198 名前:デフォルトの名無しさん mailto:sage [2014/04/27(日) 01:10:15.13 ID:TcUJdg0l]
>>196
その通りだね。

やっぱり無駄なことしてるじゃんw
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は開発工程の作業場所としてわりきってる。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<225KB

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