トップページ⇒tech
984コメント273KB

Git 6

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2013/05/21(火) 11:26:36.94
ソースコード管理を行う分散型バージョン管理システム、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 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/
0322デフォルトの名無しさん2013/09/11(水) 21:32:36.70
>>320
MS-OFFICEファイルのdiffだけだったら、TortoiseのDiff-Scriptsでも使えば
綺麗に表示できるよ。

マージができない大欠点はどうにもならないけど。
0323デフォルトの名無しさん2013/09/11(水) 21:59:40.08
>>321
特定のディレクトリを指定して clone するのは無理だと思うが
特定のブランチだけをフェッチする操作ならできる。
0324デフォルトの名無しさん2013/09/11(水) 22:14:28.71
>>320のはコメントを読んだ方がいいよ
いや別に何もよくはならないけど
0325デフォルトの名無しさん2013/09/11(水) 22:21:36.31
>>319
> オフィスのドキュメントのよーなバイナリ形式で扱うのが間違い

働いたことないんだろうな...
0326デフォルトの名無しさん2013/09/11(水) 23:04:40.89
文章はTeXにしている俺に死角は無かった
0327デフォルトの名無しさん2013/09/11(水) 23:32:45.56
オープンソースプロジェクトでdocとかodtそのまま突っ込んでいるのは見た事ないぜ
0328デフォルトの名無しさん2013/09/11(水) 23:44:04.11
それ以上にTeX突っ込んでいるの見た事ないぜ
0329デフォルトの名無しさん2013/09/11(水) 23:44:50.09
時代はmd
0330デフォルトの名無しさん2013/09/12(木) 01:27:09.68
>>321
cvsを使う。
0331デフォルトの名無しさん2013/09/12(木) 01:55:33.54
>>318
＞コミットしてしまった後で後悔することの多くをgitなら直すことが可能
そこは利点ではなく欠点だろう。
0332デフォルトの名無しさん2013/09/12(木) 01:58:51.25
>>331
何が欠点なの？

お前はミスをしないというのか？
変なことを言うやつだな。

なぜgitが歴史を変更できる手段を持っているのか
その理由を考えたことはあるのか？
0333デフォルトの名無しさん2013/09/12(木) 02:16:01.50
>>332
そういうのを手元でやってるうちはいいけどな
ローカルと同じ感覚でやられると非常に迷惑
0334デフォルトの名無しさん2013/09/12(木) 03:51:13.42
パスワードを書いたファイルをコミットしちゃった、、とかかｗ
0335デフォルトの名無しさん2013/09/12(木) 07:05:56.17
>>333
こういうやり取り見てると、まだ SVN でいいや...
と、思う。
0336デフォルトの名無しさん2013/09/12(木) 07:55:06.28
>>333
ローカルとリモートの区別があるから、
そういうことをローカルに手元でできるのがいいんじゃない
0337デフォルトの名無しさん2013/09/12(木) 08:38:16.74
>>307
git-svnの運用は諦めた
0338デフォルトの名無しさん2013/09/12(木) 10:12:33.52
>>336
普通に考えて、push済みのcommitに対してやらかしてはまるバカがいるってことでしょ。
そういう奴は、なんでやっちゃダメなのか理解できてないんだろうし。
0339デフォルトの名無しさん2013/09/12(木) 11:14:10.39
push済みのコミットを上書きさせないようにすることもできるし、
push自体をできなくしてpull request使うとかすればいい
0340デフォルトの名無しさん2013/09/12(木) 11:17:23.02
githubからパスワードが書かれたファイルを履歴を含めて完全に抹消する方法を至急おしえてｋづあしあ！
急いでます
0341デフォルトの名無しさん2013/09/12(木) 11:21:15.95
首吊れば完全末梢できるよ
0342デフォルトの名無しさん2013/09/12(木) 11:22:15.24
>>340
Githubに上げたパスワード削除
でググレ
0343デフォルトの名無しさん2013/09/12(木) 11:25:13.18
gitを使う上で起こりうるトラブルを全部おしえて
0344デフォルトの名無しさん2013/09/12(木) 11:26:44.94
>>343
gitを使う上で起こりうるトラブル
でググレ
0345デフォルトの名無しさん2013/09/12(木) 11:52:09.75
>>316
ロックさせたければ VSS をつかえって感じだが、
それはともかく、ロックしたければ subversion だと svn lock があるが、
git にはそういうのないんだっけ？
0346デフォルトの名無しさん2013/09/12(木) 12:14:48.47
http://localhost/ripojitori/daikibo/site/library/内のファイルを5人で作業します
A君はdatabase.phpを作業して
B君はview.phpとlang.phpを作業して
他の人は別のファイルを作業します

んで、A君はチーム作業を無視してview.phpを勝手に編集してプッシュしちゃう可能性があります
こういう場面はどうやって作業するんでしょうか？
0347デフォルトの名無しさん2013/09/12(木) 12:29:23.41
誰か一人がpushするようにする
ほかの人はその人にpullリクエストを送ってマージしてもらう
0348デフォルトの名無しさん2013/09/12(木) 12:30:07.64
>>346
A君はdatabase.phpを編集するといっても自分の好きにデタラメ編集してもいいってわけじゃないだろ？
バグを作りこめは当然修正する必要がある
A君が自分のdatabase.phpにバグを作りこむのも、自分の担当じゃないview.phpを編集してしまうのも、一緒だろ？
履歴が残るんだからもしA君がview.phpを編集したコミットがあったら、それをrevertさせればいい
0349デフォルトの名無しさん2013/09/12(木) 12:30:18.88
>>345
ない。
0350デフォルトの名無しさん2013/09/12(木) 12:33:31.00
Gitにファイルロックとか追加されても激しく面倒というかまともに機能しないだろうから
どうしても必要な奴らはプロジェクト管理ツールのレベルでそういう機能を用意すればいいだろう
0351デフォルトの名無しさん2013/09/12(木) 12:37:57.51
>>345
分散型の思想に反する機能なので無理
0352デフォルトの名無しさん2013/09/12(木) 13:09:45.36
分散型の思想とかそんな高尚な観点から来てるわけじゃなく、author管理と
リポジトリのアクセス権限管理を別にしてしまってるところからして無理。
0353デフォルトの名無しさん2013/09/12(木) 18:03:53.50
>>340
履歴上のファイル削除ならフィルタ掛けて一括削除みたいば事で出来るって本に書いてあったな。
0354デフォルトの名無しさん2013/09/12(木) 18:42:32.66
Mercurialにはクライアント側でファイルアクセスを禁止する
ロックの拡張機能があったけど
使い物になるのかどうか
0355デフォルトの名無しさん2013/09/12(木) 20:36:42.01
>>351 が正解
どんなにロックしても、gitに慣れた者ならばローカルにcloneしてpushする瞬間だけロックを取得するような使い方をするようになるだろうから意味ない。
例えばVSSの場合だったら、ロック中のファイルを編集するために別のフォルダに退避して、ロックが外れた時に上書き保存するようになる。
バージョン管理が不慣れな者にとってはロック方式が馴染みやすいかもしれないけど、そういう者はgitは使えないから関係ないし。
0356デフォルトの名無しさん2013/09/12(木) 20:52:37.22
>>333
> そういうのを手元でやってるうちはいいけどな
> ローカルと同じ感覚でやられると非常に迷惑

履歴の修正っていうのは、ローカルでやる作業なんだけど、
ローカルと同じ感覚でやられると迷惑ってどういうこと？

レスの内容によっては、お前が使い方わかってないだけじゃんってことになりそうだが。
0357デフォルトの名無しさん2013/09/12(木) 20:56:09.73
間違った使い方をする奴は迷惑。
それって何使っても当てはまるだろう。

subversionを1ファイルずつコミットする奴は迷惑。
ほらなｗ

間違った使い方をするのは、そいつが迷惑という話であって、
gitの問題ではない。
0358デフォルトの名無しさん2013/09/12(木) 21:09:16.44
>>355
> 例えばVSSの場合だったら、ロック中のファイルを編集するために別のフォルダに退避して、ロックが外れた時に上書き保存するようになる。

ならねーよ。
0359デフォルトの名無しさん2013/09/12(木) 21:18:19.14
add してcommitしたあとにpushするじゃないですか
pushする前に他の人が先にpushするかもしれないのでfetch & mergeしてからpushしたほうがいいのでしょうか？
0360デフォルトの名無しさん2013/09/12(木) 21:25:25.46
>>359
fetch? pullじゃなくて？
0361デフォルトの名無しさん2013/09/12(木) 21:28:16.00
pullしちゃいけなくてfetch & mergeがいいって記事みたんです
0362デフォルトの名無しさん2013/09/12(木) 22:35:46.28
>>357
svnを使い慣れた人間にgitを使わせる場合には、gitとしての使い方を教育せずに
gitを使わせるような奴はそいつが悪いってことになる。
0363デフォルトの名無しさん2013/09/12(木) 22:50:22.66
>>337
何で?
自分は満足なんだけど、誰も使ってないみたいだから大きな穴があるんじゃ
無いかと気になってる。
0364デフォルトの名無しさん2013/09/12(木) 23:00:32.67
>>337じゃないけど、git-svnを使うと結局svnから逃れられなくなる。

それは単純にsvnだけ、gitだけを使うよりも難しい作業を強いられることになる。

gitのノウハウにもgit-svnを使った例は少ない。

github及び、githubクローンであるgitlabを使うときどうするのかよくわからない。

何をするにも、gitだけだとこうやるけど、そこにgit-svnがくると・・・などという話が
いつまでも付きまとってくる。

穴があるというよりも大変。
0365デフォルトの名無しさん2013/09/12(木) 23:05:01.67
>>363
自分も使ってるけど、今のところ運用で詰んだことはないな。
0366デフォルトの名無しさん2013/09/12(木) 23:09:50.78
>>365
開発では？

gitの特色である開発中にいくつもブランチ作って
幾つものブランチを切り替えて
歴史を修正しながら、小さな修正で
開発するってことが普通に出来るの？
0367デフォルトの名無しさん2013/09/12(木) 23:15:25.90
>>355
cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

gitの場合、pushをcommit、pullをupdateに置き換えてかんがえれば、svnからの移行もしやすいんじゃないかな。
gitはあくまで、ローカル作業がより便利になっただけだよ。
0368デフォルトの名無しさん2013/09/12(木) 23:22:43.70
> gitはあくまで、ローカル作業がより便利になっただけだよ。
そうなんだよな。

ソースコードはサーバーで一元管理するもの。
逆に言えば、ローカルにあるものはソースコードの管理というよりも
開発そのもの。だからgitは開発がより便利になる。

ステージングとかいいよ。

開発してる時に、小さなミスを見つけて、それだけコミットしたいと思うだろう？
gitなら、git addでファイルの ”一部分” だけをステージング（ようはコミット予定リスト）し
あちこち修正途中のファイルがあったとしても、簡単にファイルの一部分だけをコミットすることができる。

svnだったら開発中によくある面倒なことを
gitであれば楽にこなしてしまう。
0369デフォルトの名無しさん2013/09/13(金) 00:00:07.94
svnだエラーの出る状態でコミットするなとか言い出す人が多かったな。
エラーの出る状態から作り直して失敗したらどうするんだ。
svnでもブランチとか適切に運用できていればいいんだろうけど。
0370デフォルトの名無しさん2013/09/13(金) 00:18:00.21
>>369
gitでもエラーの出る状態で入れないでよ
0371デフォルトの名無しさん2013/09/13(金) 00:19:09.17
ローカルで正しく直してからプッシュするというのなら
エラーが出る状態でもいいかな。
0372デフォルトの名無しさん2013/09/13(金) 00:34:16.73
エラーが出る出ない以前に
作業途中でコミットするのが納得できんな

単に途中経過を保存したいならstashがあるし
途中経過を他の人に見てもらいたいならMLや掲示板とかの方がいいだろう
0373デフォルトの名無しさん2013/09/13(金) 00:39:20.59
>>372
stashはpopという引数があることからもわかるように
スタックという考え方が基礎になってるんだ。

作業途中の割り込み、の割り込み、の割り込み
といった用途で使うもの。

作業途中のコミットは、
いくつかの作業を並行して行っている場合に使う。

Aという作業をやっている途中で、
Bという作業をやってさらに
Cという作業に移ってAという作業に戻る。
と思ったら、Cという作業を進めなくてはならなくて
次はBみたいな。
0374デフォルトの名無しさん2013/09/13(金) 00:54:59.34
stashはpullとかmergeする際の本当に一時的な退避にしか使わない
時間が経つとstashしておいた事実を(俺が)忘れてしまう
作業が割り込む場合は作業ブランチ切ってコミットしてる
0375デフォルトの名無しさん2013/09/13(金) 00:59:35.14
>>367
それはロックの本質をわかってない
0376デフォルトの名無しさん2013/09/13(金) 01:16:04.64
>>372
あとでそのエラーになった修正を使いたくなるかも知れないじゃないか。
それにチケットと関連付ける時にソースもあった方がわかりやすい。
公なとこにpushするなら、その前にまとめればいいだけだし。人のローカルリポジトリに口出しするとか、わけわからんわ。
0377デフォルトの名無しさん2013/09/13(金) 01:16:57.33
mercurialがいろいろ縛った理由をちょっと理解できた気がする
0378デフォルトの名無しさん2013/09/13(金) 01:24:20.08
> 人のローカルリポジトリに口出しするとか、わけわからんわ。
っ鏡
0379デフォルトの名無しさん2013/09/13(金) 07:30:06.93
まあ言ってることが自己矛盾してるわな
0380デフォルトの名無しさん2013/09/13(金) 08:58:47.04
作業途中でコミットできるのがgitのいいところじゃないか。
手元でずいぶん変更したけど まだビルド通らない/テスト通らない/バグが直りきってない ときにコミット我慢するの？
途中まで実装したけどやってみると案外うまくいかないな。もう一つの案をで実装してみるか、ってときにその瞬間のコードをコミットしないの？
03813802013/09/13(金) 09:15:18.83
作業状態の保存(commit)と成果物の公開(push)を分離したところがgitの改善点だろ。
svnと同じタイミング・粒度でしかコミットしないという使い方も否定されないとしても、厳しすぎる制約を自ら課しているんだというのは認識しといた方がいいよ
0382デフォルトの名無しさん2013/09/13(金) 09:20:31.22
もう一つの案を実装してみるときはブランチを切る
作業途中ならstashで保存する

これがベストな方法とは言わないし
他人のローカルリポジトリに口出しする気もないが
少なくとも作業途中でコミットする必然性はない
03833802013/09/13(金) 09:24:23.05
ブランチ切るのにコミットしないんだ。ふーん
0384デフォルトの名無しさん2013/09/13(金) 09:24:56.57
svnでもいただろ。「また完成してない」とか言って何週間もコミットしない奴が。
手元に巨大な変更を抱えてて作業コピーの日付バックアップを一生懸命とってるの
0385デフォルトの名無しさん2013/09/13(金) 09:29:58.54
testブランチでコード書いた後は
git checkout master
git merge test
git add -A
git commit -m "ちょめちょめ"
git push

この流れで合ってますか？
0386デフォルトの名無しさん2013/09/13(金) 09:55:25.36
>>384
Gitでは「まだ完成してない」とか言ってpushしない奴ということになるわけですね
0387デフォルトの名無しさん2013/09/13(金) 09:57:59.86
まああれだ。
自由ってのは便利だが、一定のルールで遵守させなければならないと。
0388デフォルトの名無しさん2013/09/13(金) 10:07:57.29
>>385
git add -A は何をやってるの？
0389デフォルトの名無しさん2013/09/13(金) 10:21:23.57
>>386
gitでも「まだ完成してない」と言ってコミットしないよ。きっと。
という今の流れ。

gitはそれこそstashみたいな、コミットしない自由も考慮されてるとは思うけど程度問題だな。
無闇にコミットを避けることはない
0390デフォルトの名無しさん2013/09/13(金) 10:22:55.14
>>388
あれなんですよ
git add .
ってやると、なんかたまにgit add -A使えってメッセージが出るのです
0391デフォルトの名無しさん2013/09/13(金) 10:28:03.32
>>390
git add . は何のためにするの？

＞testブランチでコード書いた後
これはtestブランチで書いたコードをtestブランチへコミット済みって意味？
0392デフォルトの名無しさん2013/09/13(金) 10:28:38.23
>>367
> cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

アホすぎ (w
チームにこんな奴いたら大変だろうな
0393デフォルトの名無しさん2013/09/13(金) 10:29:15.20
いえ、ちがいます
masterブランチに移ってからaddします
0394デフォルトの名無しさん2013/09/13(金) 10:33:52.76
>>393
何のためにtestブランチを作ったの？
0395デフォルトの名無しさん2013/09/13(金) 10:40:32.81
merge だけでコミットされる (衝突がなければ) からその後の add と commit は無駄じゃね
0396デフォルトの名無しさん2013/09/13(金) 11:03:05.11
ソースの頭にインクリメンタルなソースバージョンつけたいんだけど
gitってそういう思想じゃないから無理だよね・・・
どうしようかな
0397デフォルトの名無しさん2013/09/13(金) 11:14:25.46
そんな時にセマンティックバージョニングとかいいんじゃね？
0398デフォルトの名無しさん2013/09/13(金) 12:32:33.83
なんかすごい伸びてるな…

>>366
できるよ。自分だけだけど。
0399デフォルトの名無しさん2013/09/13(金) 12:50:29.91
testブランチにコミットしていって、
ファイナルちょめちょめの後でmasterへマージ
0400デフォルトの名無しさん2013/09/13(金) 13:14:13.68
gitを拡張することって言うのはできますか？
たとえば、git commit ってしたらc:\my.logに日時を記録する感じの機能をgitに組み込むなど
0401デフォルトの名無しさん2013/09/13(金) 14:11:16.05
できるよ
0402デフォルトの名無しさん2013/09/13(金) 19:15:58.04
>>400 適当なリポジトリで.git/hooksディレクトリの中身を読もう
0403デフォルトの名無しさん2013/09/13(金) 20:56:48.98
>>384
いまどきのIDEだとローカルの作業履歴位はとってくれてるんだけどね。
コミットコメントが有るわけじゃないから何をやってたか分からないけど
ローカルの作業履歴としては割りと機能する。 テキストエディタ以外は
認めないって人には分からないだろうけど。
0404デフォルトの名無しさん2013/09/13(金) 21:39:01.30
Eclipseの履歴だと最低限は役に立つけどマージしたりスナップショット取ったり明示的にやれるわけじゃないし
0405デフォルトの名無しさん2013/09/13(金) 21:52:13.00
>>400
gitのコミットログを見ればいいだけじゃん？
なんでわざわざ別に出力すんの？
0406デフォルトの名無しさん2013/09/13(金) 22:44:41.16
>>403
エディタの編集履歴が便利なことは否定しないが、複数ファイルのスナップショットに名前をつけて保存できる機能とは区別しようぜ
0407デフォルトの名無しさん2013/09/13(金) 22:55:30.79
>>363
git-svnだとマージに非常に制限がかかる。
そうなるとコンフリクトを恐れるようになって、いちいち手が止まってしまいストレスになる。
0408デフォルトの名無しさん2013/09/13(金) 22:59:55.68
msysgitでdaemon立ち上げてリモートからpullやcloneしようとしたとき、たまにエラーになることが
あるんだが、原因を調べるには何を調べればいいかな？
表示されるエラーメッセージはInvalid Argumentとかearly EOFとかだけなんで意味わからん。
0409デフォルトの名無しさん2013/09/13(金) 23:20:49.68
--verbose 付きで起動してみれば？
0410デフォルトの名無しさん2013/09/13(金) 23:21:47.67
>>407
よく知らんのだけどrebaseじゃダメなの？
0411デフォルトの名無しさん2013/09/14(土) 00:15:42.09
>>389
分散型だと中央を通さずに変更を渡すことが簡単だから、一部にだけ変更を伝えるという方法もあるね。

分散型はまだまだ色々な使い方ができそう。まあ運用を決めてもらわないと何もできない人には制限された方がいいんだろうけど。
0412デフォルトの名無しさん2013/09/14(土) 00:16:03.03
>>407
dcommit時にコンフリクトするとどうなるの?
いつもrebaseしてからdcommitしてたから、意図せずマージになってたことは
ほとんど無くて、コンフリクトしたことがない。
0413デフォルトの名無しさん2013/09/14(土) 00:40:38.03
>>412
rebaseあんまり使わないから向いてないのかも。
他のブランチでは気にせずgitらしくマージを繰り返してそれを中央リポジトリで公開して、いざsvn用のブランチに取り込もうとしてrebaseではまることが多かった。
0414デフォルトの名無しさん2013/09/14(土) 00:44:26.35
ローカルでグチャグチャやってる分に口出す気はないよ。
それを上に持ってくんな ということを言っている。
0415デフォルトの名無しさん2013/09/14(土) 00:48:55.25
それ結局GitでもSVNでも同様だろ？
0416デフォルトの名無しさん2013/09/14(土) 00:57:23.13
>>408
git config --global core.compression -1
でどうでしょう
04174082013/09/14(土) 07:24:34.77
>>409
それが、付けてもなんもわからなくて。
せめて、何に渡した何というArgumentがどうInvalidなのかくらいわかればいいんだが。

>>416
よくわからんが、エラーが出た箇所からすると関係ありそうな気がするな。
環境は会社なんで週明けに試してみるわ。ありがとう。
0418デフォルトの名無しさん2013/09/14(土) 09:18:19.06
>>405
なんか自動化したいんだろ
0419デフォルトの名無しさん2013/09/14(土) 10:29:28.80
>>412
rebase しないと dcommit できないんじゃないか。
0420デフォルトの名無しさん2013/09/14(土) 10:42:48.85
>>419
dcommit時にマージされます。ローカルからはそう見える。
svn上では、update→commitに見えると思う。
0421デフォルトの名無しさん2013/09/14(土) 14:16:33.20
>>405
複数人へのgit教育用にコミットしているかをひとつのログに集めたいから
■ このスレッドは過去ログ倉庫に格納されています