- 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/
- 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にマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
- 274 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 17:14:28.12 ID:jobIXRFq]
- トピックブランチのコミットが2個以上なら
マージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
- 275 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 17:18:53.63 ID:EYu9TTok]
- 連投するが、俺がいいたいのは
・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
- 276 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:11:38.86 ID:jiz/CQ6q]
- >>273
コミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
A-B-C
/ \
X-------M-M
\ /
D--E--F
こういう変更は DEF をrebaseして
A-B-C
/ \
X-------M---------M
\ /
D'-E'-F'
こうすべき、ってことでいいかい？
俺的にはどちらもfirst-parentで
\
X-M-M
/
に要約可能だからどっちでもいいよ。
# ただ自分でやる場合はコンフリクトしない限り前者のほうがrebaseしなくていいから楽だけと思うけどね。
# もちろんDEFのマージ時にコンフリクトしたらrebaseすることもある。DEF開発者によるmergeも可。
- 277 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:12:17.95 ID:jiz/CQ6q]
- 疑問視してるのは
X-A-B-C-D'-E'-F'
にすべきという主張だ。
これはA-B-CとD-E-Fが本来別の目的を目指して重ねたコミットだという情報が失われてしまうから
たとえ一直線でもわかりにくいと俺は主張しているんだよ。
トピックが2個程度ならどっちでも良さそうだが、トピックが数十の場合を想像してくれ
X-M-M-M-.....M-M
という数十個の要約を見る(必要に応じてトピック内のABC等を確認する)のと
X-A-B-C......(区切りもなく、めちゃくちゃたくさんのコミット)....x-y-z
を見るのと、どっちがわかりやすいの？ってこと。
- 278 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:15:08.80 ID:jiz/CQ6q]
- ブラウザによっては結構ずれるな。わかんなきゃ無視してくれ。
- 279 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:24:55.80 ID:VGBInRA4]
- 2.0からデフォルトでFF onlyになるのは知ってるよね君たち
どうしてこうなったのかもちろん議論されてるのも知ってるよね
- 280 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:25:46.52 ID:ABe1tyQZ]
- これもうわかんねえな(バグったときの修正範囲が)
- 281 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:30:04.67 ID:qq5sN0hH]
- >履歴は一直線になっていたほうがわかりやすい。これは事実。
一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
- 282 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:44:21.18 ID:jiz/CQ6q]
- >>279
pull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
- 283 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 18:45:53.07 ID:jiz/CQ6q]
- >>281
そうそう。
ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
- 284 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 19:02:08.02 ID:ABe1tyQZ]
- ベースブランチの状態が多いイコール検証箇所も多くなって面倒だからそうならないようコミットも最小限にしたほうがいいんじゃないの
- 285 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 19:47:52.24 ID:6KBRCzBr]
- >>223
というわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
- 286 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 19:56:50.37 ID:EYu9TTok]
- > ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
ね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
- 287 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 19:58:40.00 ID:jiz/CQ6q]
- >>285
報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
- 288 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 20:21:45.22 ID:jobIXRFq]
- 一直線バカは救いようのないバカだな
- 289 名前：デフォルトの名無しさん mailto:sage [2014/04/29(火) 23:30:04.09 ID:+oyspTjV]
- 「履歴が一直線になってわかりやすい！」かどうかって、もはやコミットの順序というものにどういう意味があるかどうかという意味論なのだから、
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
- 290 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 00:35:08.42 ID:UGHSixxv]
- 一直線が良いケースが挙げられてないけどな
- 291 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 01:11:54.22 ID:pWom3qZR]
- 一直線： 見えを貼りたいだけのバカ。俺はまっすぐ順調に開発をしてきたというアピールがしたい
- 292 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 01:29:11.37 ID:Gbwo+6jG]
- 東大一直線
- 293 名前：デフォルトの名無しさん [2014/04/30(水) 05:04:21.07 ID:mdKtpEfX]
- 意味不明なエラーでpush不可能になった
remote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
- 294 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 08:30:44.87 ID:1vNQkGgC]
- hook declined
ってかいてあんじゃん
- 295 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 11:02:23.25 ID:4gXDKzV2]
- 書き込み時刻を見ろ 察してやれ
- 296 名前：デフォルトの名無しさん [2014/04/30(水) 14:42:09.85 ID:mdKtpEfX]
- dis発言に対してはただ叩くだけ
それも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
- 297 名前：デフォルトの名無しさん [2014/04/30(水) 14:48:31.80 ID:mdKtpEfX]
- 別リポジトリで他人による大量の更新があって
半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
- 298 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 14:55:49.07 ID:nKoANYQ+]
- またいつものコンフリクト恐怖症の人か
- 299 名前：デフォルトの名無しさん [2014/04/30(水) 18:26:55.40 ID:mdKtpEfX]
- コンフリクト解消で済めばいいんだが腐ってるから済まないんだよね
- 300 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 18:51:13.84 ID:h9gMUOtr]
- なるほど、コンフリクトの解消の仕方が分からないから
コンフリクト恐怖症になってしまったのか
- 301 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 18:51:51.42 ID:rHgIYikH]
- Aリポジトリでもらったpull requestを
Bリポジトリに反映する方法を教えてください
- 302 名前：デフォルトの名無しさん [2014/04/30(水) 18:59:19.90 ID:1L5gAVQy]
- ところで、大声でジットと呼ぶ人がいて困ってるんだ
ディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
- 303 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 19:12:36.93 ID:ZY5HChQC]
- じっと我慢汁
- 304 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 19:50:56.80 ID:fWhizGrM]
- レーダーデスクカラオケ
- 305 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 19:56:34.41 ID:EonfyA0Y]
- ギットギトにしてやんよ
- 306 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 20:25:07.89 ID:WuyiDL68]
- >>297
> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
- 307 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 21:19:26.86 ID:livyiFPX]
- >>297
> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
- 308 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 21:28:01.99 ID:upmIhAH5]
- >>217
プロジェクト名に言語が入ってないとなんの言語で作ってるのかわからないじゃん
言語を変えたらリポジトリ名を変更すればいいじゃん
- 309 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 21:58:49.74 ID:Y0BKcERE]
- >>308
悪いことは言わないから足を洗え。
- 310 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 22:12:33.53 ID:livyiFPX]
- そういやgithubってプロジェクトで使用している言語がわかるようになったよね。
gitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
- 311 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 22:41:41.21 ID:rUdHCEgh]
- githubだけの視野で語られても
- 312 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 22:42:55.54 ID:livyiFPX]
- github以外のプロジェクトでも
複数言語でアプリ作るのは一般的だけど？ｗ
- 313 名前：デフォルトの名無しさん [2014/04/30(水) 23:26:12.17 ID:mdKtpEfX]
- 307は本当に馬鹿なんだなぁ
管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
- 314 名前：デフォルトの名無しさん mailto:sage [2014/04/30(水) 23:51:07.78 ID:1vNQkGgC]
- 結局gitのおかげで無事でした
めでたしめでたし
- 315 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 00:28:44.24 ID:WukXr8jq]
- ＞＞３１２
プロジェクトを1つのディレクトリに詰め込むタイプですか？
- 316 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 09:28:45.91 ID:PzUwUPDQ]
- >>313
意味がわからないなあ
コミットしたものを権限持ちに既に送ってあるとしたら、
お前が上流からマージしようとしたブランチは一体何なの？
お前がコミットしたものを含んでいないブランチ？
- 317 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 11:07:25.45 ID:PVO7jj2i]
- >>315
なんでそんな発想が出てくるんだ？ (w
- 318 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 11:24:48.42 ID:/DVUm5po]
- おれはさ
php/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
- 319 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 17:12:30.25 ID:PzUwUPDQ]
- >>318
それとGitと何の関係があるんだ？
- 320 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 17:20:29.51 ID:U31MyfYF]
- Gitはソースコードを管理するわけだからプロジェクトと関係あるだろ
C:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
- 321 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 17:24:28.79 ID:n23f7Uie]
- 名前付けのポリシーとか別に好きにすればいいと思う。
- 322 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 17:44:02.84 ID:PzUwUPDQ]
- >>320
そんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
- 323 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 17:52:02.03 ID:U31MyfYF]
- >>310
複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
- 324 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 18:01:12.45 ID:n23f7Uie]
- もう自由にタグ付けできる自分用プロジェクト管理ツール使っちゃえよ。
- 325 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 18:13:02.15 ID:ZgnY/tZG]
- >>318
コードネームつければいい。
phpは犬の種類、rubyは猫の種類とか原則を持たせても良い。
- 326 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 19:05:29.45 ID:PzUwUPDQ]
- >>323
githubがリポジトリを「https://github.com/ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
- 327 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 19:26:56.62 ID:3NSQaEE2]
- だからさGitHubだけで語るな
- 328 名前：デフォルトの名無しさん mailto:sage [2014/05/01(木) 22:47:07.56 ID:dcOXu/fE]
- 確かにSubversion使ってたときは一つのリポジトリに色々入れてたけど(そしてSubversionを適当に使う限りではそれで事足りてた)、
Gitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
- 329 名前：デフォルトの名無しさん [2014/05/02(金) 03:41:26.83 ID:ZGvM0amq]
- >>316 pullするだけでその状態になることすらわからないとかお前本当に馬鹿だな
- 330 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 03:48:34.89 ID:PU3lP69m]
- >>326
はあ？リポジトリ名の話なのに
＞「https://github.com/ユーザー名/リポジトリ名」
ってなんだよ話そらしてんじゃねえよ
- 331 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 06:22:29.35 ID:KJDTZacL]
- 自分の管理下にあるリポジトリなら好きに名前付けりゃいいじゃん
- 332 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 06:35:41.08 ID:Ujs4NpLL]
- >>330
とよひこ君はまだわからないのか
githubじゃなければ、リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
- 333 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 06:37:10.90 ID:Ujs4NpLL]
- >>329
pullするだけですべてうまく行くと思ってるのは幻想だ
ちゃんと勉強したほうがいいな
- 334 名前：デフォルトの名無しさん [2014/05/02(金) 08:09:07.29 ID:ZGvM0amq]
- わざわざvcsの勉強なくて無価値なことはしたくもないね
- 335 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 08:29:32.57 ID:Ujs4NpLL]
- Gitに関しては勉強する価値があった
正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
- 336 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 11:30:23.12 ID:W9jDDFpi]
- パスワードを含んだファイルがあるんですけど
このファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
- 337 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 13:03:04.92 ID:pbdRog+k]
- >>336
$ touch password.txt; git add password.txt; git commit
$ git update-index --skip-worktree password.txt
$ echo -n 'himitsu' > password.txt; git status
On branch master
nothing to commit, working directory clean
とか？
- 338 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 13:06:17.10 ID:Pfd+HO5D]
- >>332
> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
- 339 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 13:17:21.62 ID:Oia8PEO/]
- >>336
aaa.confってファイル名だとしたら
.gitignoreにaaa.confを登録してaaa.conf.sampleみたいなファイル名で
コミットしておくのが多いんでないかな
- 340 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 14:47:13.55 ID:Ujs4NpLL]
- >>338
話の流れを読めないアホなのか？>>216が話のはじまりだ
別に本人が / 以外でいいのならそれでいいぞ
ただし、\ で区切るのは勘弁してくれ
- 341 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 15:06:33.45 ID:WqSAbr7K]
- User/repository.gitが
User/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
- 342 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 17:26:31.17 ID:BNaPh7J8]
- % git clone .../User/php-oreore.git php/oreore.git
すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
- 343 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 17:34:19.17 ID:XSE+HkNu]
- C:￥testからD:￥testに移動したいんですけど
ファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
- 344 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 17:44:12.24 ID:BNaPh7J8]
- >>343
わからん。ありそうなのは .git/config だが、
適切に答えるには情報が不十分かつ不正確。
- 345 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 17:53:43.03 ID:XSE+HkNu]
- C:￥testでgit initして適当にファイルを作ってコミットして
C:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
- 346 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 18:06:55.59 ID:+HIQMOvh]
- 全く再現しねえな
- 347 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 18:07:33.93 ID:XSE+HkNu]
- eeeeeeeeeeee
- 348 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 18:14:47.14 ID:+HIQMOvh]
- GitBushから
cd /c/temp
mkdir git
cd git
mkdir test1
cd test1
git init
vim README
git add .
git commit -m "initial commit"
エクスプローラで
Cドライブ(C:\Temp\Git\Test1)を右クリックメニューでコピー
Dドライブ(D:\Temp\Git)にて右クリックメニューから貼り付け
GitBushから
cd /d/temp/git/test1
(ちゃんとmasterって表示になった)
git log
(ちゃんとinitial commitのコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
- 349 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 18:23:12.12 ID:3JApfdBs]
- おかしいな・・・またあとできます
- 350 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 20:15:24.71 ID:dlumt8FZ]
- Gitのこともほとんど具体的な操作方とか知らないままなんだけど、GitHub実践入門を買った
ので、Git操作のお勉強と同時にGithubも使いだした。
- 351 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 20:18:51.30 ID:6MkiwdiC]
- rmした後に全く関係ないファイルをaddするとrmしたファイルのrename扱いになるんですが
単に新規ステージングしたファイル扱いにできますか？
直後にrmしたファイルではなく、始めにrmしたファイルのrenameになっていたり
動作がわけわららんです
- 352 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 20:48:37.15 ID:YmhbMTXU]
- >>337 横レス
設定ファイルとか便利そうだな。覚えておこう。
- 353 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 20:49:12.42 ID:6MkiwdiC]
- どうやら中身が同じファイルは勝手にrename扱いにしてくれるようですね
空ファイルでトレーニングしていたので混乱してしまいました
- 354 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 20:59:01.62 ID:6ajnVdK2]
- >>351
gitのデータ構造としては、ファイルの移動や改名とかは管理してなくて、
表示の時にヒューリスティックに判断してrenameとか出してるだけだから、
気にする必要ないよ。
- 355 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 21:02:26.52 ID:6MkiwdiC]
- >>354
ありがとうございます
そういうものだと、気にしないようにします
- 356 名前：デフォルトの名無しさん [2014/05/02(金) 21:42:27.82 ID:x3xYwsX7]
- gitはファイルではなくコンテンツを管理していると言われる所以だね。
- 357 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 22:17:35.97 ID:Xf1Tcq77]
- gitでhookファイルを変更した場合
これをGitHubにプッシュした阿戸に
ローカルのファイルとリポジトリを削除してからクローンしたらhookファイルの内容がないんですが何故ですか？
- 358 名前：デフォルトの名無しさん mailto:sage [2014/05/02(金) 23:58:46.02 ID:ojQzvTVb]
- こんなGit入門の本を買った。
2ch-dc.net/v4/src/1399042353761.jpg
- 359 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 00:29:50.84 ID:9lt90aGA]
- 喜ぶべきか悼むべきか・・・
- 360 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 01:42:57.16 ID:fa3rSR83]
- >>358
それってどう？
- 361 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 02:05:49.12 ID:Z2xjVVlJ]
- >>357
フックは版管理されてないから。configも同様。
フックをシェアしたいならワーキングディレクトリにフックを置いて、Makefileなりsetupスクリプトからインストールできるようにする。
クローンしただけで勝手にスクリプトに走られたら困る。
- 362 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 02:07:15.00 ID:vyhhlfA3]
- >>360
文章読むだけならGithubで公開されてる
- 363 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 02:11:26.95 ID:Z2xjVVlJ]
- >>353
rmしたファイルのindexに注意。git rm。
git mvはgit addとgit rmを同時にやってくれる。
- 364 名前：デフォルトの名無しさん mailto:sage [2014/05/03(土) 07:45:11.01 ID:n1PIULKZ]
- >>353
中身が似てるファイルね
rename扱いにしてるのはログ表示の時だから、まあ気にしなくていいには変わらない
コピペ検出機能だとでも思っておけ
|
 |
