トップページ⇒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/
0237デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>236
俺は、お前を排除するね
0238デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>237
俺は、おまえを虐めるね
0239デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>238
もっと〜もっと〜
0240デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
どうぞどうぞ
0241デフォルトの名無しさん2013/08/13(火) NY:AN:NY.AN
lolcommitsって真面目に使っている人っているのかなw
http://mroth.github.io/lolcommits/
0242デフォルトの名無しさん2013/08/13(火) NY:AN:NY.AN
lolcommits
約 3,370 件 （0.23 秒）

使ってないでいいんじゃね？
わざわざこれがなにか調べる気も
しないけど
0243デフォルトの名無しさん2013/08/18(日) NY:AN:NY.AN
せっかく来たのに
まだ決定打的なGUI出来てないの
また明日こよ
0244デフォルトの名無しさん2013/08/19(月) NY:AN:NY.AN
>>243
頑張ってください！
応援してます！
0245デフォルトの名無しさん2013/08/20(火) NY:AN:NY.AN
永遠に明日を待ち続けるのであった
0246デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
無いなら俺が作ると考えない奴に明日はかおない
0247デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
かおないパワー！
0248デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
gitconfigでaliasに
log = log --date〜
みたいな感じで書いたんですが
デフォルトのlogで表示されます

l = log --date〜
って書くと反映されました

aliasでlogが反映されないのはなぜですか？
0249デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
>>248
仕様です
> To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored.
0250デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
そうだったんですか！
わかりました！
0251デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
間違えてIDとパスワードを含んだコードを間違えてあげてしまったので、
至急ローカルでコードからIDとパスワードを削除して
git add -A
git commit -m "IDとパスワードを消した"
git push origin master
ってしたんですが
githubの履歴にはIDとパスワードが入ってるコードが閲覧できてしまいますよね
こういう場合はどうしたらいいでしょうか？

やり方がわからずリポジトリごと消してるので一応被害はありません
0252デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
testブランチを切り替えるのを忘れてしまい、masterブランチでコードを編集してしまったのですが
この場合、.
編集したファイルを別のディレクトリにバックアップ
↓
git checkout -fで元に戻す
↓
git checkout -b testでtestブランチに切り替える
↓
バックアップしたファイルで元のファイルを上書き
という流れで解決はしたのですが、ものすごい面倒くさいです

以下の3つの状態それぞれのケースでもっとよい方法がございましたらどうか伝授してください
１．git addする前
２．git addした後
３．git commitした後
0253デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
commit --amend
push --force
0254デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
commit 前なら git stash save; git checkout xxx; git stash pop で大体おｋ。
commit してしまったら git reset HEAD^ でひとつ戻ってから同様にやればいい・・・と思う。 たぶん。 きっと。 おそらく。
0255デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
1.2. stash -> checkout test -> stash pop
0256デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
githubで自分のリポジトリでpull requestを送る練習をしてるんですが
branchはmasterじゃないほうがいいということなんですが
branch名は他の人とかぶらない様なネーミングをつけておいたほうがいいですか？
もし他の人とbranch名がかぶったらコンフリクトになっちゃいますよね？
0257デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
ブランチ名はリポジトリローカルなので、被ってもOK
自分のリモートとローカルでも別の名前使えるよ
ただ自動で生成されるコミットメッセージに出てきて紛らわしいので、意味のある名前が推奨されてる
0258デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
>>256
自分のリポジトリにpushして自分にpull requestするならブランチ名は重なってちゃまずいと思うけど
forkしたリポジトリにpushしてオリジナルのリポジトリにpull requestするなら、
ブランチ名の重複は考えなくていいんじゃないの？
02592512013/08/30(金) NY:AN:NY.AN
>>253
>>254
>>255
これのうちぼくへの暖かい回答はどれですか
0260デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
自分で判断したまえ
0261デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
まあ、問題のない世代からブランチを作り直してmasterを別のものにするしかないと思う。
編集履歴なくってしまったら、バージョン管理にならなしね。
pullしている人には事前の連絡を忘れずに
0262デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
おいおい。消す方法あるぞ。ちょっと待ってろ。
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
ローカルとリモートの区別があるから、
そういうことをローカルに手元でできるのがいいんじゃない
■ このスレッドは過去ログ倉庫に格納されています