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/

0263デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

stashという便利なコマンドがあるんですね！勉強になりました

0264デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

>>251

Gitポケットリファレンス
http://www.amazon.co.jp/dp/477415184X

の71ページに書いてある。
まさにコミットしてはいけないパスワードファイルをコミット
してしまった場合の対応。

git filter-branchコマンドを利用するらしい。
更にその後reflogも消すためにgit gcを行う。

細かいやり方は書くだけでも面倒くさいので
本を見るか、ぐぐってくれ。

0265デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>251
こういうのってどうやって管理するのがいいの？
gitでコミットするファイル内では別ファイルを読み込む形にして、その別ファイルは.gitignoreに追加するのとかいいかなと思うんやけど。。
oauthライブラリ作ってて同じことやったことある

0266デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>262
これかぁ。
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88

知らなかったや。
結果的には、同じになりそうだけれど、filter-btanchだと、他のブランチにも影響してくれるみたいだね。

>>265
本物のデータファイルを管理下に配置するのが間違いだと思う。
あと、個人的には、addのとき手抜きしないとかかなぁ
GUIだと難しそうだけど。。。。

#久しぶりに規制とれたさて、いつまで持つやら

0267デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

password.yml はリポジトリに入れない。
間違ってコミットしないように、.gitignoreに指定しておく。
代わりにpassword.yml.sample をリポジトリに入れる。

0268デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>264
宣伝成功！！！！！

0269デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

コミットをするタイミングがわかりません
やっぱり仕事でやるならコミットもきれいにしないといけないのでしょうか？
ちょっと更新したらコミットとかやめるべきですか？

0270デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>269
細かい更新でコミットするのは問題ない
むしろやった方がいい。

コミットは単なるファイルセーブじゃないんで、
コミット＝アプリが正しく動く状態にしないといけない。

でかい機能追加であっても、正しく動く状態を保ちつつ
小さい修正を繰り返して開発できるはず。
その小さい修正ごとにコミットする。

リモートリポジトリに送信しない限り
歴史は自由に書き換え可能なのだから
最終的にバグやミスがないコミットの連続になる。

これを開発用のブランチで行う。
最終的にmasterにマージするときに
一つのコミットにまとめるかどうかは方針次第。

0271デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

俺は動かない状態でも一時的な作業用のブランチ作ってコミットするのはよくやる (workとか、それとわかりやすい名前がいい)
動く状態になったらちゃんとしたブランチに merge --squash して作業ブランチ削除、みたいな感じ

0272デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

履歴に残さない一時的なコミットなら
どうでもいいよ。

0273デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

全プッシュ！
全プッシュ！

0274デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

へ？git push 以外になんか引数必要だっけ？へ？

0275デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

git push するときに　up streamだかなんかってエラーがでたんですけど
どういうことかわかりません

0276デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>275
たぶん、現在のブランチがリモートブランチと紐づいてなくて、どこにプッシュすればいいのかわからんのです
git push origin master
みたいに指定すればプッシュできませんか？

0277デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

たぶんそれかもしれません
やってみます

0278デフォルトの名無しさん

2013/09/03(火) 21:06:55.92

githubで複数のpull requestをtestブランチで送られてきた場合どうすればいいんですか！？
そのままマージボタンを1個ずつおしちゃっていいのですか！？コンフリクトしますよね？
それともひとつローカルに映して手作業でコミットとプッシュを繰り返すのでしょうか！？

これが怖くてpull request全部無視

0279デフォルトの名無しさん

2013/09/03(火) 21:31:38.54

先着順にマージして、コンフリクトするようなら
送り主にそっちでrebaseし直してくださいやがれって言えばいい

0280デフォルトの名無しさん

2013/09/03(火) 22:10:32.92

どんな状況であれローカルでpull・mergeすれば結果はいかようにでもできるはずだが

0281デフォルトの名無しさん

2013/09/05(木) 00:18:19.85

GitHubで非公開リポジトリを作った場合に
その中に作られるWikiも非公開になるんでしょうか？

0282デフォルトの名無しさん

2013/09/08(日) 02:46:33.90

.git のあるディレクトリごとzipで圧縮したファイルを
電子メールでやりとりすれば
githubいらないな

0283デフォルトの名無しさん

2013/09/08(日) 03:58:07.60

.git のあるディレクトリごとzipで圧縮したファイルを
電子メールでやりとりのが大変すぎるから
github必要だな

0284デフォルトの名無しさん

2013/09/08(日) 09:49:38.39

.gitで管理しているディレクトリがＡ君とＢ君で違うとダメなきがするんですけど

0285デフォルトの名無しさん

2013/09/08(日) 10:11:36.86

そもそも分散リポジトリの意味がないきがするんですけど

0286デフォルトの名無しさん

2013/09/08(日) 12:09:28.04

A君とB君はそれぞれローカルリポジトリを持ってそこで作業する

修正を相手に送りたいときはローカルリポジトリのコピーをメールで送る

メールで送られてきたリポジトリは自分のローカルリポジトリとは別の
場所に展開して、そのリポジトリからpullして相手のコミットを取り込む

これならおｋ？

0287デフォルトの名無しさん

2013/09/08(日) 12:11:00.91

なぜパッチセットでもバンドルでもなくリポジトリ全部を送るのよ

0288デフォルトの名無しさん

2013/09/08(日) 12:28:36.07

リポジトリ全部を送る話をしてるからだよｗくうきよめｗ

0289デフォルトの名無しさん

2013/09/08(日) 12:51:31.46

作業中のファイルがあるディレクトリを丸ごとzipで圧縮して
外付けHDDかなんかに貯めていけば
gitもいらないな

0290デフォルトの名無しさん

2013/09/08(日) 12:53:02.34

>>286
俺が前にこのすれで質問したことあるけど
リポジトリを別のフォルダに移動したいとき、そのまま移動したらおかしくなったよ
だからむり

0291デフォルトの名無しさん

2013/09/08(日) 12:55:51.27

>>286みたいなアホな使い方でもGitの効果は絶大だぞ
作業ディレクトリを丸ごとZipで溜めていくなんかとは全然違う

0292デフォルトの名無しさん

2013/09/08(日) 12:57:33.04

GitってPythonでできてるんですよね
何でPythonインストールしてないのに動くんでしょうか？

0293デフォルトの名無しさん

2013/09/08(日) 13:02:42.59

>>290
普通にできる。前スレ670でリポジトリの移動がうまくいかないとか言ってたやつか？
お前のやり方がマズイだけという結論になっただろ。

0294デフォルトの名無しさん

2013/09/08(日) 13:03:07.03

>>292
どこソースよ

0295デフォルトの名無しさん

2013/09/08(日) 13:03:22.30

>>292
GitはC言語。一部Perlとかのスクリプトも使ってるけど。

0296デフォルトの名無しさん

2013/09/08(日) 13:16:26.38

>>282
git自体に差分をメールにする機能があるのに。
あと圧縮は本質でなくて、アーカイブな。
あと.git以下か、bearだけていいだろ。

0297デフォルトの名無しさん

2013/09/08(日) 17:09:42.99

git daemon立ち上げるという選択肢はどうですか

0298デフォルトの名無しさん

2013/09/08(日) 18:09:19.54

>>289
それはただの簡易バックアップ、バージョン管理じゃない。

0299デフォルトの名無しさん

2013/09/08(日) 21:34:25.40

>>296
クマー

0300デフォルトの名無しさん

2013/09/08(日) 21:35:37.82

>>292
Mercurialと間違えてるだろ

0301デフォルトの名無しさん

2013/09/09(月) 11:40:51.66

gitの使い方覚えるつもりない人とgit使うためには
ディレクトリまるごとコピーして
>>282
みたいにすればいい

0302デフォルトの名無しさん

2013/09/09(月) 11:44:11.39

githubに公開する部分と
公開できない部分を

非公開フォルダー/公開フォルダー

みたいに分割すると落だけど
間違って非公開のを公開してしまいそうで

非公開フォルダー

かなり違う場所/公開フォルダー

にしてる

0303デフォルトの名無しさん

2013/09/09(月) 21:32:38.01

SVNほのうが簡単、わかりやすい

0304デフォルトの名無しさん

2013/09/10(火) 02:03:53.65

svnでgitと同じように運用しようとすると難しすぎる。使いこなすとsvnには戻れない。

0305デフォルトの名無しさん

2013/09/11(水) 10:01:01.01

>>303
SVNが分かりやすいと言ってSVNを使い続けるのもアリだけど、最終的にはGitがSVNよりも優れていることに気付いて「何でもっと早くGitを理解しなかったんだろう」と後悔することになる…かもしれない。

こういう違いがあるんだくらいはGitの事、分かってあげてほしいな。

0306デフォルトの名無しさん

2013/09/11(水) 10:51:34.49

優れているかどうかなんて、使い方次第じゃね？
Gitなりの使い方しないなら意味ないし。

0307デフォルトの名無しさん

2013/09/11(水) 10:56:06.33

git-svnで満足

0308デフォルトの名無しさん

2013/09/11(水) 11:31:02.67

うむ。結局の所、両方知ってない奴はカス。

0309デフォルトの名無しさん

2013/09/11(水) 12:40:01.53

>>305
gitは分散型というのが最大の長所だけど
運用形態によっては最大の短所になり得る

0310デフォルトの名無しさん

2013/09/11(水) 13:46:09.75

>>306
具体的には？

0311デフォルトの名無しさん

2013/09/11(水) 13:46:54.51

>>306 -> >>309

0312デフォルトの名無しさん

2013/09/11(水) 15:33:11.25

>>309
分散型であることが短所になるって具体的にはどういう場合にどういう所がそうなるの?

0313デフォルトの名無しさん

2013/09/11(水) 16:51:27.93

>>310,312
横レスだけど、コミット権の制御ができなくてpushのときにrejectするしかないってのが一つ思いついた

0314デフォルトの名無しさん

2013/09/11(水) 17:33:12.78

分散型の最大の欠点は、ユーザーアクセス権限の制御が不能なところ。
誰でも触れるし、ロックも出来ない。

だから今は複数のツールを同時に使っていくしかない。

0315デフォルトの名無しさん

2013/09/11(水) 18:03:48.99

githubとか使ったことない人なのかな…

0316デフォルトの名無しさん

2013/09/11(水) 19:48:10.66

共有型の最大の欠点はロック出来ない事じゃね？
いわゆるオフィス系ドキュメントを分散型で共有管理しようとすると、先祖帰り問題が発生してしまう可能性が高い

0317デフォルトの名無しさん

2013/09/11(水) 19:49:01.78

×共有型
○分散型

0318デフォルトの名無しさん

2013/09/11(水) 20:26:04.76

分散型とかどうでもいいよ。

gitの利点はそういうところじゃない。
コミット忘れを修正することが出来るのがメリットだ。

もちろんコミット忘れだけじゃない。
あの時ああいう順番で修正すればよかったとか
コミットしてしまった後で後悔することの多くをgitなら直すことが可能。

0319デフォルトの名無しさん

2013/09/11(水) 21:05:39.78

オフィスのドキュメントのよーなバイナリ形式で扱うのが間違い
マークダウン記法みたいなテキスト形式の記法を使えばマージできるからロックとか要らないでしょ

0320デフォルトの名無しさん

2013/09/11(水) 21:20:47.75

http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/

0321デフォルトの名無しさん

2013/09/11(水) 21:25:44.23

リポジトリに大量にデータが追加されてて、全部ダウンロードすると時間かかるので
特定のディレクトリに入ってるファイルとディレクトリだけ取得したいんですがいい方法ないですか？
sparsecheckoutはＮＧです

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を使わせるような奴はそいつが悪いってことになる。

■ このスレッドは過去ログ倉庫に格納されています