2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

Git 7

1 :デフォルトの名無しさん:2013/10/16(水) 22:15:47.64
ソースコード管理を行う分散型バージョン管理システム、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 :デフォルトの名無しさん:2013/10/16(水) 22:17:28.73
◆過去スレ
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 :デフォルトの名無しさん:2013/10/16(水) 22:18:01.38
◆関連書籍
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 :デフォルトの名無しさん:2013/10/16(水) 23:41:50.81
>>1-3

前スレ984以降何かあった?

5 :デフォルトの名無しさん:2013/10/16(水) 23:48:41.61
なんもなかったと思う

6 :デフォルトの名無しさん:2013/10/17(木) 15:29:47.88
プルリクエストにさdiffしてpatchした結果を送るのはありですあk?

7 :デフォルトの名無しさん:2013/10/17(木) 18:35:24.25
ubuntu 12.4 に gitlab 入れてローカル環境ではうまくいきました。
インターネット側からも自分の gitlab 鯖につなげられるようにしたいのですが
とりあえず 22/tcp を開いておくだけで大丈夫ですか

注意点としては、ubuntu 上に作成したユーザーで
SSH不要なユーザーはSSH利用停止、
SSH使うユーザーはパスワードをガチガチにする

それくらい??

8 :デフォルトの名無しさん:2013/10/17(木) 19:06:40.73
>>7
sshdのポート変更、パスワード認証の禁止。

9 :デフォルトの名無しさん:2013/10/17(木) 23:57:29.21
>>7
gitlab使ったことないけど、sshに限った話なら
公開するならポート変更しなくていい
そのかわりパスワード認証じゃなくて公開鍵認証にしないと危ない

10 :デフォルトの名無しさん:2013/10/18(金) 13:14:53.92
コンフリクトが発生しないよう予防法を教えてください

11 :デフォルトの名無しさん:2013/10/18(金) 13:21:30.07
常にFast-forwardな状態でマージする

12 :デフォルトの名無しさん:2013/10/18(金) 14:40:56.02
パスワード認証を禁止にすると、なぜセキュリティが上がるのですか?
そのマシンを勝手に使われたり、乗っ取られたら結局終わりですよね。

勝手に使われたり、乗っ取られないのが前提なら安全と言うことですか?

13 :デフォルトの名無しさん:2013/10/18(金) 15:29:01.72
簡単に言うと、強度が強くなる。
後はどうしたいかによるので自分で判断してください。

14 :デフォルトの名無しさん:2013/10/18(金) 16:09:33.18
>>12
SSHのパスワード認証は攻撃多いからね
ユーザーが1人でも弱いパスワードを設定したらあっという間に入られて、
そのマシンを踏み台にして新たな攻撃が始まるよ
ガチガチにしろと言うより公開鍵認証に限定するほうが簡単で確実

15 :デフォルトの名無しさん:2013/10/18(金) 18:53:09.12
SSHで鍵にパスフレーズつかえばいいんじゃないの

16 :デフォルトの名無しさん:2013/10/18(金) 20:53:47.40
それは別の問題ではないかと

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

18 :デフォルトの名無しさん:2013/10/19(土) 00:54:45.55
>>11
なんか2.0からはFFがデフォルトでなんたらかんたらで
.gitconfigに
[merge]
ff false
って書いてるんですがコレで大丈夫ですか?

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

20 :デフォルトの名無しさん:2013/10/19(土) 09:35:12.93
>>18
それはFF状態でも非FFマージをデフォルトにする設定で、
コンフリクトとは関係ない

21 :デフォルトの名無しさん:2013/10/19(土) 09:37:15.06
そもそも秘密鍵が他人に使われない前提だからな
俺もパス入力あってもいいと思うけど、キーロガー仕組まれること考えたら断言できるほど自信ない
キーロガー仕組まれる可能性とログイン状態で別の人にPC使われる可能性どっちが高いんだろうね

あと、gitlabからshellにアクセスできるなら、それはgitlabの脆弱性だよ

22 :デフォルトの名無しさん:2013/10/19(土) 09:52:41.89
キーロガー仕掛けられてたら
秘密鍵も参照されちゃうだろうしパスフレーズも取られちゃうだろうから
公開鍵認証使っててもダメじゃん

23 :デフォルトの名無しさん:2013/10/19(土) 11:16:49.82
>>12
あまり引きずる話でもないけど
パスワード認証を許容すれば、関係ない端末からもブルートフォースが成立してしまう。

公開鍵認証のみにしておけば、パスワード+秘密鍵になるから、その分安全になる。
ノンパスワードの鍵作成は止めましょう。
あれは、バッチシステム用です。

24 :デフォルトの名無しさん:2013/10/19(土) 11:27:07.26
この話もうちょっと続けたい・・

25 :デフォルトの名無しさん:2013/10/19(土) 11:29:04.86
やっぱいいや

26 :デフォルトの名無しさん:2013/10/19(土) 11:43:36.13
100%安全でないなら
意味が無いじゃないですか!

27 :デフォルトの名無しさん:2013/10/19(土) 12:15:44.55
sshd側で特定のコマンドしかできないようにするのは割と簡単だった気がする。他のコマンドも要求したりしてんのかなぁ。

28 :デフォルトの名無しさん:2013/10/19(土) 12:18:56.14
>>26
100%安全だと所有者も使えないだろうから意味がない。100%は有り得ない。

29 :デフォルトの名無しさん:2013/10/19(土) 16:34:27.14
この世に100%なんて存在しないから全て意味がないな

30 :デフォルトの名無しさん:2013/10/19(土) 23:04:37.06
100%勇気

31 :710:2013/10/19(土) 23:25:18.25
>>29
> この世に100%なんて存在しない

その確率は何%なの?

32 :デフォルトの名無しさん:2013/10/20(日) 05:19:41.96
頑張るしかないか

33 :デフォルトの名無しさん:2013/10/20(日) 14:21:28.25
最近Gitを使い始めたのですが質問です
以前のコミットに戻した後,コミットを戻す前の状態に戻すことは出来ないという認識でいいのでしょうか?

34 :デフォルトの名無しさん:2013/10/20(日) 14:38:18.93
>>33
戻す事はできるという認識に改めてください。

35 :デフォルトの名無しさん:2013/10/20(日) 15:04:59.36
コミットのキャンセルのキャンセル?

36 :デフォルトの名無しさん:2013/10/20(日) 15:21:03.72
>>34
できるんですか!
調べ方が悪かったみたいです
もうちょっと調べてみます

>>35
そうです
コミットのキャンセルのキャンセルです

37 :デフォルトの名無しさん:2013/10/20(日) 16:48:39.06
git reset ORIG_HEAD とか git reflog とか

38 :デフォルトの名無しさん:2013/10/21(月) 10:47:39.82
システムのデプロイにもgitコマンド使いたいんだけど
ここ落とし穴だから気をつけろ的な注意事項とかある?

39 :デフォルトの名無しさん:2013/10/23(水) 00:18:19.59
gitのことをわかりやすく書かれている本はありませんか?

40 :デフォルトの名無しさん:2013/10/23(水) 00:18:51.10
ありませんよ

41 :デフォルトの名無しさん:2013/10/23(水) 00:28:00.70
ドキュメント嫁 それで分からなければソース嫁

42 :デフォルトの名無しさん:2013/10/23(水) 02:35:44.61
どなたかご存知だったら教えていただきたいのですが
git svn clone時に空ディレクトリを無視せず取ってくる方法はないでしょうか?
git svn dcommit時に削除する方法は、ググったら出てきたのですが、、、

43 :デフォルトの名無しさん:2013/10/23(水) 07:24:17.37
ダミーで空のファイル入れておくってのはダメなんかね

44 :デフォルトの名無しさん:2013/10/23(水) 08:24:02.25
>>39
ググってわかりやすいと思ったサイトを印刷して
本のように綴じたら?

45 :デフォルトの名無しさん:2013/10/23(水) 09:48:11.53
>>43
ありがとうございます。

最初から書いておくべきで申し訳ないんですが、
空のファイルを入れておく話につきましては検索して知ってました。

しかし、自分の管理していないモジュールだったら空のファイルといえど勝手にコミットできませんよね。
それに些細なことですが、空のファイルのコミットのためにだけはsvnを直接 使わないとダメなので少々面倒です。。

46 :デフォルトの名無しさん:2013/10/23(水) 10:31:11.42
>>39
これを気合で嫁
http://git-scm.com/book/ja

47 :デフォルトの名無しさん:2013/10/24(木) 02:03:12.36
すみません。ちょっと質問なのですが、
githubで管理してる自分のプロジェクトに、海外の方からpull requestが来ました。

本来のコードへの影響を最小限にするためか、(または本人が面倒だったのか)
「既存のロジックコピペで必要なところ改変」みたいな「追加」のソースが来てます。
おかげで、似たような処理をしているロジックが結構あります。

実装された機能のアイディアはいいのですが、
改変内容が気に入らない場合、皆さんはどんな対応をしているでしょうか。

一旦受け入れて、後でガッツリ自分で改変するか、
理由を述べて却下して、相手に実装しなおしてもらうか、
どんな対応が望ましいのか、参考までに聞かせてください。
海外でどんな対応するのが一般的なのかも知りたいです。
よろしくお願いします。

48 :デフォルトの名無しさん:2013/10/24(木) 04:49:30.60
こっちかな

GitHubやってる?
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

49 :デフォルトの名無しさん:2013/10/24(木) 13:00:03.35
gitでリポジトリを作成するとき、git initを使うんですか?

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

50 :デフォルトの名無しさん:2013/10/24(木) 13:02:43.70
git clone

51 :デフォルトの名無しさん:2013/10/24(木) 13:10:01.12
>>49
サーバ側の実装による
リポジトリを作成する権限が与えられてるなら、何らかの案内があるはずだから
管理者に確認したらいいよ

52 :デフォルトの名無しさん:2013/10/24(木) 13:17:20.74
>>51
すみません、わたしが管理者です
どう案内すればいいかいま検証中なんです

53 :デフォルトの名無しさん:2013/10/24(木) 13:19:46.72
どこを中央サーバにするかって、単に運用方法の問題じゃないの?@素人

54 :デフォルトの名無しさん:2013/10/24(木) 13:30:46.61
中央サーバと末端PCがあって、
末端PCでプロジェクトを作ったのでそれを中央サーバに
新規に登録したいのですが
cvsのinitに相当するコマンドはgitにはないので

プロジェクトのファイルを中央サーバにコピーして
中央サーバでgit initして、それを
末端PCで git clone する という動きでよいですか?

55 :デフォルトの名無しさん:2013/10/24(木) 13:48:24.27
>>54
よくない。空のリポジトリが作られるだけ
基本、サーバでgit initして、ローカルからpushだけど
実装によるから、それかかないと答えようがない

56 :デフォルトの名無しさん:2013/10/24(木) 13:50:34.29
実装というか構成か

57 :デフォルトの名無しさん:2013/10/24(木) 15:45:42.37
>>55
ローカルでinitしてサーバにpushすべきというのは理解しました

でも、最初の手順で空のリポジトリが作られるだけという
動きの理由がよくわかりません。

58 :デフォルトの名無しさん:2013/10/24(木) 15:46:31.03
あ、逆ですか
じゃあ理解できてませんすみません

59 :デフォルトの名無しさん:2013/10/24(木) 15:51:56.91
initで作られるのは空のリポジトリ
それをサーバに作った直後に、末端からcloneしたところで、エラーしか出ません
初回は必ず末端のローカルリポジトリから、コミット情報をpushしてやる必要があるのです

ということかと

60 :デフォルトの名無しさん:2013/10/24(木) 15:54:31.60
んで、pushをするためには、ネットワークの構成を知る必要があるってとこかな

61 :デフォルトの名無しさん:2013/10/24(木) 16:05:04.70
中央サーバに置くのは普通はbareリポジトリ
したがって中央サーバーで行うgit initは--bareオプション付き
なので>>54でgit init --bareしても空のリポジトリができるだけである
以上の思考が>>55の脳内で行われたのだろう

実際は、>>54が言うように中央サーバ上にファイルをコピーして
そのディレクトリでbareじゃないgit initすれば、
それは末端PCからgit clone可能な中央サーバ上のリポジトリになる

でも常識的に中央サーバに置くのはbareリポジトリなんで、
末端PC側でgit initで作ったリポジトリを、
中央サーバ上に作った空のbareリポジトリにpushするのがよい

62 :デフォルトの名無しさん:2013/10/24(木) 16:19:27.16
中央サーバにbare形式で目的のリポジトリを作るだけなら、
ファイルコピーしてgit initで普通のリポジトリ作って
それをgit clone --bareでbareリポジトリ化するなんて方法もある

でも後々の運用を考えると、空のbareリポジトリを用意してpushしたほうがいい
空のbareリポジトリを用意する方法は、gitを直接使う以外にいろいろある

63 :デフォルトの名無しさん:2013/10/24(木) 16:43:59.80
なぜ、構成を書いてくれないんだろう
もしかして、意味が伝わってないのか

64 :デフォルトの名無しさん:2013/10/24(木) 17:02:40.31
構成は何を書けばよいでしょうか

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

65 :デフォルトの名無しさん:2013/10/24(木) 17:32:48.33
ああ、ごめん
>>61->>62はgit initの後にgit commit -am "〜"でリポジトリにファイルを取り込まないとダメね

66 :デフォルトの名無しさん:2013/10/24(木) 17:54:40.21
書いてくれた構成よくわからなかったから、もうあてずっぽうで書くけど
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 :デフォルトの名無しさん:2013/10/24(木) 18:43:05.48
>>64
中央サーバと呼んでるマシンのOSとサーバーソフトウェア次第で
その中央サーバにリポジトリを作る方法はいろいろあるってことだよ
君がそれを言わないから、Unixサーバのsshアカウントを利用する方法をみんな説明してる

68 :デフォルトの名無しさん:2013/10/24(木) 19:14:17.41
すみません
gitでリポジトリを作る方法はsshでログインして作るのしか
知らなかったので質問の意図がわかっていませんでした。
おっしゃるとおりsshアカウント経由で作業する予定です

gitにも、cvsのようなpserver的なものがあるのですか?

69 :デフォルトの名無しさん:2013/10/24(木) 19:41:50.45
>>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 :デフォルトの名無しさん:2013/10/24(木) 19:54:12.62
リポジトリ自体はsshでログインして作るんだけどな
ていうか、ちょっとぐらいドキュメント読めよ

71 :デフォルトの名無しさん:2013/10/24(木) 20:16:58.73
Gitolite使えばsshでログインしてリポジトリ作る必要無いだろう

72 :デフォルトの名無しさん:2013/10/24(木) 21:01:48.59
すみませんどのページを見ても
同じことを同じやり方で解説してるところがほとんどなくて
その情報が古いのかモダンなのか間違ってるのか
とんとわからない状態でした

73 :デフォルトの名無しさん:2013/10/24(木) 21:22:26.01
>>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 :デフォルトの名無しさん:2013/10/24(木) 21:44:31.37
gitolite使っとけばいいだろ難しいこと考える必要ないぞ
生のsshアカウントでやるのは権限とか考えるといろいろ面倒

75 :デフォルトの名無しさん:2013/10/24(木) 22:08:37.59
俺もgitoliteが一番いいと思う

76 :デフォルトの名無しさん:2013/10/24(木) 22:11:08.35
gitoliteってウェブインターフェースあるの?

77 :デフォルトの名無しさん:2013/10/24(木) 22:31:26.71
>>76
gitoliteには組み込まれてないよ
だから、好きなウェブベースのgitクライアント使えばいいと思う
ていうか、普段使ってるgitクライアント使うのが一番いいと思うけど
turtoiseなり、sourcetreeなり

78 :デフォルトの名無しさん:2013/10/24(木) 22:37:17.99
>>76
gitlabおすすめ。

gitolite+githubクローンと
言ってもいいぐらいの
ウェブシステムだよ。

githubを使っている人や
逆に将来github使うって人には
いいとおもうよ。

79 :デフォルトの名無しさん:2013/10/24(木) 22:39:05.26
あれよ
gitoliteはリポジトリとユーザ管理をgitolite-adminっていうリポジトリで行うから
そのリポジトリを自分が使いたいクライアントで触ればいいだけ

80 :デフォルトの名無しさん:2013/10/24(木) 22:55:54.47
gitlabってRuby自前で2入れるように書いてあるのに、なんでわざわざインストールしてる1.8消させてんの?
自前でいれるなら、1.8消さなくてもgitlabが使えるように入れたらいいのに

81 :デフォルトの名無しさん:2013/10/24(木) 22:58:55.50
>>80
Linuxはディストリがたくさんあって、
すべての環境がどうなってるのか把握できないから。
Rubyが二つ入っていると、何が起きるかわからない。

82 :デフォルトの名無しさん:2013/10/24(木) 23:04:25.26
働けど働けどわがプロジェクト楽にならざり
Git手を見る

83 :デフォルトの名無しさん:2013/10/24(木) 23:15:01.41
gitlabは機能見る度に入れようかなって思うんだけど、要件にデータベースがあるのをみて結局やめてしまう
>>81
ruby2を/opt/ruby2とかに入れて、gitlabでruby実行する時はそこを使うようにもできると思うんだけど

84 :デフォルトの名無しさん:2013/10/24(木) 23:16:12.50
データーベースが要件で断念って
よくわからん。

ファイルと同様に極普通に使うものだろう?

85 :デフォルトの名無しさん:2013/10/24(木) 23:16:44.18
>>82
歌人さんかな?

86 :デフォルトの名無しさん:2013/10/24(木) 23:42:16.74
rubyのアプリは、rbenvやbundlerが良く出来てるせいで、
かなり無茶な感じに特定rubyの特定ライブラリに依存させたもの作って運用することができるけど、
OSのパッケージマネージャでそれらを管理するのは地獄の苦しみだな

87 :デフォルトの名無しさん:2013/10/24(木) 23:47:24.39
今はどの言語もなんたらenvシリーズと
パッケージマネージャ揃ってるだろう?

88 :デフォルトの名無しさん:2013/10/24(木) 23:49:22.02
(この流れは)アカン

89 :デフォルトの名無しさん:2013/10/24(木) 23:50:49.40
せめて、gitlabとかgitoliteの流れに戻ろう

90 :デフォルトの名無しさん:2013/10/24(木) 23:56:25.07
>>84
>ファイルと同様に極普通に使うものだろう?
そうかな
データベースサーバ新しく立ち上げるとか、既存のデータベースサーバにアクセスできるようにするとか
色々考えることあると思う

91 :デフォルトの名無しさん:2013/10/25(金) 11:15:13.64
全部 /usr/local/mygit などにインストールして、そこから起動すればいいだろう

92 :デフォルトの名無しさん:2013/10/25(金) 16:23:50.44
sqlite使えなくなってたのか。

93 :デフォルトの名無しさん:2013/10/26(土) 03:52:42.91
gitを使い始めたもので管理について質問させていただきます。
WebページやWebアプリを作っているのですが、サーバ側のリモートリポジトリはそのプロジェクト毎に作成し、使うものなのでしょうか?
それとも他に一括で管理する方法があるのでしょうか?

94 :デフォルトの名無しさん:2013/10/26(土) 08:53:18.88
Visual Studio 2013 Express で git が使えるようになったらしいので、今更ながら git 使い始めたんだけど、キーワード置換とかできないんだな...

95 :デフォルトの名無しさん:2013/10/26(土) 11:37:13.47
>>93
質問がよくわからん
ローカルもサーバも違いはないよ

96 :デフォルトの名無しさん:2013/10/26(土) 14:49:08.12
>>93
一つのリポジトリの中にディレクトリを掘って、
複数のプロジェクトのファイルを突っ込んでもいいし、
プロジェクトごとにリポジトリを作ってもいい。

どちらも一長一短ある。
プロジェクト間でファイルを共有しているなら一つのリポジトリにして、
そうでないならわけた方がいいかもしれん。

わけておけばプロジェクトごとにリポジトリのcloneが可能だが、
そうでないなら全部cloneすることになる。

97 :デフォルトの名無しさん:2013/10/26(土) 17:44:41.64
プロジェクト間で共有されるファイルはsubmoduleにしたほうがいいのでは?

98 :デフォルトの名無しさん:2013/10/26(土) 18:48:46.48
それ、サーバ、ローカル関係なくない?

>一括で管理する方法があるのでしょうか?
って聞いてるから、管理方法をしりたいんじゃなかろうか。。

99 :デフォルトの名無しさん:2013/10/26(土) 19:32:00.07
>>96
ありがとうございます。
プロジェクトごとに分けることにします。

100 :デフォルトの名無しさん:2013/10/26(土) 21:09:35.51
gitってmacやwindowsでも操作同じ?
「アリスとボブのGit入門レッスン 」という本がよさそうなんだけど
この本macで解説してるんで聞いてみた。
gitってなんでこんなに名が知られていないんでしょうかね?

101 :96:2013/10/26(土) 21:17:57.89
>>97
俺ならsubmoduleを使うが、あの使いこなすのが難しい機能を
「使い始めた」と言っている>>93に勧める気にはなれなかったので。

102 :デフォルトの名無しさん:2013/10/26(土) 21:34:44.46
>>100
git自体の操作はどれでも同じ
知名度をいうなら、プログラマでgit知らない人いないぐらいだと思うけど、>>100の周りではそうじゃないの?

103 :デフォルトの名無しさん:2013/10/26(土) 23:07:45.92
ボブ「Gitからメッセージも出力されているね。」
アリス「メッセージは英語なのね・・・。」
ボブ「そうだね。英語だね。でも、簡潔な言い回しだから、じっくり読めばおおよその
意味がわかると思うよ。最初だから日本語訳を付けておくね。」

104 :デフォルトの名無しさん:2013/10/26(土) 23:08:47.72
>>100
> gitってなんでこんなに名が知られていないんでしょうかね?

可哀想に。使えないならともかく知らないっていうのは、
プログラミングに興味が無いと言っているのと同じレベルだぞ

105 :デフォルトの名無しさん:2013/10/27(日) 00:42:15.31
>>94
commitしたファイルのチェックサムが、リビジョンになるからね

106 :97:2013/10/27(日) 01:09:05.75
>>101
ごもっとも 俺もいざとなったら調べて使うだろうが今のところ練習以上に使ったことはない

107 :デフォルトの名無しさん:2013/10/27(日) 07:56:56.21
>>105
う〜ん、別にチェックサムでもいいのでソースに埋め込ませてくれてもいいと思うんだけど。
コミットした日時とか、人とかもあると嬉しいし...

108 :デフォルトの名無しさん:2013/10/27(日) 08:34:54.03
>>107
チェックサム埋め込んだらチェックサムが変わっちゃうじゃないですか。

109 :デフォルトの名無しさん:2013/10/27(日) 08:43:44.77
チェックサムを埋め込んだらチェックサムが変わってしまったでござる

110 :デフォルトの名無しさん:2013/10/27(日) 08:54:24.39
チェックサムの無限ループや!

111 :デフォルトの名無しさん:2013/10/27(日) 09:00:10.43
チェックサムがッ!一致するまで!再計算するのをやめないッ!

112 :デフォルトの名無しさん:2013/10/27(日) 09:29:59.66
>>102>>104
ほとんどひとりで個人の趣味範囲
こういうのを使ってソフトを作成していったんですね
ソフト作りも製造業に似ていますね
どちらというと一人やっているほうが楽しいかね

113 :デフォルトの名無しさん:2013/10/27(日) 10:03:49.24
>>108
Subversion 知らないの?
リポジトリから取ってくる時に埋め込むから、リポジトリのリビジョンは変わらないよ。
git でもできると思うんだけど。

114 :デフォルトの名無しさん:2013/10/27(日) 10:08:53.19
キーワード置換ってなに?

115 :デフォルトの名無しさん:2013/10/27(日) 10:19:07.93
>>94へ朗報>>113

116 :デフォルトの名無しさん:2013/10/27(日) 10:23:15.39
>>113
それ、取得元の証明であって、手元にあるものがソース+チェックサムだってどうやってわかんの?
そもそもcommitログでチェックサムも日時も人も全部わかるじゃん

117 :デフォルトの名無しさん:2013/10/27(日) 10:59:04.93
>>116
サムチェックだと考えるからわからんのだよ。
ファイルの内容とは無関係なGUIDのような任意のIDだと考えたまえ。

任意のIDはファイル内容を変えても、変わらんよ?

118 :デフォルトの名無しさん:2013/10/27(日) 11:25:16.10
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 :デフォルトの名無しさん:2013/10/27(日) 11:36:17.97
>>115
同一人物なんだが...

>>116
> それ、取得元の証明であって、手元にあるものがソース+チェックサムだってどうやってわかんの?

もちろん、取得したやつは変更し放題だからリポジトリの内容と同一かは保証できないけど、あえて変なことしなきゃいいだけでしょ?
そもそもそれは Subversion でも、同じだし。

> そもそもcommitログでチェックサムも日時も人も全部わかるじゃん

いや、印刷したソースとか、実行ファイルに埋め込んでおいて、問題が発生した版はどれだっけ? とか、git から離れたものを特定したいんよ。

120 :デフォルトの名無しさん:2013/10/27(日) 11:39:36.63
>>119
あ、おまえ、スクリプト言語しか使ってないだろ?

ソースコードを直接実行するタイプの。


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

121 :デフォルトの名無しさん:2013/10/27(日) 11:40:32.73
gitって奥が深い?
gitってなんの言語で書かれているの?

122 :デフォルトの名無しさん:2013/10/27(日) 11:41:42.21
>>114
ソースコードの中に $Rev$ とか入れておくと、自動的にそのファイルのレビジョンに置き換えてくれる機能。
レビジョンだけでなく、ファイル名とか、コミットした日時や人とかに置き換えができる。

123 :デフォルトの名無しさん:2013/10/27(日) 11:45:26.41
>>119
git でもできると思うんだけど。

124 :デフォルトの名無しさん:2013/10/27(日) 11:45:52.63
ソースコードの中の著作権とかの名前のように
原則として変わらないものは意味がある。

だがコミット日時やコミットした人の名前のように
頻繁に変わるもの($Rev$というのは変わるものにつけるもんだが)
に関して、そんなものを埋め込む意味は無い。
そんなのを埋め込んで役に立ったためしがない。

これが答え。

125 :デフォルトの名無しさん:2013/10/27(日) 11:48:44.75
>>120
文字列に埋め込んで、実行ファイルがどのソースからビルドされてるかを後から確認するとかもできるよ。
ident とかそれを見るための専用コマンドがあったりしたんだが...

126 :デフォルトの名無しさん:2013/10/27(日) 11:49:01.93
コミットした人ってさ、
複数の人がコミットしている場合
行ごとに違う人が修正していることって
よくある話だけど、

コミットした人の名前知ってどうすんの?

127 :デフォルトの名無しさん:2013/10/27(日) 11:49:54.63
そういうのはソースに書くのではなく
バージョン管理システムに任せなさい

128 :デフォルトの名無しさん:2013/10/27(日) 11:52:03.23
>>125
え? ソースファイルってたくさんあるじゃん。
実行ファイルが、どのソースファイル(全100ファイル)郡から
ビルドされてるかしってどうするの?

そんなもん、ソースファイルに埋め込むんじゃなくて、
ビルド時に生成したリビジョン番号を埋め込むだけだろ。

129 :デフォルトの名無しさん:2013/10/27(日) 11:53:22.84
>>123
やり方、教えて。

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

130 :デフォルトの名無しさん:2013/10/27(日) 11:53:58.47
例えばこんなの。

簡易ビルドスクリプト


$ build.sh リビジョン番号

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

131 :デフォルトの名無しさん:2013/10/27(日) 11:54:12.17
>>94
SubversionとGitの大きな違いはブランチのスイッチが瞬時にできること。
対象となるブランチがローカルにあるのでそれができる。
キーワード置換があったら、ブランチのスイッチで置換が必要になるので遅くなる。
だからキーワード置換の機能はGitにはない。

Gitにキーワード置換を加えるパッチは、そういう理由でLinusに却下されている。
http://thread.gmane.org/gmane.comp.version-control.git/44750

132 :デフォルトの名無しさん:2013/10/27(日) 11:55:16.68
>>129
> いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。

日付ごとにディレクトリ作ってバックアップするという作業を
”有効に使っている人” もいるでしょうねw

意味が無いことを有効だと勘違いしているだけ。

133 :デフォルトの名無しさん:2013/10/27(日) 11:57:01.66
キーワード置換なんてビルド時にやればいいだけじゃん?

ソースコードを誰が(最終)コミットしたかなんて
わかるんだしさ。なんなら全コミット者だってだせるよ?

印刷も、印刷時にキーワード埋め込みをすればいいだけ。

134 :123:2013/10/27(日) 11:58:21.18
>>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 :デフォルトの名無しさん:2013/10/27(日) 12:01:06.01
>>126
まあ、最後のコミッターにそんなに意味があるかと言われたら、俺もそれほど重要とは思えないけど、コミッターがあまり変わらない場合もあるから、できてもいいじゃんぐらいだと思う。
それはそれとして、そのファイルのレビジョンを知りたいんだよ。

>>127
もちろん、SCM に任せるんですよ?
SCM を離れたソースコードを特定したいと言う話。

136 :131:2013/10/27(日) 12:09:57.08
>>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 :デフォルトの名無しさん:2013/10/27(日) 12:11:53.26
>>135
> SCM を離れたソースコードを特定したいと言う話。

だから、SCM から離す時に埋め込めばいいじゃん。

138 :デフォルトの名無しさん:2013/10/27(日) 12:12:25.16
>>135
> それはそれとして、そのファイルのレビジョンを知りたいんだよ。

gitに問い合わせればわかる。

139 :デフォルトの名無しさん:2013/10/27(日) 12:15:42.00
>>130
なるほど、こう言うのがあるのか。
ちょっと見てみる、サンクス。

>>131
なるほど、だから >>130 みたいに外部でやると言うことになるのかな。
しかし、全部見れてないけど結構議論されたんだな。

>>132
> 意味が無いことを有効だと勘違いしているだけ。

まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
さすがに、書いてて恥ずかしくない?

140 :デフォルトの名無しさん:2013/10/27(日) 12:18:50.05
話変わるけど、git bisectって凄いよね。

例えば、何処かで動きがおかしくなったとするじゃん?
どこかのリビジョンでは正常だったことがわかってる。
どこかのリビジョンではおかしくなったことがわかってる。

そういった時に、正常と異常の二つを指定するだけで
そのその中間のソースコードを取ってこれる。

そしてそれがちゃんと動いているか確かめる。
正常であればgit bisect good、異常であればgit bisect badを実行する。

そうすれば、今度は正常と異常の中間を取ってくる・・・と繰り返すので
最初以外リビジョンなんか考えずに、どこでおかしくなったかを探すことが出来る。

141 :デフォルトの名無しさん:2013/10/27(日) 12:20:15.33
>>139

> まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
> さすがに、書いてて恥ずかしくない?

勘違いしていた人は成長した。
お前は成長しないの?

新しいものを使っていて、古いやり方をするのは
何も成長してないからね。

プログラミングでもいるんだ。
新しい言語、新しいライブラリを導入しても
古いやり方のまま続けて、導入した意味を無くす奴ってね。

142 :デフォルトの名無しさん:2013/10/27(日) 12:23:50.72
>>136
> それができないならその「ほかのSCM」を使っていた方がいい。

それはそうなんだけど、Visual Studio の Express (=無償版) には、git と TFS のクライアントしかないんだわ。
まあ、貧乏なだけなんだが (w

>>137
うん、そうなんだけど、他の SCM の多くはその機能が本体に組み込みだから git もそうだと思ってたんよ。

>>138
話の流れ追えてます?

143 :デフォルトの名無しさん:2013/10/27(日) 12:31:13.21
>>141
git が最新ともベストとも思えないので、成長とか意味わからん (w

144 :デフォルトの名無しさん:2013/10/27(日) 12:34:55.21
>>142
そもそも将来的にメンテする可能性のあるものを何故gitからわざわざ離すのかもよく解らんのだが…
仮に離すとしても、そいつはメンテせずに
大元のほうを残して、そっち使ってメンテしないか?

145 :デフォルトの名無しさん:2013/10/27(日) 12:37:26.72
94はキーワード展開のやり方教えてもらったんだから
smudge フィルタをさっさと書けよハゲ

146 :デフォルトの名無しさん:2013/10/27(日) 12:56:26.47
定期的に「ある特定のファイルのリビジョン」という話をする人が出てくるなあ
俺の理解だと,gitでそういう話をするのは無意味だと思うんだけど

147 :デフォルトの名無しさん:2013/10/27(日) 12:59:13.02
>>144
いや、離した奴をメンテとかは (普通は) しないよ。
実行ファイルの提供とか、印刷とか離れちゃう奴をどう特定するかの話。

>>145
まあ、あせるなよ。
せっかちなやつはモテないぞ (w

148 :デフォルトの名無しさん:2013/10/27(日) 13:05:39.35
以前ファイルごとのリビジョンの話もあったけど、
ソースツリー全体まとめて何かになるのであって、ファイル単体それぞれを
適当に持って来てもどうにもならないということが理解できるかで
意見が別れるようだね。

リリース管理せずに、何かあったらファイル単体だけメールで送っちゃう
ような運用だと、ファイル単体に情報は必要だろう。
場合によっては行ごとにリビジョン番号を埋め込みたい人もいるかもしれないw

金がないなら自分で工夫するんだ。頑張れ!

149 :131:2013/10/27(日) 13:09:58.38
>>142
Visual StudioのGitはリポジトリのビューワーとして使った方がいいよ。
あれでチェックインその他の操作を覚えてもろくなことにならない。

将来Gitを使いこなしているチームに君が加入することがなく、
チームに新たにGitを導入する指揮を君が取ることもないなら、
Visual Studioから使っていても構わないけど。

150 :デフォルトの名無しさん:2013/10/27(日) 13:12:42.24
出来ないことはやってはいけないこととする流儀があるんだよね。
たとえば日本語ファイル名とか。
ファイルの名前を日本語にしてるんだぜ?馬鹿だろ?なんて真顔でのたまっていた時代、
人たちがほんとにいたんだよ。

151 :デフォルトの名無しさん:2013/10/27(日) 13:12:59.41
メールでパッチ送る方法ならgitに
ついてる

まずちゃんとgitのやり方を学べ
変なやり方はやめて成長するんだ

152 :デフォルトの名無しさん:2013/10/27(日) 13:30:47.54
>>150
多くの人が使っているツールのやり方と自分のやり方のどっちが良いか
って話じゃないかな。業務パッケージに業務を合わせるか、業務に合わせて
ソフトウェアをカスタマイズさせるかの違いというか。自分のやり方の
方が良いかは置いておくとしても、カスタマイズにはコストがかかるのは当然。

日本語ファイル名はMS-DOS2.11で普通に使えてましたね。UNIXの人たちは…w

153 :デフォルトの名無しさん:2013/10/27(日) 13:34:04.11
nihongo-de-nani-ga-warui.txt

154 :デフォルトの名無しさん:2013/10/27(日) 13:36:00.09
>>148
Subversion 使ってるので、ソースツリーのリビジョンとかは違和感ない。
ただ、印刷してレビューとか、外注さんにソース渡すとかあるんだよね。
まあ、そう言う運用には向いてないってことなんだろうな。

>>150
いまでも、日本語ファイル名は結構鬼門だよ。
海外製のツールはダメなやつ結構あるし、OSS でも Doxygen とか...

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

156 :デフォルトの名無しさん:2013/10/27(日) 15:00:36.05
単にコマンドラインで日本語ファイル名を入力するのがめんどくさいから使ってないなあ

157 :デフォルトの名無しさん:2013/10/27(日) 15:04:49.81
>>113
CVSの頃はよく使ってたけど、SVNだとあんま意味無いからmakeでやってたな。

158 :デフォルトの名無しさん:2013/10/27(日) 15:08:59.04
>>152
MSがすぐ互換性崩して妨害しようとするから、ファイル名などのようなとこはメジャーなものでないと危険。

159 :デフォルトの名無しさん:2013/10/27(日) 17:00:11.36
印刷してレビューするだけで
なんでソースコードに
リビション番号を書かないと
いけないのかわからない

印刷のヘッダに書けば事足りるだろ?

160 :デフォルトの名無しさん:2013/10/27(日) 17:04:11.10
外注に渡すにしても
zipに同梱すればいいじゃないか
zipのファイル名がリビション番号
なのもよくある事だし

161 :デフォルトの名無しさん:2013/10/27(日) 17:21:53.42
>>150
Unicodeが普及した後にマになるとこういう発想が出来るのか

162 :131:2013/10/27(日) 17:51:57.45
何を勘違いしてるんだお前らは。
キーワード置換そのものが古いとか不要とかいうのはおかしいぞ。
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 :デフォルトの名無しさん:2013/10/27(日) 18:01:11.82
>>159-160
今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ?
zip 同梱とかは、ソース一つとは限らないし、目視で対応付けとかは勘弁してほしい。

>>161
最近の環境使ってれば、そんな変な感覚とは思えないけど?

164 :デフォルトの名無しさん:2013/10/27(日) 18:01:31.11
>>162
あぁ、それで問題ないな。

エクスポートする時やアーカイブを作る時に
自動的に入れればそれで事足りるわけだし。

165 :デフォルトの名無しさん:2013/10/27(日) 18:03:21.05
>>163
> 今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ?

なんで印刷ソフトが関係有るんだ?
エクスポートしたり、印刷する直前に、
ファイルの頭につければいいじゃないか。

それをコミットしなければいいだけの話だよ。

すべてのソースコードに一行付け足すことが君には難しいの?

166 :デフォルトの名無しさん:2013/10/27(日) 18:05:22.23
>>163
ってアーカイブをする作る時に
WindowsのGUI使って
.gitディレクトリ選ばないように選択して
右クリックメニューからzip作ってそうw

167 :デフォルトの名無しさん:2013/10/27(日) 18:37:33.42
CVSだとファイルごとにバージョン違ったりするけど、SVNやgitだと同じでしょ。それでもファイルごとに付ける意味あるのかな。それとも最後に変更したIDをつけるの?

168 :デフォルトの名無しさん:2013/10/27(日) 18:42:48.75
ファイルにバージョン番号がなくて
どうやってファイルを管理するのか?

(バージョン管理ソフトを知らない)

もしファイルを二つ提示されて
それが同じかどうかどうやって判断すればいいのか?

(diffを知らない)

ファイルにバージョン番号が含まれていれば、
それが分かるんですよ。

(それ以外の方法を知らない)

いちいちファイルを手動で書き換えるのは面倒ですよね?
だからキーワード置換が必要なのです。

(自動で全部のファイルを書き換えるプログラムを作れない)

一体これの何がダメだというのでしょうか?

(プログラミング技術がない素人だから金もらってはダメ)

169 :デフォルトの名無しさん:2013/10/27(日) 19:13:31.88
>>165
ああ、すまん、印刷でヘッダーっ言うと、各ページに印刷される奴のこと言ってるんだと思ったんよ。

>>166
君のおすすめの方法を教えてくれまいか。

>>167
> 最後に変更したIDをつけるの?

そう、Subversion 使ったことないかな?

170 :デフォルトの名無しさん:2013/10/27(日) 19:19:14.50
>>168
> もしファイルを二つ提示されて
> それが同じかどうかどうやって判断すればいいのか?

もし、キーワード置換の話のこと言ってるとしたら、全然違う話だから。
全てのレビジョンと比較するつもりなら止めやしないけど...
まさか、違うよね? (w

171 :デフォルトの名無しさん:2013/10/27(日) 19:32:22.19
>>170
違うに決まってるだろ
そんな勘違いするのお前だけだよ。
馬鹿じゃないのか?

172 :デフォルトの名無しさん:2013/10/27(日) 19:33:15.88
ここまででよくわかった。
gitにキーワード置換を搭載する意味は無い。
代替方法で、全く同じことができるし、
そもそもやる意味が無いということだ。

173 :デフォルトの名無しさん:2013/10/27(日) 19:38:10.28
>>169
svnが出てくる前からcvs使ってて、svnはできることそんな変わらないのに、不便な点が多くてあんま使わなかったな。svn使ってる客ってにわかなのか、単にファイルコピーとしか使ってない人が多かったし。タグ埋め込みなら使ってたかな。

174 :デフォルトの名無しさん:2013/10/27(日) 20:18:38.99
>>171
そうだよね、安心したわ。

で、
> もしファイルを二つ提示されて
なんて、どっからでてきたの? (w

175 :デフォルトの名無しさん:2013/10/27(日) 20:23:42.68
>>173
確かに、タグ埋め込みとか言ってる時点で svn 使えてなかったのは、よくわかるわ。

176 :デフォルトの名無しさん:2013/10/27(日) 21:27:59.35
>>172
てか確かSVNでも非推奨ってことで、デフォルトではオフになってないっけキーワード置換

177 :デフォルトの名無しさん:2013/10/27(日) 22:22:19.89
>>176
非推奨じゃないよ。
Subversion は指示されないことはやらないと言うポリシーなだけ。
拡張子で自動設定する機能もある。

178 :デフォルトの名無しさん:2013/10/27(日) 22:23:51.70
やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
なんか勝手に入れてくれると楽って話だろうねえ。
まともな仕事をしている人は、そういうの認めたくないんだろう。

>>163
UNICODEは正規化の話がね。MS-DOSの頃の方がある意味まともだった。

179 :デフォルトの名無しさん:2013/10/27(日) 22:31:24.56
>>178
> やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
> なんか勝手に入れてくれると楽って話だろうねえ。

ごめん、適当とか勝手にとか言ってる内容がさっぱりわからん。

180 :デフォルトの名無しさん:2013/10/27(日) 22:33:37.68
>>175
どういうこと?

181 :デフォルトの名無しさん:2013/10/27(日) 22:36:00.82
>>175
どういうこと?
タグじゃなくてブランチ名って言えってこと?

182 :デフォルトの名無しさん:2013/10/27(日) 22:42:31.03
>>180-181
タグ埋め込みなんて言わないでしょ?
タグを打つとかは言うけど。

183 :デフォルトの名無しさん:2013/10/27(日) 22:43:23.04
そもそも、キーワード置換なんて
ソースコードに入れる必要がないわけで。

あんなのCVS時代の遺産だよ。
CVSはファイル単位の管理しか出来なかったからね。

184 :デフォルトの名無しさん:2013/10/27(日) 22:44:56.39
そう、リビジョン番号なんてのは
エクスポートした時に自動で埋めればいいだけ
そういうのが必要な人は自分でやればいいやん。
gitの文化で要らないものはつけてない。それだけの話。

185 :131:2013/10/27(日) 22:50:15.53
うっとうしいので>>94はいちいちバカの相手をするのをやめてくれ。

186 :デフォルトの名無しさん:2013/10/27(日) 22:58:10.61
>>184
まあそういうことみたいやね。
>>134 >>136 >>162 で URL 教えてもらえたし、あとは何とかするわ。

187 :デフォルトの名無しさん:2013/10/27(日) 23:04:10.33
>>185
ああ、すまん。
マジで git 使うの初めてだから、もう少しこのスレのレベル高いかと思ってたんだけど、大体わかったから、あとは適当にスルーするわ (w

188 :デフォルトの名無しさん:2013/10/27(日) 23:09:28.37
馬鹿を相手にするのは馬鹿だけってことですよ
キーワード展開については前スレでもその前のスレでも>>162のリンクで終わってる

189 :デフォルトの名無しさん:2013/10/27(日) 23:27:11.22
ほんと毎回うっとおしいんだよね
テンプレには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(日) 23:34:43.52
>>182
あなたは思い込みをしているようだ。
バイナリとかにタグを入れることだよ。

191 :デフォルトの名無しさん:2013/10/28(月) 19:37:21.02
こういうレベルの低い技術者が末端に居るだけなら叩き出せば済むんだが、そうでないと無駄な作業で工数取られてイライラすんだよな
マニュアルすら通読しないし救い難い。VSProを買う金すらねぇならもっと勉強しろよ。お前にゃgitはまだ早い

192 :デフォルトの名無しさん:2013/10/28(月) 20:20:48.46
調べもせずに質問ってが腹立つのはわからんでも無いが、gitに早い遅いがあるのか?
嫌なら初心者スレでも立てて隔離すりゃいいんじゃね

193 :デフォルトの名無しさん:2013/10/28(月) 20:49:58.78
ここはお前の日記帳だ

194 :デフォルトの名無しさん:2013/10/28(月) 21:35:59.23
>>191みたいなうるさいだけで非生産的なやつが一番困る

195 :デフォルトの名無しさん:2013/10/28(月) 21:36:54.34
>>192
なんかやなことでもあったんでしょ
優しくスルーしてあげましょう

196 :デフォルトの名無しさん:2013/10/29(火) 09:00:39.16
Subversionでもキーワード置換できるけど使いたいという奴は老害ばかりだよ

197 :デフォルトの名無しさん:2013/10/29(火) 13:32:11.13
老害かどうかなんて一概には言えんのだが、
確かにその傾向は強く感じる

198 :デフォルトの名無しさん:2013/10/29(火) 21:16:49.86
キーワード置換はできるからやってるだけで
やる意味があるからやっているわけじゃない。

199 :デフォルトの名無しさん:2013/10/29(火) 22:24:37.56
authorを捏造して納品しろと言われて、リリース時にヘッダを
書き換えるようにしたら簡単かつ綺麗だったので、
CVSでも置換はやらなくなったな。

200 :デフォルトの名無しさん:2013/10/29(火) 22:38:48.68
しゃちょー、PeercastStationエラー落ちのままだったら
新しいクライアントつなげないから、再起動しておくれ

201 :デフォルトの名無しさん:2013/10/30(水) 23:55:10.83
Git 1.8.4.2
https://code.google.com/p/git-core/downloads/list

202 :デフォルトの名無しさん:2013/10/31(木) 10:38:00.00
git cloneすると
リポジトリになくてローカルにあるファイルや
ローカルで編集済みのファイルとかは
どうなりますか?

203 :デフォルトの名無しさん:2013/10/31(木) 11:35:38.90
どうもならん

204 :デフォルトの名無しさん:2013/10/31(木) 12:01:23.54
もうどうにもならない

205 :デフォルトの名無しさん:2013/11/01(金) 13:54:57.65
pull requestでコード貰ったんですけどこれってそのまま取り込んでもOKですか?
ライセンスとか面倒なことになりますか?

206 :デフォルトの名無しさん:2013/11/01(金) 15:35:23.11
それはpull req投げたヤツに聞けよ

207 :デフォルトの名無しさん:2013/11/01(金) 15:50:38.75
githubにしろpull requestのページでコメントでやりとりできるしな

208 :デフォルトの名無しさん:2013/11/01(金) 17:06:55.82
Tortoisegitを使っていて
pushするときにサブモジュールを再帰的にチェックとあるんですが
どういう意味ですか?

209 :デフォルトの名無しさん:2013/11/01(金) 21:45:00.79
サブモジュールのサブモジュールのサブモジュールもチェックするよー

210 :デフォルトの名無しさん:2013/11/02(土) 17:22:43.77
初めてGithubでPull request来たのですが
これってブランチを別につくってそこでテストしてから
マージするのが普通なんですかね?

211 :デフォルトの名無しさん:2013/11/02(土) 17:39:45.81
すいませんmasterブランチにプルリクエストでコードが来た場合
それをtestブランチに入れる方法を教えてください

212 :デフォルトの名無しさん:2013/11/02(土) 17:54:41.07
馬鹿には無理

213 :デフォルトの名無しさん:2013/11/02(土) 18:04:37.42
>>210-211
You can also merge branches on the command line.

214 :デフォルトの名無しさん:2013/11/02(土) 18:11:45.35
masterブランチ以外にマージするなら
Github上じゃなくて他のGitクライアントでの作業が必須だな
別にコマンドラインである必要は無いと思うけど
コマンドライン以外の手軽な方法は知らん

215 :デフォルトの名無しさん:2013/11/02(土) 18:14:03.84
プルリクエスト送ってくれたとこのフォークリポジトリからローカルにフェッチだかクローンだかして
ローカルでマージテスト用ブランチ作ってそこにマージしてテストしてからローカルのマスターにマージしてプッシュ

216 :デフォルトの名無しさん:2013/11/02(土) 18:19:21.14
シングル ベンティ キャラメル アーモンド ヘーゼルナッツ モカ ホワイトモカ
チョコチップ エキストラホイップ キャラメルソース チョコソース バニラクリームフラペチーノ

217 :211:2013/11/02(土) 18:52:39.71
バカがmasterブランチにさえプルリクエストを送らなければ僕は悩まなかった

218 :デフォルトの名無しさん:2013/11/02(土) 18:53:41.40
じゃあどこにプルリクエスト送るんだよ

219 :デフォルトの名無しさん:2013/11/02(土) 18:55:30.14
あの、Pull Requestを取り消すほうほうってありますか?

220 :デフォルトの名無しさん:2013/11/02(土) 18:57:48.30
>>219
アカウントを消す

221 :デフォルトの名無しさん:2013/11/02(土) 19:07:16.82
取り消すことは出来ないけど、クローズすればいいよ。クローズする理由をコメントで添えておけば尚OK

222 :デフォルトの名無しさん:2013/11/02(土) 19:46:18.91
プルリク要らなきゃプライベートリポジトリにしておけ。
金払いたくないならbitbucket.orgでやれ。

223 :デフォルトの名無しさん:2013/11/02(土) 20:56:04.66
論点ずれてる

224 :デフォルトの名無しさん:2013/11/02(土) 22:24:45.19
じゃ、こっちかな

GitHubやってる?
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

225 :デフォルトの名無しさん:2013/11/03(日) 07:14:05.11
http://itpro.nikkeibp.co.jp/article/NEWS/20130529/480625/
年収は必須です。

Q. Pull Requests、Forkなどの機能はありますか?

A. 申し訳ありません現在は実装しておりません。
作ってる本人も欲しい機能なので結構早く実装されるとおもいます。

Q. Gitサーバーにsshでアクセスすることは可能ですか?

A. 申し訳ありません現在HTTPSのみ対応しております。
開発チームがそれなりにがんばっているので、それなりな時期に対応できるとおもいます。
俺が実装してやるぜ!という奇特な方はこちらからご応募ください。
http://www.bizreach.co.jp/recruit/

226 :デフォルトの名無しさん:2013/11/03(日) 10:32:22.13
コードブレイクか
sshとpull requestはもうサポートされたんじゃなかったかな?

気になったけど、スキルとか年収とか書くの面倒くさそうで止めた

227 :デフォルトの名無しさん:2013/11/03(日) 13:50:24.97
年収0なら0と書けば良いだけ
無理して嘘を付く必要はない

228 :デフォルトの名無しさん:2013/11/03(日) 14:39:27.56
画像を加工したいのですが、変更したらコミットしていく使い方も出来ますか?

ソースコードを書く目的以外で使わないほうがいいのでしょうか?

229 :デフォルトの名無しさん:2013/11/03(日) 14:49:04.99
>>227
じゃあお前の年収をここに個人が特定できるように書いてみて。
書けないのなら、書けない理由を書いてみて。

230 :デフォルトの名無しさん:2013/11/03(日) 14:57:52.29
Windows で git 使おうと思ってるんだけど、まだ日本語ファイル名は鬼門なんだっけ?

231 :デフォルトの名無しさん:2013/11/03(日) 15:02:07.58
>>228

差分を見るのにはいろいろ工夫が必要になるけど、
単に過去のものに戻れるだけでも版管理の意味はあるよ。

gitならテキストもバイナリも保存容量の効率変わらないし。

232 :デフォルトの名無しさん:2013/11/03(日) 15:07:53.64
画像はSVGにしておけば差分取るにも効率が良い。

233 :デフォルトの名無しさん:2013/11/03(日) 15:09:53.30
SVGの差分を見て何がわかるというのか?

234 :デフォルトの名無しさん:2013/11/03(日) 15:13:47.50
エレメントの追加削除、属性の変更くらいならわかるだろ。

235 :デフォルトの名無しさん:2013/11/03(日) 15:18:46.65
>>231
ありがとうございます。

加工ミスしたときに前バージョンに戻るために使いたいと思います

236 :デフォルトの名無しさん:2013/11/03(日) 15:19:31.93
いや、画像を修正する作業を見てみ。

画像でみればほんの僅かな修正だが、
SVGのデータで見れば、大きく変更が
ある修正が大半だよ。

それをテキストの差分見て何を読み取れるのかって話。

237 :デフォルトの名無しさん:2013/11/03(日) 15:38:57.76
>>>222
これか

BitbucketでGitとMercurialの無料ソースコードホスティングを
https://bitbucket.org/

238 :デフォルトの名無しさん:2013/11/03(日) 20:33:45.16
>>237
プライベート&ぼっち、って条件なら有名なトコだな

239 :デフォルトの名無しさん:2013/11/03(日) 20:35:35.54
GitHubでの公開ぼっちとどっちがマシか

240 :デフォルトの名無しさん:2013/11/03(日) 21:15:47.05
でもさいきなりサービス終了とかしたらどうするの?

241 :デフォルトの名無しさん:2013/11/03(日) 21:18:13.87
「突然終了したらどうなるの?」
これって有償サービス無償サービスもネットもリアルも関係なく存在する話だよね

242 :デフォルトの名無しさん:2013/11/03(日) 21:55:03.76
プッシュしたものが正常に送れたか確かめる方法はありますか?

243 :デフォルトの名無しさん:2013/11/03(日) 23:00:04.30
あります

244 :デフォルトの名無しさん:2013/11/04(月) 10:05:58.22
>>241
gitなら全コピー手元にあるんでしょ。

245 :デフォルトの名無しさん:2013/11/04(月) 12:47:02.01
あそっかサービス終了してもローカルにあるから大丈夫か

246 :デフォルトの名無しさん:2013/11/04(月) 17:44:29.42
それで安心なのはリポジトリのデータ保存という点だけな

247 :デフォルトの名無しさん:2013/11/04(月) 17:50:41.59
データさえあればまた別のところで再開もできるし他に何が要るのか

248 :デフォルトの名無しさん:2013/11/04(月) 17:54:49.56
リポジトリのデータを、Gitでバージョン管理

249 :デフォルトの名無しさん:2013/11/04(月) 18:00:28.77
GitHubなどのサービス上でやったやりとりのデータが消えたら悲しいって話じゃないの?

250 :デフォルトの名無しさん:2013/11/04(月) 18:51:35.57
>>241
有償無償かじゃなくて、自分でサービス立ち上げるか、ほかのサービス使うかの話でしょ

251 :デフォルトの名無しさん:2013/11/05(火) 02:32:00.91
スレチじゃね?
ttp://kohada.2ch.net/test/read.cgi/prog/1363523309/

252 :デフォルトの名無しさん:2013/11/05(火) 02:36:57.00
そこを正規のGitHubスレにしていいものか微妙だが
OSSのホスティングの総合スレみたいなのが欲しいところだね

253 :デフォルトの名無しさん:2013/11/05(火) 02:57:13.22
【板名】 ネットサービス
【板URL】 http://toro.2ch.net/esite/
【タイトル】 OSSホスティング総合【SourceForge,GitHub,etc..】
【名前(省略可)】
【メール欄(省略可)】
【本文】↓
OSS(オープンソースソフトウェア)ホスティングサービスについて情報交換したり語り合ったりするスレ


OSSホスティングサービスの例
SourceForge GitHub GoogleCode Bitbucket Launchpad CodePlex など


Comparison of Free/Open Source Project Hosting (FOSPHost) Sites Available for Hosting Projects Externally from Project Owners
http://www.ibiblio.org/fosphost/exhost.htm

OSSホスティングサービスの比較 - Wikipedia
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

Comparison of open-source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities

254 :デフォルトの名無しさん:2013/11/05(火) 03:22:33.52
>>252
確かにGitHubの本スレ扱いにしていいかはちょっと迷ったんだよね
パッと思いつく対抗馬のbitbucketのスレは無かったし

>>253
まさにそんな感じのスレ欲しいw

255 :デフォルトの名無しさん:2013/11/05(火) 09:10:01.74
素人が紛れ込んできても面倒だし、esiteじゃなくてここでいいよ。
gitやsunversionスレもソフト板じゃなくて、ここにあるので問題ないでしょ。

テンプレをブラッシュアップしてここに立てよう

256 :デフォルトの名無しさん:2013/11/05(火) 10:16:22.96
おれもム板がいいと思う
ムの人しか使わないし

257 :デフォルトの名無しさん:2013/11/05(火) 11:48:06.25
秘密鍵とかをDropboxにそのまま保存するのってやめたほうがいいですか?

258 :デフォルトの名無しさん:2013/11/05(火) 12:00:50.40
>>257 スレ違い

259 :デフォルトの名無しさん:2013/11/05(火) 13:53:22.52
日本語ファイル名使って何が悪い!
という奴らって例えば支那語のファイル名をまともに扱えない現実を見たことがないんだろうな

260 :デフォルトの名無しさん:2013/11/06(水) 01:04:11.25
>>253
それ、あくまでOSS限定なんだよなー
プライベートのリポジトリホスティングサービスも扱いたいね

261 :デフォルトの名無しさん:2013/11/06(水) 01:30:24.18
じゃあOSSホスティング総合スレじゃなく、リポジトリホスティング総合スレにするか

262 :デフォルトの名無しさん:2013/11/06(水) 10:53:34.84
ブスはGIT使うな

263 :デフォルトの名無しさん:2013/11/06(水) 12:15:05.70
>>229
個人が特定できるように書く理由ってなに?

264 :デフォルトの名無しさん:2013/11/06(水) 15:49:25.16
git rm '>>263'

265 :デフォルトの名無しさん:2013/11/08(金) 00:29:24.12
gitignoreにtmp/**/*って書いてもtmpフォルダ以下のファイルが無視されないんですが

266 :デフォルトの名無しさん:2013/11/08(金) 01:08:51.60
.gitignore

/classes
/tmpclasses
*.class
*.jar

267 :デフォルトの名無しさん:2013/11/08(金) 01:11:28.11
>>265
tmpだけでいいのでは?

268 :デフォルトの名無しさん:2013/11/08(金) 12:34:50.76
.gitignoreとか.gitconfigとかこういうGitに関するファイルの一覧ってありませんか?

269 :デフォルトの名無しさん:2013/11/08(金) 14:34:36.01
GitlabとSourceTreeでGitデビューし始めました。

http://blog.shinji.asia/sourcetree_git/
を参考に進めているのですが、認証エラーになります。
たぶんSourceTreeでSSHキーの生成をして
Gitlabに登録を交換しないといけないのだと思いますが
そこら辺がよく分かりません。

一通り書かれたサイトとかあれば紹介いただけないでしょうか

270 :デフォルトの名無しさん:2013/11/08(金) 14:35:18.92
SourceTreeいいよね
ぼくも好きですよ
今はコマンドラインしかつかってないけど

271 :デフォルトの名無しさん:2013/11/08(金) 14:49:52.92
sshのキーはどこでも作れる
http://www.openssl.org/

272 :デフォルトの名無しさん:2013/11/08(金) 14:53:50.44
Windowsでキーの作成にputtyを使うのは地雷記事
git付属のbashで作るべき

273 :デフォルトの名無しさん:2013/11/08(金) 14:58:58.28
どれで作ろうが同じじゃねーの

274 :デフォルトの名無しさん:2013/11/08(金) 15:31:04.04
そもそも公開鍵と秘密鍵も理解できていないのですが
>>271
テキトーなソフトでキーみたいな暗号文字列を作ったとして
それをGitlabとSourceTreeの両方に登録したらいいんですか?

puttyで作った公開鍵をSourceTreeに登録しようとしたらパスフレーズを聞いてきて
作ったときに指定したつもりのものを入れてもBadと怒られてしまいます。

275 :デフォルトの名無しさん:2013/11/08(金) 15:34:43.14
Soucetreeではどのように SSHの設定をすればいいですか? - Bitbucket ドキュメンテーション - Atlassian Japan Confluence
https://confluence.atlassian.co.jp/pages/viewpage.action?pageId=35815464

276 :デフォルトの名無しさん:2013/11/08(金) 15:37:37.28
windows版 SourceTreeでsshを利用してGitHubにpushとかpullとかする方法 - Qiita [キータ]
http://qiita.com/kyanro@github/items/60a9dc5a32ed1562fec2

Tips : SourceTree for Windows で SSH key を登録しても認証に失敗する - Qiita [キータ]
http://qiita.com/Kentrow@github/items/472c4454f92feb361cd6

SourceTree for Windowsで秘密鍵と公開鍵を生成! ≪ LANCARD.LAB|ランカードコムのスタッフブログ
http://www.lancard.com/blog/2013/04/11/sourcetree-for-windows%E3%81%A7%E7%A7%98%E5%AF%86%E9%8D%B5%E3%81%A8%E5%85%AC%E9%96%8B%E9%8D%B5%E3%82%92%E7%94%9F%E6%88%90%EF%BC%81/

apeirophobia: How to make SSH key with SourceTree on Windows
http://blog.img8.com/archives/2013/04/005791.html

「GitLab」を使ってGitリポジトリを管理 - Tech-Sketch
http://tech-sketch.jp/2011/12/gitlabgit.html

277 :デフォルトの名無しさん:2013/11/08(金) 15:41:54.58
GitLabのヘルプページがGitHub上にあってワロタ

278 :デフォルトの名無しさん:2013/11/08(金) 15:45:06.34
GitLabってGitHubのクローンだったのか

279 :デフォルトの名無しさん:2013/11/08(金) 15:52:35.00
GitLabって社内LAN内にGitHubみたいな共有環境を構築するってものなのか、
個人では使う機会なさそうだな

280 :デフォルトの名無しさん:2013/11/08(金) 15:52:51.63
>>271
opensslじゃなくてopensshだろ

281 :デフォルトの名無しさん:2013/11/08(金) 16:03:23.10
ローカルで GitHub を構築! Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた | Developers.IO
http://dev.classmethod.jp/tool/gitlab-install-mac-os-x-mountain-lion/

282 :デフォルトの名無しさん:2013/11/08(金) 18:33:14.94
>>276
どうもありがとうございます。
Githubではうまくいってますが、Gitlabとの組み合わせがよく分からないんです。

しかも自分のSourceTreeが1.3.1.0と新しく、なんか微妙に画面も違うしぃ・・って風でして

283 :デフォルトの名無しさん:2013/11/08(金) 18:45:04.25
うぉーー出来ました!!
SourceTree→ToolsOptionで、SSH Client のコンボボックス
OpenSSH から PuTTY/Plink に変更したら見事に成功

GitlabとはSSH通信なのでOpenSSHだと思い込んでいたのですが・・・
OpenSSHとPuTTYの違いって何ですか?
ってのはスレ違いなので、検索してきます。どうもありがとうございました。

284 :デフォルトの名無しさん:2013/11/08(金) 19:15:10.04
ソケットとかいうものが問題なのか
OSがM$だとターミナル的なもの以外ではOpenSSHをうまく扱えないものがほとんどなんだよね

285 :デフォルトの名無しさん:2013/11/08(金) 19:15:16.08
>>279
redmineは使ってるけどな。

286 :デフォルトの名無しさん:2013/11/08(金) 19:16:48.64
M$で開発とか拷問。

287 :デフォルトの名無しさん:2013/11/08(金) 19:23:17.21
vs以外で開発とか考えられん

288 :デフォルトの名無しさん:2013/11/09(土) 04:24:25.05
サーバのホームディレクトリをサンバ共有したら、sshの自動認証ができなくなってちょっと焦った思い出

289 :デフォルトの名無しさん:2013/11/09(土) 15:05:59.21
Gitで体をバージョン管理できたら
病気や老後に若い体に乗り換えればいいですよね
誰かそういうのできるプラグイン開発してくれませんか?

290 :デフォルトの名無しさん:2013/11/09(土) 15:18:28.03
どこにも異常のない一番元気なときに
あとで簡単に各部位毎に取り出せる形で
IPSで体全体のコミットがその都度出来たら
臓器バンクビジネスにソフトバンクが手を出すだろうね

291 :デフォルトの名無しさん:2013/11/09(土) 15:22:21.70
健康状態の遺伝子を保存しておけば実現可能な木もするんですけど

292 :デフォルトの名無しさん:2013/11/09(土) 15:44:15.90
>>289
記憶も戸籍上の年齢や経済力も元に戻りますが

293 :デフォルトの名無しさん:2013/11/09(土) 15:52:12.99
>>289
情報量が多すぎてcheckoutしたら最後のバージョンの手だけだったとか。

294 :デフォルトの名無しさん:2013/11/09(土) 18:26:07.26
>>292
.gitignore

295 :デフォルトの名無しさん:2013/11/09(土) 18:53:39.00
>>294
戸籍も資産もなくなるわけですね。

296 :デフォルトの名無しさん:2013/11/09(土) 20:15:47.29
Git 1.8.4.3
https://code.google.com/p/git-core/downloads/list

297 :デフォルトの名無しさん:2013/11/09(土) 20:18:43.05
1.8.5じゃねーのか?

298 :デフォルトの名無しさん:2013/11/09(土) 20:19:47.51
gitってグーグルコード上で開発してたのか

299 :デフォルトの名無しさん:2013/11/09(土) 20:27:21.97
俺の使ってるの1.8.3だった

300 :デフォルトの名無しさん:2013/11/09(土) 20:48:12.39
メンテナンスしてる濱野氏がGoogleにいるからかね?
Githubにもリポジトリあるけど https://github.com/git/git
これはミラーでpull request are ignoredとか書いてあるのにいくつか飛んできてるのが笑える
Documentation/SubmittingPatches見る限り、なんか修正して欲しかったらパッチ送れって方針なのね

301 :デフォルトの名無しさん:2013/11/12(火) 15:06:42.40
1.8.4に移行したらbashで日本語が入力できる!!!
1.8.3以下は今すぐ切り捨てろ!!!!

302 :デフォルトの名無しさん:2013/11/12(火) 15:38:00.28
>git --version
git version 1.7.4.msysgit.0

さっき`~/.config/git/ignore`が読まれなくて手間取ったのはバージョンのせいだった

303 :デフォルトの名無しさん:2013/11/12(火) 17:14:41.45
>>301
msysgit のこと?

304 :デフォルトの名無しさん:2013/11/12(火) 21:07:26.37
え・・・どういう事だ・・・?
今まで日本語入力できなかったの?
日本語入力ができなかった頃なんて俺知らないんだけど・・・

305 :デフォルトの名無しさん:2013/11/12(火) 21:47:36.42
1.8.4入れてGit Bashを起動してみたけど、相変わらず日本語は?????だったよ

306 :デフォルトの名無しさん:2013/11/12(火) 21:52:23.64
Git GUIのほうは1.8.3のときも日本語は普通に表示できてたし

307 :デフォルトの名無しさん:2013/11/12(火) 22:37:42.98
端末の問題じゃないのか。

308 :デフォルトの名無しさん:2013/11/12(火) 22:59:29.35
とにかく、Windowsを使うのを止めろ

309 :デフォルトの名無しさん:2013/11/13(水) 07:52:25.11
Gitですけどファイルの同期は取れるんですが
タイムスタンプがバラバラ

タイムスタンプも揃えること出来ないですか
(同期させること出来ませんか)

310 :デフォルトの名無しさん:2013/11/13(水) 09:04:29.43
>>309
さんざん既出
5スレ目の1から75まであたり参照

311 :デフォルトの名無しさん:2013/11/14(木) 13:52:42.63
去年から mac のターミナル(bash)で Git 使い始めて、コミットメッセージを日本語で入力してるけど問題無いよ。
git commit で vim が起動して入力しても、git commit -m でコマンドラインで入力しても問題無し。
git log で表示しても日本語が正常に表示される。

312 :デフォルトの名無しさん:2013/11/14(木) 14:00:32.91
Windowsで使うときだけ地雷

313 :デフォルトの名無しさん:2013/11/14(木) 14:26:56.03
Windowsが地雷

314 :デフォルトの名無しさん:2013/11/14(木) 23:11:09.64
GitはコミットメッセージはUTF-8なのでUTF-8で入れてる限りWindowsでも問題無いでしょ
ところでMacはNFD-Macなパス名は解決できるの?

315 :デフォルトの名無しさん:2013/11/14(木) 23:22:51.78
ファイル名やフォルダ名がShift-JISエンコードの日本語だもの

316 :デフォルトの名無しさん:2013/11/15(金) 00:22:41.44
他のソフト使いにくくして、MSのソフト使わせる戦略ですから。

317 :デフォルトの名無しさん:2013/11/15(金) 07:12:54.53
MSのソフトって使いやすいんですね

318 :デフォルトの名無しさん:2013/11/15(金) 09:58:30.05
Appleのソフトよりは質実剛健とは思う

319 :デフォルトの名無しさん:2013/11/15(金) 22:55:07.93
>>314
解決出来ないよ

320 :デフォルトの名無しさん:2013/11/15(金) 22:55:43.90
いつ2.0でるのですかロードマップないんですか

321 :片山博文MZコスモ ◆T6xkBnTXz7B0 :2013/11/15(金) 23:18:16.92
直前のコミットまで戻すにはどうすればいい?

322 :デフォルトの名無しさん:2013/11/15(金) 23:19:46.88
>>321

Git - 作業のやり直し
http://git-scm.com/book/ja/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E4%BD%9C%E6%A5%AD%E3%81%AE%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%97

323 :デフォルトの名無しさん:2013/11/15(金) 23:22:29.43
Git - Git によるデバッグ
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-Git-%E3%81%AB%E3%82%88%E3%82%8B%E3%83%87%E3%83%90%E3%83%83%E3%82%B0

324 :デフォルトの名無しさん:2013/11/15(金) 23:51:03.39
>>314
core.precomposeunicodeを設定したら、ファイル名に対してNFC変換が行われるのでMacでもだいたいOK
実は微妙に違うんだけど、普段使う程度の文字ならだいたいOK

325 :デフォルトの名無しさん:2013/11/16(土) 21:54:41.11
USBメモリのルート(ドライブレターはG:\)にクローンをしてみたのですが
fatal: destination path 'G:' already exists and is not an empty directory.
とエラーが発生してしまいます。
フォーマット直後でも同じエラーが発生します。
ルートにはクローンできないものなのでしょうか?

326 :デフォルトの名無しさん:2013/11/16(土) 22:06:46.22
エクスプローラーで開いた時点でdesktop.iniやthumbs.dbができてしまってるとか?

327 :デフォルトの名無しさん:2013/11/16(土) 22:12:45.00
フォルダーオプションで隠しファイルを表示するにして
「保護されたオペレーティングシステムファイルを表示しない」のチェックを外しても
desktop.ini や humbs.db が表示されないので空の状態になっていると思います

328 :デフォルトの名無しさん:2013/11/16(土) 22:28:36.08
>>325
USBメモリのドライブをNTFSフォルダーにマウントするとできるかも知れない

329 :デフォルトの名無しさん:2013/11/16(土) 23:15:30.82
>>325
initしてremote addしてpullすればいいんじゃない。

330 :デフォルトの名無しさん:2013/11/16(土) 23:44:24.20
>>329
なぜかpullコマンドを実行してもpullが始まらない。
リモートから何も受け取っていないみたいでローカルは変化なし。

331 :デフォルトの名無しさん:2013/11/16(土) 23:48:50.25
URLをタイプミスしてるとかはないの

332 :デフォルトの名無しさん:2013/11/16(土) 23:56:10.65
100ファイルあるファイルの中からa.txt b.txtのみを管理したいんですが
98ファイル分を.gitignoreに書くのが面倒くさいのですが何か良い方法教えて

333 :デフォルトの名無しさん:2013/11/16(土) 23:58:49.76
>>330
リモートに何もないんじゃないの。

334 :デフォルトの名無しさん:2013/11/17(日) 00:00:48.51
同じリポジトリをルートじゃない普通のフォルダでは成功したとかなんじゃね

335 :デフォルトの名無しさん:2013/11/17(日) 00:01:46.79
>>332
*
!a.txt

336 :デフォルトの名無しさん:2013/11/17(日) 00:01:54.12
シェルでもスクリプトでもファイルの列挙を書き出してa.txtとb.txtだけ削除すればいいじゃないの

337 :デフォルトの名無しさん:2013/11/17(日) 00:07:12.00
ゲームループ
1.ゲームスタート
2.あなたのAIが数を思い浮かべる(表示可能にする)
3.あなたのプログラムは敵AIの名前と思い浮かべた数の入力を待つ
4.あなたのプログラムはあなたのAIと敵AIに交互に推測させ、どちらかが当てるまで繰り返す
 (先攻が当てた場合、後攻にもう1度推測させる。両者同じ回数で当てた場合は引き分け

これって、2.のAIが数を思い浮かべるレベルのループを作れっていう意味じゃないよね?

338 :デフォルトの名無しさん:2013/11/17(日) 00:08:10.74
ttps://github.com/github/gitignore
>A collection of useful .gitignore templates

これ便利そうなのに、使いたい言語のが無かった

339 :デフォルトの名無しさん:2013/11/17(日) 00:11:11.13
>>332,335

gitで管理しないファイルを無視させる .gitignore|misc|@OMAKASE
http://www.omakase.org/misc/gitignore.html

koreka

340 :デフォルトの名無しさん:2013/11/17(日) 00:14:43.19
つかオリジナルの説明読めばいいのか

Git
http://git-scm.com/docs/gitignore

341 :デフォルトの名無しさん:2013/11/17(日) 01:23:09.32
githubって容量無制限?
公開されるの気にしなければ
バックアップに使える?

342 :デフォルトの名無しさん:2013/11/17(日) 01:26:34.57
無制限じゃないよ、リポジトリ1つにつき1GBまでだよ

https://help.github.com/articles/what-is-my-disk-quota

343 :デフォルトの名無しさん:2013/11/17(日) 01:28:06.90
>>253のスレを誰か早く立ててほしいところ
俺はこのホストは立てられませんってエラーが出て立てられんし

344 :デフォルトの名無しさん:2013/11/17(日) 01:34:21.56
このスレに限らんが
公式のヘルプに答えが書いてあることを質問してくる奴って結構いるよな
日常生活でも家電とか取説読まずに分からんと憤慨してる奴みかけるし
人間って何なんだろうな

345 :デフォルトの名無しさん:2013/11/17(日) 01:37:06.86
>>342
バックアップ目的ならDropBoxおすすめとか書いてあってワロタ

346 :デフォルトの名無しさん:2013/11/17(日) 01:40:14.12
GitHubは完成したもののコンパイル物配布には向いてないと書いてあるな、Amazonを進めてるのな

347 :デフォルトの名無しさん:2013/11/17(日) 01:48:49.46
>>344
説明書を読むだけの店員さんの仕事を確保するためだろう。

348 :デフォルトの名無しさん:2013/11/17(日) 02:12:05.71
>>344
しかも過去スレに同じ質問と回答があるとかもうね

349 :デフォルトの名無しさん:2013/11/17(日) 02:20:32.62
2chの過去ログ漁るのは、公式手段だと●買わないとダメだし
2chにあんま詳しくないとmimizunなど過去ログ溜めてるサイトとか知らんだろ

350 :デフォルトの名無しさん:2013/11/17(日) 02:32:02.73
>>344 みたいなのが
「近頃の若いもんは・・・」
とか結構言うんだよな
人間って何なんだろうな

351 :デフォルトの名無しさん:2013/11/17(日) 03:42:32.19
git init --separate-git-dir=

これ使ってる香具師いる?

352 :デフォルトの名無しさん:2013/11/17(日) 04:56:32.23
>>349

353 :デフォルトの名無しさん:2013/11/17(日) 05:01:53.57
最近ここは面白スレ化してないか

354 :デフォルトの名無しさん:2013/11/17(日) 08:05:42.15
Googleが2ch過去ログサイトの隅々まで巡回してるのに何を言っとるんだ?

まあ、別に検索サイトや過去ログの使い方知らない訳じゃなくて、それらの手間を他人にかけてるだけだろうがな

355 :デフォルトの名無しさん:2013/11/17(日) 08:27:30.69
リファレンスより使用法やフォーラムの質問のが有用ってのは
MSかなんかが統計付きで出してた
マニュアル読めって言ってる奴は自己満足の役立たず

356 :デフォルトの名無しさん:2013/11/17(日) 08:32:51.44
それはリファレンスとフォーラムの両方を運営してる側が活用するデータで
他人に手間を押し付ける言い訳にしちゃダメだろ

357 :デフォルトの名無しさん:2013/11/17(日) 08:50:06.73
彼は自分にとって有用という点しか見ていないみたいだし、そもそも他人に手間を掛けるとか掛けないとかいう発想がなさそう

358 :デフォルトの名無しさん:2013/11/17(日) 09:06:26.90
1回100円でマニュアルを調べて回答しますというサービスを立ち上げろよ

359 :デフォルトの名無しさん:2013/11/17(日) 10:04:50.80
>>356
他人に手間かけさせるという意味ではない
質問に答えることがそいつ以外にも有用になるってこと
マニュアル読めってのは何も答えてないのと同じで自己満足

360 :デフォルトの名無しさん:2013/11/17(日) 10:38:57.78
直前のコミットを書き換える場合
なんでみんなrebaseを使うんですか?

361 :デフォルトの名無しさん:2013/11/17(日) 10:45:25.16
git reset --soft HEAD^
ってやったらMore?って聞かれるんですけどここで何を入力したら実行できますか?

362 :デフォルトの名無しさん:2013/11/17(日) 11:00:33.01
>>355
ありがちな質問ならそれは正しい
でも、そのうちそうでない疑問もでてくるから、マニュアル不要とかあり得ん

363 :デフォルトの名無しさん:2013/11/17(日) 13:19:58.08
>>359
なら、お前以外は全員知ってるような当たり前の質問すんな

364 :デフォルトの名無しさん:2013/11/17(日) 21:34:36.14
>>361
cmd.exeではサーカムフレックスと改行で行の継続になる
"HEAD^"とするがよろしいかと

365 :デフォルトの名無しさん:2013/11/17(日) 21:41:56.62
windows だったら、ckw で bashを使うんじゃねーの

366 :デフォルトの名無しさん:2013/11/17(日) 21:42:49.84
>>360
普通はcommit --amend使うだろ

367 :デフォルトの名無しさん:2013/11/17(日) 22:21:50.81
>>360>>366
commit --amendを使うとauthorの時刻が変化しないが、
「rebaseなどでcommitオブジェクトが作り直される状況を除いてはauthorとcommitterで時刻が等しいcommitオブジェクトしか作らない」という俺ルールを守るため、
俺はreset {--soft,}とaddでindex作り直してからコミットやり直す

368 :デフォルトの名無しさん:2013/11/18(月) 04:59:09.33
その俺ルールのためなら、
filter-branchでまとめて書き直せばいいんでは

369 :デフォルトの名無しさん:2013/11/18(月) 08:54:07.11
>>367
commit --ammend --reset-author
で更新されたと思う

370 :デフォルトの名無しさん:2013/11/18(月) 09:12:13.55
>commit --ammend --reset-author
>で更新されたと思う

commit --amend --reset-author だごめん

371 :デフォルトの名無しさん:2013/11/18(月) 18:47:00.91
コンフリクトさせないために気をつけることを何個でも良いからおしえて

372 :デフォルトの名無しさん:2013/11/18(月) 19:25:51.04
rebaseできる時はする

373 :デフォルトの名無しさん:2013/11/18(月) 19:28:15.03
ffマージはgitに判断させる

374 :デフォルトの名無しさん:2013/11/18(月) 20:18:27.77
編集するファイル毎に専用ブランチを切る。

375 :デフォルトの名無しさん:2013/11/18(月) 20:20:26.72
master以外ブランチを作らない

376 :371:2013/11/18(月) 20:21:06.61
なるほど、その3つぐらいですかね
基本的にコンフリクトしたときの対応記事書いてるブログってクソだと思うんですよ
コンフリクトしないことが重要なのに対応の仕方だけ書かれてもねっていつも思います

377 :デフォルトの名無しさん:2013/11/18(月) 20:24:20.08
変更は細かくコミットする
例えば移動コミットと変更コミットが分かれていたらその情報を利用してマージできる場面でも
一気にやってしまうとごちゃごちゃとコンフリクトする場合がある

378 :デフォルトの名無しさん:2013/11/18(月) 20:39:22.40
複数人で開発してれば、どんなに気を付けてても競合する時はするけどな。

379 :デフォルトの名無しさん:2013/11/18(月) 20:47:50.59
masterにあるファイルやフォルダを別フォルダに移動するときって、事前に開発者全員に知らせてから移動用のブランチ切ってやるべきかな

380 :デフォルトの名無しさん:2013/11/18(月) 20:50:12.75
git checkout -fってやっていらないファイルを整理しようと思ってたのに
gitで管理されてないゴミファイルが残ったままになります
なので一度.gtディレクトリ以外を削除してからgit checkout -fってやってるんですが面倒くさいです
こういうときはどうやるんですか?

381 :デフォルトの名無しさん:2013/11/18(月) 21:02:20.90
>>380
git clean

382 :デフォルトの名無しさん:2013/11/18(月) 22:35:49.41
コンフリクトを検出できるようにgit使っているのに。

383 :デフォルトの名無しさん:2013/11/18(月) 22:51:29.08
同一ファイルの同一行に追加されてるとgitはコンフリクトと判断するんだよね。
これがある行の上と下に分けて追加すると、両方を追加と判断できる。
gitがマージ処理をしやすくなるコーディングルールって無いものかな?

384 :デフォルトの名無しさん:2013/11/18(月) 23:02:00.99
やめろ・・・やめろよっ・・・・!
運用でカバーするって・・・甘い考えっ・・・・
道具に使われている事に・・・・まるで気付いてないっ・・・・!!

385 :デフォルトの名無しさん:2013/11/18(月) 23:45:01.61
>>383
どっちの行が先に処理されるべきかなんてgitさんに判断なんて無理だから仕方ない

386 :デフォルトの名無しさん:2013/11/19(火) 00:20:55.53
1stペアレンツの方を先にするとか

387 :デフォルトの名無しさん:2013/11/19(火) 01:25:42.04
>>380バッチ1つ作れば良いだけ

388 :デフォルトの名無しさん:2013/11/19(火) 09:39:14.25
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

389 :デフォルトの名無しさん:2013/11/19(火) 09:40:19.87
URL先にウイルスとかは言ってたりしたらおれが訴えられるから張らなかったから
必要な人は>>2以降にテンプレではっといて

390 :デフォルトの名無しさん:2013/11/19(火) 13:52:29.09
>>384
むしろ道具でカバーできたり判断できることはどんどん任せ、
他にやらなければいけないこと、かんがえなければいけないことに人間は注力すべきだろう、
とマジレス

391 :デフォルトの名無しさん:2013/11/19(火) 15:01:47.05
まあ--reset-authorやrebaseなど凝りだすとgitに使われている気分にはなるな

392 :デフォルトの名無しさん:2013/11/19(火) 19:46:41.12
>>388
おつ

393 :デフォルトの名無しさん:2013/11/20(水) 08:12:37.30
VS2012 スレで Visual Studio Tools for Git で質問したのですが
使ってる人が皆無なのか、全くのスルーだったのでこちらに参りました。

テスト的に作ったプロジェクトを GitHub 等に上げることはできましたが
別の環境(真新しい環境)で使うときがよく分かりません。

VS2012を起動させて、「新しいプロジェクト」から作るのではなくて
これから弄ろうとするプロジェクトを既に上がってる GitHub から引いてくるべきと思うのですが
どんな風にやるのでしょうか?

1台で上げ下げする解説サイトはいっぱいあるんですが
2台目以降の構築法が書かれているところが見当たらず・・・ヒントください。。

394 :デフォルトの名無しさん:2013/11/20(水) 08:30:35.78
msysgit入れてgit clone

395 :デフォルトの名無しさん:2013/11/21(木) 17:17:02.92
OSSスレ立った

396 :デフォルトの名無しさん:2013/11/21(木) 21:43:06.67
【ネット】 GitHubに「総当たり」攻撃、安易なパスワードが破られる…セキュリティ対策を強化へ
http://uni.2ch.net/test/read.cgi/newsplus/1385019870/

397 :デフォルトの名無しさん:2013/11/21(木) 22:26:16.49
Git 1.8.4.4
https://code.google.com/p/git-core/downloads/list

398 :デフォルトの名無しさん:2013/11/21(木) 22:27:11.63
1.8.4なんていらんよ。
1.8.5のRCでてるんだから
そっち使う。

399 :デフォルトの名無しさん:2013/11/21(木) 23:54:24.13
大事な資産をわざわざ人柱に提供するなんて

400 :デフォルトの名無しさん:2013/11/22(金) 13:04:00.78
git-guiのUI違和感ある物の一部変更(デフォールトとか註釈とか)
+potに反映してない文字列のうち見えたもの翻訳したった
ttp://www1.axfc.net/u/3095162.zip
更新前と更新後と差分全部入り

401 :デフォルトの名無しさん:2013/11/22(金) 21:17:27.28
>>400
Gitで管理しろよ
https://github.com/git/git/blob/master/git-gui/po/ja.po

402 :デフォルトの名無しさん:2013/11/22(金) 21:57:55.77
理由は知らんが元のpot自体が更新されとらんねん
どうしろというのさw

403 :デフォルトの名無しさん:2013/11/22(金) 22:24:33.88
forkだろ

404 :デフォルトの名無しさん:2013/11/23(土) 09:08:23.20
Git自体のoriginってgithub?kernel.orgかと思ってたわ
git://git.kernel.org/pub/scm/git/git.git

405 :デフォルトの名無しさん:2013/11/23(土) 13:00:12.52
git-scm.com のソースコードは https://github.com/git にリンクされていて
ここはmirrorだと書いてあるな。

406 :デフォルトの名無しさん:2013/11/23(土) 16:30:22.01
>>296-298

407 :デフォルトの名無しさん:2013/11/23(土) 21:29:49.06
Mercurialも使える方に質問です
バージョン管理システムに慣れる場合Gitとどっちが簡単ですか?

408 :デフォルトの名無しさん:2013/11/23(土) 21:46:58.54
>>407
どっちが簡単かだとMercurial

最初はMercurialを使い始めて不便だなと思ってました

gitを使うようになってから、それにはちゃんと理由があるんだということに気づいたよ
↓みるといいよ
https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercuria

409 :デフォルトの名無しさん:2013/11/23(土) 21:47:37.71
何か変な改行はいっちゃった

410 :デフォルトの名無しさん:2013/11/23(土) 21:59:59.20
404 - Oops, you found a dead link. | Atlassian

411 :デフォルトの名無しさん:2013/11/23(土) 22:03:06.79
https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercurial
ごめんやで

412 :デフォルトの名無しさん:2013/11/23(土) 22:11:32.53
部分変更のみのコミット可能

これ多用してるわ

413 :デフォルトの名無しさん:2013/11/24(日) 01:02:30.42
http://tortoisesvn.net/tsvn_1.8_releasenotes.html#commitparts
http://tortoisesvn.net/docs/nightly/TortoiseSVN_ja/tsvn-dug-commit.html
ファイルの一部だけをコミットする

時には、ファイルに対して行った変更の一部だけをコミットしたくなることがあるでしょう。
例えば、何かを作業をしている途中で緊急の修正をコミットする必要に迫られ、
しかも作業中のファイルに変更を加えなければならなくなった場合などです。

ファイルを右クリックし、 コンテキストメニュー → コミット後に復元 を実行してください。
これでファイルの現状のコピーが作成されます。
それからファイルを TortoiseMerge などを使用して編集し、
コミットしたくない変更点をすべて元に戻してください。
変更を保存した後で、ファイルをコミットします。

コミットが完了すると、ファイルのコピーが自動的に復元され、
コミットされていなかった変更点が元に戻ります。

414 :デフォルトの名無しさん:2013/11/24(日) 01:38:27.21
誤爆?

415 :デフォルトの名無しさん:2013/11/24(日) 01:40:16.96
そういやgitの-pって凄いと思ったわ。
編集中のファイルのうち一部分だけを
コミットできるんだよね。

TortoiseSVNはそれをぱくったの?

416 :デフォルトの名無しさん:2013/11/24(日) 01:44:39.42
git add -pもそうだけど、
履歴を変更できないと効果半減だわ。
その気に慣れば複数のブランチを使って
コミットを綺麗になおせるのがgitの素晴らしさなんだよね。

ブランチ一つ作るのにも切り替えるのにも
慎重にならないといけないものでは
綺麗に修正することも出来んわ。

417 :デフォルトの名無しさん:2013/11/24(日) 12:12:49.35
馬鹿には無理

418 :デフォルトの名無しさん:2013/11/28(木) 20:39:00.87
Git 1.8.5
https://code.google.com/p/git-core/downloads/list

419 :デフォルトの名無しさん:2013/12/03(火) 08:47:01.42
test

420 :デフォルトの名無しさん:2013/12/03(火) 09:24:11.92
git と github の違いについてですが
git のどのパッケージを使うと
github サーバーを自分で立てられるのでしょう?

421 :デフォルトの名無しさん:2013/12/03(火) 09:39:17.51
自鯖ならgithubは忘れて
「gitlab」でググろう

422 :デフォルトの名無しさん:2013/12/03(火) 10:38:00.80
github Enterprise を契約すると、自鯖でたてられるよ

423 :デフォルトの名無しさん:2013/12/03(火) 19:32:16.35
githubはリポジトリホスティングのサービス名である

424 :デフォルトの名無しさん:2013/12/03(火) 19:32:52.77
git prepとかもいいよ
日本人が作った物だよ

425 :デフォルトの名無しさん:2013/12/03(火) 19:43:48.33
420の質問の意味がよくわからないのにおまえらよく答えられるのな
何をしたくて何を知りたいのかさっぱりわからん

426 :デフォルトの名無しさん:2013/12/03(火) 19:45:27.80
GitHubのフィッシングサイトを立てたいって意味か?

427 :デフォルトの名無しさん:2013/12/03(火) 23:09:17.20
>>425は超絶アスペ

428 :デフォルトの名無しさん:2013/12/04(水) 09:16:21.64
みなさん色々なご提案ありがとう

429 :デフォルトの名無しさん:2013/12/08(日) 02:40:37.29
gitの共有リポジトリを自宅サーバーに作りたいんだけど、
相談させてください。

・自分以外に1人、外部からのアクセスを許可したい
・共有リポジトリには、自分と許可した人以外にはアクセス制限をかけたい
・サーバーはWEBサーバーとして外部公開している(HTTPのFWは開いてる)
・SSHは公開鍵認証を使用して、ローカルからのみアクセスしている(ルーターのFWのポート開けてない)
・クライアントは、二人ともWindowsのTortoiseGitを使用している (TortoiseGit使いたい)

なんだけど、どういう方法で構築するのがよいのかなぁ。。。

430 :デフォルトの名無しさん:2013/12/08(日) 02:56:23.02
sshのポート開けたら終わりじゃないの

431 :デフォルトの名無しさん:2013/12/08(日) 03:12:00.83
>>429
目的は自宅サーバにリポジトリを持つことなの?
もし 2 人がアクセスできるプライベートリポジトリさえあればよいのならば、
Bitbucket を使った方がよいのでは?
無料アカウントでもプライベートリポジトリをいくつでも持てるし、ユーザも最大 5 人まで使用できるよ
https://bitbucket.org

432 :デフォルトの名無しさん:2013/12/08(日) 03:30:56.52
宣伝乙

433 :デフォルトの名無しさん:2013/12/08(日) 03:58:17.82
その規模ならVisual Studio Onlineでいいんじゃないの?
どの規模でもいいんだけど、その規模なら無料って意味で。

434 :デフォルトの名無しさん:2013/12/08(日) 05:39:11.64
外部サービスに置くのは怖いんじゃね
こちらに連絡なしに規約が変わったりするかもよ

435 :デフォルトの名無しさん:2013/12/08(日) 06:23:12.34
gmailとか
DropBoxとか
怖くて使えんな

436 :デフォルトの名無しさん:2013/12/08(日) 07:48:50.37
>>434
だからTFSじゃなくGitなんじゃないの?
二人だし規約が変わったらまた考えればいいでしょ。

437 :デフォルトの名無しさん:2013/12/08(日) 08:58:48.46
sshのポートあけて、gitoliteでリポジトリとアクセス制限の管理するのが一番シンプルに構築できると思う

438 :デフォルトの名無しさん:2013/12/08(日) 09:15:31.72
余談だけど
sshでパスワード認証はするなよ

439 :デフォルトの名無しさん:2013/12/08(日) 09:17:58.93
シンプルなのはVisual Studio Onlineだろね。
登録するだけですぐ使えるから。

440 :デフォルトの名無しさん:2013/12/08(日) 15:28:08.79
ステマというか堂々とした宣伝か

441 :429:2013/12/08(日) 19:57:11.92
429です

自宅鯖を使用したい理由は、自宅鯖にあるRedmineと連携したい、ってのが大きいです。

一点確認なんですが、SSHは公開鍵認証にしてるけど、gitでsshをほかの人が使えるようにすると、
その人もPC自体をSSHで操作可能になる?

442 :デフォルトの名無しさん:2013/12/08(日) 20:19:13.96
>>441
ならない

443 :デフォルトの名無しさん:2013/12/08(日) 20:25:33.15
いや、なるだろ

444 :デフォルトの名無しさん:2013/12/08(日) 20:28:43.84
権限次第としか。

>>429だったら、なってもおかしくはないな。

445 :デフォルトの名無しさん:2013/12/08(日) 20:30:26.26
言葉が足りなかった。gitolite使えばならない
追加するのはgitolite用のアカウントだけ

446 :デフォルトの名無しさん:2013/12/08(日) 20:33:44.34
その点はgit-shellで解決可能かと

447 :デフォルトの名無しさん:2013/12/08(日) 22:26:30.40
Visual Studio Onlineって初めて聞いたけどgitベースなのか?
VSSはもうやめたんかよ。つーかXcodeにも対応してっしMSのくせに柔軟というか節操ないというか

448 :デフォルトの名無しさん:2013/12/08(日) 22:39:59.77
Microsoft Visual Studio:一歩先を行くバージョン管理
http://www.microsoft.com/ja-jp/dev/campaign/vsstotfs/default.aspx

449 :デフォルトの名無しさん:2013/12/08(日) 22:41:44.91
Visual Studio での Git の使用
http://msdn.microsoft.com/ja-jp/library/hh850437.aspx

450 :デフォルトの名無しさん:2013/12/08(日) 22:44:02.51
Visual Studio Online の概要
http://www.visualstudio.com/ja-jp/products/visual-studio-online-overview-vs.aspx
>Visual Studio Online (旧 Team Foundation Service) は、クラウド内のプロジェクト データのホームです。
Visual Studio Online Basic
> 5 ユーザーまで無料です

451 :デフォルトの名無しさん:2013/12/08(日) 22:45:00.47
Visual Studio Online Basic
http://www.visualstudio.com/ja-jp/products/visual-studio-online-basic-vs
>主な機能
> ?プライベートな Git リポジトリを使用してコードをクラウドに保存する

452 :デフォルトの名無しさん:2013/12/09(月) 04:07:47.51
VSS光景のTeam Foundationは当然として
オープン規格でGitだけサポートってのは何故だろう、って気はする
あの会社ならSVNやHgまで同時にやれそうだし
Windows環境へのサポートは他のが良いくらいなんだが…
まあ、とはいえ選択肢があるのは良いことか

453 :デフォルトの名無しさん:2013/12/09(月) 04:11:21.46
VCSスレのほうでGitはWindowsに不向きとか散々書かれてたしね

454 :デフォルトの名無しさん:2013/12/09(月) 08:05:13.60
やっぱタイムスタンプも同期してくれないとWindowsでは使えんわ

455 :デフォルトの名無しさん:2013/12/09(月) 08:11:24.23
えっ?

456 :デフォルトの名無しさん:2013/12/09(月) 08:16:47.18
タイムスタンプ厨が出たぞー逃げろー

457 :デフォルトの名無しさん:2013/12/09(月) 08:35:19.13
どうせどっかの会社ごと買ったんだろ。すぐにダメになる。

458 :デフォルトの名無しさん:2013/12/09(月) 08:46:28.45
>>454
>>310

459 :デフォルトの名無しさん:2013/12/09(月) 10:29:34.12
>>452
最高の分散型VCSを作ってやるぜ!

検討すればするほど、gitに近付いてしまう・・・。
そうか、最高の分散型VCSは既に存在したんだ。
それはgitだ。
よって、gitをサポートすることが最善。

って経緯らしいよ。
元々、様々なVCSをサポートすることは目的じゃない。
(そういう選択肢はプラグインインターフェイスだけ用意して、実装はサードパーティ任せ。)

460 :デフォルトの名無しさん:2013/12/09(月) 10:47:52.37
オプションでタイムスタンプ同期に対応したら完璧なのに
クライアントの当てにならない時計なんて信用できるか、ってやつは使わなければいいだけだし

461 :デフォルトの名無しさん:2013/12/09(月) 10:53:14.34
ぐちぐち言ってないでプログラマなら自分でやれ

462 :デフォルトの名無しさん:2013/12/09(月) 11:00:40.79
DropBoxがソースフリーで公開してくれたら解決だな
バイナリ差分の転送も上手にやってるし

463 :デフォルトの名無しさん:2013/12/09(月) 16:56:10.04
>>310
5スレ目の75あたりって1年前なんですが、1年前から変わってないってことなんすか

464 :デフォルトの名無しさん:2013/12/09(月) 16:59:43.16
いや
>>310 はタマタマ見つかったのを例に挙げただけで
もっと前から概出

465 :デフォルトの名無しさん:2013/12/09(月) 17:04:23.00
既出かどうか、というより、gitはタイムスタンプに関する仕様を変更する気はさらさら無いってことでつね

466 :デフォルトの名無しさん:2013/12/09(月) 17:20:19.98
仕様変わっても困らないんじゃね

467 :デフォルトの名無しさん:2013/12/09(月) 17:46:32.20
そんなにタイムスタンプ同期したいなら自分でhook書けよ、と
makeがタイムスタンプ見るから勝手に変えられると俺は困る

468 :デフォルトの名無しさん:2013/12/09(月) 19:14:14.60
MsBuildもタイムスタンプを見るから勝手に変えられると俺も困る
VisualStudioはMsBuildでビルドしてるので、全世界のVisualStudioユーザーも困る

469 :デフォルトの名無しさん:2013/12/09(月) 19:17:17.61
困らせたいんだろ。

470 :デフォルトの名無しさん:2013/12/09(月) 20:06:59.69
昔はファイルのタイムスタンプをチェックしてたけど、Git でソースプログラムを管理するようになってからはタイムスタンプを意識しなくなった

471 :デフォルトの名無しさん:2013/12/09(月) 22:27:52.68
contrib/diff-highlight ってバイト単位で比較しているから日本語が化けるね
勘で書いた patch ↓
pastebin.com/gHhShciR

utf-8 決め打ちとかいまいちなので、perl 分かる人いい感じにしてください

472 :デフォルトの名無しさん:2013/12/10(火) 22:08:07.87
Git 1.8.5.1 が出てたんだね(1.8.4.5 も)
https://code.google.com/p/git-core/downloads/list

473 :デフォルトの名無しさん:2013/12/16(月) 16:54:14.28
タイムスタンプ対応まだ?

474 :デフォルトの名無しさん:2013/12/16(月) 18:38:27.31
一生ないから自分でforkして自分で作っとけ

475 :デフォルトの名無しさん:2013/12/16(月) 20:08:51.32
Gitでの管理って
リリースの際はリリース用のブランチを切るの?それともタグ付けだけいい?

476 :デフォルトの名無しさん:2013/12/16(月) 20:24:17.50
>>475
そこのポリシーに従ってください。

ちなみに俺はリリース前から、開発版と安定版のブランチを使う。安定版へのマージがリリースになる。あ、でも最初のリリースまでは一本ってことだな。

477 :デフォルトの名無しさん:2013/12/16(月) 20:41:00.32
その場合masterブランチはどうなってるの?

478 :デフォルトの名無しさん:2013/12/16(月) 20:47:42.29
>>477
どっちだっけ。あんま気にしてない。何か違いあるの?

479 :デフォルトの名無しさん:2013/12/16(月) 20:57:38.17
よく分からなくなってきた

480 :デフォルトの名無しさん:2013/12/16(月) 21:01:51.77
Gitにおけるリリースブランチのつかいかた
http://www.eiplab.com/2011/06/git-release-branch/

481 :デフォルトの名無しさん:2013/12/16(月) 21:05:07.67
トピックブランチと統合ブランチでの運用例
http://www.backlog.jp/git-guide/stepup/stepup1_5.html

482 :デフォルトの名無しさん:2013/12/16(月) 21:26:26.14
リモートとワークツリー比較してリモートの方が最新だったらpullしてワークツリーの方が最新だったらcommit+pushみたく自動化することは出来ますか?

483 :デフォルトの名無しさん:2013/12/16(月) 21:35:47.68
>>477
masterはcloneした時にとくべ扱いされるから、気にした方が良いと最近思った

484 :デフォルトの名無しさん:2013/12/16(月) 21:43:07.51
>>475
Github にある Git 自身のリポジトリ(ミラー)を見ると
ブランチではなくてタグで対応してるみたいだけど。
https://github.com/git/git

485 :デフォルトの名無しさん:2013/12/16(月) 22:03:36.17
>>480-481を読めば全て解決

486 :デフォルトの名無しさん:2013/12/16(月) 23:04:45.55
masterブランチへのマージはリリースブランチが完成したものだけを常にマージ

リリースブランチは開発ブランチでほぼ完成であとは調整のみという段階からリリースブランチを切る

開発ブランチでは作業しない、開発ブランチからメンバーが個々に作業用ブランチを切ってそこで作業・コミットして出来上がったら開発ブランチへマージする

487 :475:2013/12/17(火) 00:27:12.19
>>476-486
ありがとうございます勉強になりました
色んな流儀があるんですね

488 :デフォルトの名無しさん:2013/12/17(火) 03:24:19.74
色んな?

皆本質は一緒だろ

489 :デフォルトの名無しさん:2013/12/17(火) 04:47:15.36
つまり本質以外は違うってことですね?
あなたの言う、本質ってのはなんですか?

490 :デフォルトの名無しさん:2013/12/17(火) 05:35:11.62
それぞれ別のものに見えるとしたら病院逝った方が良い

491 :デフォルトの名無しさん:2013/12/17(火) 07:01:04.44
既に病院にかかってる人から言われてもな

492 :デフォルトの名無しさん:2013/12/17(火) 07:50:07.52
ω

493 :デフォルトの名無しさん:2013/12/17(火) 19:45:36.61
どっちでもいいだろo

494 :デフォルトの名無しさん:2013/12/17(火) 20:03:26.54
>>482


495 :デフォルトの名無しさん:2013/12/19(木) 13:30:19.82
ローカルにコミットしたもの と リモートのリポジトリ との差分を
みたいんですが、どうしたらよいでしょうか

496 :デフォルトの名無しさん:2013/12/19(木) 14:44:36.75
>>495
とりあえず git branch -av とかやってみろ

497 :デフォルトの名無しさん:2013/12/19(木) 23:26:21.21
Git 1.8.5.2
https://code.google.com/p/git-core/downloads/list

498 :デフォルトの名無しさん:2013/12/20(金) 15:10:39.25
>>496
ありがとう

499 :デフォルトの名無しさん:2013/12/20(金) 15:13:57.74
git clone ssh://hoge@192.168.1.123/var/lib/git/UNKO.git
とかなんとかやりますが、
この ssh://hoge@192.168.1.123/var/lib/git/ の部分を
設定ファイルとかに書いたりとか出来たりとかします?

500 :デフォルトの名無しさん:2013/12/20(金) 16:25:06.53
>>499
hoge@192.168.1.123の部分はssh側の設定でaliasを付けられる

501 :デフォルトの名無しさん:2013/12/20(金) 19:50:12.90
>>500
ありがとう

これgitなんかに使うのもったいないレベルのTipsやん
ほーすげぇなこれ はー

502 :デフォルトの名無しさん:2013/12/20(金) 22:05:51.52
こんな感じだろ常識の範囲ではないか
Host g
Hostname github.com
User xyz
IdentityFile ~/.ssh/github

503 :デフォルトの名無しさん:2013/12/20(金) 23:50:49.22
ssh_config(5) 見ておくと色々幸せになるということだな。

504 :デフォルトの名無しさん:2013/12/21(土) 17:51:01.63
昔々rshというものがあってな

505 :デフォルトの名無しさん:2013/12/23(月) 11:16:11.63
結局、日本語のファイル名は使えるの?

506 :デフォルトの名無しさん:2013/12/23(月) 11:20:01.66
使えるよ

507 :デフォルトの名無しさん:2013/12/25(水) 22:53:01.74
checkoutってあいまいだよな
git checkout branch名 はbranch切り替えだけど
git checkout file名 はローカルファイル更新なんだよな

508 :デフォルトの名無しさん:2013/12/25(水) 22:58:48.73
へ? どれもリポジトリからファイルを
チェックアウトするコマンドじゃん。

ブランチ指定したら、そのブランチのファイル全部をチェックアウトするし
ブランチとファイル名指定したら、そのブランチの特定のファイル名をチェックアウトするし
ファイル名だけだったら、カレントブランチのファイルをチェックアウトする。

全部チェックアウトじゃんか

509 :デフォルトの名無しさん:2013/12/25(水) 23:00:39.32
ブランチ名とファイル名が同一のものあったら

510 :デフォルトの名無しさん:2013/12/25(水) 23:05:33.49
--

511 :デフォルトの名無しさん:2013/12/25(水) 23:06:38.08
普通ファイル名には拡張子つけるから
かぶることはまずないけどな。
心配な人は--をつけるようにすればいいだろう。

512 :デフォルトの名無しさん:2013/12/26(木) 08:24:06.69
git checkout branch名
の場合は
ファイルの取り出しだけでなくて
カレントブランチの切り替えも行うのだから
ぜんぶ同じってことはないと思うけど

513 :デフォルトの名無しさん:2013/12/26(木) 12:42:56.91
readme.mdはどのタイミングで入れるべきか教えてください

1.git initをしたあと
2.git initをするまえ
3.そのた

514 :デフォルトの名無しさん:2013/12/26(木) 12:50:56.29
好きな時でいいだろ

515 :デフォルトの名無しさん:2013/12/26(木) 12:59:46.51
readme.mdをaddする前

516 :デフォルトの名無しさん:2013/12/26(木) 13:17:03.09
敢えてinitial commitには入れないことにしてるな。その次で入れる。
readmeは何度も書き直したくなるが、initial commitだとrebaseで手出しできない。

517 :デフォルトの名無しさん:2013/12/26(木) 13:45:55.84
initial commitには何を入れるわけ?

518 :デフォルトの名無しさん:2013/12/26(木) 13:48:43.18
.gitignore

519 :デフォルトの名無しさん:2013/12/26(木) 16:30:41.22
何も入れずに --allow-empty

520 :デフォルトの名無しさん:2013/12/26(木) 16:57:56.85
ああ、git便利すぎて幸せ。
gitに弱点ってある?

521 :デフォルトの名無しさん:2013/12/26(木) 17:40:24.62
同じファイルをコミットしたらコンフリクトすること
ロックできないのが弱点

522 :デフォルトの名無しさん:2013/12/26(木) 18:21:02.13
ロックという考えがもう前時代的だよね

523 :デフォルトの名無しさん:2013/12/26(木) 18:30:24.35
コンフリクトをエラーのように言ってる人がけっこういる。

524 :デフォルトの名無しさん:2013/12/26(木) 19:02:49.50
複数人で修正してコミットしたらコンフリクトするのだから
ロックできれば未然に防げるはずなのだ
コンフリクトを起こさないのが良いバージョン管理方法である

525 :デフォルトの名無しさん:2013/12/26(木) 19:12:18.15
分散管理でロックとか不可能だろ
誰かがロックしたら全員のリポジトリのファイルにロックがかかるのかよ

526 :デフォルトの名無しさん:2013/12/26(木) 19:19:45.32
いまからさGit Wikiつくろうとおもうんだけど逆引きで
そしたらテンプレに入れてくれますか?アフィ張らないので

527 :526:2013/12/26(木) 19:20:20.68
ちなみに初心者ですけど間違っているのをここの先輩方に直してもらうためにWikiを作るのです!

528 :デフォルトの名無しさん:2013/12/26(木) 19:55:51.33
サルでもわかるGit入門
http://www.backlog.jp/git-guide/

529 :デフォルトの名無しさん:2013/12/26(木) 20:12:11.66
>>524
コンフリクトしてから考えればいいじゃん。
ロックされててコミットできないとか困る。

530 :デフォルトの名無しさん:2013/12/26(木) 21:17:20.89
git diff
って、
git diff A B
という A、B が省略されているものだと思うんだけど
A、B が何なのかわからないので、知ってたら教えて。

531 :デフォルトの名無しさん:2013/12/26(木) 21:53:37.20
>>530
AはHEADまたはindexで、Bがワーキングコピー。

532 :デフォルトの名無しさん:2013/12/26(木) 22:04:46.27
git add . ってやるとindexに保存されますけど
git commit する前にまたファイルを編集してgit add .をしたらindexを上書きしているって事であってますか?
つまり

git add.
git add.
git commit

ってやってます

533 :デフォルトの名無しさん:2013/12/27(金) 00:08:26.57
>>524
コンフリクトが発生したら直せばいいだけじゃん。
バージョン管理ってそういうものですよ。

コンフリクトの修正がいやなら自分のした修正を無かったことにすればいい。
ファイルをロックされるというのはそう言うこと

534 :デフォルトの名無しさん:2013/12/27(金) 00:11:26.44
コンフリクトはしたらいけないんですよ!

535 :デフォルトの名無しさん:2013/12/27(金) 00:12:50.45
コンフリクトはバグみたいなもんだからな。
発生したら「あれ? 俺やらかしちゃった?」って思わないといけない。

536 :デフォルトの名無しさん:2013/12/27(金) 00:25:37.27
自分のとこを最新のにマージしてからプッシュしとらんのか

537 :デフォルトの名無しさん:2013/12/27(金) 00:30:53.07
最新のにマージする時にコンフリクトが起きたらどうするんだよ!

538 :デフォルトの名無しさん:2013/12/27(金) 00:35:46.30
解決しろよ
どうせどっち取るか選ばなきゃならんのだから

539 :デフォルトの名無しさん:2013/12/27(金) 01:20:31.98
>>537
それ何か問題あるの?

540 :デフォルトの名無しさん:2013/12/27(金) 07:46:09.79
コンフリクト起きる度にgitありがとうと思っている俺に隙は無かった

541 :デフォルトの名無しさん:2013/12/27(金) 11:13:12.07
コンフリクトって何だ。コンフリクトを知りたい。by梅原

ってのは冗談で、実際にプロジェクトでgit使ってるんだがコンフリクトは一回も起こってないね。同一ファイルを同時に弄った場合でも、gitがキレイに判断してくれるおかげで助かってる。

そりゃ、同一行をいじったりしたら怒られるのは目に見えてるから、チーム間でコミュニケーションしながらだけど。

542 :デフォルトの名無しさん:2013/12/27(金) 18:06:39.25
同一行をいじらないためのコミュニケーションってイヤだな

543 :デフォルトの名無しさん:2013/12/27(金) 18:12:42.31
コミュニケーション不足

544 :デフォルトの名無しさん:2013/12/27(金) 20:37:13.04
ソースファイルは小さく小分けする方がいいだろ
複数人で1つのソースファイルを編集する必要がある大きさなんて、
俺やってるプロジェクトでは考えられない

545 :デフォルトの名無しさん:2013/12/27(金) 20:47:43.00
開発版とバグフィックスをマージしてコンフリクトとかあるだろ。

546 :デフォルトの名無しさん:2013/12/27(金) 21:04:33.79
複雑さと変更箇所のばらつきは極端に偏る

547 :デフォルトの名無しさん:2013/12/27(金) 21:33:49.36
コンフリクトをよく起こすファイルがある場合、設計ミスを疑うべきだな、何でそのファイルばかり修正が集中するのか

548 :デフォルトの名無しさん:2013/12/27(金) 22:09:54.27
>>547
頻繁に開発が行われているモジュールなら、変更もバグフィックスも多いだろうから必然だろう。

549 :デフォルトの名無しさん:2013/12/27(金) 22:43:43.06
>>548
コンフリクトがどういうときに起きるか理解してないだろ

550 :デフォルトの名無しさん:2013/12/27(金) 22:56:31.85
安価するとこ間違ってるぞ

551 :デフォルトの名無しさん:2013/12/27(金) 23:26:57.37
>>549
おまえがな

552 :デフォルトの名無しさん:2013/12/27(金) 23:33:58.22
コンフリクトがいやならSVNみたいな集中型でlockしたほうが幸せだぞ

553 :デフォルトの名無しさん:2013/12/27(金) 23:36:45.80
コンフリクトの修正手間が自分に係るのが嫌なんだろう?

554 :デフォルトの名無しさん:2013/12/28(土) 11:47:50.28
コンフリクトしたら、ロックされていたつもりになって
ローカルの変更を捨てればいいだけ

555 :デフォルトの名無しさん:2013/12/28(土) 13:28:47.67
コンフリクトで見つかるトラブルはまだありがたい。
相互に離れた場所で副作用でバグると見つけづらいし、片方直すと別の場所でバグる

556 :デフォルトの名無しさん:2013/12/28(土) 13:48:56.37
revert

557 :デフォルトの名無しさん:2013/12/28(土) 13:55:43.79
>>555
自動テストが必要だな。

558 :デフォルトの名無しさん:2013/12/28(土) 16:15:01.66
「ロックを"強制"して無駄なコンフリクトをなくす」というワークフローが構築できないから

やっぱ svn でいいじゃん

559 :デフォルトの名無しさん:2013/12/28(土) 16:30:36.50
ロックを強制する方が無駄が多いんだけどな

560 :デフォルトの名無しさん:2013/12/28(土) 16:54:20.47
素人開発にロックは厳禁。
みんなダメもとで開発して上手く行ったのを採用するんだからロックなんてできない。
まったくもって無駄。

561 :デフォルトの名無しさん:2013/12/28(土) 17:07:38.30
他人がロック中に作り貯めたやつをマージせずcommitする奴が出てくるんだよな
commitしようとしたらできなかったので、別の場所にコピーしておきましたとか
言われる。

562 :デフォルトの名無しさん:2013/12/28(土) 17:13:15.96
上がそう指示するのも当たり前に見かけるという

563 :デフォルトの名無しさん:2013/12/28(土) 17:15:25.11
そろそろ「バージョン管理システムについて語るスレ」に移らないか?

564 :デフォルトの名無しさん:2013/12/28(土) 17:53:37.15
そもそもツールの機能に頼るからいけないんだよ
バージョン管理の番人を1人つけるだけでトラブルがびっくりするほど無くなるよ

仕様書マイスターが1人いれば効率あがるのは知ってると思うけど
バージョン管理も同じ。余裕があるプロジェクトじゃないと無理だとは思うけどな

565 :デフォルトの名無しさん:2013/12/28(土) 18:03:42.17
このスレではGitと密着した話題だけしたいという人がVCS全般の話題はあっちのスレでと切に願っているわけだ

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

566 :デフォルトの名無しさん:2013/12/28(土) 20:55:18.43
>>564
24時間不眠不休なのですね。

567 :デフォルトの名無しさん:2013/12/28(土) 21:20:14.75
>>564
実際それが有用だから、Gitでpull request方式が流行ってるわけだな

568 :デフォルトの名無しさん:2013/12/28(土) 21:38:33.30
無責任なパッチを気軽に投げられるからな

569 :デフォルトの名無しさん:2013/12/28(土) 21:53:54.88
Gitくるぅ〜Gitくるぅ〜季節はしろくぅ〜

570 :デフォルトの名無しさん:2013/12/28(土) 22:16:50.39
>>567
流行るもなにも、GitはLinux kernel用に作られたものだから、元々そういう
ワークフローが前提

571 :デフォルトの名無しさん:2013/12/28(土) 22:50:44.30
そんな前提は無い

572 :デフォルトの名無しさん:2013/12/29(日) 00:14:03.95
マメインラインにマージするには責任者(管理者)を通す運用が当たり前だよなあ
それができない会社は無能

573 :デフォルトの名無しさん:2013/12/29(日) 00:29:33.66
豆インライン?

574 :デフォルトの名無しさん:2013/12/29(日) 01:40:56.87
>>571
いやあるだろ
あの変態が作ったんだぜ?

575 :デフォルトの名無しさん:2013/12/29(日) 01:51:05.16
変態でごめん。

576 :デフォルトの名無しさん:2013/12/29(日) 05:43:04.31
お、おう

577 :デフォルトの名無しさん:2013/12/29(日) 10:31:50.10
変態? 俺のことか?

578 :デフォルトの名無しさん:2013/12/29(日) 13:38:41.98
>>531
ありがとう
ワーキングコピーを明示的に書くとしたら
なんて書けばいいの?

579 :デフォルトの名無しさん:2013/12/29(日) 14:15:59.69
手元のレポジトリを リモートにベアリポジトリとして置きたいのだけど
どうしたらよいでしょうか

git clone --bare ./sample ssh://hoge@192.168.1.2:/var/lig/git/sample.git

とやってもローカルに ssh: とかいうディレクトリが出来て絶望した

580 :デフォルトの名無しさん:2013/12/29(日) 14:41:14.02
>>578
.

581 :デフォルトの名無しさん:2013/12/29(日) 14:44:57.13
>>579
リモート側で空のベアリポジトリを作ってそこにpushする

582 :デフォルトの名無しさん:2013/12/29(日) 14:50:53.82
>>581
それしかないの?
いちいちリモートにログインするのっていやなんだよな・・・

583 :デフォルトの名無しさん:2013/12/29(日) 14:53:14.40
>>582
ssh使ってるならログインしなくたってできるだろ

584 :デフォルトの名無しさん:2013/12/29(日) 14:57:08.14
間違えてた

git remote add origin ssh://hoge@192.168.1.2/var/lib/git/sample.git
git push
ってやればいいのか。

585 :デフォルトの名無しさん:2013/12/29(日) 15:02:45.30
>>584
それで何をするつもりだ?

586 :デフォルトの名無しさん:2013/12/29(日) 15:19:49.99
>>585
手元のレポジトリを リモートにベアリポジトリとして置きます。



これからリポジトリを作るのになぜかリポジトリがないと言われるのは
なんだろうgitさんってあんまり賢くないのかな

587 :デフォルトの名無しさん:2013/12/29(日) 15:36:01.25
>>586
>>584はリモートリポジトリにoriginっていう別名をつけるだけだアホ
お前がアホなんだよハゲ

588 :デフォルトの名無しさん:2013/12/29(日) 15:46:30.51
コンフリクトなんてするべきじゃない
ロックもできないとかクソすぎる
今後はGitのこういう欠点を修正した新しいバージョン管理が登場してGitなんて使われなくなるよ
そうSVNみたいな過去のものになるだけ

589 :デフォルトの名無しさん:2013/12/29(日) 15:48:09.10
testブランチにいます
ファイルを更新しましたが一時的にmasterブランチに移動したいのです
このとき
1.git add をしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか?
2.git add をしてgit commitしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか?

それぞれ教えてください

590 :デフォルトの名無しさん:2013/12/29(日) 15:55:32.76
>>589
Gitのリポジトリなんか簡単につくれるんだから
試しにやってみようかと思わないの?

591 :デフォルトの名無しさん:2013/12/29(日) 16:00:39.39
>>588
コンフリクトを撲滅したいなら、ロックをサポートするだけじゃなくて
ブランチのマージをできないようにしないとダメだよ
どっちも導入すると随分不自由な仕組みになるな

592 :デフォルトの名無しさん:2013/12/29(日) 16:19:16.58
>>590
怖くて手が震えてできませんっ!
OSが壊れたらどうしようと思って

593 :デフォルトの名無しさん:2013/12/29(日) 16:59:33.08
つまんね
-35894点

594 :デフォルトの名無しさん:2013/12/29(日) 17:16:35.13
>>592
まず、アル中の治療から始めましょうか

595 :デフォルトの名無しさん:2013/12/30(月) 04:15:37.23
>>587
なるほど。 リモートに置くにはどうしたらいいかな。
おしえてフサフサな人

596 :デフォルトの名無しさん:2013/12/30(月) 11:41:52.28
リモートにリポジトリを作る方法は、リモート側のシステムに依存する

597 :デフォルトの名無しさん:2013/12/30(月) 12:15:50.64
なんパターン化あるなら、
その代表例を言えばいいよ。
1つでもいいんだぜ?

598 :デフォルトの名無しさん:2013/12/30(月) 12:17:26.83
git addしたあとにまたファイルを更新したんですがこの場合はどうしたらいいんですか?
そのままgit addを取り消すのか?git addをそのままうっちゃっていいのか?

599 :デフォルトの名無しさん:2013/12/30(月) 12:38:53.37
>>597
リモート側でGitoliteを使ってるなら、
gitolite-adminリポジトリのgitolite.confを編集してpushすれば新しいリモートリポジトリが作成される
そこにローカルリポジトリをpushする

600 :デフォルトの名無しさん:2013/12/30(月) 12:40:31.79
>>598
git addを追加で行えばいい

601 :デフォルトの名無しさん:2013/12/30(月) 12:44:18.74
GitのGUIは分岐も表示できるじゃないですか
あれをぼくも作りたいんですけど、ああいうログってgit logの出力をパースしてるだけなんでしょうか?

602 :デフォルトの名無しさん:2013/12/30(月) 12:50:37.25
>>599
ありがとう
gitコマンドだけではやはり無理ってことですか
世の中うまくいかないもんですな

603 :デフォルトの名無しさん:2013/12/30(月) 13:03:41.65
そもそもUNIXのコマンドは単品に機能を過剰に詰め込んだりしない
gitコマンドも同じようなポリシーで作られてる
ネットワーク関係の機能も自身が持たずにsshコマンドとかに多くを依存してる
ローカルにリポジトリを作る機能さえあればsshと組み合わせてリモートにリポジトリを作るのも簡単にできる
それによってネットワークに関わるセキュリティ的な部分をgit自身が抱え込まずにsshに任せられる
これで世の中うまくいっている

604 :デフォルトの名無しさん:2013/12/30(月) 13:06:39.87
>>601
パースしてもいいし、gitのファイル構造は簡単だから自分で読んでグラフデータ構造を構築してもいい
分岐の表示はgit log --graphとかでCUIでもできる

605 :デフォルトの名無しさん:2013/12/30(月) 17:22:21.53
>>603
車輪の再発明的なことを避けたってこと?

606 :デフォルトの名無しさん:2013/12/30(月) 17:42:59.06
UNIXの考え方はこれでいいや。
http://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

でかくすると保守しにくいからね。

607 :18:2013/12/30(月) 21:24:46.36
>>605
単機能のプログラムとプログラムを繋ぐ仕組み (パイプとかシェルとか) を提供して、プログラムを組み合わせることで目的を達成するようにした。
利用者にそれなりのスキルがあることが前提になる。
あと、GUI だと繋ぐ仕組みがうまく機能してないので、GUI 上のアプリは Windows とたいして変わらない。

608 :デフォルトの名無しさん:2013/12/30(月) 21:40:18.85
GUIのアプリといっても中でCUIのコマンドを組み合わせて動いてるのも多いけどな

609 :デフォルトの名無しさん:2013/12/31(火) 10:15:07.74
来年こそはタイムスタンプに対応してくらさい

610 :デフォルトの名無しさん:2013/12/31(火) 10:22:21.36
永遠に対応しないことが決定してる

611 :デフォルトの名無しさん:2013/12/31(火) 14:07:33.94
>>602
なんか難しく考えてるみたいだが、リモートが普通のUNIXなら
ローカルでつくったベアリポジトリをリモートにコピーすればいいだけやで

612 :デフォルトの名無しさん:2013/12/31(火) 14:18:28.15
>>611
sshでログインしたくなかったけど
gitサーバも立てたくないワガママが
ことの発端なので、あきらめました

613 :デフォルトの名無しさん:2013/12/31(火) 14:27:55.57
×わがまま
○怠惰

614 :デフォルトの名無しさん:2013/12/31(火) 14:37:48.81
>>612
ログインしなくてもscpでコピーすればいいし、
アクセスするのはsshd経由だからgitサーバはいらんよ?
ほんと何もわかってないのにに口だけ達者だな

615 :デフォルトの名無しさん:2013/12/31(火) 14:45:45.05
とにかくWindowsで色つきのやつおしえて
コマンドプロンプトは色が着かない

616 :デフォルトの名無しさん:2013/12/31(火) 14:49:29.74
cygwinでminttyをつかう

617 :デフォルトの名無しさん:2013/12/31(火) 15:08:46.55
一応cmdでも色つくよ。
cygwinいれてexeある場所にパス通すと
lsとかのexeがつかえるのだが、
ls --colorとか打ち込むと色分けされる。

ぶっちゃけメンテとか詰めとが実用的なレベルにすらならない低さで甘いだけ。
一応機能的には色分けできる。

618 :デフォルトの名無しさん:2013/12/31(火) 17:16:10.14
>>614
scpでコピペって、sshでログインするのとどれだけ違いがあるのよ
だいたい相手のファイル構成知らなきゃならない時点でダメだろ

619 :デフォルトの名無しさん:2013/12/31(火) 17:28:06.31
コピペw
別にどこに置いてもいいんだから自分のホームディレクトリにコピーしろよ
書き込み権限無いとこに置きたいならリポジトリ管理ツール用意してもらえ

620 :デフォルトの名無しさん:2013/12/31(火) 17:32:58.20
そいつはたぶんUnixとか使ったこと無いからまともに相手にしても無駄だぞ

621 :デフォルトの名無しさん:2014/01/01(水) 11:40:09.64
>>620
つまらないレッテル貼りはやめなよ

622 :デフォルトの名無しさん:2014/01/01(水) 15:42:08.86
GitHub for Windows のコマンドラインシェルって
プロンプトにブランチ名が色つきで表示されてた。
あのプロンプトだけは素敵だな。
それ以外は使いづらいシェルだったが。

623 :デフォルトの名無しさん:2014/01/01(水) 15:50:46.01
>>621
レッテル貼りの定義はよ

624 :デフォルトの名無しさん:2014/01/01(水) 16:14:24.62
修正すれど修正すれど、わが暮らし楽にならざり
Git手を見る

625 :デフォルトの名無しさん:2014/01/01(水) 16:52:56.91
くだらん自尊心ばっかりだ

626 :デフォルトの名無しさん:2014/01/01(水) 17:51:00.97
1.masterブランチでファイルを更新しました
2.addとかcommitとか何もしないでgit checkout -b testでtestブランチに移動しました

この場合masterブランチで更新した内容は消えてしまいますか?

627 :デフォルトの名無しさん:2014/01/01(水) 18:12:36.76
git checkout -b <branch>なら消えない
既存のほかのブランチに(-bなしで)移動するなら、
消えない(git管理下でないファイルの場合)か、またはエラーになって移動できない(git管理下のファイルの場合)

628 :デフォルトの名無しさん:2014/01/01(水) 18:24:51.79
ってことはtestブランチでadd してcommitしてからmasterブランチに移動したら
1の時点のファイルの内容は復活するということですか?

629 :デフォルトの名無しさん:2014/01/01(水) 18:34:39.56
もう、本気で本読むとか入門サイト読んでくるとかした方がいい
何この初歩的な質問、ありえないんだけど・・・

630 :デフォルトの名無しさん:2014/01/01(水) 18:54:45.37
馬鹿には無理

631 :デフォルトの名無しさん:2014/01/01(水) 21:46:03.98
>>626とか>>628みたいな疑問が最初出てくるのはしょうが無いし、
本読むだけじゃなんかよくわからないだろうから、自分でリポジトリ作って試せ
git statusやgit diffで状況を確認しつついろいろやってみろ
ローカルで簡単にリポジトリ作ったり消したりできるgitの利点だ

632 :デフォルトの名無しさん:2014/01/02(木) 04:21:21.52
>>629
上級者専用スレを立ててください。お願いします。

633 :デフォルトの名無しさん:2014/01/02(木) 04:23:00.28
これ一通り読む気が無い人が質問してるん?
読んで分からなかったら分からなかった箇所を訊いてこいよ

Git - Book
http://git-scm.com/book/ja

634 :デフォルトの名無しさん:2014/01/02(木) 09:11:42.80
公式なんて何の役にも立たんよ
gitなんてローカルで何の変更もしてないのに
pull繰り返すだけでコンフリしょっちゅうだし
なのにそのときどうするかなんてことは書いてない
ここの前スレだか前々スレにたどり着いてようやく解決した

つまり公式は2ch未満の肥溜め

635 :デフォルトの名無しさん:2014/01/02(木) 09:19:25.42
そうだな
Junioをさっさとクビにして2chの有志がGit開発しないと

636 :デフォルトの名無しさん:2014/01/02(木) 09:55:11.27
>>634
んー、状況がわからんけどブランチ切らずに修正してるのか?
gitでの修正/開発はブランチでやるのが基本だと思うのだけど。
あと、マージもあまりしない方がいいってのもある。

あと、公式のマニュアルは、そこいらの入門書買うよりおすすめできる内容だと思うけどね

637 :デフォルトの名無しさん:2014/01/02(木) 09:59:45.53
あー、失礼。
コミットした人がFFしてないのか。
しょっちゅうやらかすようなら、説教ですね。

638 :デフォルトの名無しさん:2014/01/02(木) 10:14:19.35
>>632
>>628の答えが分かる人が「上級者」だとでも思ってるの?
「コミットってどうするのですか?」ってレベルの質問だぞ
何でもかんでも質問するんじゃなくて、最低限は学んで来いよ

639 :デフォルトの名無しさん:2014/01/02(木) 10:25:40.95
答える気がないなら黙ってろよ役立たず

640 :デフォルトの名無しさん:2014/01/02(木) 10:59:22.95
馬鹿には無理

641 :デフォルトの名無しさん:2014/01/02(木) 11:41:28.05
>>636
あのさ
修正も何もないんだよ
手元で何もしてないのにpull繰り返すだけでコンフリ起こすから糞だと言ってる
FFしてないわけでもない
そもそもFFでないと禁止されてて蹴られる

642 :デフォルトの名無しさん:2014/01/02(木) 11:47:44.21
これはgit本体ではないと思うがpushしたら鯖側で不具合あって
手元では送れたことになってるのに鯖側では変更されてないなんてこともあったな
そんな具合であまりに不具合が多すぎる

だがしかし公式なんかにはその時どうする必要があるのかなんて書いてない
検索も実質不可能なんだな

そんなわけで作業は全てツリー外でやるようになりましたとさ

643 :デフォルトの名無しさん:2014/01/02(木) 11:50:24.86
>>641
そんなバカな

644 :デフォルトの名無しさん:2014/01/02(木) 11:54:20.89
「何もしていないのにパソコンが壊れた」と言ってるヤツと同じタイプか

645 :デフォルトの名無しさん:2014/01/02(木) 11:55:21.82
そんなバカなことが現実に起きるのがgit
一方svnなら途中でトラブったら戻してくれる

646 :デフォルトの名無しさん:2014/01/02(木) 11:59:19.87
634の時唯一参考になったのがこれ
バッチで処理できる体制は既にこさえてあるが
メモに残していつでもすぐ見られるようにはしてある

http://toro.2ch.net/test/read.cgi/tech/1310403238/499+501
git pullを試みたところ、
error: Your local changes to the following files would be overwritten by merge:
と言われました。しかし、今現在worktreeにある変更はどうでもいい些細なものなので、worktreeにある変更を
破棄して、とにかくpullしたいです。どうすればいいですか?

競合のあるbranch上で git reset --hard origin/upstream_worktree

647 :デフォルトの名無しさん:2014/01/02(木) 12:03:00.36
>>641
それコンフリクトじゃないだろ
rebaseとかしてて公開していない本来pull元にすべきじゃないブランチを
おまえがpull元に指定しちゃってるだけだろ

648 :デフォルトの名無しさん:2014/01/02(木) 12:10:35.86
>>646
おまえ手元で何もしてないと言ってるのに、
その>>646の手元で行った修正を無効にして強引にpullする方法が有効だった意味が理解できてる?
何も理解せずに対処療法でとりあえずうまくいったから得意満面かよw
本が役に立たないとか言ってるが、Junioの本をよく読めば何が起こってるのか理解できるぞ

649 :デフォルトの名無しさん:2014/01/02(木) 12:14:19.39
>>642
gitは手元で送れたかどうかなんて情報は保存してないので
もう一度pushすればいいだけ
確実にpushできたかどうかはfetchして確かめろ

650 :デフォルトの名無しさん:2014/01/02(木) 12:16:16.79
もしそんな不具合てんこ盛りだったらLinuxカーネルの開発には使えんわな

651 :デフォルトの名無しさん:2014/01/02(木) 12:16:28.11
だーかーらー、公式が理解できない糞だから言ってるんだろうが!!!!
Junioとやらはてめえが作ってるソフトのこともろくに説明できない糞なんだよ
このスレの連中の方がJunioとやらよりよっぽどGit理解しててわかりやすく説明してくれてる
このスレがあれば糞みたいな本もGit公式とかも不要

652 :デフォルトの名無しさん:2014/01/02(木) 12:18:32.11
ワラタwwwwwwwww

653 :デフォルトの名無しさん:2014/01/02(木) 12:27:47.69
純ちゃんの本買ってやれよw
ここのスレでいろいろ説明したりしてるば、最初はこの本で勉強したぞw

654 :デフォルトの名無しさん:2014/01/02(木) 12:45:36.21
gitは動作原理が単純で中で何をやってるか理解しやすいから
原理を理解しちまえば大抵の問題は自分で対処できるんだよね
上っ面だけ理解しようとすると大変で>>651みたいに顔真っ赤になる

655 :デフォルトの名無しさん:2014/01/02(木) 12:59:32.71
何故か必死な奴が何人も湧いてるけどさ
647とか648とか完全に的外れなんだよね
扱ってるのは当然許可されてる開発用の公開ブランチだし他のブランチなんか触ることはない
pull繰り返すだけで634の状況になるから646だし

651は俺じゃねえよ

656 :デフォルトの名無しさん:2014/01/02(木) 13:11:04.92
>>655
改変が行われていない公開ブランチをpullしてるだけで
git reset --hard origin/upstream_worktreeが必要になるとしたら、
明らかに環境が壊れてる
gitコマンドがOSのファイルシステムを正常にアクセスできてない
どういう環境で使えばそんな馬鹿なことになるんだ?
git reset --hardでとりあえず凌いでもワークツリーの状態が
正常である保障は何もないぞ
そんな環境を使うのをやめろ

657 :デフォルトの名無しさん:2014/01/02(木) 13:16:36.72
王様のブランチ

658 :デフォルトの名無しさん:2014/01/02(木) 13:21:10.87
>>655
「当然許可されてる開発用の公開ブランチ」であってもrebaseされていない保障は無いぞ?
そのブランチがrebaseされていないことを確認した?
GCされてなければ今からでもreflog使えば確認できるぞ?
Junioの本をちゃんと読めばこの辺のことも理解できる

659 :デフォルトの名無しさん:2014/01/02(木) 13:23:23.72
FFじゃないってgitが検出してるならそれは正常な動作だな
上流のブランチ管理してる奴が馬鹿なだけだ

660 :デフォルトの名無しさん:2014/01/02(木) 13:29:41.53
>>656
普通のM$謹製vistaだからな
あいにくpcの9割はこちらの流れなんだよね
>>658
rebaseされていない保障は無いとか言われてもねえ
ローカルで何も変更してないのにまともに同期できない時点でまともじゃねえわ
646見つけるまで何度かcloneし直したわ

Junioの本だかなんだかしらねえけどさ
こちとら仕方なく使う羽目になってるだけでgitなんかには興味ねえのよ

661 :デフォルトの名無しさん:2014/01/02(木) 13:30:38.52
japan.blogs.atlassian.com/2013/11/git-team-workflows-merge-or-rebase/
そのリポジトリがマージを一切せずにリベースだけでいくと決めてるならそれはそれでアリ。そのプロジェクトの方針ぐらいは尊重してやれ。
pullに--ff-onlyでも付けとけ。

662 :デフォルトの名無しさん:2014/01/02(木) 13:39:22.53
windows用の単純なgit.exeって配布されて無いの?
インストーラーとかcygwinとかはできれば避けたいんだけど

663 :デフォルトの名無しさん:2014/01/02(木) 13:44:12.70
gitの中身は半分bashスクリプトとpythonなんで、シェル環境ごと持ってこないと_

664 :デフォルトの名無しさん:2014/01/02(木) 13:51:59.77
プロジェクトの方針とか関係無く、公開してるブランチのコミットを改変するとか普通は有り得ないよ
リベースだけで運用するとしても、公開ブランチにリベース済みのコミットをpushすることになるだけで、
公開したコミットを改変することは普通しない

でも管理上どうしても改変したいときもあるから、それをgitは許してる
うちとか止むを得ずそれやるときはpullしてるみんなに平謝りして回る
頻繁に公開ブランチ改変してるとしたら管理が糞すぎる

665 :デフォルトの名無しさん:2014/01/02(木) 14:04:50.69
ウチはこうしてる(から他のプロジェクトもこうするべきだ)なんてのはgit以前に傲慢過ぎやしないか

666 :デフォルトの名無しさん:2014/01/02(木) 14:11:05.28
>>665
公開ブランチの改変のことを言ってるの?
公開ブランチのコミットを改変することの意味を理解してる?

667 :デフォルトの名無しさん:2014/01/02(木) 14:21:03.73
メリットデメリットは>>661のリンク先でも論じられてるだろ
わかってやってるなら問題ない、そういうことだ

機能ブランチではrebaseしまくってmasterへはcherry-pickのみでもいいというかそっちが普通だろうけど

668 :デフォルトの名無しさん:2014/01/02(木) 14:32:54.66
わかってなくてやってるから馬鹿が騒いでるんだろw
わかってるならpullしてる馬鹿全員にちゃんと説明して回れw

669 :デフォルトの名無しさん:2014/01/02(木) 14:36:22.57
上の奴は、pullしてるだけのプロジェクト外の人間じゃないのか?w

670 :デフォルトの名無しさん:2014/01/02(木) 14:38:03.65
>>660
cloneの必要ないだろw
resetだって必要無いw
ローカルなブランチ消して作りなせばいいだけじゃないかw

671 :デフォルトの名無しさん:2014/01/02(木) 14:43:04.72
>>660
ローカルで変更してないわけない。
コミットしてないだけで何かしらの変更をワークツリーに加えてるから>>646で解決出来る状態になる。
おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの?

672 :デフォルトの名無しさん:2014/01/02(木) 14:46:04.19
>>667
いやなんか勘違いしてるぞ
rebaseチームポリシーでも公開してるブランチの履歴をリベースして改変しちゃダメだ
公開ブランチへのpushはつねにFFで行う。
pushの前に非公開ブランチでリベースはすましておく。
当然ながら非公開ブランチで行うリベースは公開ブランチのコミットを巻き込んではいけない。
(公開ブランチへのpushがFFでなくなるから)

673 :デフォルトの名無しさん:2014/01/02(木) 14:53:35.74
まあ公開してた機能ブランチをリベースしてマスターにpushするとかもありだと思うけどね
その時点で機能ブランチはクローズすべきだよ
もしくは機能ブランチはそのまま残して、機能ブランチから作った非公開ブランチ上でリベースしてpushするとか
公開したブランチを改変してそのまま履歴をさらに伸ばすとか絶対良いことないからやめとけ

674 :デフォルトの名無しさん:2014/01/02(木) 15:03:21.18
公開ブランチをrebaseするのと
rebaseしたコミットを公開ブランチにFFでpushするのを区別できてない奴がいるのか

675 :デフォルトの名無しさん:2014/01/02(木) 15:04:51.46
ちなみに、一体どんな差分がコンフリクトするの?
pullしたときの、状況の方が気になるな。

676 :デフォルトの名無しさん:2014/01/02(木) 15:10:54.53
>>673
masterとの差が離れてきたとかここらで一旦履歴を可読にしたいとかで
rebaseしてmasterと足並みを揃えてから機能ブランチは継続もアリと思うけどね

677 :デフォルトの名無しさん:2014/01/02(木) 15:21:00.37
>>676
自分だけがその機能ブランチを使うならそれでいいと思うよ
その機能ブランチを公開してるならブランチを変えた方がいい

678 :デフォルトの名無しさん:2014/01/02(木) 15:30:38.09
お正月から賑やかだなwおまえらw

679 :デフォルトの名無しさん:2014/01/02(木) 15:55:43.22
>>671
たぶん上流が履歴を改変してる
origin/upstream_worktreeへのfetchはデフォルトの+つきで行われるから自動的に上書きされるけど、
それでorigin/upstream_worktreeとローカルのupstream_worktreeのFF状態が崩れるから、
非FFなマージが走ることになって失敗するんじゃないかな
本来pullしてるだけなら非FFマージは走らないからコンフリクトとか有り得ないからね

680 :デフォルトの名無しさん:2014/01/02(木) 16:56:55.46
ところで、上流がpush -fされた時のメッセージはforced updateなんちゃらであって
>>646のYour local changes to the following files would be overwritten by mergeってのは出ない気がする
手元で確認して確かめた

なのでやっぱり、手元で何かしちゃってるはず

681 :デフォルトの名無しさん:2014/01/02(木) 17:53:58.95
>>680
そう思うだろうけどしてないんだよね
つーか上と下関係なくね?
覚えてないけどYour local changes云々は違うかもしれんよ
そのログは参考にした対処だからね

何か月も過ぎてるから良く覚えてないけどgitと破棄で検索して見つけたのかなあ

682 :デフォルトの名無しさん:2014/01/02(木) 19:30:19.89
周知もせず履歴の改変を行う管理者と
適当に検索してその場しのぎの対処で誤魔化すプログラマとか最悪だな

683 :デフォルトの名無しさん:2014/01/02(木) 20:40:34.46
上から権限をスター的な構成にしたいけど難しいよな

684 :デフォルトの名無しさん:2014/01/02(木) 20:50:57.58
>>683
Gitoliteとか使うんじゃダメなのか?

685 :デフォルトの名無しさん:2014/01/02(木) 23:22:59.71
>>681
関係あるだろ、だってYour local〜ってのは将に手元で変更してたときのメッセージだもの

686 :デフォルトの名無しさん:2014/01/03(金) 00:48:30.57
>>638
うるせーはげ

687 :デフォルトの名無しさん:2014/01/03(金) 11:47:32.11
>>671
> おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの?

AndroidのカスROM作ろうとしてAPIにメソッド追加したりすると、ビルド生成物の一部が管理対象に含まれてるんで、こうなる。
API変更しておいて生成物の更新を忘れてたままpushすると顰蹙もの。

688 :デフォルトの名無しさん:2014/01/03(金) 16:09:05.10
git reset --hard HEAD

689 :デフォルトの名無しさん:2014/01/05(日) 02:30:52.82
Githubって無料じゃプライベートリポジトリ作れないの?
なんか使えねーな。
個数制限3つとかできりゃいいのに。

690 :デフォルトの名無しさん:2014/01/05(日) 02:42:44.34
BitBucketの存在も知らずに「Githubって使えねえゴミ」とか罵倒する奴にGitを使ってほしくない

691 :デフォルトの名無しさん:2014/01/05(日) 02:46:04.88
>>689
bitbucketとかでやればいいんじゃね

692 :デフォルトの名無しさん:2014/01/05(日) 02:48:43.30
>>690-691
情報ご苦労
使えねえGithubはbitbucketに潰されろ

693 :デフォルトの名無しさん:2014/01/05(日) 03:14:40.68
↓機能してるスレかは分からんが、Gitで無料でプライベートリポジトリ作れるとこ教えてくれるかもしれんぞ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

694 :デフォルトの名無しさん:2014/01/05(日) 03:21:21.01
>>692
わざわざ煽りご苦労。

695 :デフォルトの名無しさん:2014/01/05(日) 08:33:05.15
プライベートリポジトリって秘密にしたいもの置くんだろ
無料のサービスを信用するって頭沸いてるとしか思えない

696 :デフォルトの名無しさん:2014/01/05(日) 09:32:28.75
誰も信用するとは書いていないが

697 :デフォルトの名無しさん:2014/01/05(日) 09:35:32.12
そこに秘密のファイル置くんだろ

698 :デフォルトの名無しさん:2014/01/05(日) 09:40:39.34
無料を信用するより、信用してないとこに秘密のファイル置く方が、よりヒドイと思うんだがw

699 :デフォルトの名無しさん:2014/01/05(日) 10:01:38.12
自分でGit鯖立てればいいじゃん
GitLabでもGitoliteでも好きなの選べ

700 :デフォルトの名無しさん:2014/01/05(日) 10:22:28.47
アホかこいつ

701 :デフォルトの名無しさん:2014/01/05(日) 10:31:16.72
プライベートでなけりゃ、無くなる心配だけすればいいけど
プライベートだと、それに加えて盗まれる心配もしなきゃならない

702 :デフォルトの名無しさん:2014/01/05(日) 14:58:33.54
Github「お前のものは俺のもの」

703 :デフォルトの名無しさん:2014/01/05(日) 15:01:27.82
「アトリエのどか式 Git入門」
ttp://www.atelier-nodoka.net/2013/12/c85-information/

この本ってお勧めですか?

704 :デフォルトの名無しさん:2014/01/05(日) 15:04:45.53
>>703
表紙が気に入ったら買えばいいのでは?
内容はネットで読めるみたいだし。

705 :デフォルトの名無しさん:2014/01/05(日) 15:11:47.14
>>702
金も払わずにプライベートリポジトリが使えて当然とか、乞食かよ

706 :デフォルトの名無しさん:2014/01/05(日) 16:11:14.76
Evernote, Dropbox 「ウェルカム乞食」

707 :デフォルトの名無しさん:2014/01/05(日) 17:06:07.43
>>706
EvernoteとDropboxは無料で体験してもらって有料プランに引き込むビジネスモデルだから全く話が違う。
GitHubは、まず根底に「全てのソフトウェアは自由であるべき」っていうフリーソフトウェア運動の理念があって、
フリーソフトウェアの要件のひとつである「オープンソース化」を促進するのがそもそもの存在意義なんだな。
でもそれだけじゃサービスを維持できないから、金をとってクローズドソースでのリポジトリホスティングもやってるわけ。
有料と無料の違いはプライベートにできるかどうかだけなんで、機能とかを体験するならオープンのリポジトリでやってもらえばよくて、
無料でプライベートリポジトリを提供する理由がない。文句あるなら金払うかオープンソースでどうぞって話。

708 :デフォルトの名無しさん:2014/01/05(日) 17:19:36.92
自由であるべき理想、というより、お前の自由は俺に金を払わなきゃ与えない、ってことだよな。

709 :デフォルトの名無しさん:2014/01/05(日) 17:25:08.24
>>708
なんで自分のことしか考えない(=金を払わない&ソースも公開しない)人間に無銭の宿(リポジトリ)を提供しなきゃならんのさ。
世の中ギブ&テイク。リポジトリを使わせてくれというのなら対価は必要だ。
GitHubの場合はそれが単なる金か、あるいは世の中への貢献(=ソースコードの公開)ということさ。
金も払わない、世の中への貢献もしない、でもリポジトリは使わせろってそっちの方が無茶苦茶言ってるぞ?

710 :デフォルトの名無しさん:2014/01/05(日) 18:15:54.46
「使えねえ」なら見かけたが「使わせろ」とは誰も書いてない

711 :デフォルトの名無しさん:2014/01/05(日) 18:20:10.94
>>710
?
有料でしかプライベートリポジトリ使えないのかよ、使えねぇな=無料でプライベートリポジトリ使わせろ
ってことでしょ?

712 :デフォルトの名無しさん:2014/01/05(日) 18:28:32.04
>>711
使えねえから使わない。だろ
おまえホント使えなさそうだな

713 :デフォルトの名無しさん:2014/01/05(日) 19:13:38.03
正確に言うと、

無料で使えないから、使わない

という話。

別にgithubの機能が劣っているわけじゃない。
むしろ優れている。

だが金かかるので使わない。

714 :デフォルトの名無しさん:2014/01/05(日) 19:22:51.35
使えねえのは貧乏な俺だったというオチ

715 :デフォルトの名無しさん:2014/01/05(日) 19:31:23.04
gitに無料のお試しプライベートリポジトリサービスがあればいいのに、って書いただけで
どうしてそこまで発狂できるのかふしぎ

716 :デフォルトの名無しさん:2014/01/05(日) 20:04:57.67
>>715
おまえが最初に煽ったからだろ
> Githubって無料じゃプライベートリポジトリ作れないの?
> なんか使えねーな。

717 :デフォルトの名無しさん:2014/01/05(日) 21:33:45.92
Githubって無料じゃプライベートリポジトリ作れないの?
なんか金払えない俺には使えねーな。

718 :デフォルトの名無しさん:2014/01/05(日) 21:35:29.19
つまり、使えねえのは貧乏な俺だったというオチ

719 :デフォルトの名無しさん:2014/01/06(月) 00:25:11.50
>>706
Google大先生も入れてあげて

720 :デフォルトの名無しさん:2014/01/06(月) 04:46:08.61
Gitはスナップショットだから、無駄に大量にコミットしまくるとゴミデータが溜まりまくる・・・

721 :デフォルトの名無しさん:2014/01/06(月) 05:00:12.07
ブランチの切り替えは大量のファイル移動があってHDD負荷が

722 :デフォルトの名無しさん:2014/01/06(月) 11:50:47.99
>>720
過去のコミットは圧縮がかかるので、
差分を保持してるのとほとんど代わらない程度のディスクスペースしか消費しない

723 :デフォルトの名無しさん:2014/01/06(月) 11:53:05.51
>>721
かなり大規模なプロジェクトでも、
問題になるほど大量のファイル書き換えが起こることはマレだよ

724 :デフォルトの名無しさん:2014/01/06(月) 12:56:06.48
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
git関係ないんだから、こっちでやれよ

725 :デフォルトの名無しさん:2014/01/06(月) 14:04:11.57
BitBucket使えばいいじゃん

726 :デフォルトの名無しさん:2014/01/06(月) 15:25:56.39
723までで流れが元に戻ってんのに蒸し返す馬鹿なんなの

727 :デフォルトの名無しさん:2014/01/06(月) 15:36:14.89
燕返し!

728 :デフォルトの名無しさん:2014/01/07(火) 04:04:08.39
> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。

友人や家族からも軽蔑されるのかよ!

729 :デフォルトの名無しさん:2014/01/07(火) 04:10:23.48
リベース、つまり今までプッシュしてないブランチにマージしたい先のブランチの最新状態を取り込むってことやな

730 :デフォルトの名無しさん:2014/01/07(火) 13:55:51.90
>>728
公開したコミットをリベースする奴なんてもううちの子じゃないよ

731 :うちの子:2014/01/07(火) 14:02:50.88
お前の子だった覚えがないわ>>730

732 :デフォルトの名無しさん:2014/01/07(火) 14:10:17.62
J( 'ー`)し<ごめんね。おかあさんはじめてpull失敗して散々だったから、ごめんね

733 :デフォルトの名無しさん:2014/01/07(火) 15:21:34.71
リモートブランチに含まれているコミットをrebaseしようとしたら警告が出るとか無いのか

734 :デフォルトの名無しさん:2014/01/07(火) 15:50:50.86
使ったこと無いの?普通はpushできない設定になってる
リモート側で直接リベースすることはできるけど、
普通は公開してるリポジトリのブランチを直接操作しない

735 :デフォルトの名無しさん:2014/01/07(火) 17:32:17.99
>>734
誤読だ
rebase段階での警告が無いと不便と思うだろう?

736 :デフォルトの名無しさん:2014/01/07(火) 17:54:08.19
pushの段階のエラーで十分だわ
Gitの仕組み的にそれをチェックしようとすると実装も使い勝手も面倒なことになる

737 :デフォルトの名無しさん:2014/01/07(火) 18:35:49.21
使ったこと無いのはどっちなんだ
紐付いてるupstreamと比べるだけだろ

738 :デフォルトの名無しさん:2014/01/07(火) 19:33:28.65
Git使ったことないんだけど、自分だけがバージョン管理に使いたい場合、
SourceTreeとかインストールすればローカルのリポジトリって作れるの?

739 :デフォルトの名無しさん:2014/01/07(火) 19:47:05.02
作りたいディレクトリの場所で
git init
と打つだけで準備はOK。
git add somefile
でステージングエリアに、
git commit
でコミット可能。 等といった要領でローカルリポジトリ作れる。

740 :デフォルトの名無しさん:2014/01/07(火) 19:52:41.07
githubのプライベートリポジトリの話ではないだろうか

まさかね
ははは、かんがえすぎだよね

741 :デフォルトの名無しさん:2014/01/07(火) 20:09:32.06
>>739
サンクス
やってみる

742 :デフォルトの名無しさん:2014/01/07(火) 20:10:42.83
その場にリポジトリができるのは便利ではあるんだけど
バックアップ的な意味では不安なんだよな…

743 :デフォルトの名無しさん:2014/01/07(火) 20:14:32.60
>>737
リベースするときに上流のリポジトリにアクセスするとかありえんわ
ローカルのremotes/originはpushした上流の情報をつねに保持してるわけじゃないからな

744 :デフォルトの名無しさん:2014/01/07(火) 21:10:49.21
>>743
どーせpushまでに間が空くんだからそこまでやらんでいい
既にfetchしてる分だけで単純ミス避けには充分

745 :デフォルトの名無しさん:2014/01/07(火) 21:12:06.70
>>742
バックアップとる分には不安はないのだけれど、戻し方がどうすればいいか悩むんだよね。

/直下に、.git作れば複数のサーバで同じ設定維持するの楽かも!
と、考えた時期もありましたorz

746 :デフォルトの名無しさん:2014/01/07(火) 21:25:12.24
>>742
pushがバックアップでは。

747 :デフォルトの名無しさん:2014/01/07(火) 22:11:18.86
>>745
設定共有目的ではないがetckeeperとかあるぞ

748 :デフォルトの名無しさん:2014/01/08(水) 11:55:19.56
git diff で、すでに消したファイルが
空のファイルとみなして差分表示されるんだけど
cvsみたいに ファイルが増えた/減った だけ表示できない?

749 :デフォルトの名無しさん:2014/01/08(水) 13:38:16.29
>>748

--diff-filter=AD とか --summary とか?

750 :デフォルトの名無しさん:2014/01/08(水) 23:28:22.35
なんだよSourceTreeってXP じゃ動かねえじゃんかよ
激おこぷんぷんだわもう

751 :デフォルトの名無しさん:2014/01/09(木) 00:26:12.31
>>748
たぶん git diff -D

752 :デフォルトの名無しさん:2014/01/09(木) 11:42:22.01
84 デフォルトの名無しさん [sage] 2014/01/09(木) 07:03:24.99 ID: Be:
Github が落ちて世界中のプログラマが発狂してるw

85 デフォルトの名無しさん [sage] 2014/01/09(木) 09:12:51.50 ID: Be:
Github のトラブル発生から完全に回復するまで約 2 時間 30 分かかった。

Github Status

Today
23:59 UTCAll systems reporting at 100%

Yesterday, January 07, 2014
23:47 UTCEverything operating normally.
23:24 UTCWe still have one last fileserver that we're working to restore access to. Getting closer.
22:43 UTCThere's a single fileserver offline that we're working to restore access to. Almost there.
22:24 UTCGitHub and Gist are online, we're working to restore connectivity to some repositories.
22:13 UTCWe've recovered from an internal DNS outage, and are working to restore service to all repositories.
21:54 UTCGitHub and Gist are down. We're working to recover the site.
21:36 UTCWe're investigating reports of outages across GitHub and Gist.
21:33 UTCgist.github.com is offline for unscheduled maintenance.

https://status.github.com/messages

753 :デフォルトの名無しさん:2014/01/09(木) 11:58:06.87
>>752
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

754 :デフォルトの名無しさん:2014/01/09(木) 12:57:00.39
>>752
開発者ならcloneしてるのだから、svnとかほどの問題にはならないだろう。

755 :デフォルトの名無しさん:2014/01/09(木) 13:09:12.10
落ちてたの気付かなかった
っていうか気づいてなくて良かった
気付いてたら発狂してるとこだった

756 :デフォルトの名無しさん:2014/01/09(木) 13:11:19.43
分散型なのになんで発狂するの?
cvsをまったく笑えないよね

757 :デフォルトの名無しさん:2014/01/09(木) 13:29:37.03
pushしたら自動でfetchしたいんだけどできる?

758 :デフォルトの名無しさん:2014/01/09(木) 14:57:36.23
なんでgitおちたん

759 :デフォルトの名無しさん:2014/01/09(木) 15:03:12.27
githubをgitと略すにわかはかえれ

760 :デフォルトの名無しさん:2014/01/09(木) 16:07:55.87
>>758
せつこ、それgitちゃう! githubや!

761 :デフォルトの名無しさん:2014/01/09(木) 17:10:39.99
なんの疑問も抱かずgitと打ってしまった

762 :デフォルトの名無しさん:2014/01/09(木) 18:26:48.31
githubとかしょっちゅう落ちてるよ

763 :デフォルトの名無しさん:2014/01/09(木) 23:47:07.74
GitってVSSみたいにファイルのチェックイン、チェックアウトを厳密に
アトミックにロックするやり方の管理もできるの?

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。

764 :デフォルトの名無しさん:2014/01/10(金) 01:11:34.53
ロックの管理はGit以外の方法でやればいい

765 :デフォルトの名無しさん:2014/01/10(金) 02:04:57.98
アンチはGithubが落ちた、と鬼の首でも取ったように大騒ぎしたがるけど、
むしろリモートに接続しなくてもローカルのリポジトリで作業ができてしまう
Gitのすごさが立証された事象だったんだよな。

766 :デフォルトの名無しさん:2014/01/10(金) 02:12:31.59
gitの凄さが立証されただけで
Githubが落ちたこととは関係ない。

767 :うちの子:2014/01/10(金) 03:45:56.32
リモートが落ちただけで作業ができなくなる奴が致命的に馬鹿なだけ

768 :デフォルトの名無しさん:2014/01/10(金) 07:16:28.52
WikipediaをWikiと略すやつがいるように、そのうちGithubもGitと略される日が来るんだろう

769 :デフォルトの名無しさん:2014/01/10(金) 09:42:34.96
だがこのスレにおいてはハブとかサバとかサブとかホモとかそういう感じで

770 :デフォルトの名無しさん:2014/01/10(金) 11:54:00.94
それはWikipediaがpediaと呼ばれるくらい非現実的だな

771 :デフォルトの名無しさん:2014/01/10(金) 13:26:07.49
WikipediaでないただのWikiを使う人は限りなく少ないけど、
Githubとは関係なくGitを使う人は多いからなあ

772 :デフォルトの名無しさん:2014/01/10(金) 17:31:58.59
>>771
いやいやwiki使う人めちゃくちゃ多いだろ。wikipediaで使ってるmediawikiに限定するならともかく。

773 :デフォルトの名無しさん:2014/01/10(金) 18:17:01.09
Wikipedia以外にWikiってものを意識して使わないような人が沢山いるって話だろ?そりゃWikiをなんらかの形で使ってる人は沢山いるだろうけど。

774 :デフォルトの名無しさん:2014/01/10(金) 18:25:23.58
Wikipediaではない他のWikiをWikipediaと呼ぶ奴までいるんだぞ

775 :デフォルトの名無しさん:2014/01/10(金) 18:30:37.18
mediawiki使ってるとこをWikipediaと勘違いしちゃうのは仕方ないと思うけどねー

776 :デフォルトの名無しさん:2014/01/10(金) 18:47:32.96
wordpressのことをwikiって言ってる人もいたな

777 :デフォルトの名無しさん:2014/01/10(金) 19:32:41.57
知ってる人とでも面倒臭がって間違いを正してあげないからなー。ホームページやハッカーに続くのか。

778 :デフォルトの名無しさん:2014/01/11(土) 00:31:31.16
Bitkeeper使えよ貧乏人ども

779 :デフォルトの名無しさん:2014/01/11(土) 01:54:16.94
irane

780 :デフォルトの名無しさん:2014/01/11(土) 15:10:37.04
とにかく自動でfetchするようにしたいんだけどどうしたらいい?

781 :デフォルトの名無しさん:2014/01/11(土) 15:27:06.55
10 fetch
20 goto 10

782 :デフォルトの名無しさん:2014/01/11(土) 16:07:38.53
githubかgitlabにNGユーザーと通報機能みたいな荒らしを排除する仕組みはある?
それっぽいのなくて荒らされても止められず不特定多数のユーザーのリクエストをすべて拒否するしかなさそうだけど

783 :デフォルトの名無しさん:2014/01/11(土) 16:13:21.04
荒らされる奴って荒らされる方にも問題があるんだろ

784 :18:2014/01/11(土) 16:25:50.53
煽り抜きで、みんなドキュメントとか画像とかの管理はどうしてるの?
マジで >>764 しかないの?

785 :デフォルトの名無しさん:2014/01/11(土) 16:40:10.75
>>1
このURLアクセスできる?
http://progit.org/book/ja/

こっちのURLならアクセスできる
http://git-scm.com/book/ja/

786 :デフォルトの名無しさん:2014/01/11(土) 16:41:09.32
>>784
しかないの

787 :デフォルトの名無しさん:2014/01/11(土) 16:53:48.75
>>783
自分も荒らされてるところ見たことないけど実際攻撃されたら
ただのgitとしてしか使えなくなるのはあまりに脆弱で不安
たとえば領土問題のある地名をデータとして持つか受け入れるプログラムの
リポジトリにクレーマーが粘着するというケースはありえるしそのとき
普通のユーザーごとリクエストを拒否するしかないのは欠陥でしょ

788 :デフォルトの名無しさん:2014/01/11(土) 17:00:49.11
>>787
おまえら自分がGitスレ荒らしてるって認識はある?
Githubのことはこっちに行けよ
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

789 :デフォルトの名無しさん:2014/01/11(土) 17:28:42.04
git diff --color で
空白のみ違うときに 豆腐を表示してくれるけど
あれウザいんでなんとかならんかな

かといって、 -w をつけると空白のみの差分を無視しちゃうので
空白は豆腐でなく空白で表示してほしい

790 :デフォルトの名無しさん:2014/01/11(土) 17:40:32.33
git diff FETCH_HEAD
と書いたらfetchした分との差分になるけど
git diff
と書いたら何との差分になるの?
git diff △△△△△△
あえて明示的に書くとしたら
△△△△△△ は何になるの?

791 :デフォルトの名無しさん:2014/01/11(土) 17:42:45.25
HEAD

792 :デフォルトの名無しさん:2014/01/11(土) 17:43:42.68
>>789
いいアイデアがあるぜ
自分でソースを書き換えてgitを再構築するんだ
Coolだろ?

793 :デフォルトの名無しさん:2014/01/11(土) 17:46:34.09
>>792
あぁ、そんなことは知ってる。

それをやらずにする方はないのかって意味なんだが、
理解できなかったか?

794 :デフォルトの名無しさん:2014/01/11(土) 18:02:12.96
git config color.diff.whitespace normal

795 :デフォルトの名無しさん:2014/01/11(土) 18:55:11.30
>>790
ありがとうございます
HEAD かー

796 :デフォルトの名無しさん:2014/01/11(土) 19:29:54.10
>>794
ありがとうございます
こういうデフォルトで設定されているオプションを一覧したいけど
表示させる方法ってあるんですかね

797 :デフォルトの名無しさん:2014/01/11(土) 22:40:19.25
>>788
すまんそのスレ知らんかった

798 :デフォルトの名無しさん:2014/01/12(日) 00:09:33.77
>>784
CVSやSubversionじゃだめなの?

確かにGitってテキスト主体のオープンソースの分散開発ならいいけど、
社内とかの仕事で使うにはあまり意味ないよね。

各人勝手にソースいじることないし、最終的にどこを取り入れるか判断する
人の負担が大きいし。

799 :デフォルトの名無しさん:2014/01/12(日) 00:57:44.96
>>784
textやsvgをふつーにgitで管理してる。
別にバイナリでもロックする必要性を感じない。

800 :デフォルトの名無しさん:2014/01/12(日) 01:07:08.37
gitって画像のやりとりにも使えそうな気がするけど
やってはイカンのだろうな

801 :デフォルトの名無しさん:2014/01/12(日) 01:22:02.26
いいんじゃないの?
本でも漫画でも同人誌でも。
著作権法に違反しないなら。

802 :デフォルトの名無しさん:2014/01/12(日) 01:33:25.17
>>798
gitにかぎった話じゃないけど、内部管理とプロジェクト管理を別々のリポジトリ使うことはよくあるよ。
そういうとき、分散型の方が楽にマージできる。

一応、バイナリファイルも管理できる。
コンフリクトしやすいから--oursとか必要になるけど

803 :デフォルトの名無しさん:2014/01/12(日) 04:55:03.09
>>798
お前、ソースコードの管理にしか使ってないだろ?

CVSやSubversionでどうやって
一日数回のコミットと複数のブランチを作ってマージが出来るっていうんだ?
不可能ではないが面倒くさすぎるだろ。

804 :デフォルトの名無しさん:2014/01/12(日) 07:29:28.39
>>796
git config --help
では?

805 :デフォルトの名無しさん:2014/01/12(日) 08:04:40.71
>>798
> CVSやSubversionじゃだめなの?

いまは Subversion 使ってるんだけど、git のローカルコミットは確かに便利なので、みんなどうしてるのかと。

>>799
> 別にバイナリでもロックする必要性を感じない。

運用でカバーできてるってこと?

806 :デフォルトの名無しさん:2014/01/12(日) 08:34:10.62
>>805
バイナリ入れるのはデザイナの作った画像くらいだし、滅多に更新しないから。

807 :デフォルトの名無しさん:2014/01/12(日) 09:32:23.79
>>803
コミットもブランチ分けも全部紙ベースの申請と会議で許可が出るんだよ
察してやれ…

808 :デフォルトの名無しさん:2014/01/12(日) 10:21:59.90
素人が好き勝手にやるにはGitが便利
組織のなかできちんとした管理をするにはCVSが便利
って結論か。

809 :デフォルトの名無しさん:2014/01/12(日) 10:29:31.14
>>808
     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |
.   /: : : //ヾ ; :|!: イ、||ll|||||::||    ノノ  イ|||||||ヾ、 |: ::|!: : イ: ::|/   な 思 が
   /: : ://: : :ヽソ::ヽl |{ i||ll"ン    ´   i| l|||l"l `|: /|: : /'!/l     ん う
 ∠: : : ~: : : : : : : :丶ゝ-―-      ,  ー=z_ソ   |/ ハメ;, :: ::|.   だ ん
   i|::ハ: : : : : : : : : : : 、ヘヘヘヘ     、  ヘヘヘヘヘ /: : : : : \,|.   ろ な
   |!l |: : : : : : : : :、: ::\    、-―-,      / : : :丶;,,;,:ミヽ   う  ら
     丶: :ハ、lヽ: :ヽ: : ::\__  `~ "      /: : ト; lヽ)   ゝ
       レ `| `、l`、>=ニ´        ,  _´ : :} `   /
         ,,、r"^~´"''''"t-`r、 _  -、 ´ヽノ \ノ   /    お ・
       ,;'~  _r-- 、__     ~f、_>'、_         |  で  前 ・
      f~  ,;"     ~"t___    ミ、 ^'t         |  は  ん ・
      ,"  ,~         ヾ~'-、__ ミ_ξ丶     |  な  中 ・
     ;'  ,イ ..          ヽ_   ヾ、0ヽ丶    l         /
     ( ;":: |: :: ..          .`,   ヾ 丶 !    \____/
     ;;;; :: 入:: :: ::      l`ー-、   )l   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶

810 :デフォルトの名無しさん:2014/01/12(日) 10:58:37.50
>>806
ああなるほど。
仕様書とかマニュアルはどうしてます?

811 :デフォルトの名無しさん:2014/01/12(日) 12:16:37.86
>>810
よくよく考えると、文書類はwikiがほとんどだ。小さいアプリだとtext/plainなくらい。
マニュアルはhtmlだな。またはwikiからpdfを生成とか。

812 :デフォルトの名無しさん:2014/01/12(日) 12:59:36.68
組織もでかくなって人の出入りが多かったりするとロック方式のVCSとか面倒だよ

813 :デフォルトの名無しさん:2014/01/12(日) 14:10:34.66
ドキュメントのフォーマットに合わせてコードの管理方式を選択するとかアホすぎると思わんのか
コードの管理はロックの無い分散管理が便利過ぎて集中管理なんかに戻る気になれん

814 :デフォルトの名無しさん:2014/01/12(日) 16:00:00.05
大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
大事だから、やっぱGitは向いてないよ。

別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている(その
ために作られた)わけでさ。

815 :デフォルトの名無しさん:2014/01/12(日) 16:10:12.56
Linuxカーネルはいい加減な開発体制
弊社は中小にすぎないがLinuxカーネルのようないい加減なソフトは作っていない
よってGitなど使っては開発体制が崩壊する

816 :デフォルトの名無しさん:2014/01/12(日) 16:15:57.54
Linusみたいな独裁者がいるとGitは上手くいく。
北朝鮮型。

817 :デフォルトの名無しさん:2014/01/12(日) 16:16:17.98
馬鹿には無理

818 :デフォルトの名無しさん:2014/01/12(日) 16:51:23.17
馬鹿には使いこなせない

819 :デフォルトの名無しさん:2014/01/12(日) 16:55:14.09
分散型は個々の作業を重視した開発に向いているよね
そういう意味でオープンソフト向けなのは確かだと思う
自由気ままに各自で開発して、良ければマージしてねってスタイル向け

個々のスキルを重視できる職場向きとも思う
だけど日本の職場には向かないんじゃないかな
理由はお察s(ry

820 :デフォルトの名無しさん:2014/01/12(日) 18:35:04.93
>>814
> 大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
> 大事だから、やっぱGitは向いてないよ。

なんで? その理由を書かないのはなんで?

821 :デフォルトの名無しさん:2014/01/12(日) 18:51:57.96
大きな組織でのスケジューリングや担当分けの調整で
集中型のバージョン管理ツールが大活躍してるんですか?www

822 :デフォルトの名無しさん:2014/01/12(日) 19:12:21.30
ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。

823 :デフォルトの名無しさん:2014/01/12(日) 19:32:09.59
ウォーターフォール型のプロジェクトでコンフリクトが多発とかマジですか?w

824 :デフォルトの名無しさん:2014/01/12(日) 19:42:26.69
>>822
gitでコンフリクトが起こるようならsvnでも起こるでしょ
コンフリクトは分散や集中とかとは関係ないよ
ただ集中型ツールならロックというコンフリクト回避手段が用意されているだけで

825 :デフォルトの名無しさん:2014/01/12(日) 19:43:08.28
ウォーターフォール開発でGitのコンフリクトは基本的には起こらないだろ
どういうときにコンフリクトするのか理解してないのか?

826 :デフォルトの名無しさん:2014/01/12(日) 20:06:29.51
オープンソースなら見知らぬ他人からプルリクエスト来たりするじゃん
どうやって回避してるの?

827 :デフォルトの名無しさん:2014/01/12(日) 20:21:25.64
下手っ糞なコードであちこち改編されて
プルリクエストが来た日には殺意を覚えたもんです

828 :デフォルトの名無しさん:2014/01/12(日) 20:23:07.80
何を回避するんだ?

829 :デフォルトの名無しさん:2014/01/12(日) 20:27:09.83
気に入らない pull request は無視すれば良いだけ

830 :デフォルトの名無しさん:2014/01/12(日) 20:35:41.89
なんかGitと関係あるの?
昔からメーリングリストにパッチ投げるとか普通にあるんだが

831 :デフォルトの名無しさん:2014/01/12(日) 20:53:10.12
gitでpull requestってどうやるんですか?

832 :デフォルトの名無しさん:2014/01/12(日) 20:58:50.54
m9 prpr

833 :デフォルトの名無しさん:2014/01/12(日) 21:01:25.84
>>831
リポジトリをクローンして修正して相手がアクセスできる場所に置いてから、
相手に連絡をつけて、レポジトリを置いた場所とマージしてちょ!という意思を伝えます。

834 :デフォルトの名無しさん:2014/01/12(日) 21:34:34.91
うちも同じ感じで コミットしました って電話してる。

835 :デフォルトの名無しさん:2014/01/12(日) 21:48:11.94
うちはコミットしたら課長のハンコもらって社内便でPR!

836 :デフォルトの名無しさん:2014/01/12(日) 22:41:41.76
>>821
> 大きな組織でのスケジューリングや担当分けの調整で
> 集中型のバージョン管理ツールが大活躍してるんですか?www

? バージョン管理ツールはスケジューリング用のツールじゃないよ?
だから全く関係ない話で、大活躍もしないし、逆に向かないってこともない。
だって全く関係ないから。

837 :デフォルトの名無しさん:2014/01/12(日) 22:45:20.41
うちは予定と予定完了をコミットして管理してる

838 :デフォルトの名無しさん:2014/01/12(日) 23:07:39.95
あー、わざとらしいw

839 :デフォルトの名無しさん:2014/01/12(日) 23:34:50.18
予定日のコミット位置は未来になるからコミットの位置では進捗確認できないのでは

840 :デフォルトの名無しさん:2014/01/12(日) 23:36:42.83
そのコミットじゃねーよ。バーヤ

841 :デフォルトの名無しさん:2014/01/12(日) 23:49:25.02
TODOリストをバージョン管理してるだけなんだけど?
基本的にメモとか全部Gitのレポジトリの中

842 :デフォルトの名無しさん:2014/01/12(日) 23:49:28.42
Gitは〜には向かないのでは? という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。

大組織での開発にも、いや、Gitってこういう使い方すれば役に立つよ、という書き込みなら
まだ建設的な議論が出来そうだけど、具体的な内容ゼロの当てこすりや小馬鹿にしたような
書き込みばかり。

まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね?
と思う。

843 :デフォルトの名無しさん:2014/01/12(日) 23:59:57.42
バージョン管理ツールで予定する前提で話してる奴とスケジューリングツール前提のやつ入り混じってて
話がかみ合ってないのに自信満々で語ってるアホがいるからややこしい

844 :デフォルトの名無しさん:2014/01/13(月) 00:01:25.93
〜には向かないのでは?っていう書き込みに、
別にそんなことないよ?って答えが返ってきてるだけじゃない
それ以上の情報が欲しいとか、炎上させて情報得ようとかの糞野郎でしかないね

845 :デフォルトの名無しさん:2014/01/13(月) 00:05:40.38
>>842
小馬鹿にするっていうか、「〜には向かないのでは?」って書いてる奴が馬鹿過ぎるんだものw

846 :デフォルトの名無しさん:2014/01/13(月) 00:09:57.58
Githubについて語りたいならこっちへ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

Gitというより分散バージョン管理の問題について語りたいならこっちへ

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

847 :デフォルトの名無しさん:2014/01/13(月) 00:10:41.62
× Gitは〜には向かない
○ 〜はGitには向かない

管理者、利用者含めて、運用システム構築できないんだったら、git使わないほうがいい
使う側も管理する側もgit理解してないといけないぐらいgitって自由度高すぎるんだよ
ていうのを
mercurial→gitにきて思った

848 :デフォルトの名無しさん:2014/01/13(月) 00:11:27.67
草生やした会話が普通だと思ってるお客様は巣から出てこないでね
迷惑だから

849 :デフォルトの名無しさん:2014/01/13(月) 00:12:20.08
Gitに向かない用途なんてないだろ
使いこなせない奴がバカなだけ
だいたい一流企業ではGit使ってる

850 :デフォルトの名無しさん:2014/01/13(月) 00:14:35.00
わかってるだろうけど>>849=>>845
自演してるだけ

851 :デフォルトの名無しさん:2014/01/13(月) 00:17:09.99
敵は一人妄想の奴とか自演妄想の奴って、自分に自信がないもんだから、
「自分は多数派である」という幻想にしがみつくしかないのかな?
なんか哀れっぽいw

852 :デフォルトの名無しさん:2014/01/13(月) 00:21:59.90
なんで>>849=>>845だと自演なんだ?

ちなみに
Googleは独自ソース管理システムを持っててGitを使ってない
MSはVisual StuidoがようやくGitサポートし始めたとこだから、社内でも本格的には使ってないんじゃないかな?
Appleはよく知らんが使ってそう

853 :デフォルトの名無しさん:2014/01/13(月) 00:23:46.26
日本のIT関係だとどうなの?使ってる率高いの?

854 :デフォルトの名無しさん:2014/01/13(月) 00:30:08.19
>>852
一人二役で論争作って炎上させようとしてるからだよ
>>851で化けの皮はがれたからこんな場違いに低能な奴もう相手にされないだろうがね

855 :デフォルトの名無しさん:2014/01/13(月) 00:44:11.92
>>852
MSがTFS使ってなかったら笑い話やな

856 :デフォルトの名無しさん:2014/01/13(月) 00:59:10.80
また敵は一人妄想か。

857 :デフォルトの名無しさん:2014/01/13(月) 01:05:09.50
>>854
いやべつに、849と845が同じ奴の書き込みでも違う奴の書き込みでも大勢に影響無いと思うのだが…?

858 :デフォルトの名無しさん:2014/01/13(月) 01:07:29.98
割と大手電機メーカー子会社系列のソフト屋だけど、まわりじゃGitは使われてないね。
MSDNのライセンスを買っているからSourceSafeを使うことが多い。
WORDとかのドキュメントは差分取っても意味ないので、MSSみたいなチェックイン、チェックアウト式で充分。
ちなみにGithubはファイル交換サイト扱いでアクセスできない(w
これは大手はどこでもそうじゃないかな?

859 :デフォルトの名無しさん:2014/01/13(月) 01:08:06.21
>>853
SIerは案件毎に違うだろうね
Webとかソーシャル系はほぼ使ってるだろう

860 :デフォルトの名無しさん:2014/01/13(月) 01:13:24.41
上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

上でGitのコンフリクトの意味が分かってない人がいたけど、別にGitのツールとしてのコンフリクト回避機能に問題があるってわけじゃないんですよ。
大手だと誰がどこを直すのか決めてからやるわけで(そのミスを減らすためにバージョン管理ソフトを使うわけで)、ファイルのロックやロールバックがきちんと行われる方が大事なんですな。

Gitだと複数の人が同じところ勝手に直しだしたりしても検出できないでしょ。無駄な作業が発生するわけ。
どっちが悪いとかじゃなくて、Gitが向いてないタイプの管理が企業内にはあるってこと。
おわかりかな?

861 :デフォルトの名無しさん:2014/01/13(月) 01:18:07.05
>>860
大手のウォーターフォール型の開発だと
どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ
誰かどこを弄るとかはコード弄る前にレビューとかして明確になってるんだから

862 :デフォルトの名無しさん:2014/01/13(月) 01:23:30.89
だからさ、それが完璧に機能するなら単にファイル共有でいいでしょ。
あくまでミスをなくす(あるいはミスが起きたときにリカバーする方策)目的だよ。
ほんとに頭悪いの?

863 :デフォルトの名無しさん:2014/01/13(月) 01:24:06.89
誰がどこを直すかのミスを減らすためにロックを使うって、
みんながコーディング終わるまでずっとロック取り続けたりするのか?

864 :デフォルトの名無しさん:2014/01/13(月) 01:26:35.03
>>863
はぁ?
お前本当にバージョン管理システム使ったことあるの?

とんだけ的外れな質問だよ?

865 :デフォルトの名無しさん:2014/01/13(月) 01:30:20.70
>>860
GitHubは1人の責任者でなくメンバーそれぞれで採用を決める方法で開発運用できてるのだから独裁にこだわる必要はないでしょ
日本の慣習に合わないってだけで

866 :デフォルトの名無しさん:2014/01/13(月) 01:33:06.24
>>864
Gitにはロック無いんだからここでそんなこと言われてもねえ
それともGitはバージョン管理ツールじゃないの?

867 :デフォルトの名無しさん:2014/01/13(月) 01:37:44.01
また繰り返しかよ。

>>866
>Gitにはロック無いんだからここでそんなこと言われてもねえ
だからGitには向いてない組織あるよね、という話をした。

>それともGitはバージョン管理ツールじゃないの?
誰がそんなバカなこと書いているんだ?
そう読めるなら病院行け。

ほんとバカだよな。

868 :デフォルトの名無しさん:2014/01/13(月) 01:39:40.67
アスペかな?

869 :デフォルトの名無しさん:2014/01/13(月) 01:42:43.97
Gitにはロック無いという前提の話をしているので貼れば、
gitにロックがあるということを説明すれば話は覆る。


gitにおいてロックとは、許可がない限りマージできないということ。
これがロックと同等になる。

マージする時に、マージ担当者に「今からマージします」って言って
マージ担当者に他のマージを待ってもらうようにすればいいだけ。

subversionでもロックを掛けられるからといって
勝手にマージしたらダメだろう?
どっちみちマージ担当者に許可を得ているのだから同じことである。

870 :デフォルトの名無しさん:2014/01/13(月) 01:43:14.25
いやちょっとまてよお前話の流れ掴めてないだろ
まじでお前に反論してるのが一人だと思ってるのか?

おれ
>誰がどこを直すかのミスを減らすためにロックを使うって、
>みんながコーディング終わるまでずっとロック取り続けたりするのか?

おまえ
>はぁ?
>お前本当にバージョン管理システム使ったことあるの?
>とんだけ的外れな質問だよ?

おれ
>Gitにはロック無いんだからここでそんなこと言われてもねえ
>それともGitはバージョン管理ツールじゃないの?

おまえ
>>867

871 :デフォルトの名無しさん:2014/01/13(月) 01:47:10.48
>>869
>gitにおいてロックとは、許可がない限りマージできないということ。
>これがロックと同等になる。

だからさあ、それ自体は間違ってないって。

もうわざとやってるだろうけど、それで良い用途と、そういう作業が発生する「無駄」を避けたい
用途があるってだよ。

もう嫌になっちゃうな頭の悪い人に説明する徒労感って(笑)
いちど読み直してみなよ、流れを。

872 :デフォルトの名無しさん:2014/01/13(月) 01:49:41.19
流れって860の俺の書き込みからの、ってことね。
念の為。

873 :デフォルトの名無しさん:2014/01/13(月) 01:49:58.05
> >gitにおいてロックとは、許可がない限りマージできないということ。
> >これがロックと同等になる。
>
> だからさあ、それ自体は間違ってないって。

いやこれは全然違うだろw

874 :デフォルトの名無しさん:2014/01/13(月) 01:53:41.15
>>871
こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが

875 :デフォルトの名無しさん:2014/01/13(月) 01:54:55.69
ファイルのロックで修正箇所ミスを偶然検知できることを期待して
集中管理方式使うとか、さすがにアホすぎる

876 :デフォルトの名無しさん:2014/01/13(月) 01:57:17.72
>>871
Gitじゃなくてロックのない分散管理方式を否定したいなら
>>846 のとこへ行ってやってくれる?

877 :うちの子:2014/01/13(月) 01:58:25.22
否定したいわけじゃなくても>>846 のとこへ行ってやれ

878 :デフォルトの名無しさん:2014/01/13(月) 01:59:15.63
分散じゃないsvnだって、普通のソースコードの管理に関してはロック無しが推奨なんだがな

879 :デフォルトの名無しさん:2014/01/13(月) 01:59:33.15
上にもあったがGitが向いてない用途という話をされただけで、気が狂ったみたいなに真っ赤になって発狂する奴がいるんだな。
おまけに頭が悪くて、話も通じない。
勝手に曲解してはまともな反論したつもり(笑)
少しは恥を知れよ、まあ無理なんだろうが。

880 :デフォルトの名無しさん:2014/01/13(月) 02:01:21.29
noob

881 :デフォルトの名無しさん:2014/01/13(月) 02:01:40.61
大草原から来た土民の相手するのもうやめたら?

882 :デフォルトの名無しさん:2014/01/13(月) 02:02:14.44
まあGitに限らず信者ってそんなもん

883 :デフォルトの名無しさん:2014/01/13(月) 02:03:43.19
>>879
>>870は無視かよ。ロックの無いGitしか知らないおれに、ロックをどういう風に使ってるか教えてくれよ

884 :デフォルトの名無しさん:2014/01/13(月) 02:10:18.53
そいつスレ読んで知ってるふりしてるだけのバカだから聞くだけ無駄
どのみちGitが向いてないなら向いてる管理ツールのスレに行けば用は済む

885 :デフォルトの名無しさん:2014/01/13(月) 02:12:42.37
そういうことにしたいのですね

886 :デフォルトの名無しさん:2014/01/13(月) 02:14:32.97
ロックをどういう風に使ってるか説明しないならそういうことになっちゃうね

887 :デフォルトの名無しさん:2014/01/13(月) 02:25:21.45
>>885じゃないけど煽りを煽りと見抜けないお前らの純粋さに驚きだよ
9割が悪口のレスを律儀に相手するなんて

888 :デフォルトの名無しさん:2014/01/13(月) 02:26:39.18
             ,,.. -──‐- 、
         ,. ‐'"´::::::::::::::::::::::::::::::``‐、
       ,/:::::::::::::::::::::::::::::::::::::::::::::::::::::::\
     /:/ ̄'''7::r--'~l,;─--;:::::::::::::::::::::::::\
    /:::::/   /:/   ,    |::| ̄ ̄'``L::::::ヽ,
   /::::::::' -‐‐'::::'‐‐、/i__i|/:::|      ヾ::::::i
   /::::::::::::::::,、:::::::::::::::::::::::::::::::::::::'─'─'ヽ、  i:::::i,    よびましたか?
  i:::::::::::::::::://:::::::::::/i::::::::::::::::::::::::::::;;:::::::::::`'‐、|::::::i
  |:::::::::::::/ '-、-┬' |::::::::::|i::::l|:::::::::||:::::::::::::::::::::::::::|
  ヽ:::::::r'  .r''\ヽ、__ ̄ '  ̄ フ ̄ヾ::::::::::::::::::::::::::|
  ,:ヘ::::|   l ●\/  、‐''~,,.. -、'ヾ;:::::::::::::::::::::::|
/   ヽ|.  ´ ゝ,-‐'゙    `i'''"● l  i::::::::::::::::::::;!
.     |           ヽ、、'、  i:::::::::::::/
      i       、 ,    ` `    |:::::::/
      ヽ,     r-、          r‐''~ \
       丶,    i''‐i        /     \
        \  | ,!      , -''~       \
.          \ `''  ,,.. -'''~
             ̄ ̄

889 :デフォルトの名無しさん:2014/01/13(月) 02:26:56.15
そういうことにしたいのですね

890 :デフォルトの名無しさん:2014/01/13(月) 02:27:24.63
>>874
>こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが
むしろスレの切り貼りで分かるレベルのことを理解できないバカがいるのが不思議なんだが(笑)

891 :デフォルトの名無しさん:2014/01/13(月) 02:29:17.80
>上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
>世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。

Gitに「開発思想」があるとしたらこれだよな
Githubはまた異なるが

892 :デフォルトの名無しさん:2014/01/13(月) 02:41:43.72
pushしてきたのをどれを採用するか決めるのって
どうやって実現すればいいの?
これすごくやりたいんだけどやり方が全然わからない

893 :デフォルトの名無しさん:2014/01/13(月) 02:48:12.53
マージ

タイミングと内容的に教えてくんのふりした荒らしにしか見えんな

894 :デフォルトの名無しさん:2014/01/13(月) 02:52:57.77
>>860
バージョン管理システムっていうのは、修正の履歴を残すことと、過去に逆戻って取り出せる事が必要なんだよ。

だから、バージョン管理システムとしては本来ファイルをロックするという行為は必要ない。
その点は理解するべき。
まして、gitの場合、最新のものに対して以外はコミットできないのだから、なんでファイルをロックできなきゃいけないのか理解できない。

複数の人が修正すればコンフリクトは発生するものだから、組織の中で修正担当を決めるのはコンフリクトを運用回避しているだけだよ。
バージョン管理の仕組みとは次元が違う。

895 :デフォルトの名無しさん:2014/01/13(月) 03:01:02.19
>>892
修正したコミットをどこかに置いてもらって、
それをチェックしてからマージするなり突っ返すなりするだけ

コミットをどこに置くかは、クローンした別のリポジトリを用意してそこにpushするのが一般的だけど、
同じレポジトリの別のブランチでもいい

別のリポジトリならpullする必要があるからpullリクエストだね
同じレポジトリの場合はpullする必要ないけど、やってることはあまり変わらん

896 :デフォルトの名無しさん:2014/01/13(月) 03:12:54.70
>>892
君が独裁者となり、どれを採用するか却下するか決めれば良い。

897 :デフォルトの名無しさん:2014/01/13(月) 03:39:15.82
subversionなら独裁者なんていないから
誰でも好き勝手コードをコミットできるのに。

898 :デフォルトの名無しさん:2014/01/13(月) 03:52:01.41
>>895
A→B でpushしてもらって、それを見てパッチを作って
Cに適用してC→D にpushするってこと?

899 :デフォルトの名無しさん:2014/01/13(月) 08:06:46.44
>>897
いや、それこそ崩壊せんかw

900 :デフォルトの名無しさん:2014/01/13(月) 09:48:03.23
うわー、何か伸びとるなー
話が噛み合ってないように見えるけど

901 :デフォルトの名無しさん:2014/01/13(月) 10:07:53.06
宗教戦争は神が命じなくても起きるものなのです

902 :デフォルトの名無しさん:2014/01/13(月) 11:15:27.64
独裁スイッチ

903 :デフォルトの名無しさん:2014/01/13(月) 11:27:18.03
>>898
Git使ってるのにパッチ作って適用する必要とかないだろ
どこかにpushしてもらったら、それを自分のローカルなレポジトリの適当なブランチに
pullして内容を確認すればいい
問題なければ正式なブランチにマージして公開レポジトリにpushだな

904 :デフォルトの名無しさん:2014/01/13(月) 11:41:04.55
>>855
MSがVSS使ってないっていう笑い話があったな。

905 :デフォルトの名無しさん:2014/01/13(月) 11:52:47.31
また根拠のない中傷か

906 :デフォルトの名無しさん:2014/01/13(月) 12:33:54.27
そもそもVSSが酷すぎるからMSはTFSを作ったんだろ

907 :デフォルトの名無しさん:2014/01/13(月) 13:06:03.71
一方Bitkeeperが只で使えなくなったと言ってライナスはGitを作った

908 :デフォルトの名無しさん:2014/01/13(月) 13:22:06.92
OSS界隈でGitが使われる政治的理由は、Google臭やMicrosoft臭、IBM臭がしないから
あのコミュニティはソフトウェア技術者になれなかったものたちの怨恨で膨れ上がっている
何をするにもベストとは言い難い選択肢にも関わらず、それが使われ続けるには、
スタートアップって場所に集まるような連中が何らかのコンプレックス持ちで、
TFSとかBitkeeperみたいなプロフェッショナルたちの使う道具に反感を持ってんだよ。
何者にも成れなかった連中は何かに向いた道具なんて使いたくなかった。
親世代たちへの謀反で反逆者たちの集まり。特にその劣等感の強いのがGitコミュニティ。

909 :デフォルトの名無しさん:2014/01/13(月) 13:32:30.58
>>908
アホはRubyスレに帰れ

278 名前:デフォルトの名無しさん[sage] 投稿日:2014/01/12(日) 14:55:32.49
>>268
違うね。そんなものは所詮、日本国内だけでの話。
世界中でRubyが使われる政治的理由は、Google臭やMicrosoft臭、IBM臭がしないから
あのコミュニティはソフトウェア技術者になれなかったものたちの怨恨で膨れ上がっている
何をするにもベストとは言い難い選択肢にも関わらず、それが使われ続けるには、
スタートアップって場所に集まるような連中が何らかのコンプレックス持ちで、
c#とかjavaみたいなプロフェッショナルたちの使う道具に反感を持ってんだよ。
何者にも成れなかった連中は何かに向いた道具なんて使いたくなかった。
親世代たちへの謀反で反逆者たちの集まり。特にその劣等感の強いのがRubyコミュニティ。

910 :デフォルトの名無しさん:2014/01/13(月) 13:33:28.15
>>908
なにか凄い怨念を感じます!!

911 :デフォルトの名無しさん:2014/01/13(月) 13:38:54.51
さすがスレ監視員の仕事は早いなw

912 :うちの子:2014/01/13(月) 13:43:10.25
>>885 糞壁乙

913 :デフォルトの名無しさん:2014/01/13(月) 14:03:31.14
>>858
MSSなんて初めて聞いたわwww

914 :デフォルトの名無しさん:2014/01/13(月) 14:07:08.56
>>811
なるほど、そう言う運用なら管理対象はほぼテキストだけだからロックとかはなくても大丈夫そうですね。

>>861
> どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ

なんでそんな発想になるの?
ロックで取り合いするんじゃなくて、予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。

915 :デフォルトの名無しさん:2014/01/13(月) 14:27:35.27
上でも書いてる人がいるけど
あらかじめ決めた人以外が間違って編集しないようにする目的には、ロックはあまり役に立たなくない?
あらかじめ決めた人がロックして編集はじめる前に、他の人が間違えて編集してコミット終えちゃったら意味ないよね?
ほんとにそんな機能が必要なら、ファイル毎にアクセス権を指定するとかの仕組みを用意した方がいいと思うんだけど

916 :デフォルトの名無しさん:2014/01/13(月) 14:43:15.16
>>915
ちょっと何を言ってるのかわからない

ファイル毎のアクセス権を一時的に指定する仕組みがロックでしょ

917 :デフォルトの名無しさん:2014/01/13(月) 15:00:39.60
ブランチに権限設定するだけで十分じゃないすかね
プルリクエストならチェックしてからしか編集されないからロックもいらないし

918 :デフォルトの名無しさん:2014/01/13(月) 15:06:18.53
>>916
普通、ロックは誰でも取得できるよね?間違えて取得してしまう可能性もあるわけだ。
アクセス権は普通は管理者がまとめて設定する。

919 :デフォルトの名無しさん:2014/01/13(月) 15:11:18.54
>>916
Aさんがfoo.cを担当することになりました。
Bさんはfoe.cを担当することになりました。
Aさんは他に作業があったのでまだfoo.cをロックしてませんでした。
Bさんは間違えてfoo.cをロックしてコミットして作業を終えてロックを開放しました。

920 :デフォルトの名無しさん:2014/01/13(月) 15:20:26.34
それ非同期で分業できてます?

921 :デフォルトの名無しさん:2014/01/13(月) 15:27:27.64
Aさんがfoo.cのa関数を担当することになりました。
Bさんがfoo.cをb関数を担当することになりました。

Aさんはa関数を作るためにfoo.cをロックします。
ロックされているのでBさんはb関数を作れません

こういうことになると思うけど、これどうやって解決するの?

922 :デフォルトの名無しさん:2014/01/13(月) 15:31:52.66
>>920
非同期に分業するとしても全員が完全に同時に作業を始めるわけじゃないし、
複数の案件を抱えてれば一時的に作業を遅らせることもあるわけよ

923 :デフォルトの名無しさん:2014/01/13(月) 15:36:17.51
>>922
遅らせる”ことも” あるわけってことは
遅らせないこともあるんだろ?

同時に作業を始められて、その方が良い場合はどうするのさ?

924 :デフォルトの名無しさん:2014/01/13(月) 15:42:30.91
>>922
つまり並行して作業しないと書いてるように見えるが
どのみちリポジトリ落として作業してたらよそでロックされても関係ないよね?

925 :デフォルトの名無しさん:2014/01/13(月) 15:44:40.21
>>923
同時に始めることもあれば、同時に始めないこともある。
各個人が行うロックは、同時に始めたときしか間違って編集するのを防げないから、
そんな中途半端な方式に頼るのをやめてファイル単位にアクセス権を設定した方がいいですね。

926 :デフォルトの名無しさん:2014/01/13(月) 15:46:47.03
>>924
並行して作業が行われるかどうかは確定できないと書いてる。

927 :うちの子:2014/01/13(月) 15:47:47.64
馬鹿には無理

928 :デフォルトの名無しさん:2014/01/13(月) 15:53:40.62
マージベースになったSVNでもオプションでロックが用意されてるのは
マージが難しいファイルの同時編集を避ける目的であって、
ファイルを間違えて編集するのを防止するためとかどっかズレてるんだよ
ファイル間違えて編集しちまったら諦めてリジェクトされてやり直せ

929 :デフォルトの名無しさん:2014/01/13(月) 15:54:25.13
>>925
そのロックもうGitの役割じゃないというかGitの機能を損ねてると思う
Gitじゃなくて自分がやりたい開発管理でしょ

930 :デフォルトの名無しさん:2014/01/13(月) 15:56:20.78
つまりさ、ロックをすると
同じファイルを平行して作業できないってことだよね?

それって不便だと思うけど。

931 :デフォルトの名無しさん:2014/01/13(月) 15:59:21.82
>>919
Aさんが作業開始する前にBさんがロックを解放したなら何の問題ないし、
そうでないなら、Aさんがロックできないことに気付くので、Bさんに直接間違いを指摘すればいい。

>>921
二つのやり方がある。

1、ロックを使わない。後でマージする。

2、同一ファイルに書かれているということは、関数同士に関連があり、
マージで不具合が発生する可能性が高いので、
Aさんが作業完了した後にBさんが作業を開始する。
もし、関連がないなら別のファイルに分離し、それぞれのファイルをロックして同時に作業する。

ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。

932 :デフォルトの名無しさん:2014/01/13(月) 16:07:43.00
>>931
問題あることになるだろう。
予め編集すると決めた人以外が間違って編集することを防げないんだから。
>>919>>915は、>>914のこれに対する書き込みだぞ?話の流れ読めてる?
>予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。

933 :デフォルトの名無しさん:2014/01/13(月) 16:13:42.03
「予め編集すると決める」 -> 「ロックを取る」ことなんだよ
>>931は日本語不自由なんだからそのぐらい察してやれw

>>860のこの書き込みからはズレちゃってるが
「大手だと誰がどこを直すのか決めてからやるわけで(そのミスを減らすためにバージョン管理ソフトを使うわけで)、
ファイルのロックやロールバックがきちんと行われる方が大事なんですな。」
こいつは話の流れ無視して好きなこと書き込んでるだけだからしょうが無い

934 :デフォルトの名無しさん:2014/01/13(月) 16:18:33.41
常にサーバーにあるオリジナルのリポジトリを参照(してロック状態を確認)しながらしか作業できないGit
退化しすぎ
コンフリクトの発生は間違えて指示出した奴と間違えて作業した奴が悪いのであってロックがないせいじゃない

935 :デフォルトの名無しさん:2014/01/13(月) 16:19:14.19
緊急のバグフィックス入れたいが、開発者がロック取りっぱなしだから入れられない。しょうがないからパッチファイルにしといて後でコミットするか。あー変更されてるからマージしなきゃ。と、gitがしてくれることを手動でやることになりそう。

936 :デフォルトの名無しさん:2014/01/13(月) 16:19:20.36
>>931
> ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。

じゃあ、ロック使わないでやればいいんじゃね?

ロックされていても出来る方法をあなたが書いたでしょ?
> 1、ロックを使わない。後でマージする。

常にこれをやれば、ロックは不要だよね?

937 :デフォルトの名無しさん:2014/01/13(月) 16:22:56.27
排他制御であるロックと、アクセス制御は違いますよ、
っていう当たり前の事をわざわざ主張してたの?

そりゃ想定外だわ。

vcsの話なんだから、
「予め編集すると決める」はアクセス制御目的ではなく、排他制御目的で言ってるのかと思ってたよ。

938 :デフォルトの名無しさん:2014/01/13(月) 16:25:07.22
後でマージすればいいだけなんだから
排他制御する必要はないと思うけどな。

939 :デフォルトの名無しさん:2014/01/13(月) 16:26:37.73
まあ普通そうだけど話の発端は>>860だからね

940 :デフォルトの名無しさん:2014/01/13(月) 16:28:07.09
担当者と常に連絡が付くならロックでもいいんだよね。

普段はロックでできるだけマージを排除しつつ、
緊急時はロックを解除してもらって、後からマージ。
同時にリスケジュールなどの調整も行う。

問題は担当者が不在の時。
それを考えると、最初からロックしなくていいか・・・って話になる。

941 :デフォルトの名無しさん:2014/01/13(月) 16:35:09.91
昔のVSS思い出すなあ

942 :デフォルトの名無しさん:2014/01/13(月) 16:44:00.04
もう当分ロックの話題は見たくないわ

943 :デフォルトの名無しさん:2014/01/13(月) 16:49:30.33
「ロック」・・・そんな事はする必要がねーんだ。
なぜなら、オレや、オレたちの仲間は、
ロックするファイルがわかった時には!
実際に編集しちまって、もう既に終わってるからだ!
だから使った事がねェーッ。

「コミットする」なら使ってもいいッ!

944 :デフォルトの名無しさん:2014/01/13(月) 17:12:52.23
>>943
なんで大事な最後で噛むんだよ兄貴

945 :デフォルトの名無しさん:2014/01/13(月) 17:14:13.11
じゃあ、次はキーワード展開の話題に移ります^^

946 :デフォルトの名無しさん:2014/01/13(月) 17:22:34.86
またエライ伸びててビビったぞ

なんの脈絡も無くね?
>キーワード展開

947 :デフォルトの名無しさん:2014/01/13(月) 18:13:55.77
>>946
釣りネタに釣られる阿呆に対する皮肉じゃないの

その次はタイムスタンプの話題

948 :デフォルトの名無しさん:2014/01/13(月) 18:29:09.38
実行属性は保存されるのにタイムスタンプは保存されない
ってのはたしかに片手落ちな感じはするな・・・
これってgit界では定番の問題なの?

949 :デフォルトの名無しさん:2014/01/13(月) 18:34:03.18
MSはWindowsも使ってないんじゃないかな

950 :デフォルトの名無しさん:2014/01/13(月) 18:38:52.85
タイムスタンプはmakeが使うわけで、意図的にやってると思うが。

951 :デフォルトの名無しさん:2014/01/13(月) 18:39:16.15
>>948
タイムスタンプを見てビルドする前提のソースコードを管理する仕組みだから、
タイムスタンプが維持されてブランチ切り替え後のビルドがうまく走らないのは問題がある

952 :デフォルトの名無しさん:2014/01/13(月) 18:40:57.13
なるほど。gitはタイムスタンプの問題点を
解決しているわけで、これは進化なのか。

953 :デフォルトの名無しさん:2014/01/13(月) 18:45:23.97
進化というか、UNIXで動くソース管理ツールは昔からこうじゃないの?

954 :デフォルトの名無しさん:2014/01/13(月) 19:01:24.39
>>951
それは強制される話ではない気がする
タイムスタンプを保持するかしないかは選択できるべきだよね

955 :デフォルトの名無しさん:2014/01/13(月) 19:08:28.64
>>954
ソースコード管理のために必要最小限の機能だけを用意するのがGitのポリシー
実装が簡単になるし、関連ツールなんかも作りやすい

956 :デフォルトの名無しさん:2014/01/13(月) 19:15:23.28
構造をシンプルにしておくことは大切だよ
以下、戦いに敗れたBazの恨み節

Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
http://cpplover.blogspot.jp/2014/01/bazaar-ng-7.html

>ほとんどのGitユーザーはファイルフォーマットの詳細を知っているし、たとえ知らないにせよ一日で学べる。
>Gitのバグをソースファイル上で見つけるのは、様々なレイヤーが関係するBazaarを理解するよりも、
>だいぶ簡単だ。新し目のBazaarのファイルフォーマットは、たいていドキュメント化されていない。
>bzrの世界にいて何年も経た後でも、いまだに筆者は、gitのpack実装のバグを修正するほうが、
>Bazaarのバグを修正するより簡単だと感じる。

957 :デフォルトの名無しさん:2014/01/13(月) 19:15:32.78
>>955
>必要最小限の機能だけを用意
そんなポリシーあったのか・・・ 知らなかった

diff周りとかゴチャゴチャとどんどん機能増量してっから
わりと行き当りばったりな思想だと思ってた。

958 :デフォルトの名無しさん:2014/01/13(月) 19:20:14.72
てゆーか タイムスタンプを残す ってのはそんなに大変なことなの?
シンプルイズベストを理由に拒むだけの複雑さがあるとは思いにくい

簡単な実装でシンプルに実現できると思うけど、やろうとしたら
案外と難しいもんなんかな

959 :デフォルトの名無しさん:2014/01/13(月) 19:22:52.42
馬鹿には無理

960 :デフォルトの名無しさん:2014/01/13(月) 19:24:34.22
>>957
diffなんて枝葉部分はいいんだよ
リポジトリの構造なんかに関連するコアの部分に余分なメタデータとか肥大化させるなってことだ

diffはある意味コアな部分をシンプルに保つために機能が肥大化されたりしてるからな
リネーム関連の追跡とか

961 :デフォルトの名無しさん:2014/01/13(月) 19:29:31.88
ファイルの属性ってメタデータとして別途保持してんの?

962 :デフォルトの名無しさん:2014/01/13(月) 19:30:08.46
>>958
少なくともリポジトリの構造が変わるのに対応する必要がある
関連ツールは新旧リポジトリを見分けて対応する必要がでてくるな
>>956とか読んでみてよ。barはそういうのを吸収するために分厚いレイヤーをもった
複雑な構造をしててそれが開発コミュニティーにとっては障害になってたそうだ

963 :デフォルトの名無しさん:2014/01/13(月) 19:47:19.05
>>961
ファイルの属性に関しては、ディクレトリの情報を保存するtreeオブジェクトの中に
「ノードの型(実行属性とか含む100644みたいなの)、実体を指すハッシュ、ファイル名」の三つの情報を保存してて、
実体のほうでヘッダにファイルサイズが保存されてるだけかな
スゲー簡単

964 :デフォルトの名無しさん:2014/01/13(月) 20:07:54.72
内容のほうにファイル名がぶら下がってるのはgitの特徴ではなかろうか。

965 :デフォルトの名無しさん:2014/01/13(月) 20:37:02.84
ファイル名変えるとgit追ってくれなくないか?

966 :デフォルトの名無しさん:2014/01/13(月) 20:40:23.65
>>940
連絡つくのならそれこそ、ロックはいらないでしょ。
当事者間でちゃんと調整しようよ。

ロックにしろ、タイムスタンプ保持にしろ本来バージョン管理には必要ない機能だから無いことを当然として、運用を考えるべき。

それにしても、ここたまに爆発するなw

967 :デフォルトの名無しさん:2014/01/13(月) 21:07:25.21
>>965
--find-renames
完璧に追跡してくれるわけではないが

968 :デフォルトの名無しさん:2014/01/13(月) 21:19:58.26
git mv で変えれば追ってくれるとかじゃないのか?

969 :デフォルトの名無しさん:2014/01/13(月) 21:22:59.24
>>963-964
ファイル本体の方には中身に関連する情報以外の属性は含んでないんだよな
だから中身が同じなら別のファイルでも同じファイルで管理してる

$ ls -l
total 8
-rw-r--r-- 1 root root 6 2014-01-13 21:20 bar.txt
-rw-r--r-- 1 root root 6 2014-01-13 21:12 foo.txt
$ cat foo.txt
Hello
$ cat bar.txt
Hello
$ git ls-tree HEAD
100644 blob e965047ad7c57865823c7d992b1d046ea66edf78 bar.txt
100644 blob e965047ad7c57865823c7d992b1d046ea66edf78 foo.txt

ファイルの実体を指すハッシュが一致

970 :デフォルトの名無しさん:2014/01/13(月) 21:25:19.35
>>968
関係無い
git mvしてもリネームしたっていう情報が保存されるわけじゃない
diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる
logなんかにもおなじように推測する機能がある

971 :デフォルトの名無しさん:2014/01/14(火) 00:13:51.57
そもそも当てにならないマシン毎の時計を元にしたタイムスタンプや、タイムゾーンを
超えた地域とも共同開発するのがあたりまえのGitなんだから、そんなものを重視する方が
おかしい。
あくまでファイルの内容そのものだけを判断の基準にするのが優れた典なのだから。
昨日から長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込みして
るのはプログラマになれなかったアホが板で暴れてるようだな。他のスレまでコピペして
ご苦労なことだ。自演してもすぐわかるのにな。

972 :デフォルトの名無しさん:2014/01/14(火) 01:38:33.21
>>971
>長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込み

973 :デフォルトの名無しさん:2014/01/14(火) 02:11:44.12
バカはすぐ文系とかレッテル貼りたがるよな(笑)

974 :デフォルトの名無しさん:2014/01/14(火) 03:10:26.47
svnだとファイル移動する時にsvn mvしないと追跡しないけど、
gitだと別にgit mvしなくても、普通にmvなどで名前変えるだけで
いいから便利なんだよな。
通常のファイル処理してるだけなのに、特殊なコマンド使わなくていいからね。

975 :デフォルトの名無しさん:2014/01/14(火) 10:57:43.15
mvで名前変えるとgit rmとgit addしないといけないから面倒だろ?

976 :デフォルトの名無しさん:2014/01/14(火) 13:50:43.75
>>966
> 無いことを当然として、運用を考えるべき。

で、君のところはバイナリファイル (要するにマージできないファイル) の管理はどうしてるの?
git 以外を使ってるとか?

977 :デフォルトの名無しさん:2014/01/14(火) 13:59:15.82
>>970
> diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる

必要最小限の機能とかいいながらこんな余計な機能をつける奴ってバカじゃね?

978 :デフォルトの名無しさん:2014/01/14(火) 14:11:28.69
>>977
だからコアな部分の機能を必要最小限と言ってるだろ

リネームに関する機能をコアな部分に組み込めば、コアだけじゃなく関連するいろいろな部分に影響がでる
diffとか一部コマンドだけで対応できれば他はシンプルななままに保てる

979 :デフォルトの名無しさん:2014/01/14(火) 14:21:24.10
>>976
うちは、画像とかは担当決まってるんで複数の人が同じものを編集することは無いし、
ドキュメントはテキストベースのHTMLやらMarkdownで管理してるんでマージ可能なので、
特に問題にならない

980 :デフォルトの名無しさん:2014/01/14(火) 14:29:59.26
どうしてもエクセルファイルで管理したいって部署があって
そこはエクセルファイル自体はファイル共有してるのをみんなで触って
担当者が定期的にそのファイルをコミットしてるらしい

981 :デフォルトの名無しさん:2014/01/14(火) 18:41:21.98
それテキストと違って差分が分かるわけじゃないから、Gitで管理する意味ないよね。
チェクイン、チェックアウトでやった方が無駄な作業が発生しないのでは?

982 :デフォルトの名無しさん:2014/01/14(火) 18:47:45.48
GitであることよりわかりやすいGUIで版を管理できることがニーズに合ったんじゃないの

983 :デフォルトの名無しさん:2014/01/14(火) 19:25:40.45
progitというのを6章まで読んだが
gitって難しそうだな(vcs自体が俺にとっては初めてでもあるが)
末端開発者は実に気楽だがメンテナというマージ担当者の負担が重そうだ

984 :デフォルトの名無しさん:2014/01/14(火) 20:04:53.26
>>983
負担になるようなマージ処理が発生するようなコンフリクトがあるときは
末端にリベースしてもらうから問題無い
計画的に開発してるならそういうコンフリクトはほとんど起こらないけどね

985 :デフォルトの名無しさん:2014/01/14(火) 20:09:21.19
コンフリクトってテキスト的なコンフリクトの検出だけでしょgitが出来るのって
コード上の整合性での問題は検出してくれない

986 :デフォルトの名無しさん:2014/01/14(火) 20:18:59.30
そんな便利なものを検出するのはVCSだけじゃ不可能だわな
ファイルを跨ってプログラムの処理がコンフリクトしてる可能性もあるわけだし
だからコミットしたら自動的にテストが走るような仕組みを作るわけで
Gitの関連ツールの作りやすさはその辺にも役立つ

987 :デフォルトの名無しさん:2014/01/14(火) 20:24:52.78
ファイルロックが必要だ!

988 :デフォルトの名無しさん:2014/01/14(火) 21:08:06.94
テストツール使え

989 :デフォルトの名無しさん:2014/01/14(火) 21:10:03.76
次スレよろ

990 :デフォルトの名無しさん:2014/01/14(火) 21:18:23.73
立てたよ

Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/

991 :デフォルトの名無しさん:2014/01/15(水) 00:45:23.04
Windowsで使うのに、どのツールを使うのが一番?
日本語メニューを希望

992 :デフォルトの名無しさん:2014/01/15(水) 00:46:50.10
Eclipseに入ってるEGitは結構お気に入り

993 :デフォルトの名無しさん:2014/01/15(水) 00:59:25.85
スタッシュとかフェッチとかいうカタカナメニューが並んでるツールとか
使い方を覚えられる気がしない

994 :デフォルトの名無しさん:2014/01/15(水) 01:10:57.14
埋め

995 :デフォルトの名無しさん:2014/01/15(水) 01:11:28.71
埋め

996 :デフォルトの名無しさん:2014/01/15(水) 01:19:45.62
埋め-

997 :デフォルトの名無しさん:2014/01/15(水) 01:20:44.44
埋め

998 :デフォルトの名無しさん:2014/01/15(水) 01:23:19.03
働けど働けどなお我が暮らし楽にならざりGit手を見る

999 :デフォルトの名無しさん:2014/01/15(水) 01:23:38.61
埋め

1000 :デフォルトの名無しさん:2014/01/15(水) 01:37:18.06
1000

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

222 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)