Git 9
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2014/04/12(土) 13:22:20.98ID:s4x1CSLNGit - 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/
0249デフォルトの名無しさん
2014/04/29(火) 14:26:17.37ID:jiz/CQ6q> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？
> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？
一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。
「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。
ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
0250デフォルトの名無しさん
2014/04/29(火) 14:28:32.84ID:jobIXRFq0251デフォルトの名無しさん
2014/04/29(火) 14:30:18.99ID:GcKmP5Zr0252デフォルトの名無しさん
2014/04/29(火) 14:58:20.39ID:jiz/CQ6q「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。
だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識
もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
0253デフォルトの名無しさん
2014/04/29(火) 15:08:09.46ID:jiz/CQ6qhttp://powerful-code.com/blog/2012/11/merge-or-rebase/
mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。
rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
0254デフォルトの名無しさん
2014/04/29(火) 15:16:46.84ID:jiz/CQ6qかなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。
例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。
これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
0255デフォルトの名無しさん
2014/04/29(火) 15:25:33.99ID:GKmjQvWP> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが
>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの
考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
0256デフォルトの名無しさん
2014/04/29(火) 15:48:55.09ID:+oyspTjVrebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
0257デフォルトの名無しさん
2014/04/29(火) 15:56:19.89ID:jiz/CQ6qそういうことなの？
トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。
rebase && FFはトピックブランチ使わないってことなのかね。
0258デフォルトの名無しさん
2014/04/29(火) 16:01:07.06ID:jiz/CQ6qなるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、
って感じかな。
感謝感謝。
0259デフォルトの名無しさん
2014/04/29(火) 16:15:23.14ID:GKmjQvWPFFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの
まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
0260デフォルトの名無しさん
2014/04/29(火) 16:17:02.13ID:EYu9TTok問題なのは「FF only の masterマージ」だろう？
rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。
さらに言えば、masterへのマージ以外には
当てはまらないだろう？
0261デフォルトの名無しさん
2014/04/29(火) 16:19:03.64ID:EYu9TTok有名なライブラリ例を上げておく。
https://github.com/lodash/lodash/commits/master
0262デフォルトの名無しさん
2014/04/29(火) 16:21:51.52ID:EYu9TTok> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
0263デフォルトの名無しさん
2014/04/29(火) 16:26:11.71ID:jiz/CQ6qいや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
0264デフォルトの名無しさん
2014/04/29(火) 16:29:31.48ID:jiz/CQ6q> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
0265デフォルトの名無しさん
2014/04/29(火) 16:30:46.56ID:+oyspTjVブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
0266デフォルトの名無しさん
2014/04/29(火) 16:30:55.69ID:jiz/CQ6q> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> https://github.com/lodash/lodash/commits/master
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
0267デフォルトの名無しさん
2014/04/29(火) 16:31:51.96ID:EYu9TTok> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
0268デフォルトの名無しさん
2014/04/29(火) 16:40:59.32ID:jiz/CQ6q> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
0269デフォルトの名無しさん
2014/04/29(火) 16:43:19.24ID:EYu9TTok> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
0270デフォルトの名無しさん
2014/04/29(火) 16:51:05.11ID:jiz/CQ6q> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
0271デフォルトの名無しさん
2014/04/29(火) 16:53:09.53ID:EYu9TTok説明してるじゃねーか。
ライブラリの作者じゃないんだから
作者の本当の考えはわからん。
それは当たり前。
それとは別に推測で
ちゃんと説明してる。
0272デフォルトの名無しさん
2014/04/29(火) 16:59:55.32ID:EYu9TTok> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
0273デフォルトの名無しさん
2014/04/29(火) 17:07:40.73ID:EYu9TTok「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
0274デフォルトの名無しさん
2014/04/29(火) 17:14:28.12ID:jobIXRFqマージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
0275デフォルトの名無しさん
2014/04/29(火) 17:18:53.63ID:EYu9TTok・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
0276デフォルトの名無しさん
2014/04/29(火) 18:11:38.86ID:jiz/CQ6qコミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
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も可。
0277デフォルトの名無しさん
2014/04/29(火) 18:12:17.95ID:jiz/CQ6qX-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
を見るのと、どっちがわかりやすいの？ってこと。
0278デフォルトの名無しさん
2014/04/29(火) 18:15:08.80ID:jiz/CQ6q0279デフォルトの名無しさん
2014/04/29(火) 18:24:55.80ID:VGBInRA4どうしてこうなったのかもちろん議論されてるのも知ってるよね
0280デフォルトの名無しさん
2014/04/29(火) 18:25:46.52ID:ABe1tyQZ0281デフォルトの名無しさん
2014/04/29(火) 18:30:04.67ID:qq5sN0hH一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
0282デフォルトの名無しさん
2014/04/29(火) 18:44:21.18ID:jiz/CQ6qpull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
0283デフォルトの名無しさん
2014/04/29(火) 18:45:53.07ID:jiz/CQ6qそうそう。
ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
0284デフォルトの名無しさん
2014/04/29(火) 19:02:08.02ID:ABe1tyQZ0285デフォルトの名無しさん
2014/04/29(火) 19:47:52.24ID:6KBRCzBrというわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
0286デフォルトの名無しさん
2014/04/29(火) 19:56:50.37ID:EYu9TTokね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
0287デフォルトの名無しさん
2014/04/29(火) 19:58:40.00ID:jiz/CQ6q報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
0288デフォルトの名無しさん
2014/04/29(火) 20:21:45.22ID:jobIXRFq0289デフォルトの名無しさん
2014/04/29(火) 23:30:04.09ID:+oyspTjVケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
0290デフォルトの名無しさん
2014/04/30(水) 00:35:08.42ID:UGHSixxv0291デフォルトの名無しさん
2014/04/30(水) 01:11:54.22ID:pWom3qZR0292デフォルトの名無しさん
2014/04/30(水) 01:29:11.37ID:Gbwo+6jG0293デフォルトの名無しさん
2014/04/30(水) 05:04:21.07ID:mdKtpEfXremote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
0294デフォルトの名無しさん
2014/04/30(水) 08:30:44.87ID:1vNQkGgCってかいてあんじゃん
0295デフォルトの名無しさん
2014/04/30(水) 11:02:23.25ID:4gXDKzV20296デフォルトの名無しさん
2014/04/30(水) 14:42:09.85ID:mdKtpEfXそれも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
0297デフォルトの名無しさん
2014/04/30(水) 14:48:31.80ID:mdKtpEfX半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
0298デフォルトの名無しさん
2014/04/30(水) 14:55:49.07ID:nKoANYQ+0299デフォルトの名無しさん
2014/04/30(水) 18:26:55.40ID:mdKtpEfX0300デフォルトの名無しさん
2014/04/30(水) 18:51:13.84ID:h9gMUOtrコンフリクト恐怖症になってしまったのか
0301デフォルトの名無しさん
2014/04/30(水) 18:51:51.42ID:rHgIYikHBリポジトリに反映する方法を教えてください
0302デフォルトの名無しさん
2014/04/30(水) 18:59:19.90ID:1L5gAVQyディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
0303デフォルトの名無しさん
2014/04/30(水) 19:12:36.93ID:ZY5HChQC0304デフォルトの名無しさん
2014/04/30(水) 19:50:56.80ID:fWhizGrM0305デフォルトの名無しさん
2014/04/30(水) 19:56:34.41ID:EonfyA0Y0306デフォルトの名無しさん
2014/04/30(水) 20:25:07.89ID:WuyiDL68> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
0307デフォルトの名無しさん
2014/04/30(水) 21:19:26.86ID:livyiFPX> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
0308デフォルトの名無しさん
2014/04/30(水) 21:28:01.99ID:upmIhAH5プロジェクト名に言語が入ってないとなんの言語で作ってるのかわからないじゃん
言語を変えたらリポジトリ名を変更すればいいじゃん
0309デフォルトの名無しさん
2014/04/30(水) 21:58:49.74ID:Y0BKcERE悪いことは言わないから足を洗え。
0310デフォルトの名無しさん
2014/04/30(水) 22:12:33.53ID:livyiFPXgitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
0311デフォルトの名無しさん
2014/04/30(水) 22:41:41.21ID:rUdHCEgh0312デフォルトの名無しさん
2014/04/30(水) 22:42:55.54ID:livyiFPX複数言語でアプリ作るのは一般的だけど？ｗ
0313デフォルトの名無しさん
2014/04/30(水) 23:26:12.17ID:mdKtpEfX管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
0314デフォルトの名無しさん
2014/04/30(水) 23:51:07.78ID:1vNQkGgCめでたしめでたし
0315デフォルトの名無しさん
2014/05/01(木) 00:28:44.24ID:WukXr8jqプロジェクトを1つのディレクトリに詰め込むタイプですか？
0316デフォルトの名無しさん
2014/05/01(木) 09:28:45.91ID:PzUwUPDQ意味がわからないなあ
コミットしたものを権限持ちに既に送ってあるとしたら、
お前が上流からマージしようとしたブランチは一体何なの？
お前がコミットしたものを含んでいないブランチ？
0317デフォルトの名無しさん
2014/05/01(木) 11:07:25.45ID:PVO7jj2iなんでそんな発想が出てくるんだ？ (w
0318デフォルトの名無しさん
2014/05/01(木) 11:24:48.42ID:/DVUm5pophp/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
0319デフォルトの名無しさん
2014/05/01(木) 17:12:30.25ID:PzUwUPDQそれとGitと何の関係があるんだ？
0320デフォルトの名無しさん
2014/05/01(木) 17:20:29.51ID:U31MyfYFC:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
0321デフォルトの名無しさん
2014/05/01(木) 17:24:28.79ID:n23f7Uie0322デフォルトの名無しさん
2014/05/01(木) 17:44:02.84ID:PzUwUPDQそんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
0323デフォルトの名無しさん
2014/05/01(木) 17:52:02.03ID:U31MyfYF複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
0324デフォルトの名無しさん
2014/05/01(木) 18:01:12.45ID:n23f7Uie0325デフォルトの名無しさん
2014/05/01(木) 18:13:02.15ID:ZgnY/tZGコードネームつければいい。
phpは犬の種類、rubyは猫の種類とか原則を持たせても良い。
0326デフォルトの名無しさん
2014/05/01(木) 19:05:29.45ID:PzUwUPDQgithubがリポジトリを「https://github.com/ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
0327デフォルトの名無しさん
2014/05/01(木) 19:26:56.62ID:3NSQaEE20328デフォルトの名無しさん
2014/05/01(木) 22:47:07.56ID:dcOXu/fEGitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
0329デフォルトの名無しさん
2014/05/02(金) 03:41:26.83ID:ZGvM0amq0330デフォルトの名無しさん
2014/05/02(金) 03:48:34.89ID:PU3lP69mはあ？リポジトリ名の話なのに
＞「https://github.com/ユーザー名/リポジトリ名」
ってなんだよ話そらしてんじゃねえよ
0331デフォルトの名無しさん
2014/05/02(金) 06:22:29.35ID:KJDTZacL0332デフォルトの名無しさん
2014/05/02(金) 06:35:41.08ID:Ujs4NpLLとよひこ君はまだわからないのか
githubじゃなければ、リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
0333デフォルトの名無しさん
2014/05/02(金) 06:37:10.90ID:Ujs4NpLLpullするだけですべてうまく行くと思ってるのは幻想だ
ちゃんと勉強したほうがいいな
0334デフォルトの名無しさん
2014/05/02(金) 08:09:07.29ID:ZGvM0amq0335デフォルトの名無しさん
2014/05/02(金) 08:29:32.57ID:Ujs4NpLL正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
0336デフォルトの名無しさん
2014/05/02(金) 11:30:23.12ID:W9jDDFpiこのファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
0337デフォルトの名無しさん
2014/05/02(金) 13:03:04.92ID:pbdRog+k$ 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
とか？
0338デフォルトの名無しさん
2014/05/02(金) 13:06:17.10ID:Pfd+HO5D> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
0339デフォルトの名無しさん
2014/05/02(金) 13:17:21.62ID:Oia8PEO/aaa.confってファイル名だとしたら
.gitignoreにaaa.confを登録してaaa.conf.sampleみたいなファイル名で
コミットしておくのが多いんでないかな
0340デフォルトの名無しさん
2014/05/02(金) 14:47:13.55ID:Ujs4NpLL話の流れを読めないアホなのか？>>216が話のはじまりだ
別に本人が / 以外でいいのならそれでいいぞ
ただし、\ で区切るのは勘弁してくれ
0341デフォルトの名無しさん
2014/05/02(金) 15:06:33.45ID:WqSAbr7KUser/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
0342デフォルトの名無しさん
2014/05/02(金) 17:26:31.17ID:BNaPh7J8すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
0343デフォルトの名無しさん
2014/05/02(金) 17:34:19.17ID:XSE+HkNuファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
0344デフォルトの名無しさん
2014/05/02(金) 17:44:12.24ID:BNaPh7J8わからん。ありそうなのは .git/config だが、
適切に答えるには情報が不十分かつ不正確。
0345デフォルトの名無しさん
2014/05/02(金) 17:53:43.03ID:XSE+HkNuC:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
0346デフォルトの名無しさん
2014/05/02(金) 18:06:55.59ID:+HIQMOvh0347デフォルトの名無しさん
2014/05/02(金) 18:07:33.93ID:XSE+HkNu0348デフォルトの名無しさん
2014/05/02(金) 18:14:47.14ID:+HIQMOvhcd /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のコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
■ このスレッドは過去ログ倉庫に格納されています