Git 7

1 ：2013/10/16 〜 最終レス ：2013/10/27

ソースコード管理を行う分散型バージョン管理システム、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 6
http://toro.2ch.net/test/read.cgi/tech/1369103196/

2 ：

◆過去スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/
Git 4
http://toro.2ch.net/test/read.cgi/tech/1329234309/
Git 3
http://toro.2ch.net/test/read.cgi/tech/1310403238/
Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/
◆関連スレ
◆関連スレ
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
CVS導入スレ〜 Rev.3
http://toro.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://toro.2ch.net/test/read.cgi/tech/1326806859/
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://toro.2ch.net/test/read.cgi/tech/1356521407/
◆関連スレ 別板
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/

3 ：

◆関連書籍
Gitによるバージョン管理
2011/10
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5
実用Git
2010/02
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8
入門Git
2009/9
http://www.shuwasystem.co.jp/products/7980html/2380.html
入門git
2009/08
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

4 ：

>>1-3 乙
前スレ984以降何かあった？

5 ：

なんもなかったと思う

6 ：

プルリクエストにさdiffしてpatchした結果を送るのはありですあｋ？

7 ：

ubuntu 12.4 に gitlab 入れてローカル環境ではうまくいきました。
インターネット側からも自分の gitlab 鯖につなげられるようにしたいのですが
とりあえず 22/tcp を開いておくだけで大丈夫ですか
注意点としては、ubuntu 上に作成したユーザーで
SSH不要なユーザーはSSH利用停止、
SSH使うユーザーはパスワードをガチガチにする
それくらい？？

8 ：

>>7
sshdのポート変更、パスワード認証の禁止。

9 ：

>>7
gitlab使ったことないけど、sshに限った話なら
公開するならポート変更しなくていい
そのかわりパスワード認証じゃなくて公開鍵認証にしないと危ない

10 ：

コンフリクトが発生しないよう予防法を教えてください

11 ：

常にFast-forwardな状態でマージする

12 ：

パスワード認証を禁止にすると、なぜセキュリティが上がるのですか？
そのマシンを勝手に使われたり、乗っ取られたら結局終わりですよね。
勝手に使われたり、乗っ取られないのが前提なら安全と言うことですか？

13 ：

簡単に言うと、強度が強くなる。
後はどうしたいかによるので自分で判断してください。

14 ：

>>12
SSHのパスワード認証は攻撃多いからね
ユーザーが1人でも弱いパスワードを設定したらあっという間に入られて、
そのマシンを踏み台にして新たな攻撃が始まるよ
ガチガチにしろと言うより公開鍵認証に限定するほうが簡単で確実

15 ：

SSHで鍵にパスフレーズつかえばいいんじゃないの

16 ：

それは別の問題ではないかと

17 ：

>>12
端末に侵入されたら、キーロガーとかでパスワードも盗まれるでしょうし、セッションジャックもある。終わってる。
入られない前提で困るのはサーバにアクセスされ続けること。
ブルートフォースでは、鍵だと相手にも強度が伝わるので諦めてくれるが、パスワードだと弱いかもなので責められ続ける。パスワードだと当然辞書も来る。
あと管理が楽。

18 ：

>>11
なんか2.0からはFFがデフォルトでなんたらかんたらで
.gitconfigに
[merge]
ff false
って書いてるんですがコレで大丈夫ですか？

19 ：

認証方式としては鍵認証の方が強力だけど
パスフレーズの無いsshキーファイルを参照されるとそれだけでアウトだからな
古い脆弱性のあるsshエージェント使ってる人も多いし
gitのようなバージョン管理の為だけにshellを解放するのが良くないんだろうな
面倒くさいからssh使ってるだけで

20 ：

>>18
それはFF状態でも非FFマージをデフォルトにする設定で、
コンフリクトとは関係ない

21 ：

そもそも秘密鍵が他人に使われない前提だからな
俺もパス入力あってもいいと思うけど、キーロガー仕組まれること考えたら断言できるほど自信ない
キーロガー仕組まれる可能性とログイン状態で別の人にPC使われる可能性どっちが高いんだろうね
あと、gitlabからshellにアクセスできるなら、それはgitlabの脆弱性だよ

22 ：

キーロガー仕掛けられてたら
秘密鍵も参照されちゃうだろうしパスフレーズも取られちゃうだろうから
公開鍵認証使っててもダメじゃん

23 ：

>>12
あまり引きずる話でもないけど
パスワード認証を許容すれば、関係ない端末からもブルートフォースが成立してしまう。
公開鍵認証のみにしておけば、パスワード+秘密鍵になるから、その分安全になる。
ノンパスワードの鍵作成は止めましょう。
あれは、バッチシステム用です。

24 ：

この話もうちょっと続けたい・・

25 ：

やっぱいいや

26 ：

100％安全でないなら
意味が無いじゃないですか！

27 ：

sshd側で特定のコマンドしかできないようにするのは割と簡単だった気がする。他のコマンドも要求したりしてんのかなぁ。

28 ：

>>26
100%安全だと所有者も使えないだろうから意味がない。100%は有り得ない。

29 ：

この世に100%なんて存在しないから全て意味がないな

30 ：

100%勇気

31 ：

>>29
> この世に100%なんて存在しない
その確率は何％なの？

32 ：

頑張るしかないか

33 ：

最近Gitを使い始めたのですが質問です
以前のコミットに戻した後，コミットを戻す前の状態に戻すことは出来ないという認識でいいのでしょうか？

34 ：

>>33
戻す事はできるという認識に改めてください。

35 ：

コミットのキャンセルのキャンセル？

36 ：

>>34
できるんですか！
調べ方が悪かったみたいです
もうちょっと調べてみます
>>35
そうです
コミットのキャンセルのキャンセルです

37 ：

git reset ORIG_HEAD とか git reflog とか

38 ：

システムのデプロイにもgitコマンド使いたいんだけど
ここ落とし穴だから気をつけろ的な注意事項とかある？

39 ：

gitのことをわかりやすく書かれている本はありませんか？

40 ：

ありませんよ

41 ：

ドキュメント嫁　それで分からなければソース嫁

42 ：

どなたかご存知だったら教えていただきたいのですが
git svn clone時に空ディレクトリを無視せず取ってくる方法はないでしょうか？
git svn dcommit時に削除する方法は、ググったら出てきたのですが、、、

43 ：

ダミーで空のファイル入れておくってのはダメなんかね

44 ：

>>39
ググってわかりやすいと思ったサイトを印刷して
本のように綴じたら？

45 ：

>>43
ありがとうございます。
最初から書いておくべきで申し訳ないんですが、
空のファイルを入れておく話につきましては検索して知ってました。
しかし、自分の管理していないモジュールだったら空のファイルといえど勝手にコミットできませんよね。
それに些細なことですが、空のファイルのコミットのためにだけはsvnを直接 使わないとダメなので少々面倒です。。

46 ：

>>39
これを気合で嫁
http://git-scm.com/book/ja

47 ：

すみません。ちょっと質問なのですが、
githubで管理してる自分のプロジェクトに、海外の方からpull requestが来ました。
本来のコードへの影響を最小限にするためか、（または本人が面倒だったのか）
「既存のロジックコピペで必要なところ改変」みたいな「追加」のソースが来てます。
おかげで、似たような処理をしているロジックが結構あります。
実装された機能のアイディアはいいのですが、
改変内容が気に入らない場合、皆さんはどんな対応をしているでしょうか。
一旦受け入れて、後でガッツリ自分で改変するか、
理由を述べて却下して、相手に実装しなおしてもらうか、
どんな対応が望ましいのか、参考までに聞かせてください。
海外でどんな対応するのが一般的なのかも知りたいです。
よろしくお願いします。

48 ：

こっちかな
GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

49 ：

gitでリポジトリを作成するとき、git initを使うんですか？
このコマンドだと自分のところが中央リポジトリになるように
思えるんですが、中央サーバに登録するには
どうしたらよいのでしょうか

50 ：

git clone

51 ：

>>49
サーバ側の実装による
リポジトリを作成する権限が与えられてるなら、何らかの案内があるはずだから
管理者に確認したらいいよ

52 ：

>>51
すみません、わたしが管理者です
どう案内すればいいかいま検証中なんです

53 ：

どこを中央サーバにするかって、単に運用方法の問題じゃないの？＠素人

54 ：

中央サーバと末端PCがあって、
末端PCでプロジェクトを作ったのでそれを中央サーバに
新規に登録したいのですが
cvsのinitに相当するコマンドはgitにはないので
プロジェクトのファイルを中央サーバにコピーして
中央サーバでgit initして、それを
末端PCで git clone する という動きでよいですか？

55 ：

>>54
よくない。空のリポジトリが作られるだけ
基本、サーバでgit initして、ローカルからpushだけど
実装によるから、それかかないと答えようがない

56 ：

実装というか構成か

57 ：

>>55
ローカルでinitしてサーバにpushすべきというのは理解しました
でも、最初の手順で空のリポジトリが作られるだけという
動きの理由がよくわかりません。

58 ：

あ、逆ですか
じゃあ理解できてませんすみません

59 ：

initで作られるのは空のリポジトリ
それをサーバに作った直後に、末端からcloneしたところで、エラーしか出ません
初回は必ず末端のローカルリポジトリから、コミット情報をpushしてやる必要があるのです
ということかと

60 ：

んで、pushをするためには、ネットワークの構成を知る必要があるってとこかな

61 ：

中央サーバに置くのは普通はbareリポジトリ
したがって中央サーバーで行うgit initは--bareオプション付き
なので>>54でgit init --bareしても空のリポジトリができるだけである
以上の思考が>>55の脳内で行われたのだろう
実際は、>>54が言うように中央サーバ上にファイルをコピーして
そのディレクトリでbareじゃないgit initすれば、
それは末端PCからgit clone可能な中央サーバ上のリポジトリになる
でも常識的に中央サーバに置くのはbareリポジトリなんで、
末端PC側でgit initで作ったリポジトリを、
中央サーバ上に作った空のbareリポジトリにpushするのがよい

62 ：

中央サーバにbare形式で目的のリポジトリを作るだけなら、
ファイルコピーしてgit initで普通のリポジトリ作って
それをgit clone --bareでbareリポジトリ化するなんて方法もある
でも後々の運用を考えると、空のbareリポジトリを用意してpushしたほうがいい
空のbareリポジトリを用意する方法は、gitを直接使う以外にいろいろある

63 ：

なぜ、構成を書いてくれないんだろう
もしかして、意味が伝わってないのか

64 ：

構成は何を書けばよいでしょうか
マシンなら中央と端末の2台構成です。
ディレクトリなら、とりあえずファイル10個程度、ディレクトリは無しです。
開発者は二人います。ひとりはわたしです。

65 ：

ああ、ごめん
>>61->>62はgit initの後にgit commit -am "〜"でリポジトリにファイルを取り込まないとダメね

66 ：

書いてくれた構成よくわからなかったから、もうあてずっぽうで書くけど
git-daemon動かしてたり、gitoliteやgitlabみたいな管理ツールつかってるわけじゃないなら、サーバ上で
$git init --bare your_repo
してから、ローカルのリポジトリから
$git push user_name@server_address:your_repo master
ってすればいいよ。
あとは、ローカリにサーバから
$git clone user_name@server_address:your_repo
SSHが必要

67 ：

>>64
中央サーバと呼んでるマシンのOSとサーバーソフトウェア次第で
その中央サーバにリポジトリを作る方法はいろいろあるってことだよ
君がそれを言わないから、Unixサーバのsshアカウントを利用する方法をみんな説明してる

68 ：

すみません
gitでリポジトリを作る方法はsshでログインして作るのしか
知らなかったので質問の意図がわかっていませんでした。
おっしゃるとおりsshアカウント経由で作業する予定です
gitにも、cvsのようなpserver的なものがあるのですか？

69 ：

>>68
Gitoliteとか良く使われてる
ここに目を通しておくといい
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
4.8章にGitoliteの説明もある

70 ：

リポジトリ自体はsshでログインして作るんだけどな
ていうか、ちょっとぐらいドキュメント読めよ

71 ：

Gitolite使えばsshでログインしてリポジトリ作る必要無いだろう

72 ：

すみませんどのページを見ても
同じことを同じやり方で解説してるところがほとんどなくて
その情報が古いのかモダンなのか間違ってるのか
とんとわからない状態でした

73 ：

>>72
どのページってどこのこと。知らんよ
Chapter 4　Git サーバー
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
この4章一通りよんでわからんかったら、もう無理だよ。諦めよう。
前提となるgitやサーバの知識が足りてないんだよ

74 ：

gitolite使っとけばいいだろ難しいこと考える必要ないぞ
生のsshアカウントでやるのは権限とか考えるといろいろ面倒

75 ：

俺もgitoliteが一番いいと思う

76 ：

gitoliteってウェブインターフェースあるの？

77 ：

>>76
gitoliteには組み込まれてないよ
だから、好きなウェブベースのgitクライアント使えばいいと思う
ていうか、普段使ってるgitクライアント使うのが一番いいと思うけど
turtoiseなり、sourcetreeなり

78 ：

>>76
gitlabおすすめ。
gitolite＋githubクローンと
言ってもいいぐらいの
ウェブシステムだよ。
githubを使っている人や
逆に将来github使うって人には
いいとおもうよ。

79 ：

あれよ
gitoliteはリポジトリとユーザ管理をgitolite-adminっていうリポジトリで行うから
そのリポジトリを自分が使いたいクライアントで触ればいいだけ

80 ：

gitlabってRuby自前で2入れるように書いてあるのに、なんでわざわざインストールしてる1.8消させてんの？
自前でいれるなら、1.8消さなくてもgitlabが使えるように入れたらいいのに

81 ：

>>80
Linuxはディストリがたくさんあって、
すべての環境がどうなってるのか把握できないから。
Rubyが二つ入っていると、何が起きるかわからない。

82 ：

働けど働けどわがプロジェクト楽にならざり
Git手を見る

83 ：

gitlabは機能見る度に入れようかなって思うんだけど、要件にデータベースがあるのをみて結局やめてしまう
>>81
ruby2を/opt/ruby2とかに入れて、gitlabでruby実行する時はそこを使うようにもできると思うんだけど

84 ：

データーベースが要件で断念って
よくわからん。
ファイルと同様に極普通に使うものだろう？

85 ：

>>82
歌人さんかな？

86 ：

rubyのアプリは、rbenvやbundlerが良く出来てるせいで、
かなり無茶な感じに特定rubyの特定ライブラリに依存させたもの作って運用することができるけど、
OSのパッケージマネージャでそれらを管理するのは地獄の苦しみだな

87 ：

今はどの言語もなんたらenvシリーズと
パッケージマネージャ揃ってるだろう？

88 ：

(この流れは）アカン

89 ：

せめて、gitlabとかgitoliteの流れに戻ろう

90 ：

>>84
>ファイルと同様に極普通に使うものだろう？
そうかな
データベースサーバ新しく立ち上げるとか、既存のデータベースサーバにアクセスできるようにするとか
色々考えることあると思う

91 ：

全部 /usr/local/mygit などにインストールして、そこから起動すればいいだろう

92 ：

sqlite使えなくなってたのか。

93 ：

gitを使い始めたもので管理について質問させていただきます。
WebページやWebアプリを作っているのですが、サーバ側のリモートリポジトリはそのプロジェクト毎に作成し、使うものなのでしょうか？
それとも他に一括で管理する方法があるのでしょうか？

94 ：

Visual Studio 2013 Express で git が使えるようになったらしいので、今更ながら git 使い始めたんだけど、キーワード置換とかできないんだな...

95 ：

>>93
質問がよくわからん
ローカルもサーバも違いはないよ

96 ：

>>93
一つのリポジトリの中にディレクトリを掘って、
複数のプロジェクトのファイルを突っ込んでもいいし、
プロジェクトごとにリポジトリを作ってもいい。
どちらも一長一短ある。
プロジェクト間でファイルを共有しているなら一つのリポジトリにして、
そうでないならわけた方がいいかもしれん。
わけておけばプロジェクトごとにリポジトリのcloneが可能だが、
そうでないなら全部cloneすることになる。

97 ：

プロジェクト間で共有されるファイルはsubmoduleにしたほうがいいのでは？

98 ：

それ、サーバ、ローカル関係なくない？
>一括で管理する方法があるのでしょうか？
って聞いてるから、管理方法をしりたいんじゃなかろうか。。

99 ：

>>96
ありがとうございます。
プロジェクトごとに分けることにします。

100 ：

gitってmacやwindowsでも操作同じ？
「アリスとボブのGit入門レッスン 」という本がよさそうなんだけど
この本macで解説してるんで聞いてみた。
gitってなんでこんなに名が知られていないんでしょうかね？

101 ：

>>97
俺ならsubmoduleを使うが、あの使いこなすのが難しい機能を
「使い始めた」と言っている>>93に勧める気にはなれなかったので。

102 ：

>>100
git自体の操作はどれでも同じ
知名度をいうなら、プログラマでgit知らない人いないぐらいだと思うけど、>>100の周りではそうじゃないの？

103 ：

ボブ「Gitからメッセージも出力されているね。」
アリス「メッセージは英語なのね・・・。」
ボブ「そうだね。英語だね。でも、簡潔な言い回しだから、じっくり読めばおおよその
意味がわかると思うよ。最初だから日本語訳を付けておくね。」

104 ：

>>100
> gitってなんでこんなに名が知られていないんでしょうかね？
可哀想に。使えないならともかく知らないっていうのは、
プログラミングに興味が無いと言っているのと同じレベルだぞ

105 ：

>>94
commitしたファイルのチェックサムが、リビジョンになるからね

106 ：

>>101
ごもっとも　俺もいざとなったら調べて使うだろうが今のところ練習以上に使ったことはない

107 ：

>>105
う〜ん、別にチェックサムでもいいのでソースに埋め込ませてくれてもいいと思うんだけど。
コミットした日時とか、人とかもあると嬉しいし...

108 ：

>>107
チェックサム埋め込んだらチェックサムが変わっちゃうじゃないですか。

109 ：

チェックサムを埋め込んだらチェックサムが変わってしまったでござる

110 ：

チェックサムの無限ループや！

111 ：

チェックサムがッ！一致するまで！再計算するのをやめないッ！

112 ：

>>102>>104
ほとんどひとりで個人の趣味範囲
こういうのを使ってソフトを作成していったんですね
ソフト作りも製造業に似ていますね
どちらというと一人やっているほうが楽しいかね

113 ：

>>108
Subversion 知らないの？
リポジトリから取ってくる時に埋め込むから、リポジトリのリビジョンは変わらないよ。
git でもできると思うんだけど。

114 ：

キーワード置換ってなに？

115 ：

>>94へ朗報>>113

116 ：

>>113
それ、取得元の証明であって、手元にあるものがソース＋チェックサムだってどうやってわかんの？
そもそもcommitログでチェックサムも日時も人も全部わかるじゃん

117 ：

>>116
サムチェックだと考えるからわからんのだよ。
ファイルの内容とは無関係なGUIDのような任意のIDだと考えたまえ。
任意のIDはファイル内容を変えても、変わらんよ？

118 ：

Git - Gitオブジェクト
http://git-scm.com/book/ja/Git%E3%81%AE%E5%86%85%E5%81%B4-Git%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88

119 ：

>>115
同一人物なんだが...
>>116
> それ、取得元の証明であって、手元にあるものがソース＋チェックサムだってどうやってわかんの？
もちろん、取得したやつは変更し放題だからリポジトリの内容と同一かは保証できないけど、あえて変なことしなきゃいいだけでしょ？
そもそもそれは Subversion でも、同じだし。
> そもそもcommitログでチェックサムも日時も人も全部わかるじゃん
いや、印刷したソースとか、実行ファイルに埋め込んでおいて、問題が発生した版はどれだっけ？ とか、git から離れたものを特定したいんよ。

120 ：

>>119
あ、おまえ、スクリプト言語しか使ってないだろ？
ソースコードを直接実行するタイプの。

いるんだよねー。
ビルドという工程の存在を知らない人ってｗ

121 ：

gitって奥が深い？
gitってなんの言語で書かれているの？

122 ：

>>114
ソースコードの中に $Rev$ とか入れておくと、自動的にそのファイルのレビジョンに置き換えてくれる機能。
レビジョンだけでなく、ファイル名とか、コミットした日時や人とかに置き換えができる。

123 ：

>>119
git でもできると思うんだけど。

124 ：

ソースコードの中の著作権とかの名前のように
原則として変わらないものは意味がある。
だがコミット日時やコミットした人の名前のように
頻繁に変わるもの（$Rev$というのは変わるものにつけるもんだが）
に関して、そんなものを埋め込む意味は無い。
そんなのを埋め込んで役に立ったためしがない。
これが答え。

125 ：

>>120
文字列に埋め込んで、実行ファイルがどのソースからビルドされてるかを後から確認するとかもできるよ。
ident とかそれを見るための専用コマンドがあったりしたんだが...

126 ：

コミットした人ってさ、
複数の人がコミットしている場合
行ごとに違う人が修正していることって
よくある話だけど、
コミットした人の名前知ってどうすんの？

127 ：

そういうのはソースに書くのではなく
バージョン管理システムに任せなさい

128 ：

>>125
え？ ソースファイルってたくさんあるじゃん。
実行ファイルが、どのソースファイル（全100ファイル）郡から
ビルドされてるかしってどうするの？
そんなもん、ソースファイルに埋め込むんじゃなくて、
ビルド時に生成したリビジョン番号を埋め込むだけだろ。

129 ：

>>123
やり方、教えて。
>>124
いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。
SCCS から使ってるけど、有名どころの SCM でできないやつは git が初めてなんだわ。

130 ：

例えばこんなの。
簡易ビルドスクリプト

$ build.sh リビジョン番号
gitから指定したリビジョン番号をチェックアウト
echo リビジョン番号 > revision.dat
コンパイル時にresivion.datを埋め込み
実行ファイル生成

131 ：

>>94
SubversionとGitの大きな違いはブランチのスイッチが瞬時にできること。
対象となるブランチがローカルにあるのでそれができる。
キーワード置換があったら、ブランチのスイッチで置換が必要になるので遅くなる。
だからキーワード置換の機能はGitにはない。
Gitにキーワード置換を加えるパッチは、そういう理由でLinusに却下されている。
http://thread.gmane.org/gmane.comp.version-control.git/44750

132 ：

>>129
> いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。
日付ごとにディレクトリ作ってバックアップするという作業を
”有効に使っている人” もいるでしょうねｗ
意味が無いことを有効だと勘違いしているだけ。

133 ：

キーワード置換なんてビルド時にやればいいだけじゃん？
ソースコードを誰が（最終）コミットしたかなんて
わかるんだしさ。なんなら全コミット者だってだせるよ？
印刷も、印刷時にキーワード埋め込みをすればいいだけ。

134 ：

>>129=94=113?
ほい。
Git-のカスタマイズ-Git-の属性#キーワード展開
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7#%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E5%B1%95%E9%96%8B

135 ：

>>126
まあ、最後のコミッターにそんなに意味があるかと言われたら、俺もそれほど重要とは思えないけど、コミッターがあまり変わらない場合もあるから、できてもいいじゃんぐらいだと思う。
それはそれとして、そのファイルのレビジョンを知りたいんだよ。
>>127
もちろん、SCM に任せるんですよ？
SCM を離れたソースコードを特定したいと言う話。

136 ：

>>129
やり方はここに書いてあるがはまりどころ満載なのでお勧めしない。
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7#%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E5%B1%95%E9%96%8B
Gitを使いこなすコツは「ほかのSCMでは××だった」という考え方をすべて捨て去ること。
それができないならその「ほかのSCM」を使っていた方がいい。
Visual StudioのGitのインターフェイスが罪深いのは
「ほかのSCM」の知識でわりと使えるようになってること。
Git本来の使い方からかなり離れてる。
コマンドラインで使い方を覚えておかないと、いつかはまることになるよ。

137 ：

>>135
> SCM を離れたソースコードを特定したいと言う話。
だから、SCM から離す時に埋め込めばいいじゃん。

138 ：

>>135
> それはそれとして、そのファイルのレビジョンを知りたいんだよ。
gitに問い合わせればわかる。

139 ：

>>130
なるほど、こう言うのがあるのか。
ちょっと見てみる、サンクス。
>>131
なるほど、だから >>130 みたいに外部でやると言うことになるのかな。
しかし、全部見れてないけど結構議論されたんだな。
>>132
> 意味が無いことを有効だと勘違いしているだけ。
まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
さすがに、書いてて恥ずかしくない？

140 ：

話変わるけど、git bisectって凄いよね。
例えば、何処かで動きがおかしくなったとするじゃん？
どこかのリビジョンでは正常だったことがわかってる。
どこかのリビジョンではおかしくなったことがわかってる。
そういった時に、正常と異常の二つを指定するだけで
そのその中間のソースコードを取ってこれる。
そしてそれがちゃんと動いているか確かめる。
正常であればgit bisect good、異常であればgit bisect badを実行する。
そうすれば、今度は正常と異常の中間を取ってくる・・・と繰り返すので
最初以外リビジョンなんか考えずに、どこでおかしくなったかを探すことが出来る。

141 ：

>>139
> まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
> さすがに、書いてて恥ずかしくない？
勘違いしていた人は成長した。
お前は成長しないの？
新しいものを使っていて、古いやり方をするのは
何も成長してないからね。
プログラミングでもいるんだ。
新しい言語、新しいライブラリを導入しても
古いやり方のまま続けて、導入した意味を無くす奴ってね。

142 ：

>>136
> それができないならその「ほかのSCM」を使っていた方がいい。
それはそうなんだけど、Visual Studio の Express (=無償版) には、git と TFS のクライアントしかないんだわ。
まあ、貧乏なだけなんだが (w
>>137
うん、そうなんだけど、他の SCM の多くはその機能が本体に組み込みだから git もそうだと思ってたんよ。
>>138
話の流れ追えてます？

143 ：

>>141
git が最新ともベストとも思えないので、成長とか意味わからん (w

144 ：

>>142
そもそも将来的にメンテする可能性のあるものを何故gitからわざわざ離すのかもよく解らんのだが…
仮に離すとしても、そいつはメンテせずに
大元のほうを残して、そっち使ってメンテしないか？

145 ：

94はキーワード展開のやり方教えてもらったんだから
smudge フィルタをさっさと書けよハゲ

146 ：

定期的に「ある特定のファイルのリビジョン」という話をする人が出てくるなあ
俺の理解だと，gitでそういう話をするのは無意味だと思うんだけど

147 ：

>>144
いや、離した奴をメンテとかは (普通は) しないよ。
実行ファイルの提供とか、印刷とか離れちゃう奴をどう特定するかの話。
>>145
まあ、あせるなよ。
せっかちなやつはモテないぞ (w

148 ：

以前ファイルごとのリビジョンの話もあったけど、
ソースツリー全体まとめて何かになるのであって、ファイル単体それぞれを
適当に持って来てもどうにもならないということが理解できるかで
意見が別れるようだね。
リリース管理せずに、何かあったらファイル単体だけメールで送っちゃう
ような運用だと、ファイル単体に情報は必要だろう。
場合によっては行ごとにリビジョン番号を埋め込みたい人もいるかもしれないw
金がないなら自分で工夫するんだ。頑張れ!

149 ：

>>142
Visual StudioのGitはリポジトリのビューワーとして使った方がいいよ。
あれでチェックインその他の操作を覚えてもろくなことにならない。
将来Gitを使いこなしているチームに君が加入することがなく、
チームに新たにGitを導入する指揮を君が取ることもないなら、
Visual Studioから使っていても構わないけど。

150 ：

出来ないことはやってはいけないこととする流儀があるんだよね。
たとえば日本語ファイル名とか。
ファイルの名前を日本語にしてるんだぜ？馬鹿だろ？なんて真顔でのたまっていた時代、
人たちがほんとにいたんだよ。

151 ：

メールでパッチ送る方法ならgitに
ついてる
まずちゃんとgitのやり方を学べ
変なやり方はやめて成長するんだ

152 ：

>>150
多くの人が使っているツールのやり方と自分のやり方のどっちが良いか
って話じゃないかな。業務パッケージに業務を合わせるか、業務に合わせて
ソフトウェアをカスタマイズさせるかの違いというか。自分のやり方の
方が良いかは置いておくとしても、カスタマイズにはコストがかかるのは当然。
日本語ファイル名はMS-DOS2.11で普通に使えてましたね。UNIXの人たちは…w

153 ：

nihongo-de-nani-ga-warui.txt

154 ：

>>148
Subversion 使ってるので、ソースツリーのリビジョンとかは違和感ない。
ただ、印刷してレビューとか、外注さんにソース渡すとかあるんだよね。
まあ、そう言う運用には向いてないってことなんだろうな。
>>150
いまでも、日本語ファイル名は結構鬼門だよ。
海外製のツールはダメなやつ結構あるし、OSS でも Doxygen とか...

155 ：

日本人（と本人は主張している）が日本語を使ってはいけない理由を説明して
一生懸命日本語を否定してた。
本来は1億人の日本人を説得するのではなく、少数にすぎないソフトウエア発行元を
説得したりお願いしたりしたほうが良かったと思う。
まして、年寄りは日本語を使いたがるとか初心者は日本語を使いたがるとか
ドザは日本語を使いたがるとか、日本語を使う人間は劣っているかのような
イメージを植え付ける必要はなかったんじゃないかな。

156 ：

単にコマンドラインで日本語ファイル名を入力するのがめんどくさいから使ってないなあ

157 ：

>>113
CVSの頃はよく使ってたけど、SVNだとあんま意味無いからmakeでやってたな。

158 ：

>>152
MSがすぐ互換性崩して妨害しようとするから、ファイル名などのようなとこはメジャーなものでないと危険。

159 ：

印刷してレビューするだけで
なんでソースコードに
リビション番号を書かないと
いけないのかわからない
印刷のヘッダに書けば事足りるだろ？

160 ：

外注に渡すにしても
zipに同梱すればいいじゃないか
zipのファイル名がリビション番号
なのもよくある事だし

161 ：

>>150
Unicodeが普及した後にマになるとこういう発想が出来るのか

162 ：

何を勘違いしてるんだお前らは。
キーワード置換そのものが古いとか不要とかいうのはおかしいぞ。
Gitはチェックアウトのときこそキーワード置換はしないが、
リポジトリの外にファイルを出すときならキーワード置換ができる。
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7#%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%82%92%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9D%E3%83%BC%E3%83%88%E3%81%99%E3%82%8B

163 ：

>>159-160
今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？
zip 同梱とかは、ソース一つとは限らないし、目視で対応付けとかは勘弁してほしい。
>>161
最近の環境使ってれば、そんな変な感覚とは思えないけど？

164 ：

>>162
あぁ、それで問題ないな。
エクスポートする時やアーカイブを作る時に
自動的に入れればそれで事足りるわけだし。

165 ：

>>163
> 今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？
なんで印刷ソフトが関係有るんだ？
エクスポートしたり、印刷する直前に、
ファイルの頭につければいいじゃないか。
それをコミットしなければいいだけの話だよ。
すべてのソースコードに一行付け足すことが君には難しいの？

166 ：

>>163
ってアーカイブをする作る時に
WindowsのGUI使って
.gitディレクトリ選ばないように選択して
右クリックメニューからzip作ってそうｗ

167 ：

CVSだとファイルごとにバージョン違ったりするけど、SVNやgitだと同じでしょ。それでもファイルごとに付ける意味あるのかな。それとも最後に変更したIDをつけるの?

168 ：

ファイルにバージョン番号がなくて
どうやってファイルを管理するのか？
（バージョン管理ソフトを知らない）
もしファイルを二つ提示されて
それが同じかどうかどうやって判断すればいいのか？
（diffを知らない）
ファイルにバージョン番号が含まれていれば、
それが分かるんですよ。
（それ以外の方法を知らない）
いちいちファイルを手動で書き換えるのは面倒ですよね？
だからキーワード置換が必要なのです。
（自動で全部のファイルを書き換えるプログラムを作れない）
一体これの何がダメだというのでしょうか？
（プログラミング技術がない素人だから金もらってはダメ）

169 ：

>>165
ああ、すまん、印刷でヘッダーっ言うと、各ページに印刷される奴のこと言ってるんだと思ったんよ。
>>166
君のおすすめの方法を教えてくれまいか。
>>167
> 最後に変更したIDをつけるの?
そう、Subversion 使ったことないかな？

170 ：

>>168
> もしファイルを二つ提示されて
> それが同じかどうかどうやって判断すればいいのか？
もし、キーワード置換の話のこと言ってるとしたら、全然違う話だから。
全てのレビジョンと比較するつもりなら止めやしないけど...
まさか、違うよね？ (w

171 ：

>>170
違うに決まってるだろ
そんな勘違いするのお前だけだよ。
馬鹿じゃないのか？

172 ：

ここまででよくわかった。
gitにキーワード置換を搭載する意味は無い。
代替方法で、全く同じことができるし、
そもそもやる意味が無いということだ。

173 ：

>>169
svnが出てくる前からcvs使ってて、svnはできることそんな変わらないのに、不便な点が多くてあんま使わなかったな。svn使ってる客ってにわかなのか、単にファイルコピーとしか使ってない人が多かったし。タグ埋め込みなら使ってたかな。

174 ：

>>171
そうだよね、安心したわ。
で、
> もしファイルを二つ提示されて
なんて、どっからでてきたの？ (w

175 ：

>>173
確かに、タグ埋め込みとか言ってる時点で svn 使えてなかったのは、よくわかるわ。

176 ：

>>172
てか確かSVNでも非推奨ってことで、デフォルトではオフになってないっけキーワード置換

177 ：

>>176
非推奨じゃないよ。
Subversion は指示されないことはやらないと言うポリシーなだけ。
拡張子で自動設定する機能もある。

178 ：

やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
なんか勝手に入れてくれると楽って話だろうねえ。
まともな仕事をしている人は、そういうの認めたくないんだろう。
>>163
UNICODEは正規化の話がね。MS-DOSの頃の方がある意味まともだった。

179 ：

>>178
> やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
> なんか勝手に入れてくれると楽って話だろうねえ。
ごめん、適当とか勝手にとか言ってる内容がさっぱりわからん。

180 ：

>>175
どういうこと?

181 ：

>>175
どういうこと?
タグじゃなくてブランチ名って言えってこと?

182 ：

>>180-181
タグ埋め込みなんて言わないでしょ？
タグを打つとかは言うけど。

183 ：

そもそも、キーワード置換なんて
ソースコードに入れる必要がないわけで。
あんなのCVS時代の遺産だよ。
CVSはファイル単位の管理しか出来なかったからね。

184 ：

そう、リビジョン番号なんてのは
エクスポートした時に自動で埋めればいいだけ
そういうのが必要な人は自分でやればいいやん。
gitの文化で要らないものはつけてない。それだけの話。

185 ：

うっとうしいので>>94はいちいちバカの相手をするのをやめてくれ。

186 ：

>>184
まあそういうことみたいやね。
>>134 >>136 >>162 で URL 教えてもらえたし、あとは何とかするわ。

187 ：

>>185
ああ、すまん。
マジで git 使うの初めてだから、もう少しこのスレのレベル高いかと思ってたんだけど、大体わかったから、あとは適当にスルーするわ (w

188 ：

馬鹿を相手にするのは馬鹿だけってことですよ
キーワード展開については前スレでもその前のスレでも>>162のリンクで終わってる

189 ：

ほんと毎回うっとおしいんだよね
テンプレにはhttp://git-scm.com/のトップだけ入れてあるけど、
日本語目次のURLとよく話題になる章の見出しも入れといたほうがいいんじゃない？
http://git-scm.com/book/ja
4. Gitサーバー
4.8 Gitolite
7. Gitのカスタマイズ
7.2 Gitの属性 (バイナリファイル / キーワード展開)
8. Gitとその他のシステムの連携
8.1 GitとSubversion (git svn)

190 ：2013/10/27

>>182
あなたは思い込みをしているようだ。
バイナリとかにタグを入れることだよ。