トップページ⇒tech
1001コメント292KB

Git 7

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん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/
0002デフォルトの名無しさん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/
0003デフォルトの名無しさん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
0004デフォルトの名無しさん2013/10/16(水) 23:41:50.81
>>1-3 乙

前スレ984以降何かあった？
0005デフォルトの名無しさん2013/10/16(水) 23:48:41.61
なんもなかったと思う
0006デフォルトの名無しさん2013/10/17(木) 15:29:47.88
プルリクエストにさdiffしてpatchした結果を送るのはありですあｋ？
0007デフォルトの名無しさん2013/10/17(木) 18:35:24.25
ubuntu 12.4 に gitlab 入れてローカル環境ではうまくいきました。
インターネット側からも自分の gitlab 鯖につなげられるようにしたいのですが
とりあえず 22/tcp を開いておくだけで大丈夫ですか

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

それくらい？？
0008デフォルトの名無しさん2013/10/17(木) 19:06:40.73
>>7
sshdのポート変更、パスワード認証の禁止。
0009デフォルトの名無しさん2013/10/17(木) 23:57:29.21
>>7
gitlab使ったことないけど、sshに限った話なら
公開するならポート変更しなくていい
そのかわりパスワード認証じゃなくて公開鍵認証にしないと危ない
0010デフォルトの名無しさん2013/10/18(金) 13:14:53.92
コンフリクトが発生しないよう予防法を教えてください
0011デフォルトの名無しさん2013/10/18(金) 13:21:30.07
常にFast-forwardな状態でマージする
0012デフォルトの名無しさん2013/10/18(金) 14:40:56.02
パスワード認証を禁止にすると、なぜセキュリティが上がるのですか？
そのマシンを勝手に使われたり、乗っ取られたら結局終わりですよね。

勝手に使われたり、乗っ取られないのが前提なら安全と言うことですか？
0013デフォルトの名無しさん2013/10/18(金) 15:29:01.72
簡単に言うと、強度が強くなる。
後はどうしたいかによるので自分で判断してください。
0014デフォルトの名無しさん2013/10/18(金) 16:09:33.18
>>12
SSHのパスワード認証は攻撃多いからね
ユーザーが1人でも弱いパスワードを設定したらあっという間に入られて、
そのマシンを踏み台にして新たな攻撃が始まるよ
ガチガチにしろと言うより公開鍵認証に限定するほうが簡単で確実
0015デフォルトの名無しさん2013/10/18(金) 18:53:09.12
SSHで鍵にパスフレーズつかえばいいんじゃないの
0016デフォルトの名無しさん2013/10/18(金) 20:53:47.40
それは別の問題ではないかと
0017デフォルトの名無しさん2013/10/18(金) 23:40:59.49
>>12
端末に侵入されたら、キーロガーとかでパスワードも盗まれるでしょうし、セッションジャックもある。終わってる。
入られない前提で困るのはサーバにアクセスされ続けること。
ブルートフォースでは、鍵だと相手にも強度が伝わるので諦めてくれるが、パスワードだと弱いかもなので責められ続ける。パスワードだと当然辞書も来る。
あと管理が楽。
0018デフォルトの名無しさん2013/10/19(土) 00:54:45.55
>>11
なんか2.0からはFFがデフォルトでなんたらかんたらで
.gitconfigに
[merge]
ff false
って書いてるんですがコレで大丈夫ですか？
0019デフォルトの名無しさん2013/10/19(土) 08:48:48.68
認証方式としては鍵認証の方が強力だけど
パスフレーズの無いsshキーファイルを参照されるとそれだけでアウトだからな
古い脆弱性のあるsshエージェント使ってる人も多いし
gitのようなバージョン管理の為だけにshellを解放するのが良くないんだろうな
面倒くさいからssh使ってるだけで
0020デフォルトの名無しさん2013/10/19(土) 09:35:12.93
>>18
それはFF状態でも非FFマージをデフォルトにする設定で、
コンフリクトとは関係ない
0021デフォルトの名無しさん2013/10/19(土) 09:37:15.06
そもそも秘密鍵が他人に使われない前提だからな
俺もパス入力あってもいいと思うけど、キーロガー仕組まれること考えたら断言できるほど自信ない
キーロガー仕組まれる可能性とログイン状態で別の人にPC使われる可能性どっちが高いんだろうね

あと、gitlabからshellにアクセスできるなら、それはgitlabの脆弱性だよ
0022デフォルトの名無しさん2013/10/19(土) 09:52:41.89
キーロガー仕掛けられてたら
秘密鍵も参照されちゃうだろうしパスフレーズも取られちゃうだろうから
公開鍵認証使っててもダメじゃん
0023デフォルトの名無しさん2013/10/19(土) 11:16:49.82
>>12
あまり引きずる話でもないけど
パスワード認証を許容すれば、関係ない端末からもブルートフォースが成立してしまう。

公開鍵認証のみにしておけば、パスワード+秘密鍵になるから、その分安全になる。
ノンパスワードの鍵作成は止めましょう。
あれは、バッチシステム用です。
0024デフォルトの名無しさん2013/10/19(土) 11:27:07.26
この話もうちょっと続けたい・・
0025デフォルトの名無しさん2013/10/19(土) 11:29:04.86
やっぱいいや
0026デフォルトの名無しさん2013/10/19(土) 11:43:36.13
100％安全でないなら
意味が無いじゃないですか！
0027デフォルトの名無しさん2013/10/19(土) 12:15:44.55
sshd側で特定のコマンドしかできないようにするのは割と簡単だった気がする。他のコマンドも要求したりしてんのかなぁ。
0028デフォルトの名無しさん2013/10/19(土) 12:18:56.14
>>26
100%安全だと所有者も使えないだろうから意味がない。100%は有り得ない。
0029デフォルトの名無しさん2013/10/19(土) 16:34:27.14
この世に100%なんて存在しないから全て意味がないな
0030デフォルトの名無しさん2013/10/19(土) 23:04:37.06
100%勇気
00317102013/10/19(土) 23:25:18.25
>>29
> この世に100%なんて存在しない

その確率は何％なの？
0032デフォルトの名無しさん2013/10/20(日) 05:19:41.96
頑張るしかないか
0033デフォルトの名無しさん2013/10/20(日) 14:21:28.25
最近Gitを使い始めたのですが質問です
以前のコミットに戻した後，コミットを戻す前の状態に戻すことは出来ないという認識でいいのでしょうか？
0034デフォルトの名無しさん2013/10/20(日) 14:38:18.93
>>33
戻す事はできるという認識に改めてください。
0035デフォルトの名無しさん2013/10/20(日) 15:04:59.36
コミットのキャンセルのキャンセル？
0036デフォルトの名無しさん2013/10/20(日) 15:21:03.72
>>34
できるんですか！
調べ方が悪かったみたいです
もうちょっと調べてみます

>>35
そうです
コミットのキャンセルのキャンセルです
0037デフォルトの名無しさん2013/10/20(日) 16:48:39.06
git reset ORIG_HEAD とか git reflog とか
0038デフォルトの名無しさん2013/10/21(月) 10:47:39.82
システムのデプロイにもgitコマンド使いたいんだけど
ここ落とし穴だから気をつけろ的な注意事項とかある？
0039デフォルトの名無しさん2013/10/23(水) 00:18:19.59
gitのことをわかりやすく書かれている本はありませんか？
0040デフォルトの名無しさん2013/10/23(水) 00:18:51.10
ありませんよ
0041デフォルトの名無しさん2013/10/23(水) 00:28:00.70
ドキュメント嫁　それで分からなければソース嫁
0042デフォルトの名無しさん2013/10/23(水) 02:35:44.61
どなたかご存知だったら教えていただきたいのですが
git svn clone時に空ディレクトリを無視せず取ってくる方法はないでしょうか？
git svn dcommit時に削除する方法は、ググったら出てきたのですが、、、
0043デフォルトの名無しさん2013/10/23(水) 07:24:17.37
ダミーで空のファイル入れておくってのはダメなんかね
0044デフォルトの名無しさん2013/10/23(水) 08:24:02.25
>>39
ググってわかりやすいと思ったサイトを印刷して
本のように綴じたら？
0045デフォルトの名無しさん2013/10/23(水) 09:48:11.53
>>43
ありがとうございます。

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

しかし、自分の管理していないモジュールだったら空のファイルといえど勝手にコミットできませんよね。
それに些細なことですが、空のファイルのコミットのためにだけはsvnを直接 使わないとダメなので少々面倒です。。
0046デフォルトの名無しさん2013/10/23(水) 10:31:11.42
>>39
これを気合で嫁
http://git-scm.com/book/ja
0047デフォルトの名無しさん2013/10/24(木) 02:03:12.36
すみません。ちょっと質問なのですが、
githubで管理してる自分のプロジェクトに、海外の方からpull requestが来ました。

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

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

一旦受け入れて、後でガッツリ自分で改変するか、
理由を述べて却下して、相手に実装しなおしてもらうか、
どんな対応が望ましいのか、参考までに聞かせてください。
海外でどんな対応するのが一般的なのかも知りたいです。
よろしくお願いします。
0048デフォルトの名無しさん2013/10/24(木) 04:49:30.60
こっちかな

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/
0049デフォルトの名無しさん2013/10/24(木) 13:00:03.35
gitでリポジトリを作成するとき、git initを使うんですか？

このコマンドだと自分のところが中央リポジトリになるように
思えるんですが、中央サーバに登録するには
どうしたらよいのでしょうか
0050デフォルトの名無しさん2013/10/24(木) 13:02:43.70
git clone
0051デフォルトの名無しさん2013/10/24(木) 13:10:01.12
>>49
サーバ側の実装による
リポジトリを作成する権限が与えられてるなら、何らかの案内があるはずだから
管理者に確認したらいいよ
0052デフォルトの名無しさん2013/10/24(木) 13:17:20.74
>>51
すみません、わたしが管理者です
どう案内すればいいかいま検証中なんです
0053デフォルトの名無しさん2013/10/24(木) 13:19:46.72
どこを中央サーバにするかって、単に運用方法の問題じゃないの？＠素人
0054デフォルトの名無しさん2013/10/24(木) 13:30:46.61
中央サーバと末端PCがあって、
末端PCでプロジェクトを作ったのでそれを中央サーバに
新規に登録したいのですが
cvsのinitに相当するコマンドはgitにはないので

プロジェクトのファイルを中央サーバにコピーして
中央サーバでgit initして、それを
末端PCで git clone する という動きでよいですか？
0055デフォルトの名無しさん2013/10/24(木) 13:48:24.27
>>54
よくない。空のリポジトリが作られるだけ
基本、サーバでgit initして、ローカルからpushだけど
実装によるから、それかかないと答えようがない
0056デフォルトの名無しさん2013/10/24(木) 13:50:34.29
実装というか構成か
0057デフォルトの名無しさん2013/10/24(木) 15:45:42.37
>>55
ローカルでinitしてサーバにpushすべきというのは理解しました

でも、最初の手順で空のリポジトリが作られるだけという
動きの理由がよくわかりません。
0058デフォルトの名無しさん2013/10/24(木) 15:46:31.03
あ、逆ですか
じゃあ理解できてませんすみません
0059デフォルトの名無しさん2013/10/24(木) 15:51:56.91
initで作られるのは空のリポジトリ
それをサーバに作った直後に、末端からcloneしたところで、エラーしか出ません
初回は必ず末端のローカルリポジトリから、コミット情報をpushしてやる必要があるのです

ということかと
0060デフォルトの名無しさん2013/10/24(木) 15:54:31.60
んで、pushをするためには、ネットワークの構成を知る必要があるってとこかな
0061デフォルトの名無しさん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するのがよい
0062デフォルトの名無しさん2013/10/24(木) 16:19:27.16
中央サーバにbare形式で目的のリポジトリを作るだけなら、
ファイルコピーしてgit initで普通のリポジトリ作って
それをgit clone --bareでbareリポジトリ化するなんて方法もある

でも後々の運用を考えると、空のbareリポジトリを用意してpushしたほうがいい
空のbareリポジトリを用意する方法は、gitを直接使う以外にいろいろある
0063デフォルトの名無しさん2013/10/24(木) 16:43:59.80
なぜ、構成を書いてくれないんだろう
もしかして、意味が伝わってないのか
0064デフォルトの名無しさん2013/10/24(木) 17:02:40.31
構成は何を書けばよいでしょうか

マシンなら中央と端末の2台構成です。
ディレクトリなら、とりあえずファイル10個程度、ディレクトリは無しです。
開発者は二人います。ひとりはわたしです。
0065デフォルトの名無しさん2013/10/24(木) 17:32:48.33
ああ、ごめん
>>61->>62はgit initの後にgit commit -am "～"でリポジトリにファイルを取り込まないとダメね
0066デフォルトの名無しさん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が必要
0067デフォルトの名無しさん2013/10/24(木) 18:43:05.48
>>64
中央サーバと呼んでるマシンのOSとサーバーソフトウェア次第で
その中央サーバにリポジトリを作る方法はいろいろあるってことだよ
君がそれを言わないから、Unixサーバのsshアカウントを利用する方法をみんな説明してる
0068デフォルトの名無しさん2013/10/24(木) 19:14:17.41
すみません
gitでリポジトリを作る方法はsshでログインして作るのしか
知らなかったので質問の意図がわかっていませんでした。
おっしゃるとおりsshアカウント経由で作業する予定です

gitにも、cvsのようなpserver的なものがあるのですか？
0069デフォルトの名無しさん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の説明もある
0070デフォルトの名無しさん2013/10/24(木) 19:54:12.62
リポジトリ自体はsshでログインして作るんだけどな
ていうか、ちょっとぐらいドキュメント読めよ
0071デフォルトの名無しさん2013/10/24(木) 20:16:58.73
Gitolite使えばsshでログインしてリポジトリ作る必要無いだろう
0072デフォルトの名無しさん2013/10/24(木) 21:01:48.59
すみませんどのページを見ても
同じことを同じやり方で解説してるところがほとんどなくて
その情報が古いのかモダンなのか間違ってるのか
とんとわからない状態でした
0073デフォルトの名無しさん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やサーバの知識が足りてないんだよ
0074デフォルトの名無しさん2013/10/24(木) 21:44:31.37
gitolite使っとけばいいだろ難しいこと考える必要ないぞ
生のsshアカウントでやるのは権限とか考えるといろいろ面倒
0075デフォルトの名無しさん2013/10/24(木) 22:08:37.59
俺もgitoliteが一番いいと思う
0076デフォルトの名無しさん2013/10/24(木) 22:11:08.35
gitoliteってウェブインターフェースあるの？
0077デフォルトの名無しさん2013/10/24(木) 22:31:26.71
>>76
gitoliteには組み込まれてないよ
だから、好きなウェブベースのgitクライアント使えばいいと思う
ていうか、普段使ってるgitクライアント使うのが一番いいと思うけど
turtoiseなり、sourcetreeなり
0078デフォルトの名無しさん2013/10/24(木) 22:37:17.99
>>76
gitlabおすすめ。

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

githubを使っている人や
逆に将来github使うって人には
いいとおもうよ。
0079デフォルトの名無しさん2013/10/24(木) 22:39:05.26
あれよ
gitoliteはリポジトリとユーザ管理をgitolite-adminっていうリポジトリで行うから
そのリポジトリを自分が使いたいクライアントで触ればいいだけ
0080デフォルトの名無しさん2013/10/24(木) 22:55:54.47
gitlabってRuby自前で2入れるように書いてあるのに、なんでわざわざインストールしてる1.8消させてんの？
自前でいれるなら、1.8消さなくてもgitlabが使えるように入れたらいいのに
0081デフォルトの名無しさん2013/10/24(木) 22:58:55.50
>>80
Linuxはディストリがたくさんあって、
すべての環境がどうなってるのか把握できないから。
Rubyが二つ入っていると、何が起きるかわからない。
0082デフォルトの名無しさん2013/10/24(木) 23:04:25.26
働けど働けどわがプロジェクト楽にならざり
Git手を見る
0083デフォルトの名無しさん2013/10/24(木) 23:15:01.41
gitlabは機能見る度に入れようかなって思うんだけど、要件にデータベースがあるのをみて結局やめてしまう
>>81
ruby2を/opt/ruby2とかに入れて、gitlabでruby実行する時はそこを使うようにもできると思うんだけど
0084デフォルトの名無しさん2013/10/24(木) 23:16:12.50
データーベースが要件で断念って
よくわからん。

ファイルと同様に極普通に使うものだろう？
0085デフォルトの名無しさん2013/10/24(木) 23:16:44.18
>>82
歌人さんかな？
0086デフォルトの名無しさん2013/10/24(木) 23:42:16.74
rubyのアプリは、rbenvやbundlerが良く出来てるせいで、
かなり無茶な感じに特定rubyの特定ライブラリに依存させたもの作って運用することができるけど、
OSのパッケージマネージャでそれらを管理するのは地獄の苦しみだな
0087デフォルトの名無しさん2013/10/24(木) 23:47:24.39
今はどの言語もなんたらenvシリーズと
パッケージマネージャ揃ってるだろう？
0088デフォルトの名無しさん2013/10/24(木) 23:49:22.02
(この流れは）アカン
0089デフォルトの名無しさん2013/10/24(木) 23:50:49.40
せめて、gitlabとかgitoliteの流れに戻ろう
0090デフォルトの名無しさん2013/10/24(木) 23:56:25.07
>>84
>ファイルと同様に極普通に使うものだろう？
そうかな
データベースサーバ新しく立ち上げるとか、既存のデータベースサーバにアクセスできるようにするとか
色々考えることあると思う
0091デフォルトの名無しさん2013/10/25(金) 11:15:13.64
全部 /usr/local/mygit などにインストールして、そこから起動すればいいだろう
0092デフォルトの名無しさん2013/10/25(金) 16:23:50.44
sqlite使えなくなってたのか。
0093デフォルトの名無しさん2013/10/26(土) 03:52:42.91
gitを使い始めたもので管理について質問させていただきます。
WebページやWebアプリを作っているのですが、サーバ側のリモートリポジトリはそのプロジェクト毎に作成し、使うものなのでしょうか？
それとも他に一括で管理する方法があるのでしょうか？
0094デフォルトの名無しさん2013/10/26(土) 08:53:18.88
Visual Studio 2013 Express で git が使えるようになったらしいので、今更ながら git 使い始めたんだけど、キーワード置換とかできないんだな...
0095デフォルトの名無しさん2013/10/26(土) 11:37:13.47
>>93
質問がよくわからん
ローカルもサーバも違いはないよ
0096デフォルトの名無しさん2013/10/26(土) 14:49:08.12
>>93
一つのリポジトリの中にディレクトリを掘って、
複数のプロジェクトのファイルを突っ込んでもいいし、
プロジェクトごとにリポジトリを作ってもいい。

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

わけておけばプロジェクトごとにリポジトリのcloneが可能だが、
そうでないなら全部cloneすることになる。
0097デフォルトの名無しさん2013/10/26(土) 17:44:41.64
プロジェクト間で共有されるファイルはsubmoduleにしたほうがいいのでは？
0098デフォルトの名無しさん2013/10/26(土) 18:48:46.48
それ、サーバ、ローカル関係なくない？

>一括で管理する方法があるのでしょうか？
って聞いてるから、管理方法をしりたいんじゃなかろうか。。
0099デフォルトの名無しさん2013/10/26(土) 19:32:00.07
>>96
ありがとうございます。
プロジェクトごとに分けることにします。
0100デフォルトの名無しさん2013/10/26(土) 21:09:35.51
gitってmacやwindowsでも操作同じ？
「アリスとボブのGit入門レッスン 」という本がよさそうなんだけど
この本macで解説してるんで聞いてみた。
gitってなんでこんなに名が知られていないんでしょうかね？
0101962013/10/26(土) 21:17:57.89
>>97
俺ならsubmoduleを使うが、あの使いこなすのが難しい機能を
「使い始めた」と言っている>>93に勧める気にはなれなかったので。
0102デフォルトの名無しさん2013/10/26(土) 21:34:44.46
>>100
git自体の操作はどれでも同じ
知名度をいうなら、プログラマでgit知らない人いないぐらいだと思うけど、>>100の周りではそうじゃないの？
0103デフォルトの名無しさん2013/10/26(土) 23:07:45.92
ボブ「Gitからメッセージも出力されているね。」
アリス「メッセージは英語なのね・・・。」
ボブ「そうだね。英語だね。でも、簡潔な言い回しだから、じっくり読めばおおよその
意味がわかると思うよ。最初だから日本語訳を付けておくね。」
0104デフォルトの名無しさん2013/10/26(土) 23:08:47.72
>>100
> gitってなんでこんなに名が知られていないんでしょうかね？

可哀想に。使えないならともかく知らないっていうのは、
プログラミングに興味が無いと言っているのと同じレベルだぞ
0105デフォルトの名無しさん2013/10/27(日) 00:42:15.31
>>94
commitしたファイルのチェックサムが、リビジョンになるからね
0106972013/10/27(日) 01:09:05.75
>>101
ごもっとも　俺もいざとなったら調べて使うだろうが今のところ練習以上に使ったことはない
0107デフォルトの名無しさん2013/10/27(日) 07:56:56.21
>>105
う～ん、別にチェックサムでもいいのでソースに埋め込ませてくれてもいいと思うんだけど。
コミットした日時とか、人とかもあると嬉しいし...
0108デフォルトの名無しさん2013/10/27(日) 08:34:54.03
>>107
チェックサム埋め込んだらチェックサムが変わっちゃうじゃないですか。
0109デフォルトの名無しさん2013/10/27(日) 08:43:44.77
チェックサムを埋め込んだらチェックサムが変わってしまったでござる
0110デフォルトの名無しさん2013/10/27(日) 08:54:24.39
チェックサムの無限ループや！
0111デフォルトの名無しさん2013/10/27(日) 09:00:10.43
チェックサムがッ！一致するまで！再計算するのをやめないッ！
0112デフォルトの名無しさん2013/10/27(日) 09:29:59.66
>>102>>104
ほとんどひとりで個人の趣味範囲
こういうのを使ってソフトを作成していったんですね
ソフト作りも製造業に似ていますね
どちらというと一人やっているほうが楽しいかね
0113デフォルトの名無しさん2013/10/27(日) 10:03:49.24
>>108
Subversion 知らないの？
リポジトリから取ってくる時に埋め込むから、リポジトリのリビジョンは変わらないよ。
git でもできると思うんだけど。
0114デフォルトの名無しさん2013/10/27(日) 10:08:53.19
キーワード置換ってなに？
0115デフォルトの名無しさん2013/10/27(日) 10:19:07.93
>>94へ朗報>>113
0116デフォルトの名無しさん2013/10/27(日) 10:23:15.39
>>113
それ、取得元の証明であって、手元にあるものがソース＋チェックサムだってどうやってわかんの？
そもそもcommitログでチェックサムも日時も人も全部わかるじゃん
0117デフォルトの名無しさん2013/10/27(日) 10:59:04.93
>>116
サムチェックだと考えるからわからんのだよ。
ファイルの内容とは無関係なGUIDのような任意のIDだと考えたまえ。

任意のIDはファイル内容を変えても、変わらんよ？
0118デフォルトの名無しさん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
0119デフォルトの名無しさん2013/10/27(日) 11:36:17.97
>>115
同一人物なんだが...

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

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

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

いや、印刷したソースとか、実行ファイルに埋め込んでおいて、問題が発生した版はどれだっけ？ とか、git から離れたものを特定したいんよ。
0120デフォルトの名無しさん2013/10/27(日) 11:39:36.63
>>119
あ、おまえ、スクリプト言語しか使ってないだろ？

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


いるんだよねー。
ビルドという工程の存在を知らない人ってｗ
0121デフォルトの名無しさん2013/10/27(日) 11:40:32.73
gitって奥が深い？
gitってなんの言語で書かれているの？
0122デフォルトの名無しさん2013/10/27(日) 11:41:42.21
>>114
ソースコードの中に $Rev$ とか入れておくと、自動的にそのファイルのレビジョンに置き換えてくれる機能。
レビジョンだけでなく、ファイル名とか、コミットした日時や人とかに置き換えができる。
0123デフォルトの名無しさん2013/10/27(日) 11:45:26.41
>>119
git でもできると思うんだけど。
0124デフォルトの名無しさん2013/10/27(日) 11:45:52.63
ソースコードの中の著作権とかの名前のように
原則として変わらないものは意味がある。

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

これが答え。
0125デフォルトの名無しさん2013/10/27(日) 11:48:44.75
>>120
文字列に埋め込んで、実行ファイルがどのソースからビルドされてるかを後から確認するとかもできるよ。
ident とかそれを見るための専用コマンドがあったりしたんだが...
0126デフォルトの名無しさん2013/10/27(日) 11:49:01.93
コミットした人ってさ、
複数の人がコミットしている場合
行ごとに違う人が修正していることって
よくある話だけど、

コミットした人の名前知ってどうすんの？
0127デフォルトの名無しさん2013/10/27(日) 11:49:54.63
そういうのはソースに書くのではなく
バージョン管理システムに任せなさい
0128デフォルトの名無しさん2013/10/27(日) 11:52:03.23
>>125
え？ ソースファイルってたくさんあるじゃん。
実行ファイルが、どのソースファイル（全100ファイル）郡から
ビルドされてるかしってどうするの？

そんなもん、ソースファイルに埋め込むんじゃなくて、
ビルド時に生成したリビジョン番号を埋め込むだけだろ。
0129デフォルトの名無しさん2013/10/27(日) 11:53:22.84
>>123
やり方、教えて。

>>124
いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。
SCCS から使ってるけど、有名どころの SCM でできないやつは git が初めてなんだわ。
0130デフォルトの名無しさん2013/10/27(日) 11:53:58.47
例えばこんなの。

簡易ビルドスクリプト


$ build.sh リビジョン番号

gitから指定したリビジョン番号をチェックアウト
echo リビジョン番号 > revision.dat
コンパイル時にresivion.datを埋め込み
実行ファイル生成
0131デフォルトの名無しさん2013/10/27(日) 11:54:12.17
>>94
SubversionとGitの大きな違いはブランチのスイッチが瞬時にできること。
対象となるブランチがローカルにあるのでそれができる。
キーワード置換があったら、ブランチのスイッチで置換が必要になるので遅くなる。
だからキーワード置換の機能はGitにはない。

Gitにキーワード置換を加えるパッチは、そういう理由でLinusに却下されている。
http://thread.gmane.org/gmane.comp.version-control.git/44750
0132デフォルトの名無しさん2013/10/27(日) 11:55:16.68
>>129
> いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。

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

意味が無いことを有効だと勘違いしているだけ。
0133デフォルトの名無しさん2013/10/27(日) 11:57:01.66
キーワード置換なんてビルド時にやればいいだけじゃん？

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

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

>>127
もちろん、SCM に任せるんですよ？
SCM を離れたソースコードを特定したいと言う話。
01361312013/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本来の使い方からかなり離れてる。
コマンドラインで使い方を覚えておかないと、いつかはまることになるよ。
0137デフォルトの名無しさん2013/10/27(日) 12:11:53.26
>>135
> SCM を離れたソースコードを特定したいと言う話。

だから、SCM から離す時に埋め込めばいいじゃん。
0138デフォルトの名無しさん2013/10/27(日) 12:12:25.16
>>135
> それはそれとして、そのファイルのレビジョンを知りたいんだよ。

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

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

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

まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
さすがに、書いてて恥ずかしくない？
0140デフォルトの名無しさん2013/10/27(日) 12:18:50.05
話変わるけど、git bisectって凄いよね。

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

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

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

そうすれば、今度は正常と異常の中間を取ってくる・・・と繰り返すので
最初以外リビジョンなんか考えずに、どこでおかしくなったかを探すことが出来る。
0141デフォルトの名無しさん2013/10/27(日) 12:20:15.33
>>139

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

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

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

プログラミングでもいるんだ。
新しい言語、新しいライブラリを導入しても
古いやり方のまま続けて、導入した意味を無くす奴ってね。
0142デフォルトの名無しさん2013/10/27(日) 12:23:50.72
>>136
> それができないならその「ほかのSCM」を使っていた方がいい。

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

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

>>138
話の流れ追えてます？
0143デフォルトの名無しさん2013/10/27(日) 12:31:13.21
>>141
git が最新ともベストとも思えないので、成長とか意味わからん (w
0144デフォルトの名無しさん2013/10/27(日) 12:34:55.21
>>142
そもそも将来的にメンテする可能性のあるものを何故gitからわざわざ離すのかもよく解らんのだが…
仮に離すとしても、そいつはメンテせずに
大元のほうを残して、そっち使ってメンテしないか？
0145デフォルトの名無しさん2013/10/27(日) 12:37:26.72
94はキーワード展開のやり方教えてもらったんだから
smudge フィルタをさっさと書けよハゲ
0146デフォルトの名無しさん2013/10/27(日) 12:56:26.47
定期的に「ある特定のファイルのリビジョン」という話をする人が出てくるなあ
俺の理解だと，gitでそういう話をするのは無意味だと思うんだけど
0147デフォルトの名無しさん2013/10/27(日) 12:59:13.02
>>144
いや、離した奴をメンテとかは (普通は) しないよ。
実行ファイルの提供とか、印刷とか離れちゃう奴をどう特定するかの話。

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

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

金がないなら自分で工夫するんだ。頑張れ!
01491312013/10/27(日) 13:09:58.38
>>142
Visual StudioのGitはリポジトリのビューワーとして使った方がいいよ。
あれでチェックインその他の操作を覚えてもろくなことにならない。

将来Gitを使いこなしているチームに君が加入することがなく、
チームに新たにGitを導入する指揮を君が取ることもないなら、
Visual Studioから使っていても構わないけど。
0150デフォルトの名無しさん2013/10/27(日) 13:12:42.24
出来ないことはやってはいけないこととする流儀があるんだよね。
たとえば日本語ファイル名とか。
ファイルの名前を日本語にしてるんだぜ？馬鹿だろ？なんて真顔でのたまっていた時代、
人たちがほんとにいたんだよ。
0151デフォルトの名無しさん2013/10/27(日) 13:12:59.41
メールでパッチ送る方法ならgitに
ついてる

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

日本語ファイル名はMS-DOS2.11で普通に使えてましたね。UNIXの人たちは…w
0153デフォルトの名無しさん2013/10/27(日) 13:34:04.11
nihongo-de-nani-ga-warui.txt
0154デフォルトの名無しさん2013/10/27(日) 13:36:00.09
>>148
Subversion 使ってるので、ソースツリーのリビジョンとかは違和感ない。
ただ、印刷してレビューとか、外注さんにソース渡すとかあるんだよね。
まあ、そう言う運用には向いてないってことなんだろうな。

>>150
いまでも、日本語ファイル名は結構鬼門だよ。
海外製のツールはダメなやつ結構あるし、OSS でも Doxygen とか...
0155デフォルトの名無しさん2013/10/27(日) 13:59:54.40
日本人（と本人は主張している）が日本語を使ってはいけない理由を説明して
一生懸命日本語を否定してた。
本来は1億人の日本人を説得するのではなく、少数にすぎないソフトウエア発行元を
説得したりお願いしたりしたほうが良かったと思う。
まして、年寄りは日本語を使いたがるとか初心者は日本語を使いたがるとか
ドザは日本語を使いたがるとか、日本語を使う人間は劣っているかのような
イメージを植え付ける必要はなかったんじゃないかな。
0156デフォルトの名無しさん2013/10/27(日) 15:00:36.05
単にコマンドラインで日本語ファイル名を入力するのがめんどくさいから使ってないなあ
0157デフォルトの名無しさん2013/10/27(日) 15:04:49.81
>>113
CVSの頃はよく使ってたけど、SVNだとあんま意味無いからmakeでやってたな。
0158デフォルトの名無しさん2013/10/27(日) 15:08:59.04
>>152
MSがすぐ互換性崩して妨害しようとするから、ファイル名などのようなとこはメジャーなものでないと危険。
0159デフォルトの名無しさん2013/10/27(日) 17:00:11.36
印刷してレビューするだけで
なんでソースコードに
リビション番号を書かないと
いけないのかわからない

印刷のヘッダに書けば事足りるだろ？
0160デフォルトの名無しさん2013/10/27(日) 17:04:11.10
外注に渡すにしても
zipに同梱すればいいじゃないか
zipのファイル名がリビション番号
なのもよくある事だし
0161デフォルトの名無しさん2013/10/27(日) 17:21:53.42
>>150
Unicodeが普及した後にマになるとこういう発想が出来るのか
01621312013/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
0163デフォルトの名無しさん2013/10/27(日) 18:01:11.82
>>159-160
今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？
zip 同梱とかは、ソース一つとは限らないし、目視で対応付けとかは勘弁してほしい。

>>161
最近の環境使ってれば、そんな変な感覚とは思えないけど？
0164デフォルトの名無しさん2013/10/27(日) 18:01:31.11
>>162
あぁ、それで問題ないな。

エクスポートする時やアーカイブを作る時に
自動的に入れればそれで事足りるわけだし。
0165デフォルトの名無しさん2013/10/27(日) 18:03:21.05
>>163
> 今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？

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

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

すべてのソースコードに一行付け足すことが君には難しいの？
0166デフォルトの名無しさん2013/10/27(日) 18:05:22.23
>>163
ってアーカイブをする作る時に
WindowsのGUI使って
.gitディレクトリ選ばないように選択して
右クリックメニューからzip作ってそうｗ
0167デフォルトの名無しさん2013/10/27(日) 18:37:33.42
CVSだとファイルごとにバージョン違ったりするけど、SVNやgitだと同じでしょ。それでもファイルごとに付ける意味あるのかな。それとも最後に変更したIDをつけるの?
0168デフォルトの名無しさん2013/10/27(日) 18:42:48.75
ファイルにバージョン番号がなくて
どうやってファイルを管理するのか？

（バージョン管理ソフトを知らない）

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

（diffを知らない）

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

（それ以外の方法を知らない）

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

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

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

（プログラミング技術がない素人だから金もらってはダメ）
0169デフォルトの名無しさん2013/10/27(日) 19:13:31.88
>>165
ああ、すまん、印刷でヘッダーっ言うと、各ページに印刷される奴のこと言ってるんだと思ったんよ。

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

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

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

もし、キーワード置換の話のこと言ってるとしたら、全然違う話だから。
全てのレビジョンと比較するつもりなら止めやしないけど...
まさか、違うよね？ (w
0171デフォルトの名無しさん2013/10/27(日) 19:32:22.19
>>170
違うに決まってるだろ
そんな勘違いするのお前だけだよ。
馬鹿じゃないのか？
0172デフォルトの名無しさん2013/10/27(日) 19:33:15.88
ここまででよくわかった。
gitにキーワード置換を搭載する意味は無い。
代替方法で、全く同じことができるし、
そもそもやる意味が無いということだ。
0173デフォルトの名無しさん2013/10/27(日) 19:38:10.28
>>169
svnが出てくる前からcvs使ってて、svnはできることそんな変わらないのに、不便な点が多くてあんま使わなかったな。svn使ってる客ってにわかなのか、単にファイルコピーとしか使ってない人が多かったし。タグ埋め込みなら使ってたかな。
0174デフォルトの名無しさん2013/10/27(日) 20:18:38.99
>>171
そうだよね、安心したわ。

で、
> もしファイルを二つ提示されて
なんて、どっからでてきたの？ (w
0175デフォルトの名無しさん2013/10/27(日) 20:23:42.68
>>173
確かに、タグ埋め込みとか言ってる時点で svn 使えてなかったのは、よくわかるわ。
0176デフォルトの名無しさん2013/10/27(日) 21:27:59.35
>>172
てか確かSVNでも非推奨ってことで、デフォルトではオフになってないっけキーワード置換
0177デフォルトの名無しさん2013/10/27(日) 22:22:19.89
>>176
非推奨じゃないよ。
Subversion は指示されないことはやらないと言うポリシーなだけ。
拡張子で自動設定する機能もある。
0178デフォルトの名無しさん2013/10/27(日) 22:23:51.70
やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
なんか勝手に入れてくれると楽って話だろうねえ。
まともな仕事をしている人は、そういうの認めたくないんだろう。

>>163
UNICODEは正規化の話がね。MS-DOSの頃の方がある意味まともだった。
0179デフォルトの名無しさん2013/10/27(日) 22:31:24.56
>>178
> やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
> なんか勝手に入れてくれると楽って話だろうねえ。

ごめん、適当とか勝手にとか言ってる内容がさっぱりわからん。
0180デフォルトの名無しさん2013/10/27(日) 22:33:37.68
>>175
どういうこと?
0181デフォルトの名無しさん2013/10/27(日) 22:36:00.82
>>175
どういうこと?
タグじゃなくてブランチ名って言えってこと?
0182デフォルトの名無しさん2013/10/27(日) 22:42:31.03
>>180-181
タグ埋め込みなんて言わないでしょ？
タグを打つとかは言うけど。
0183デフォルトの名無しさん2013/10/27(日) 22:43:23.04
そもそも、キーワード置換なんて
ソースコードに入れる必要がないわけで。

あんなのCVS時代の遺産だよ。
CVSはファイル単位の管理しか出来なかったからね。
0184デフォルトの名無しさん2013/10/27(日) 22:44:56.39
そう、リビジョン番号なんてのは
エクスポートした時に自動で埋めればいいだけ
そういうのが必要な人は自分でやればいいやん。
gitの文化で要らないものはつけてない。それだけの話。
01851312013/10/27(日) 22:50:15.53
うっとうしいので>>94はいちいちバカの相手をするのをやめてくれ。
0186デフォルトの名無しさん2013/10/27(日) 22:58:10.61
>>184
まあそういうことみたいやね。
>>134 >>136 >>162 で URL 教えてもらえたし、あとは何とかするわ。
0187デフォルトの名無しさん2013/10/27(日) 23:04:10.33
>>185
ああ、すまん。
マジで git 使うの初めてだから、もう少しこのスレのレベル高いかと思ってたんだけど、大体わかったから、あとは適当にスルーするわ (w
0188デフォルトの名無しさん2013/10/27(日) 23:09:28.37
馬鹿を相手にするのは馬鹿だけってことですよ
キーワード展開については前スレでもその前のスレでも>>162のリンクで終わってる
0189デフォルトの名無しさん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)
0190デフォルトの名無しさん2013/10/27(日) 23:34:43.52
>>182
あなたは思い込みをしているようだ。
バイナリとかにタグを入れることだよ。
0191デフォルトの名無しさん2013/10/28(月) 19:37:21.02
こういうレベルの低い技術者が末端に居るだけなら叩き出せば済むんだが、そうでないと無駄な作業で工数取られてイライラすんだよな
マニュアルすら通読しないし救い難い。VSProを買う金すらねぇならもっと勉強しろよ。お前にゃgitはまだ早い
0192デフォルトの名無しさん2013/10/28(月) 20:20:48.46
調べもせずに質問ってが腹立つのはわからんでも無いが、gitに早い遅いがあるのか？
嫌なら初心者スレでも立てて隔離すりゃいいんじゃね
0193デフォルトの名無しさん2013/10/28(月) 20:49:58.78
ここはお前の日記帳だ
0194デフォルトの名無しさん2013/10/28(月) 21:35:59.23
>>191みたいなうるさいだけで非生産的なやつが一番困る
0195デフォルトの名無しさん2013/10/28(月) 21:36:54.34
>>192
なんかやなことでもあったんでしょ
優しくスルーしてあげましょう
0196デフォルトの名無しさん2013/10/29(火) 09:00:39.16
Subversionでもキーワード置換できるけど使いたいという奴は老害ばかりだよ
0197デフォルトの名無しさん2013/10/29(火) 13:32:11.13
老害かどうかなんて一概には言えんのだが、
確かにその傾向は強く感じる
0198デフォルトの名無しさん2013/10/29(火) 21:16:49.86
キーワード置換はできるからやってるだけで
やる意味があるからやっているわけじゃない。
0199デフォルトの名無しさん2013/10/29(火) 22:24:37.56
authorを捏造して納品しろと言われて、リリース時にヘッダを
書き換えるようにしたら簡単かつ綺麗だったので、
CVSでも置換はやらなくなったな。
0200デフォルトの名無しさん2013/10/29(火) 22:38:48.68
しゃちょー、PeercastStationエラー落ちのままだったら
新しいクライアントつなげないから、再起動しておくれ
0201デフォルトの名無しさん2013/10/30(水) 23:55:10.83
Git 1.8.4.2
https://code.google.com/p/git-core/downloads/list
0202デフォルトの名無しさん2013/10/31(木) 10:38:00.00
git cloneすると
リポジトリになくてローカルにあるファイルや
ローカルで編集済みのファイルとかは
どうなりますか？
0203デフォルトの名無しさん2013/10/31(木) 11:35:38.90
どうもならん
0204デフォルトの名無しさん2013/10/31(木) 12:01:23.54
もうどうにもならない
0205デフォルトの名無しさん2013/11/01(金) 13:54:57.65
pull requestでコード貰ったんですけどこれってそのまま取り込んでもＯＫですか？
ライセンスとか面倒なことになりますか？
0206デフォルトの名無しさん2013/11/01(金) 15:35:23.11
それはpull req投げたヤツに聞けよ
0207デフォルトの名無しさん2013/11/01(金) 15:50:38.75
githubにしろpull requestのページでコメントでやりとりできるしな
0208デフォルトの名無しさん2013/11/01(金) 17:06:55.82
Tortoisegitを使っていて
pushするときにサブモジュールを再帰的にチェックとあるんですが
どういう意味ですか？
0209デフォルトの名無しさん2013/11/01(金) 21:45:00.79
サブモジュールのサブモジュールのサブモジュールもチェックするよー
0210デフォルトの名無しさん2013/11/02(土) 17:22:43.77
初めてGithubでPull request来たのですが
これってブランチを別につくってそこでテストしてから
マージするのが普通なんですかね？
0211デフォルトの名無しさん2013/11/02(土) 17:39:45.81
すいませんmasterブランチにプルリクエストでコードが来た場合
それをtestブランチに入れる方法を教えてください
0212デフォルトの名無しさん2013/11/02(土) 17:54:41.07
馬鹿には無理
0213デフォルトの名無しさん2013/11/02(土) 18:04:37.42
>>210-211
You can also merge branches on the command line.
0214デフォルトの名無しさん2013/11/02(土) 18:11:45.35
masterブランチ以外にマージするなら
Github上じゃなくて他のGitクライアントでの作業が必須だな
別にコマンドラインである必要は無いと思うけど
コマンドライン以外の手軽な方法は知らん
0215デフォルトの名無しさん2013/11/02(土) 18:14:03.84
プルリクエスト送ってくれたとこのフォークリポジトリからローカルにフェッチだかクローンだかして
ローカルでマージテスト用ブランチ作ってそこにマージしてテストしてからローカルのマスターにマージしてプッシュ
0216デフォルトの名無しさん2013/11/02(土) 18:19:21.14
シングル ベンティ キャラメル アーモンド ヘーゼルナッツ モカ ホワイトモカ
チョコチップ エキストラホイップ キャラメルソース チョコソース バニラクリームフラペチーノ
02172112013/11/02(土) 18:52:39.71
バカがmasterブランチにさえプルリクエストを送らなければ僕は悩まなかった
0218デフォルトの名無しさん2013/11/02(土) 18:53:41.40
じゃあどこにプルリクエスト送るんだよ
0219デフォルトの名無しさん2013/11/02(土) 18:55:30.14
あの、Pull Requestを取り消すほうほうってありますか？
0220デフォルトの名無しさん2013/11/02(土) 18:57:48.30
>>219
アカウントを消す
0221デフォルトの名無しさん2013/11/02(土) 19:07:16.82
取り消すことは出来ないけど、クローズすればいいよ。クローズする理由をコメントで添えておけば尚ＯＫ
0222デフォルトの名無しさん2013/11/02(土) 19:46:18.91
プルリク要らなきゃプライベートリポジトリにしておけ。
金払いたくないならbitbucket.orgでやれ。
0223デフォルトの名無しさん2013/11/02(土) 20:56:04.66
論点ずれてる
0224デフォルトの名無しさん2013/11/02(土) 22:24:45.19
じゃ、こっちかな

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/
0225デフォルトの名無しさん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/
0226デフォルトの名無しさん2013/11/03(日) 10:32:22.13
コードブレイクか
sshとpull requestはもうサポートされたんじゃなかったかな？

気になったけど、スキルとか年収とか書くの面倒くさそうで止めた
0227デフォルトの名無しさん2013/11/03(日) 13:50:24.97
年収0なら0と書けば良いだけ
無理して嘘を付く必要はない
0228デフォルトの名無しさん2013/11/03(日) 14:39:27.56
画像を加工したいのですが、変更したらコミットしていく使い方も出来ますか？

ソースコードを書く目的以外で使わないほうがいいのでしょうか？
0229デフォルトの名無しさん2013/11/03(日) 14:49:04.99
>>227
じゃあお前の年収をここに個人が特定できるように書いてみて。
書けないのなら、書けない理由を書いてみて。
0230デフォルトの名無しさん2013/11/03(日) 14:57:52.29
Windows で git 使おうと思ってるんだけど、まだ日本語ファイル名は鬼門なんだっけ？
0231デフォルトの名無しさん2013/11/03(日) 15:02:07.58
>>228

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

gitならテキストもバイナリも保存容量の効率変わらないし。
0232デフォルトの名無しさん2013/11/03(日) 15:07:53.64
画像はSVGにしておけば差分取るにも効率が良い。
0233デフォルトの名無しさん2013/11/03(日) 15:09:53.30
SVGの差分を見て何がわかるというのか？
0234デフォルトの名無しさん2013/11/03(日) 15:13:47.50
エレメントの追加削除、属性の変更くらいならわかるだろ。
0235デフォルトの名無しさん2013/11/03(日) 15:18:46.65
>>231
ありがとうございます。

加工ミスしたときに前バージョンに戻るために使いたいと思います
0236デフォルトの名無しさん2013/11/03(日) 15:19:31.93
いや、画像を修正する作業を見てみ。

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

それをテキストの差分見て何を読み取れるのかって話。
0237デフォルトの名無しさん2013/11/03(日) 15:38:57.76
>>>222
これか

BitbucketでGitとMercurialの無料ソースコードホスティングを
https://bitbucket.org/
0238デフォルトの名無しさん2013/11/03(日) 20:33:45.16
>>237
プライベート&ぼっち、って条件なら有名なトコだな
0239デフォルトの名無しさん2013/11/03(日) 20:35:35.54
GitHubでの公開ぼっちとどっちがマシか
0240デフォルトの名無しさん2013/11/03(日) 21:15:47.05
でもさいきなりサービス終了とかしたらどうするの？
0241デフォルトの名無しさん2013/11/03(日) 21:18:13.87
「突然終了したらどうなるの？」
これって有償サービス無償サービスもネットもリアルも関係なく存在する話だよね
0242デフォルトの名無しさん2013/11/03(日) 21:55:03.76
プッシュしたものが正常に送れたか確かめる方法はありますか？
0243デフォルトの名無しさん2013/11/03(日) 23:00:04.30
あります
0244デフォルトの名無しさん2013/11/04(月) 10:05:58.22
>>241
gitなら全コピー手元にあるんでしょ。
0245デフォルトの名無しさん2013/11/04(月) 12:47:02.01
あそっかサービス終了してもローカルにあるから大丈夫か
0246デフォルトの名無しさん2013/11/04(月) 17:44:29.42
それで安心なのはリポジトリのデータ保存という点だけな
0247デフォルトの名無しさん2013/11/04(月) 17:50:41.59
データさえあればまた別のところで再開もできるし他に何が要るのか
0248デフォルトの名無しさん2013/11/04(月) 17:54:49.56
リポジトリのデータを、Gitでバージョン管理
0249デフォルトの名無しさん2013/11/04(月) 18:00:28.77
GitHubなどのサービス上でやったやりとりのデータが消えたら悲しいって話じゃないの？
0250デフォルトの名無しさん2013/11/04(月) 18:51:35.57
>>241
有償無償かじゃなくて、自分でサービス立ち上げるか、ほかのサービス使うかの話でしょ
0251デフォルトの名無しさん2013/11/05(火) 02:32:00.91
スレチじゃね？
ttp://kohada.2ch.net/test/read.cgi/prog/1363523309/
0252デフォルトの名無しさん2013/11/05(火) 02:36:57.00
そこを正規のGitHubスレにしていいものか微妙だが
OSSのホスティングの総合スレみたいなのが欲しいところだね
0253デフォルトの名無しさん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
0254デフォルトの名無しさん2013/11/05(火) 03:22:33.52
>>252
確かにGitHubの本スレ扱いにしていいかはちょっと迷ったんだよね
パッと思いつく対抗馬のbitbucketのスレは無かったし

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

テンプレをブラッシュアップしてここに立てよう
0256デフォルトの名無しさん2013/11/05(火) 10:16:22.96
おれもム板がいいと思う
ムの人しか使わないし
0257デフォルトの名無しさん2013/11/05(火) 11:48:06.25
秘密鍵とかをDropboxにそのまま保存するのってやめたほうがいいですか？
0258デフォルトの名無しさん2013/11/05(火) 12:00:50.40
>>257 スレ違い
0259デフォルトの名無しさん2013/11/05(火) 13:53:22.52
日本語ファイル名使って何が悪い!
という奴らって例えば支那語のファイル名をまともに扱えない現実を見たことがないんだろうな
0260デフォルトの名無しさん2013/11/06(水) 01:04:11.25
>>253
それ、あくまでOSS限定なんだよなー
プライベートのリポジトリホスティングサービスも扱いたいね
0261デフォルトの名無しさん2013/11/06(水) 01:30:24.18
じゃあOSSホスティング総合スレじゃなく、リポジトリホスティング総合スレにするか
0262デフォルトの名無しさん2013/11/06(水) 10:53:34.84
ブスはGIT使うな
0263デフォルトの名無しさん2013/11/06(水) 12:15:05.70
>>229
個人が特定できるように書く理由ってなに？
0264デフォルトの名無しさん2013/11/06(水) 15:49:25.16
git rm '>>263'
0265デフォルトの名無しさん2013/11/08(金) 00:29:24.12
gitignoreにtmp/**/*って書いてもtmpフォルダ以下のファイルが無視されないんですが
0266デフォルトの名無しさん2013/11/08(金) 01:08:51.60
.gitignore

/classes
/tmpclasses
*.class
*.jar
0267デフォルトの名無しさん2013/11/08(金) 01:11:28.11
>>265
tmpだけでいいのでは？
0268デフォルトの名無しさん2013/11/08(金) 12:34:50.76
.gitignoreとか.gitconfigとかこういうGitに関するファイルの一覧ってありませんか？
0269デフォルトの名無しさん2013/11/08(金) 14:34:36.01
GitlabとSourceTreeでGitデビューし始めました。

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

一通り書かれたサイトとかあれば紹介いただけないでしょうか
0270デフォルトの名無しさん2013/11/08(金) 14:35:18.92
SourceTreeいいよね
ぼくも好きですよ
今はコマンドラインしかつかってないけど
0271デフォルトの名無しさん2013/11/08(金) 14:49:52.92
sshのキーはどこでも作れる
っ http://www.openssl.org/
0272デフォルトの名無しさん2013/11/08(金) 14:53:50.44
Windowsでキーの作成にputtyを使うのは地雷記事
git付属のbashで作るべき
0273デフォルトの名無しさん2013/11/08(金) 14:58:58.28
どれで作ろうが同じじゃねーの
0274デフォルトの名無しさん2013/11/08(金) 15:31:04.04
そもそも公開鍵と秘密鍵も理解できていないのですが
>>271
テキトーなソフトでキーみたいな暗号文字列を作ったとして
それをGitlabとSourceTreeの両方に登録したらいいんですか？

puttyで作った公開鍵をSourceTreeに登録しようとしたらパスフレーズを聞いてきて
作ったときに指定したつもりのものを入れてもBadと怒られてしまいます。
0275デフォルトの名無しさん2013/11/08(金) 15:34:43.14
Soucetreeではどのように SSHの設定をすればいいですか？ - Bitbucket ドキュメンテーション - Atlassian Japan Confluence
https://confluence.atlassian.co.jp/pages/viewpage.action?pageId=35815464
0276デフォルトの名無しさん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
0277デフォルトの名無しさん2013/11/08(金) 15:41:54.58
GitLabのヘルプページがGitHub上にあってワロタ
0278デフォルトの名無しさん2013/11/08(金) 15:45:06.34
GitLabってGitHubのクローンだったのか
0279デフォルトの名無しさん2013/11/08(金) 15:52:35.00
GitLabって社内LAN内にGitHubみたいな共有環境を構築するってものなのか、
個人では使う機会なさそうだな
0280デフォルトの名無しさん2013/11/08(金) 15:52:51.63
>>271
opensslじゃなくてopensshだろ
0281デフォルトの名無しさん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/
0282デフォルトの名無しさん2013/11/08(金) 18:33:14.94
>>276
どうもありがとうございます。
Githubではうまくいってますが、Gitlabとの組み合わせがよく分からないんです。

しかも自分のSourceTreeが1.3.1.0と新しく、なんか微妙に画面も違うしぃ・・って風でして
0283デフォルトの名無しさん2013/11/08(金) 18:45:04.25
うぉーー出来ました！！
SourceTree→ToolsOptionで、SSH Client のコンボボックス
OpenSSH から PuTTY/Plink に変更したら見事に成功

GitlabとはSSH通信なのでOpenSSHだと思い込んでいたのですが・・・
OpenSSHとPuTTYの違いって何ですか？
ってのはスレ違いなので、検索してきます。どうもありがとうございました。
0284デフォルトの名無しさん2013/11/08(金) 19:15:10.04
ソケットとかいうものが問題なのか
OSがM$だとターミナル的なもの以外ではOpenSSHをうまく扱えないものがほとんどなんだよね
0285デフォルトの名無しさん2013/11/08(金) 19:15:16.08
>>279
redmineは使ってるけどな。
0286デフォルトの名無しさん2013/11/08(金) 19:16:48.64
M$で開発とか拷問。
0287デフォルトの名無しさん2013/11/08(金) 19:23:17.21
vs以外で開発とか考えられん
0288デフォルトの名無しさん2013/11/09(土) 04:24:25.05
サーバのホームディレクトリをサンバ共有したら、sshの自動認証ができなくなってちょっと焦った思い出
0289デフォルトの名無しさん2013/11/09(土) 15:05:59.21
Gitで体をバージョン管理できたら
病気や老後に若い体に乗り換えればいいですよね
誰かそういうのできるプラグイン開発してくれませんか？
0290デフォルトの名無しさん2013/11/09(土) 15:18:28.03
どこにも異常のない一番元気なときに
あとで簡単に各部位毎に取り出せる形で
IPSで体全体のコミットがその都度出来たら
臓器バンクビジネスにソフトバンクが手を出すだろうね
0291デフォルトの名無しさん2013/11/09(土) 15:22:21.70
健康状態の遺伝子を保存しておけば実現可能な木もするんですけど
0292デフォルトの名無しさん2013/11/09(土) 15:44:15.90
>>289
記憶も戸籍上の年齢や経済力も元に戻りますが
0293デフォルトの名無しさん2013/11/09(土) 15:52:12.99
>>289
情報量が多すぎてcheckoutしたら最後のバージョンの手だけだったとか。
0294デフォルトの名無しさん2013/11/09(土) 18:26:07.26
>>292
.gitignore
0295デフォルトの名無しさん2013/11/09(土) 18:53:39.00
>>294
戸籍も資産もなくなるわけですね。
0296デフォルトの名無しさん2013/11/09(土) 20:15:47.29
Git 1.8.4.3
https://code.google.com/p/git-core/downloads/list
0297デフォルトの名無しさん2013/11/09(土) 20:18:43.05
1.8.5じゃねーのか？
0298デフォルトの名無しさん2013/11/09(土) 20:19:47.51
gitってグーグルコード上で開発してたのか
0299デフォルトの名無しさん2013/11/09(土) 20:27:21.97
俺の使ってるの1.8.3だった
0300デフォルトの名無しさん2013/11/09(土) 20:48:12.39
メンテナンスしてる濱野氏がGoogleにいるからかね？
Githubにもリポジトリあるけど https://github.com/git/git
これはミラーでpull request are ignoredとか書いてあるのにいくつか飛んできてるのが笑える
Documentation/SubmittingPatches見る限り、なんか修正して欲しかったらパッチ送れって方針なのね
0301デフォルトの名無しさん2013/11/12(火) 15:06:42.40
1.8.4に移行したらbashで日本語が入力できる！！！
1.8.3以下は今すぐ切り捨てろ！！！！
0302デフォルトの名無しさん2013/11/12(火) 15:38:00.28
>git --version
git version 1.7.4.msysgit.0

さっき`~/.config/git/ignore`が読まれなくて手間取ったのはバージョンのせいだった
0303デフォルトの名無しさん2013/11/12(火) 17:14:41.45
>>301
msysgit のこと？
0304デフォルトの名無しさん2013/11/12(火) 21:07:26.37
え・・・どういう事だ・・・？
今まで日本語入力できなかったの？
日本語入力ができなかった頃なんて俺知らないんだけど・・・
0305デフォルトの名無しさん2013/11/12(火) 21:47:36.42
1.8.4入れてGit Bashを起動してみたけど、相変わらず日本語は?????だったよ
0306デフォルトの名無しさん2013/11/12(火) 21:52:23.64
Git GUIのほうは1.8.3のときも日本語は普通に表示できてたし
0307デフォルトの名無しさん2013/11/12(火) 22:37:42.98
端末の問題じゃないのか。
0308デフォルトの名無しさん2013/11/12(火) 22:59:29.35
とにかく、Windowsを使うのを止めろ
0309デフォルトの名無しさん2013/11/13(水) 07:52:25.11
Gitですけどファイルの同期は取れるんですが
タイムスタンプがバラバラ

タイムスタンプも揃えること出来ないですか
(同期させること出来ませんか)
0310デフォルトの名無しさん2013/11/13(水) 09:04:29.43
>>309
さんざん既出
5スレ目の1から75まであたり参照
0311デフォルトの名無しさん2013/11/14(木) 13:52:42.63
去年から mac のターミナル（bash）で Git 使い始めて、コミットメッセージを日本語で入力してるけど問題無いよ。
git commit で vim が起動して入力しても、git commit -m でコマンドラインで入力しても問題無し。
git log で表示しても日本語が正常に表示される。
0312デフォルトの名無しさん2013/11/14(木) 14:00:32.91
Windowsで使うときだけ地雷
0313デフォルトの名無しさん2013/11/14(木) 14:26:56.03
Windowsが地雷
0314デフォルトの名無しさん2013/11/14(木) 23:11:09.64
GitはコミットメッセージはUTF-8なのでUTF-8で入れてる限りWindowsでも問題無いでしょ
ところでMacはNFD-Macなパス名は解決できるの？
0315デフォルトの名無しさん2013/11/14(木) 23:22:51.78
ファイル名やフォルダ名がShift-JISエンコードの日本語だもの
0316デフォルトの名無しさん2013/11/15(金) 00:22:41.44
他のソフト使いにくくして、MSのソフト使わせる戦略ですから。
0317デフォルトの名無しさん2013/11/15(金) 07:12:54.53
MSのソフトって使いやすいんですね
0318デフォルトの名無しさん2013/11/15(金) 09:58:30.05
Appleのソフトよりは質実剛健とは思う
0319デフォルトの名無しさん2013/11/15(金) 22:55:07.93
>>314
解決出来ないよ
0320デフォルトの名無しさん2013/11/15(金) 22:55:43.90
いつ2.0でるのですかロードマップないんですか
0321片山博文MZコスモ ◆T6xkBnTXz7B0 2013/11/15(金) 23:18:16.92
直前のコミットまで戻すにはどうすればいい？
0322デフォルトの名無しさん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
0323デフォルトの名無しさん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
0324デフォルトの名無しさん2013/11/15(金) 23:51:03.39
>>314
core.precomposeunicodeを設定したら、ファイル名に対してNFC変換が行われるのでMacでもだいたいOK
実は微妙に違うんだけど、普段使う程度の文字ならだいたいOK
0325デフォルトの名無しさん2013/11/16(土) 21:54:41.11
USBメモリのルート（ドライブレターはG:\）にクローンをしてみたのですが
fatal: destination path 'G:' already exists and is not an empty directory.
とエラーが発生してしまいます。
フォーマット直後でも同じエラーが発生します。
ルートにはクローンできないものなのでしょうか？
0326デフォルトの名無しさん2013/11/16(土) 22:06:46.22
エクスプローラーで開いた時点でdesktop.iniやthumbs.dbができてしまってるとか？
0327デフォルトの名無しさん2013/11/16(土) 22:12:45.00
フォルダーオプションで隠しファイルを表示するにして
「保護されたオペレーティングシステムファイルを表示しない」のチェックを外しても
desktop.ini や humbs.db が表示されないので空の状態になっていると思います
0328デフォルトの名無しさん2013/11/16(土) 22:28:36.08
>>325
USBメモリのドライブをNTFSフォルダーにマウントするとできるかも知れない
0329デフォルトの名無しさん2013/11/16(土) 23:15:30.82
>>325
initしてremote addしてpullすればいいんじゃない。
0330デフォルトの名無しさん2013/11/16(土) 23:44:24.20
>>329
なぜかpullコマンドを実行してもpullが始まらない。
リモートから何も受け取っていないみたいでローカルは変化なし。
0331デフォルトの名無しさん2013/11/16(土) 23:48:50.25
URLをタイプミスしてるとかはないの
0332デフォルトの名無しさん2013/11/16(土) 23:56:10.65
100ファイルあるファイルの中からa.txt b.txtのみを管理したいんですが
98ファイル分を.gitignoreに書くのが面倒くさいのですが何か良い方法教えて
0333デフォルトの名無しさん2013/11/16(土) 23:58:49.76
>>330
リモートに何もないんじゃないの。
0334デフォルトの名無しさん2013/11/17(日) 00:00:48.51
同じリポジトリをルートじゃない普通のフォルダでは成功したとかなんじゃね
0335デフォルトの名無しさん2013/11/17(日) 00:01:46.79
>>332
*
!a.txt
0336デフォルトの名無しさん2013/11/17(日) 00:01:54.12
シェルでもスクリプトでもファイルの列挙を書き出してa.txtとb.txtだけ削除すればいいじゃないの
0337デフォルトの名無しさん2013/11/17(日) 00:07:12.00
ゲームループ
1.ゲームスタート
2.あなたのAIが数を思い浮かべる(表示可能にする）
3.あなたのプログラムは敵AIの名前と思い浮かべた数の入力を待つ
4.あなたのプログラムはあなたのAIと敵AIに交互に推測させ、どちらかが当てるまで繰り返す
　（先攻が当てた場合、後攻にもう1度推測させる。両者同じ回数で当てた場合は引き分け

これって、2.のAIが数を思い浮かべるレベルのループを作れっていう意味じゃないよね？
0338デフォルトの名無しさん2013/11/17(日) 00:08:10.74
ttps://github.com/github/gitignore
>A collection of useful .gitignore templates

これ便利そうなのに、使いたい言語のが無かった
0339デフォルトの名無しさん2013/11/17(日) 00:11:11.13
>>332,335

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

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

Git
http://git-scm.com/docs/gitignore
0341デフォルトの名無しさん2013/11/17(日) 01:23:09.32
githubって容量無制限？
公開されるの気にしなければ
バックアップに使える？
0342デフォルトの名無しさん2013/11/17(日) 01:26:34.57
無制限じゃないよ、リポジトリ１つにつき1GBまでだよ

https://help.github.com/articles/what-is-my-disk-quota
0343デフォルトの名無しさん2013/11/17(日) 01:28:06.90
>>253のスレを誰か早く立ててほしいところ
俺はこのホストは立てられませんってエラーが出て立てられんし
0344デフォルトの名無しさん2013/11/17(日) 01:34:21.56
このスレに限らんが
公式のヘルプに答えが書いてあることを質問してくる奴って結構いるよな
日常生活でも家電とか取説読まずに分からんと憤慨してる奴みかけるし
人間って何なんだろうな
0345デフォルトの名無しさん2013/11/17(日) 01:37:06.86
>>342
バックアップ目的ならDropBoxおすすめとか書いてあってワロタ
0346デフォルトの名無しさん2013/11/17(日) 01:40:14.12
GitHubは完成したもののコンパイル物配布には向いてないと書いてあるな、Amazonを進めてるのな
0347デフォルトの名無しさん2013/11/17(日) 01:48:49.46
>>344
説明書を読むだけの店員さんの仕事を確保するためだろう。
0348デフォルトの名無しさん2013/11/17(日) 02:12:05.71
>>344
しかも過去スレに同じ質問と回答があるとかもうね
0349デフォルトの名無しさん2013/11/17(日) 02:20:32.62
2chの過去ログ漁るのは、公式手段だと●買わないとダメだし
2chにあんま詳しくないとmimizunなど過去ログ溜めてるサイトとか知らんだろ
0350デフォルトの名無しさん2013/11/17(日) 02:32:02.73
>>344 みたいなのが
「近頃の若いもんは・・・」
とか結構言うんだよな
人間って何なんだろうな
0351デフォルトの名無しさん2013/11/17(日) 03:42:32.19
git init --separate-git-dir=

これ使ってる香具師いる？
0352デフォルトの名無しさん2013/11/17(日) 04:56:32.23
>>349
0353デフォルトの名無しさん2013/11/17(日) 05:01:53.57
最近ここは面白スレ化してないか
0354デフォルトの名無しさん2013/11/17(日) 08:05:42.15
Googleが2ch過去ログサイトの隅々まで巡回してるのに何を言っとるんだ？

まあ、別に検索サイトや過去ログの使い方知らない訳じゃなくて、それらの手間を他人にかけてるだけだろうがな
0355デフォルトの名無しさん2013/11/17(日) 08:27:30.69
リファレンスより使用法やフォーラムの質問のが有用ってのは
MSかなんかが統計付きで出してた
マニュアル読めって言ってる奴は自己満足の役立たず
0356デフォルトの名無しさん2013/11/17(日) 08:32:51.44
それはリファレンスとフォーラムの両方を運営してる側が活用するデータで
他人に手間を押し付ける言い訳にしちゃダメだろ
0357デフォルトの名無しさん2013/11/17(日) 08:50:06.73
彼は自分にとって有用という点しか見ていないみたいだし、そもそも他人に手間を掛けるとか掛けないとかいう発想がなさそう
0358デフォルトの名無しさん2013/11/17(日) 09:06:26.90
１回１００円でマニュアルを調べて回答しますというサービスを立ち上げろよ
0359デフォルトの名無しさん2013/11/17(日) 10:04:50.80
>>356
他人に手間かけさせるという意味ではない
質問に答えることがそいつ以外にも有用になるってこと
マニュアル読めってのは何も答えてないのと同じで自己満足
0360デフォルトの名無しさん2013/11/17(日) 10:38:57.78
直前のコミットを書き換える場合
なんでみんなrebaseを使うんですか？
0361デフォルトの名無しさん2013/11/17(日) 10:45:25.16
git reset --soft HEAD^
ってやったらMore?って聞かれるんですけどここで何を入力したら実行できますか？
0362デフォルトの名無しさん2013/11/17(日) 11:00:33.01
>>355
ありがちな質問ならそれは正しい
でも、そのうちそうでない疑問もでてくるから、マニュアル不要とかあり得ん
0363デフォルトの名無しさん2013/11/17(日) 13:19:58.08
>>359
なら、お前以外は全員知ってるような当たり前の質問すんな
0364デフォルトの名無しさん2013/11/17(日) 21:34:36.14
>>361
cmd.exeではサーカムフレックスと改行で行の継続になる
"HEAD^"とするがよろしいかと
0365デフォルトの名無しさん2013/11/17(日) 21:41:56.62
windows だったら、ckw で bashを使うんじゃねーの
0366デフォルトの名無しさん2013/11/17(日) 21:42:49.84
>>360
普通はcommit --amend使うだろ
0367デフォルトの名無しさん2013/11/17(日) 22:21:50.81
>>360>>366
commit --amendを使うとauthorの時刻が変化しないが、
「rebaseなどでcommitオブジェクトが作り直される状況を除いてはauthorとcommitterで時刻が等しいcommitオブジェクトしか作らない」という俺ルールを守るため、
俺はreset {--soft,}とaddでindex作り直してからコミットやり直す
0368デフォルトの名無しさん2013/11/18(月) 04:59:09.33
その俺ルールのためなら、
filter-branchでまとめて書き直せばいいんでは
0369デフォルトの名無しさん2013/11/18(月) 08:54:07.11
>>367
commit --ammend --reset-author
で更新されたと思う
0370デフォルトの名無しさん2013/11/18(月) 09:12:13.55
＞commit --ammend --reset-author
＞で更新されたと思う

commit --amend --reset-author だごめん
0371デフォルトの名無しさん2013/11/18(月) 18:47:00.91
コンフリクトさせないために気をつけることを何個でも良いからおしえて
0372デフォルトの名無しさん2013/11/18(月) 19:25:51.04
rebaseできる時はする
0373デフォルトの名無しさん2013/11/18(月) 19:28:15.03
ffマージはgitに判断させる
0374デフォルトの名無しさん2013/11/18(月) 20:18:27.77
編集するファイル毎に専用ブランチを切る。
0375デフォルトの名無しさん2013/11/18(月) 20:20:26.72
master以外ブランチを作らない
03763712013/11/18(月) 20:21:06.61
なるほど、その３つぐらいですかね
基本的にコンフリクトしたときの対応記事書いてるブログってクソだと思うんですよ
コンフリクトしないことが重要なのに対応の仕方だけ書かれてもねっていつも思います
0377デフォルトの名無しさん2013/11/18(月) 20:24:20.08
変更は細かくコミットする
例えば移動コミットと変更コミットが分かれていたらその情報を利用してマージできる場面でも
一気にやってしまうとごちゃごちゃとコンフリクトする場合がある
0378デフォルトの名無しさん2013/11/18(月) 20:39:22.40
複数人で開発してれば、どんなに気を付けてても競合する時はするけどな。
0379デフォルトの名無しさん2013/11/18(月) 20:47:50.59
masterにあるファイルやフォルダを別フォルダに移動するときって、事前に開発者全員に知らせてから移動用のブランチ切ってやるべきかな
0380デフォルトの名無しさん2013/11/18(月) 20:50:12.75
git checkout -fってやっていらないファイルを整理しようと思ってたのに
gitで管理されてないゴミファイルが残ったままになります
なので一度.gtディレクトリ以外を削除してからgit checkout -fってやってるんですが面倒くさいです
こういうときはどうやるんですか？
0381デフォルトの名無しさん2013/11/18(月) 21:02:20.90
>>380
git clean
0382デフォルトの名無しさん2013/11/18(月) 22:35:49.41
コンフリクトを検出できるようにgit使っているのに。
0383デフォルトの名無しさん2013/11/18(月) 22:51:29.08
同一ファイルの同一行に追加されてるとgitはコンフリクトと判断するんだよね。
これがある行の上と下に分けて追加すると、両方を追加と判断できる。
gitがマージ処理をしやすくなるコーディングルールって無いものかな？
0384デフォルトの名無しさん2013/11/18(月) 23:02:00.99
やめろ・・・やめろよっ・・・・！
運用でカバーするって・・・甘い考えっ・・・・
道具に使われている事に・・・・まるで気付いてないっ・・・・！！
0385デフォルトの名無しさん2013/11/18(月) 23:45:01.61
>>383
どっちの行が先に処理されるべきかなんてgitさんに判断なんて無理だから仕方ない
0386デフォルトの名無しさん2013/11/19(火) 00:20:55.53
1stペアレンツの方を先にするとか
0387デフォルトの名無しさん2013/11/19(火) 01:25:42.04
>>380バッチ1つ作れば良いだけ
0388デフォルトの名無しさん2013/11/19(火) 09:39:14.25
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
0389デフォルトの名無しさん2013/11/19(火) 09:40:19.87
URL先にウイルスとかは言ってたりしたらおれが訴えられるから張らなかったから
必要な人は>>2以降にテンプレではっといて
0390デフォルトの名無しさん2013/11/19(火) 13:52:29.09
>>384
むしろ道具でカバーできたり判断できることはどんどん任せ、
他にやらなければいけないこと、かんがえなければいけないことに人間は注力すべきだろう、
とマジレス
0391デフォルトの名無しさん2013/11/19(火) 15:01:47.05
まあ--reset-authorやrebaseなど凝りだすとgitに使われている気分にはなるな
0392デフォルトの名無しさん2013/11/19(火) 19:46:41.12
>>388
おつ
0393デフォルトの名無しさん2013/11/20(水) 08:12:37.30
VS2012 スレで Visual Studio Tools for Git で質問したのですが
使ってる人が皆無なのか、全くのスルーだったのでこちらに参りました。

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

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

1台で上げ下げする解説サイトはいっぱいあるんですが
2台目以降の構築法が書かれているところが見当たらず・・・ヒントください。。
0394デフォルトの名無しさん2013/11/20(水) 08:30:35.78
msysgit入れてgit clone
0395デフォルトの名無しさん2013/11/21(木) 17:17:02.92
OSSスレ立った
0396デフォルトの名無しさん2013/11/21(木) 21:43:06.67
【ネット】 GitHubに「総当たり」攻撃、安易なパスワードが破られる…セキュリティ対策を強化へ
http://uni.2ch.net/test/read.cgi/newsplus/1385019870/
0397デフォルトの名無しさん2013/11/21(木) 22:26:16.49
Git 1.8.4.4
https://code.google.com/p/git-core/downloads/list
0398デフォルトの名無しさん2013/11/21(木) 22:27:11.63
1.8.4なんていらんよ。
1.8.5のRCでてるんだから
そっち使う。
0399デフォルトの名無しさん2013/11/21(木) 23:54:24.13
大事な資産をわざわざ人柱に提供するなんて
0400デフォルトの名無しさん2013/11/22(金) 13:04:00.78
git-guiのUI違和感ある物の一部変更(デフォールトとか註釈とか)
+potに反映してない文字列のうち見えたもの翻訳したった
ttp://www1.axfc.net/u/3095162.zip
更新前と更新後と差分全部入り
0401デフォルトの名無しさん2013/11/22(金) 21:17:27.28
>>400
Gitで管理しろよ
https://github.com/git/git/blob/master/git-gui/po/ja.po
0402デフォルトの名無しさん2013/11/22(金) 21:57:55.77
理由は知らんが元のpot自体が更新されとらんねん
どうしろというのさw
0403デフォルトの名無しさん2013/11/22(金) 22:24:33.88
forkだろ
0404デフォルトの名無しさん2013/11/23(土) 09:08:23.20
Git自体のoriginってgithub？kernel.orgかと思ってたわ
git://git.kernel.org/pub/scm/git/git.git
0405デフォルトの名無しさん2013/11/23(土) 13:00:12.52
git-scm.com のソースコードは https://github.com/git にリンクされていて
ここはmirrorだと書いてあるな。
0406デフォルトの名無しさん2013/11/23(土) 16:30:22.01
>>296-298
0407デフォルトの名無しさん2013/11/23(土) 21:29:49.06
Mercurialも使える方に質問です
バージョン管理システムに慣れる場合Gitとどっちが簡単ですか？
0408デフォルトの名無しさん2013/11/23(土) 21:46:58.54
>>407
どっちが簡単かだとMercurial

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

gitを使うようになってから、それにはちゃんと理由があるんだということに気づいたよ
↓みるといいよ
https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercuria
0409デフォルトの名無しさん2013/11/23(土) 21:47:37.71
何か変な改行はいっちゃった
0410デフォルトの名無しさん2013/11/23(土) 21:59:59.20
404 - Oops, you found a dead link. | Atlassian
0411デフォルトの名無しさん2013/11/23(土) 22:03:06.79
https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercurial
ごめんやで
0412デフォルトの名無しさん2013/11/23(土) 22:11:32.53
部分変更のみのコミット可能

これ多用してるわ
0413デフォルトの名無しさん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 などを使用して編集し、
コミットしたくない変更点をすべて元に戻してください。
変更を保存した後で、ファイルをコミットします。

コミットが完了すると、ファイルのコピーが自動的に復元され、
コミットされていなかった変更点が元に戻ります。
0414デフォルトの名無しさん2013/11/24(日) 01:38:27.21
誤爆？
0415デフォルトの名無しさん2013/11/24(日) 01:40:16.96
そういやgitの-pって凄いと思ったわ。
編集中のファイルのうち一部分だけを
コミットできるんだよね。

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

ブランチ一つ作るのにも切り替えるのにも
慎重にならないといけないものでは
綺麗に修正することも出来んわ。
0417デフォルトの名無しさん2013/11/24(日) 12:12:49.35
馬鹿には無理
0418デフォルトの名無しさん2013/11/28(木) 20:39:00.87
Git 1.8.5
https://code.google.com/p/git-core/downloads/list
0419デフォルトの名無しさん2013/12/03(火) 08:47:01.42
test
0420デフォルトの名無しさん2013/12/03(火) 09:24:11.92
git と github の違いについてですが
git のどのパッケージを使うと
github サーバーを自分で立てられるのでしょう？
0421デフォルトの名無しさん2013/12/03(火) 09:39:17.51
自鯖ならgithubは忘れて
「gitlab」でググろう
0422デフォルトの名無しさん2013/12/03(火) 10:38:00.80
github Enterprise を契約すると、自鯖でたてられるよ
0423デフォルトの名無しさん2013/12/03(火) 19:32:16.35
githubはリポジトリホスティングのサービス名である
0424デフォルトの名無しさん2013/12/03(火) 19:32:52.77
git prepとかもいいよ
日本人が作った物だよ
0425デフォルトの名無しさん2013/12/03(火) 19:43:48.33
420の質問の意味がよくわからないのにおまえらよく答えられるのな
何をしたくて何を知りたいのかさっぱりわからん
0426デフォルトの名無しさん2013/12/03(火) 19:45:27.80
GitHubのフィッシングサイトを立てたいって意味か？
0427デフォルトの名無しさん2013/12/03(火) 23:09:17.20
>>425は超絶アスペ
0428デフォルトの名無しさん2013/12/04(水) 09:16:21.64
みなさん色々なご提案ありがとう
0429デフォルトの名無しさん2013/12/08(日) 02:40:37.29
gitの共有リポジトリを自宅サーバーに作りたいんだけど、
相談させてください。

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

なんだけど、どういう方法で構築するのがよいのかなぁ。。。
0430デフォルトの名無しさん2013/12/08(日) 02:56:23.02
sshのポート開けたら終わりじゃないの
0431デフォルトの名無しさん2013/12/08(日) 03:12:00.83
>>429
目的は自宅サーバにリポジトリを持つことなの？
もし 2 人がアクセスできるプライベートリポジトリさえあればよいのならば、
Bitbucket を使った方がよいのでは？
無料アカウントでもプライベートリポジトリをいくつでも持てるし、ユーザも最大 5 人まで使用できるよ
https://bitbucket.org
0432デフォルトの名無しさん2013/12/08(日) 03:30:56.52
宣伝乙
0433デフォルトの名無しさん2013/12/08(日) 03:58:17.82
その規模ならVisual Studio Onlineでいいんじゃないの？
どの規模でもいいんだけど、その規模なら無料って意味で。
0434デフォルトの名無しさん2013/12/08(日) 05:39:11.64
外部サービスに置くのは怖いんじゃね
こちらに連絡なしに規約が変わったりするかもよ
0435デフォルトの名無しさん2013/12/08(日) 06:23:12.34
gmailとか
DropBoxとか
怖くて使えんな
0436デフォルトの名無しさん2013/12/08(日) 07:48:50.37
>>434
だからTFSじゃなくGitなんじゃないの？
二人だし規約が変わったらまた考えればいいでしょ。
0437デフォルトの名無しさん2013/12/08(日) 08:58:48.46
sshのポートあけて、gitoliteでリポジトリとアクセス制限の管理するのが一番シンプルに構築できると思う
0438デフォルトの名無しさん2013/12/08(日) 09:15:31.72
余談だけど
sshでパスワード認証はするなよ
0439デフォルトの名無しさん2013/12/08(日) 09:17:58.93
シンプルなのはVisual Studio Onlineだろね。
登録するだけですぐ使えるから。
0440デフォルトの名無しさん2013/12/08(日) 15:28:08.79
ステマというか堂々とした宣伝か
04414292013/12/08(日) 19:57:11.92
429です

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

一点確認なんですが、SSHは公開鍵認証にしてるけど、gitでsshをほかの人が使えるようにすると、
その人もPC自体をSSHで操作可能になる？
0442デフォルトの名無しさん2013/12/08(日) 20:19:13.96
>>441
ならない
0443デフォルトの名無しさん2013/12/08(日) 20:25:33.15
いや、なるだろ
0444デフォルトの名無しさん2013/12/08(日) 20:28:43.84
権限次第としか。

>>429だったら、なってもおかしくはないな。
0445デフォルトの名無しさん2013/12/08(日) 20:30:26.26
言葉が足りなかった。gitolite使えばならない
追加するのはgitolite用のアカウントだけ
0446デフォルトの名無しさん2013/12/08(日) 20:33:44.34
その点はgit-shellで解決可能かと
0447デフォルトの名無しさん2013/12/08(日) 22:26:30.40
Visual Studio Onlineって初めて聞いたけどgitベースなのか？
VSSはもうやめたんかよ。つーかXcodeにも対応してっしMSのくせに柔軟というか節操ないというか
0448デフォルトの名無しさん2013/12/08(日) 22:39:59.77
Microsoft Visual Studio：一歩先を行くバージョン管理
http://www.microsoft.com/ja-jp/dev/campaign/vsstotfs/default.aspx
0449デフォルトの名無しさん2013/12/08(日) 22:41:44.91
Visual Studio での Git の使用
http://msdn.microsoft.com/ja-jp/library/hh850437.aspx
0450デフォルトの名無しさん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 ユーザーまで無料です
0451デフォルトの名無しさん2013/12/08(日) 22:45:00.47
Visual Studio Online Basic
http://www.visualstudio.com/ja-jp/products/visual-studio-online-basic-vs
>主な機能
> ?プライベートな Git リポジトリを使用してコードをクラウドに保存する
0452デフォルトの名無しさん2013/12/09(月) 04:07:47.51
VSS光景のTeam Foundationは当然として
オープン規格でGitだけサポートってのは何故だろう、って気はする
あの会社ならSVNやHgまで同時にやれそうだし
Windows環境へのサポートは他のが良いくらいなんだが…
まあ、とはいえ選択肢があるのは良いことか
0453デフォルトの名無しさん2013/12/09(月) 04:11:21.46
VCSスレのほうでGitはWindowsに不向きとか散々書かれてたしね
0454デフォルトの名無しさん2013/12/09(月) 08:05:13.60
やっぱタイムスタンプも同期してくれないとWindowsでは使えんわ
0455デフォルトの名無しさん2013/12/09(月) 08:11:24.23
えっ？
0456デフォルトの名無しさん2013/12/09(月) 08:16:47.18
タイムスタンプ厨が出たぞー逃げろー
0457デフォルトの名無しさん2013/12/09(月) 08:35:19.13
どうせどっかの会社ごと買ったんだろ。すぐにダメになる。
0458デフォルトの名無しさん2013/12/09(月) 08:46:28.45
>>454
>>310
0459デフォルトの名無しさん2013/12/09(月) 10:29:34.12
>>452
最高の分散型VCSを作ってやるぜ！
↓
検討すればするほど、gitに近付いてしまう・・・。
そうか、最高の分散型VCSは既に存在したんだ。
それはgitだ。
よって、gitをサポートすることが最善。

って経緯らしいよ。
元々、様々なVCSをサポートすることは目的じゃない。
（そういう選択肢はプラグインインターフェイスだけ用意して、実装はサードパーティ任せ。）
0460デフォルトの名無しさん2013/12/09(月) 10:47:52.37
オプションでタイムスタンプ同期に対応したら完璧なのに
クライアントの当てにならない時計なんて信用できるか、ってやつは使わなければいいだけだし
0461デフォルトの名無しさん2013/12/09(月) 10:53:14.34
ぐちぐち言ってないでプログラマなら自分でやれ
0462デフォルトの名無しさん2013/12/09(月) 11:00:40.79
DropBoxがソースフリーで公開してくれたら解決だな
バイナリ差分の転送も上手にやってるし
0463デフォルトの名無しさん2013/12/09(月) 16:56:10.04
>>310
5スレ目の75あたりって1年前なんですが、１年前から変わってないってことなんすか
0464デフォルトの名無しさん2013/12/09(月) 16:59:43.16
いや
>>310 はタマタマ見つかったのを例に挙げただけで
もっと前から概出
0465デフォルトの名無しさん2013/12/09(月) 17:04:23.00
既出かどうか、というより、gitはタイムスタンプに関する仕様を変更する気はさらさら無いってことでつね
0466デフォルトの名無しさん2013/12/09(月) 17:20:19.98
仕様変わっても困らないんじゃね
0467デフォルトの名無しさん2013/12/09(月) 17:46:32.20
そんなにタイムスタンプ同期したいなら自分でhook書けよ、と
makeがタイムスタンプ見るから勝手に変えられると俺は困る
0468デフォルトの名無しさん2013/12/09(月) 19:14:14.60
MsBuildもタイムスタンプを見るから勝手に変えられると俺も困る
VisualStudioはMsBuildでビルドしてるので、全世界のVisualStudioユーザーも困る
0469デフォルトの名無しさん2013/12/09(月) 19:17:17.61
困らせたいんだろ。
0470デフォルトの名無しさん2013/12/09(月) 20:06:59.69
昔はファイルのタイムスタンプをチェックしてたけど、Git でソースプログラムを管理するようになってからはタイムスタンプを意識しなくなった
0471デフォルトの名無しさん2013/12/09(月) 22:27:52.68
contrib/diff-highlight ってバイト単位で比較しているから日本語が化けるね
勘で書いた patch ↓
pastebin.com/gHhShciR

utf-8 決め打ちとかいまいちなので、perl 分かる人いい感じにしてください
0472デフォルトの名無しさん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
0473デフォルトの名無しさん2013/12/16(月) 16:54:14.28
タイムスタンプ対応まだ？
0474デフォルトの名無しさん2013/12/16(月) 18:38:27.31
一生ないから自分でforkして自分で作っとけ
0475デフォルトの名無しさん2013/12/16(月) 20:08:51.32
Gitでの管理って
リリースの際はリリース用のブランチを切るの？それともタグ付けだけいい？
0476デフォルトの名無しさん2013/12/16(月) 20:24:17.50
>>475
そこのポリシーに従ってください。

ちなみに俺はリリース前から、開発版と安定版のブランチを使う。安定版へのマージがリリースになる。あ、でも最初のリリースまでは一本ってことだな。
0477デフォルトの名無しさん2013/12/16(月) 20:41:00.32
その場合masterブランチはどうなってるの？
0478デフォルトの名無しさん2013/12/16(月) 20:47:42.29
>>477
どっちだっけ。あんま気にしてない。何か違いあるの?
0479デフォルトの名無しさん2013/12/16(月) 20:57:38.17
よく分からなくなってきた
0480デフォルトの名無しさん2013/12/16(月) 21:01:51.77
Gitにおけるリリースブランチのつかいかた
http://www.eiplab.com/2011/06/git-release-branch/
0481デフォルトの名無しさん2013/12/16(月) 21:05:07.67
トピックブランチと統合ブランチでの運用例
http://www.backlog.jp/git-guide/stepup/stepup1_5.html
0482デフォルトの名無しさん2013/12/16(月) 21:26:26.14
リモートとワークツリー比較してリモートの方が最新だったらpullしてワークツリーの方が最新だったらcommit+pushみたく自動化することは出来ますか？
0483デフォルトの名無しさん2013/12/16(月) 21:35:47.68
>>477
masterはcloneした時にとくべ扱いされるから、気にした方が良いと最近思った
0484デフォルトの名無しさん2013/12/16(月) 21:43:07.51
>>475
Github にある Git 自身のリポジトリ（ミラー）を見ると
ブランチではなくてタグで対応してるみたいだけど。
https://github.com/git/git
0485デフォルトの名無しさん2013/12/16(月) 22:03:36.17
>>480-481を読めば全て解決
0486デフォルトの名無しさん2013/12/16(月) 23:04:45.55
masterブランチへのマージはリリースブランチが完成したものだけを常にマージ

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

開発ブランチでは作業しない、開発ブランチからメンバーが個々に作業用ブランチを切ってそこで作業・コミットして出来上がったら開発ブランチへマージする
04874752013/12/17(火) 00:27:12.19
>>476-486
ありがとうございます勉強になりました
色んな流儀があるんですね
0488デフォルトの名無しさん2013/12/17(火) 03:24:19.74
色んな？

皆本質は一緒だろ
0489デフォルトの名無しさん2013/12/17(火) 04:47:15.36
つまり本質以外は違うってことですね？
あなたの言う、本質ってのはなんですか？
0490デフォルトの名無しさん2013/12/17(火) 05:35:11.62
それぞれ別のものに見えるとしたら病院逝った方が良い
0491デフォルトの名無しさん2013/12/17(火) 07:01:04.44
既に病院にかかってる人から言われてもな
0492デフォルトの名無しさん2013/12/17(火) 07:50:07.52
ω
0493デフォルトの名無しさん2013/12/17(火) 19:45:36.61
どっちでもいいだろo
0494デフォルトの名無しさん2013/12/17(火) 20:03:26.54
>>482
？
0495デフォルトの名無しさん2013/12/19(木) 13:30:19.82
ローカルにコミットしたもの と リモートのリポジトリ との差分を
みたいんですが、どうしたらよいでしょうか
0496デフォルトの名無しさん2013/12/19(木) 14:44:36.75
>>495
とりあえず git branch -av とかやってみろ
0497デフォルトの名無しさん2013/12/19(木) 23:26:21.21
Git 1.8.5.2
https://code.google.com/p/git-core/downloads/list
0498デフォルトの名無しさん2013/12/20(金) 15:10:39.25
>>496
ありがとう
0499デフォルトの名無しさん2013/12/20(金) 15:13:57.74
git clone ssh://[email protected]/var/lib/git/UNKO.git
とかなんとかやりますが、
この ssh://[email protected]/var/lib/git/ の部分を
設定ファイルとかに書いたりとか出来たりとかします？
0500デフォルトの名無しさん2013/12/20(金) 16:25:06.53
>>499
[email protected]の部分はssh側の設定でaliasを付けられる
0501デフォルトの名無しさん2013/12/20(金) 19:50:12.90
>>500
ありがとう

これgitなんかに使うのもったいないレベルのTipsやん
ほーすげぇなこれ はー
0502デフォルトの名無しさん2013/12/20(金) 22:05:51.52
こんな感じだろ常識の範囲ではないか
Host g
Hostname github.com
User xyz
IdentityFile ~/.ssh/github
0503デフォルトの名無しさん2013/12/20(金) 23:50:49.22
ssh_config(5) 見ておくと色々幸せになるということだな。
0504デフォルトの名無しさん2013/12/21(土) 17:51:01.63
昔々rshというものがあってな
0505デフォルトの名無しさん2013/12/23(月) 11:16:11.63
結局、日本語のファイル名は使えるの？
0506デフォルトの名無しさん2013/12/23(月) 11:20:01.66
使えるよ
0507デフォルトの名無しさん2013/12/25(水) 22:53:01.74
checkoutってあいまいだよな
git checkout branch名　はbranch切り替えだけど
git checkout file名　はローカルファイル更新なんだよな
0508デフォルトの名無しさん2013/12/25(水) 22:58:48.73
へ？ どれもリポジトリからファイルを
チェックアウトするコマンドじゃん。

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

全部チェックアウトじゃんか
0509デフォルトの名無しさん2013/12/25(水) 23:00:39.32
ブランチ名とファイル名が同一のものあったら
0510デフォルトの名無しさん2013/12/25(水) 23:05:33.49
--
0511デフォルトの名無しさん2013/12/25(水) 23:06:38.08
普通ファイル名には拡張子つけるから
かぶることはまずないけどな。
心配な人は--をつけるようにすればいいだろう。
0512デフォルトの名無しさん2013/12/26(木) 08:24:06.69
git checkout branch名
の場合は
ファイルの取り出しだけでなくて
カレントブランチの切り替えも行うのだから
ぜんぶ同じってことはないと思うけど
0513デフォルトの名無しさん2013/12/26(木) 12:42:56.91
readme.mdはどのタイミングで入れるべきか教えてください

１．git initをしたあと
２．git initをするまえ
３．そのた
0514デフォルトの名無しさん2013/12/26(木) 12:50:56.29
好きな時でいいだろ
0515デフォルトの名無しさん2013/12/26(木) 12:59:46.51
readme.mdをaddする前
0516デフォルトの名無しさん2013/12/26(木) 13:17:03.09
敢えてinitial commitには入れないことにしてるな。その次で入れる。
readmeは何度も書き直したくなるが、initial commitだとrebaseで手出しできない。
0517デフォルトの名無しさん2013/12/26(木) 13:45:55.84
initial commitには何を入れるわけ？
0518デフォルトの名無しさん2013/12/26(木) 13:48:43.18
.gitignore
0519デフォルトの名無しさん2013/12/26(木) 16:30:41.22
何も入れずに --allow-empty
0520デフォルトの名無しさん2013/12/26(木) 16:57:56.85
ああ、git便利すぎて幸せ。
gitに弱点ってある？
0521デフォルトの名無しさん2013/12/26(木) 17:40:24.62
同じファイルをコミットしたらコンフリクトすること
ロックできないのが弱点
0522デフォルトの名無しさん2013/12/26(木) 18:21:02.13
ロックという考えがもう前時代的だよね
0523デフォルトの名無しさん2013/12/26(木) 18:30:24.35
コンフリクトをエラーのように言ってる人がけっこういる。
0524デフォルトの名無しさん2013/12/26(木) 19:02:49.50
複数人で修正してコミットしたらコンフリクトするのだから
ロックできれば未然に防げるはずなのだ
コンフリクトを起こさないのが良いバージョン管理方法である
0525デフォルトの名無しさん2013/12/26(木) 19:12:18.15
分散管理でロックとか不可能だろ
誰かがロックしたら全員のリポジトリのファイルにロックがかかるのかよ
0526デフォルトの名無しさん2013/12/26(木) 19:19:45.32
いまからさGit Wikiつくろうとおもうんだけど逆引きで
そしたらテンプレに入れてくれますか？アフィ張らないので
05275262013/12/26(木) 19:20:20.68
ちなみに初心者ですけど間違っているのをここの先輩方に直してもらうためにWikiを作るのです！
0528デフォルトの名無しさん2013/12/26(木) 19:55:51.33
サルでもわかるGit入門
http://www.backlog.jp/git-guide/
0529デフォルトの名無しさん2013/12/26(木) 20:12:11.66
>>524
コンフリクトしてから考えればいいじゃん。
ロックされててコミットできないとか困る。
0530デフォルトの名無しさん2013/12/26(木) 21:17:20.89
git diff
って、
git diff A B
という A、B が省略されているものだと思うんだけど
A、B が何なのかわからないので、知ってたら教えて。
0531デフォルトの名無しさん2013/12/26(木) 21:53:37.20
>>530
AはHEADまたはindexで、Bがワーキングコピー。
0532デフォルトの名無しさん2013/12/26(木) 22:04:46.27
git add .　ってやるとindexに保存されますけど
git commit する前にまたファイルを編集してgit add .をしたらindexを上書きしているって事であってますか？
つまり

git add.
git add.
git commit

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

コンフリクトの修正がいやなら自分のした修正を無かったことにすればいい。
ファイルをロックされるというのはそう言うこと
0534デフォルトの名無しさん2013/12/27(金) 00:11:26.44
コンフリクトはしたらいけないんですよ！
0535デフォルトの名無しさん2013/12/27(金) 00:12:50.45
コンフリクトはバグみたいなもんだからな。
発生したら「あれ？ 俺やらかしちゃった？」って思わないといけない。
0536デフォルトの名無しさん2013/12/27(金) 00:25:37.27
自分のとこを最新のにマージしてからプッシュしとらんのか
0537デフォルトの名無しさん2013/12/27(金) 00:30:53.07
最新のにマージする時にコンフリクトが起きたらどうするんだよ！
0538デフォルトの名無しさん2013/12/27(金) 00:35:46.30
解決しろよ
どうせどっち取るか選ばなきゃならんのだから
0539デフォルトの名無しさん2013/12/27(金) 01:20:31.98
>>537
それ何か問題あるの？
0540デフォルトの名無しさん2013/12/27(金) 07:46:09.79
コンフリクト起きる度にgitありがとうと思っている俺に隙は無かった
0541デフォルトの名無しさん2013/12/27(金) 11:13:12.07
コンフリクトって何だ。コンフリクトを知りたい。by梅原

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

そりゃ、同一行をいじったりしたら怒られるのは目に見えてるから、チーム間でコミュニケーションしながらだけど。
0542デフォルトの名無しさん2013/12/27(金) 18:06:39.25
同一行をいじらないためのコミュニケーションってイヤだな
0543デフォルトの名無しさん2013/12/27(金) 18:12:42.31
コミュニケーション不足
0544デフォルトの名無しさん2013/12/27(金) 20:37:13.04
ソースファイルは小さく小分けする方がいいだろ
複数人で１つのソースファイルを編集する必要がある大きさなんて、
俺やってるプロジェクトでは考えられない
0545デフォルトの名無しさん2013/12/27(金) 20:47:43.00
開発版とバグフィックスをマージしてコンフリクトとかあるだろ。
0546デフォルトの名無しさん2013/12/27(金) 21:04:33.79
複雑さと変更箇所のばらつきは極端に偏る
0547デフォルトの名無しさん2013/12/27(金) 21:33:49.36
コンフリクトをよく起こすファイルがある場合、設計ミスを疑うべきだな、何でそのファイルばかり修正が集中するのか
0548デフォルトの名無しさん2013/12/27(金) 22:09:54.27
>>547
頻繁に開発が行われているモジュールなら、変更もバグフィックスも多いだろうから必然だろう。
0549デフォルトの名無しさん2013/12/27(金) 22:43:43.06
>>548
コンフリクトがどういうときに起きるか理解してないだろ
0550デフォルトの名無しさん2013/12/27(金) 22:56:31.85
安価するとこ間違ってるぞ
0551デフォルトの名無しさん2013/12/27(金) 23:26:57.37
>>549
おまえがな
0552デフォルトの名無しさん2013/12/27(金) 23:33:58.22
コンフリクトがいやならSVNみたいな集中型でlockしたほうが幸せだぞ
0553デフォルトの名無しさん2013/12/27(金) 23:36:45.80
コンフリクトの修正手間が自分に係るのが嫌なんだろう？
0554デフォルトの名無しさん2013/12/28(土) 11:47:50.28
コンフリクトしたら、ロックされていたつもりになって
ローカルの変更を捨てればいいだけ
0555デフォルトの名無しさん2013/12/28(土) 13:28:47.67
コンフリクトで見つかるトラブルはまだありがたい。
相互に離れた場所で副作用でバグると見つけづらいし、片方直すと別の場所でバグる
0556デフォルトの名無しさん2013/12/28(土) 13:48:56.37
revert
0557デフォルトの名無しさん2013/12/28(土) 13:55:43.79
>>555
自動テストが必要だな。
0558デフォルトの名無しさん2013/12/28(土) 16:15:01.66
「ロックを"強制"して無駄なコンフリクトをなくす」というワークフローが構築できないから

やっぱ svn でいいじゃん
0559デフォルトの名無しさん2013/12/28(土) 16:30:36.50
ロックを強制する方が無駄が多いんだけどな
0560デフォルトの名無しさん2013/12/28(土) 16:54:20.47
素人開発にロックは厳禁。
みんなダメもとで開発して上手く行ったのを採用するんだからロックなんてできない。
まったくもって無駄。
0561デフォルトの名無しさん2013/12/28(土) 17:07:38.30
他人がロック中に作り貯めたやつをマージせずcommitする奴が出てくるんだよな
commitしようとしたらできなかったので、別の場所にコピーしておきましたとか
言われる。
0562デフォルトの名無しさん2013/12/28(土) 17:13:15.96
上がそう指示するのも当たり前に見かけるという
0563デフォルトの名無しさん2013/12/28(土) 17:15:25.11
そろそろ「バージョン管理システムについて語るスレ」に移らないか？
0564デフォルトの名無しさん2013/12/28(土) 17:53:37.15
そもそもツールの機能に頼るからいけないんだよ
バージョン管理の番人を1人つけるだけでトラブルがびっくりするほど無くなるよ

仕様書マイスターが1人いれば効率あがるのは知ってると思うけど
バージョン管理も同じ。余裕があるプロジェクトじゃないと無理だとは思うけどな
0565デフォルトの名無しさん2013/12/28(土) 18:03:42.17
このスレではGitと密着した話題だけしたいという人がVCS全般の話題はあっちのスレでと切に願っているわけだ

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
0566デフォルトの名無しさん2013/12/28(土) 20:55:18.43
>>564
24時間不眠不休なのですね。
0567デフォルトの名無しさん2013/12/28(土) 21:20:14.75
>>564
実際それが有用だから、Gitでpull request方式が流行ってるわけだな
0568デフォルトの名無しさん2013/12/28(土) 21:38:33.30
無責任なパッチを気軽に投げられるからな
0569デフォルトの名無しさん2013/12/28(土) 21:53:54.88
Gitくるぅ～Gitくるぅ～季節はしろくぅ～
0570デフォルトの名無しさん2013/12/28(土) 22:16:50.39
>>567
流行るもなにも、GitはLinux kernel用に作られたものだから、元々そういう
ワークフローが前提
0571デフォルトの名無しさん2013/12/28(土) 22:50:44.30
そんな前提は無い
0572デフォルトの名無しさん2013/12/29(日) 00:14:03.95
マメインラインにマージするには責任者（管理者）を通す運用が当たり前だよなあ
それができない会社は無能
0573デフォルトの名無しさん2013/12/29(日) 00:29:33.66
豆インライン？
0574デフォルトの名無しさん2013/12/29(日) 01:40:56.87
>>571
いやあるだろ
あの変態が作ったんだぜ？
0575デフォルトの名無しさん2013/12/29(日) 01:51:05.16
変態でごめん。
0576デフォルトの名無しさん2013/12/29(日) 05:43:04.31
お、おう
0577デフォルトの名無しさん2013/12/29(日) 10:31:50.10
変態？ 俺のことか？
0578デフォルトの名無しさん2013/12/29(日) 13:38:41.98
>>531
ありがとう
ワーキングコピーを明示的に書くとしたら
なんて書けばいいの？
0579デフォルトの名無しさん2013/12/29(日) 14:15:59.69
手元のレポジトリを リモートにベアリポジトリとして置きたいのだけど
どうしたらよいでしょうか

git clone --bare ./sample ssh://[email protected]:/var/lig/git/sample.git

とやってもローカルに ssh: とかいうディレクトリが出来て絶望した
0580デフォルトの名無しさん2013/12/29(日) 14:41:14.02
>>578
.
0581デフォルトの名無しさん2013/12/29(日) 14:44:57.13
>>579
リモート側で空のベアリポジトリを作ってそこにpushする
0582デフォルトの名無しさん2013/12/29(日) 14:50:53.82
>>581
それしかないの？
いちいちリモートにログインするのっていやなんだよな・・・
0583デフォルトの名無しさん2013/12/29(日) 14:53:14.40
>>582
ssh使ってるならログインしなくたってできるだろ
0584デフォルトの名無しさん2013/12/29(日) 14:57:08.14
間違えてた

git remote add origin ssh://[email protected]/var/lib/git/sample.git
git push
ってやればいいのか。
0585デフォルトの名無しさん2013/12/29(日) 15:02:45.30
>>584
それで何をするつもりだ？
0586デフォルトの名無しさん2013/12/29(日) 15:19:49.99
>>585
手元のレポジトリを リモートにベアリポジトリとして置きます。



これからリポジトリを作るのになぜかリポジトリがないと言われるのは
なんだろうgitさんってあんまり賢くないのかな
0587デフォルトの名無しさん2013/12/29(日) 15:36:01.25
>>586
>>584はリモートリポジトリにoriginっていう別名をつけるだけだアホ
お前がアホなんだよハゲ
0588デフォルトの名無しさん2013/12/29(日) 15:46:30.51
コンフリクトなんてするべきじゃない
ロックもできないとかクソすぎる
今後はGitのこういう欠点を修正した新しいバージョン管理が登場してGitなんて使われなくなるよ
そうSVNみたいな過去のものになるだけ
0589デフォルトの名無しさん2013/12/29(日) 15:48:09.10
testブランチにいます
ファイルを更新しましたが一時的にmasterブランチに移動したいのです
このとき
１．git add をしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか？
２．git add をしてgit commitしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか？

それぞれ教えてください
0590デフォルトの名無しさん2013/12/29(日) 15:55:32.76
>>589
Gitのリポジトリなんか簡単につくれるんだから
試しにやってみようかと思わないの？
0591デフォルトの名無しさん2013/12/29(日) 16:00:39.39
>>588
コンフリクトを撲滅したいなら、ロックをサポートするだけじゃなくて
ブランチのマージをできないようにしないとダメだよ
どっちも導入すると随分不自由な仕組みになるな
0592デフォルトの名無しさん2013/12/29(日) 16:19:16.58
>>590
怖くて手が震えてできませんっ！
OSが壊れたらどうしようと思って
0593デフォルトの名無しさん2013/12/29(日) 16:59:33.08
つまんね
-35894点
0594デフォルトの名無しさん2013/12/29(日) 17:16:35.13
>>592
まず、アル中の治療から始めましょうか
0595デフォルトの名無しさん2013/12/30(月) 04:15:37.23
>>587
なるほど。 リモートに置くにはどうしたらいいかな。
おしえてフサフサな人
0596デフォルトの名無しさん2013/12/30(月) 11:41:52.28
リモートにリポジトリを作る方法は、リモート側のシステムに依存する
0597デフォルトの名無しさん2013/12/30(月) 12:15:50.64
なんパターン化あるなら、
その代表例を言えばいいよ。
1つでもいいんだぜ？
0598デフォルトの名無しさん2013/12/30(月) 12:17:26.83
git addしたあとにまたファイルを更新したんですがこの場合はどうしたらいいんですか？
そのままgit addを取り消すのか？git addをそのままうっちゃっていいのか？
0599デフォルトの名無しさん2013/12/30(月) 12:38:53.37
>>597
リモート側でGitoliteを使ってるなら、
gitolite-adminリポジトリのgitolite.confを編集してpushすれば新しいリモートリポジトリが作成される
そこにローカルリポジトリをpushする
0600デフォルトの名無しさん2013/12/30(月) 12:40:31.79
>>598
git addを追加で行えばいい
0601デフォルトの名無しさん2013/12/30(月) 12:44:18.74
GitのGUIは分岐も表示できるじゃないですか
あれをぼくも作りたいんですけど、ああいうログってgit logの出力をパースしてるだけなんでしょうか？
0602デフォルトの名無しさん2013/12/30(月) 12:50:37.25
>>599
ありがとう
gitコマンドだけではやはり無理ってことですか
世の中うまくいかないもんですな
0603デフォルトの名無しさん2013/12/30(月) 13:03:41.65
そもそもUNIXのコマンドは単品に機能を過剰に詰め込んだりしない
gitコマンドも同じようなポリシーで作られてる
ネットワーク関係の機能も自身が持たずにsshコマンドとかに多くを依存してる
ローカルにリポジトリを作る機能さえあればsshと組み合わせてリモートにリポジトリを作るのも簡単にできる
それによってネットワークに関わるセキュリティ的な部分をgit自身が抱え込まずにsshに任せられる
これで世の中うまくいっている
0604デフォルトの名無しさん2013/12/30(月) 13:06:39.87
>>601
パースしてもいいし、gitのファイル構造は簡単だから自分で読んでグラフデータ構造を構築してもいい
分岐の表示はgit log --graphとかでCUIでもできる
0605デフォルトの名無しさん2013/12/30(月) 17:22:21.53
>>603
車輪の再発明的なことを避けたってこと？
0606デフォルトの名無しさん2013/12/30(月) 17:42:59.06
UNIXの考え方はこれでいいや。
http://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

でかくすると保守しにくいからね。
0607182013/12/30(月) 21:24:46.36
>>605
単機能のプログラムとプログラムを繋ぐ仕組み (パイプとかシェルとか) を提供して、プログラムを組み合わせることで目的を達成するようにした。
利用者にそれなりのスキルがあることが前提になる。
あと、GUI だと繋ぐ仕組みがうまく機能してないので、GUI 上のアプリは Windows とたいして変わらない。
0608デフォルトの名無しさん2013/12/30(月) 21:40:18.85
GUIのアプリといっても中でCUIのコマンドを組み合わせて動いてるのも多いけどな
0609デフォルトの名無しさん2013/12/31(火) 10:15:07.74
来年こそはタイムスタンプに対応してくらさい
0610デフォルトの名無しさん2013/12/31(火) 10:22:21.36
永遠に対応しないことが決定してる
0611デフォルトの名無しさん2013/12/31(火) 14:07:33.94
>>602
なんか難しく考えてるみたいだが、リモートが普通のUNIXなら
ローカルでつくったベアリポジトリをリモートにコピーすればいいだけやで
0612デフォルトの名無しさん2013/12/31(火) 14:18:28.15
>>611
sshでログインしたくなかったけど
gitサーバも立てたくないワガママが
ことの発端なので、あきらめました
0613デフォルトの名無しさん2013/12/31(火) 14:27:55.57
×わがまま
○怠惰
0614デフォルトの名無しさん2013/12/31(火) 14:37:48.81
>>612
ログインしなくてもscpでコピーすればいいし、
アクセスするのはsshd経由だからgitサーバはいらんよ？
ほんと何もわかってないのにに口だけ達者だな
0615デフォルトの名無しさん2013/12/31(火) 14:45:45.05
とにかくWindowsで色つきのやつおしえて
コマンドプロンプトは色が着かない
0616デフォルトの名無しさん2013/12/31(火) 14:49:29.74
cygwinでminttyをつかう
0617デフォルトの名無しさん2013/12/31(火) 15:08:46.55
一応cmdでも色つくよ。
cygwinいれてexeある場所にパス通すと
lsとかのexeがつかえるのだが、
ls --colorとか打ち込むと色分けされる。

ぶっちゃけメンテとか詰めとが実用的なレベルにすらならない低さで甘いだけ。
一応機能的には色分けできる。
0618デフォルトの名無しさん2013/12/31(火) 17:16:10.14
>>614
scpでコピペって、sshでログインするのとどれだけ違いがあるのよ
だいたい相手のファイル構成知らなきゃならない時点でダメだろ
0619デフォルトの名無しさん2013/12/31(火) 17:28:06.31
コピペｗ
別にどこに置いてもいいんだから自分のホームディレクトリにコピーしろよ
書き込み権限無いとこに置きたいならリポジトリ管理ツール用意してもらえ
0620デフォルトの名無しさん2013/12/31(火) 17:32:58.20
そいつはたぶんUnixとか使ったこと無いからまともに相手にしても無駄だぞ
0621デフォルトの名無しさん2014/01/01(水) 11:40:09.64
>>620
つまらないレッテル貼りはやめなよ
0622デフォルトの名無しさん2014/01/01(水) 15:42:08.86
GitHub for Windows のコマンドラインシェルって
プロンプトにブランチ名が色つきで表示されてた。
あのプロンプトだけは素敵だな。
それ以外は使いづらいシェルだったが。
0623デフォルトの名無しさん2014/01/01(水) 15:50:46.01
>>621
レッテル貼りの定義はよ
0624デフォルトの名無しさん2014/01/01(水) 16:14:24.62
修正すれど修正すれど、わが暮らし楽にならざり
Git手を見る
0625デフォルトの名無しさん2014/01/01(水) 16:52:56.91
くだらん自尊心ばっかりだ
0626デフォルトの名無しさん2014/01/01(水) 17:51:00.97
１．masterブランチでファイルを更新しました
２．addとかcommitとか何もしないでgit checkout -b testでtestブランチに移動しました

この場合masterブランチで更新した内容は消えてしまいますか？
0627デフォルトの名無しさん2014/01/01(水) 18:12:36.76
git checkout -b <branch>なら消えない
既存のほかのブランチに(-bなしで)移動するなら、
消えない(git管理下でないファイルの場合)か、またはエラーになって移動できない(git管理下のファイルの場合)
0628デフォルトの名無しさん2014/01/01(水) 18:24:51.79
ってことはtestブランチでadd してcommitしてからmasterブランチに移動したら
１の時点のファイルの内容は復活するということですか？
0629デフォルトの名無しさん2014/01/01(水) 18:34:39.56
もう、本気で本読むとか入門サイト読んでくるとかした方がいい
何この初歩的な質問、ありえないんだけど・・・
0630デフォルトの名無しさん2014/01/01(水) 18:54:45.37
馬鹿には無理
0631デフォルトの名無しさん2014/01/01(水) 21:46:03.98
>>626とか>>628みたいな疑問が最初出てくるのはしょうが無いし、
本読むだけじゃなんかよくわからないだろうから、自分でリポジトリ作って試せ
git statusやgit diffで状況を確認しつついろいろやってみろ
ローカルで簡単にリポジトリ作ったり消したりできるgitの利点だ
0632デフォルトの名無しさん2014/01/02(木) 04:21:21.52
>>629
上級者専用スレを立ててください。お願いします。
0633デフォルトの名無しさん2014/01/02(木) 04:23:00.28
これ一通り読む気が無い人が質問してるん？
読んで分からなかったら分からなかった箇所を訊いてこいよ

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

つまり公式は2ch未満の肥溜め
0635デフォルトの名無しさん2014/01/02(木) 09:19:25.42
そうだな
Junioをさっさとクビにして2chの有志がGit開発しないと
0636デフォルトの名無しさん2014/01/02(木) 09:55:11.27
>>634
んー、状況がわからんけどブランチ切らずに修正してるのか？
gitでの修正/開発はブランチでやるのが基本だと思うのだけど。
あと、マージもあまりしない方がいいってのもある。

あと、公式のマニュアルは、そこいらの入門書買うよりおすすめできる内容だと思うけどね
0637デフォルトの名無しさん2014/01/02(木) 09:59:45.53
あー、失礼。
コミットした人がFFしてないのか。
しょっちゅうやらかすようなら、説教ですね。
0638デフォルトの名無しさん2014/01/02(木) 10:14:19.35
>>632
>>628の答えが分かる人が「上級者」だとでも思ってるの？
「コミットってどうするのですか？」ってレベルの質問だぞ
何でもかんでも質問するんじゃなくて、最低限は学んで来いよ
0639デフォルトの名無しさん2014/01/02(木) 10:25:40.95
答える気がないなら黙ってろよ役立たず
0640デフォルトの名無しさん2014/01/02(木) 10:59:22.95
馬鹿には無理
0641デフォルトの名無しさん2014/01/02(木) 11:41:28.05
>>636
あのさ
修正も何もないんだよ
手元で何もしてないのにpull繰り返すだけでコンフリ起こすから糞だと言ってる
FFしてないわけでもない
そもそもFFでないと禁止されてて蹴られる
0642デフォルトの名無しさん2014/01/02(木) 11:47:44.21
これはgit本体ではないと思うがpushしたら鯖側で不具合あって
手元では送れたことになってるのに鯖側では変更されてないなんてこともあったな
そんな具合であまりに不具合が多すぎる

だがしかし公式なんかにはその時どうする必要があるのかなんて書いてない
検索も実質不可能なんだな

そんなわけで作業は全てツリー外でやるようになりましたとさ
0643デフォルトの名無しさん2014/01/02(木) 11:50:24.86
>>641
そんなバカな
0644デフォルトの名無しさん2014/01/02(木) 11:54:20.89
「何もしていないのにパソコンが壊れた」と言ってるヤツと同じタイプか
0645デフォルトの名無しさん2014/01/02(木) 11:55:21.82
そんなバカなことが現実に起きるのがgit
一方svnなら途中でトラブったら戻してくれる
0646デフォルトの名無しさん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
0647デフォルトの名無しさん2014/01/02(木) 12:03:00.36
>>641
それコンフリクトじゃないだろ
rebaseとかしてて公開していない本来pull元にすべきじゃないブランチを
おまえがpull元に指定しちゃってるだけだろ
0648デフォルトの名無しさん2014/01/02(木) 12:10:35.86
>>646
おまえ手元で何もしてないと言ってるのに、
その>>646の手元で行った修正を無効にして強引にpullする方法が有効だった意味が理解できてる？
何も理解せずに対処療法でとりあえずうまくいったから得意満面かよｗ
本が役に立たないとか言ってるが、Junioの本をよく読めば何が起こってるのか理解できるぞ
0649デフォルトの名無しさん2014/01/02(木) 12:14:19.39
>>642
gitは手元で送れたかどうかなんて情報は保存してないので
もう一度pushすればいいだけ
確実にpushできたかどうかはfetchして確かめろ
0650デフォルトの名無しさん2014/01/02(木) 12:16:16.79
もしそんな不具合てんこ盛りだったらLinuxカーネルの開発には使えんわな
0651デフォルトの名無しさん2014/01/02(木) 12:16:28.11
だーかーらー、公式が理解できない糞だから言ってるんだろうが！！！！
Junioとやらはてめえが作ってるソフトのこともろくに説明できない糞なんだよ
このスレの連中の方がJunioとやらよりよっぽどGit理解しててわかりやすく説明してくれてる
このスレがあれば糞みたいな本もGit公式とかも不要
0652デフォルトの名無しさん2014/01/02(木) 12:18:32.11
ワラタｗｗｗｗｗｗｗｗｗ
0653デフォルトの名無しさん2014/01/02(木) 12:27:47.69
純ちゃんの本買ってやれよｗ
ここのスレでいろいろ説明したりしてるば、最初はこの本で勉強したぞｗ
0654デフォルトの名無しさん2014/01/02(木) 12:45:36.21
gitは動作原理が単純で中で何をやってるか理解しやすいから
原理を理解しちまえば大抵の問題は自分で対処できるんだよね
上っ面だけ理解しようとすると大変で>>651みたいに顔真っ赤になる
0655デフォルトの名無しさん2014/01/02(木) 12:59:32.71
何故か必死な奴が何人も湧いてるけどさ
647とか648とか完全に的外れなんだよね
扱ってるのは当然許可されてる開発用の公開ブランチだし他のブランチなんか触ることはない
pull繰り返すだけで634の状況になるから646だし

651は俺じゃねえよ
0656デフォルトの名無しさん2014/01/02(木) 13:11:04.92
>>655
改変が行われていない公開ブランチをpullしてるだけで
git reset --hard origin/upstream_worktreeが必要になるとしたら、
明らかに環境が壊れてる
gitコマンドがOSのファイルシステムを正常にアクセスできてない
どういう環境で使えばそんな馬鹿なことになるんだ？
git reset --hardでとりあえず凌いでもワークツリーの状態が
正常である保障は何もないぞ
そんな環境を使うのをやめろ
0657デフォルトの名無しさん2014/01/02(木) 13:16:36.72
王様のブランチ
0658デフォルトの名無しさん2014/01/02(木) 13:21:10.87
>>655
「当然許可されてる開発用の公開ブランチ」であってもrebaseされていない保障は無いぞ？
そのブランチがrebaseされていないことを確認した？
GCされてなければ今からでもreflog使えば確認できるぞ？
Junioの本をちゃんと読めばこの辺のことも理解できる
0659デフォルトの名無しさん2014/01/02(木) 13:23:23.72
FFじゃないってgitが検出してるならそれは正常な動作だな
上流のブランチ管理してる奴が馬鹿なだけだ
0660デフォルトの名無しさん2014/01/02(木) 13:29:41.53
>>656
普通のM$謹製vistaだからな
あいにくpcの9割はこちらの流れなんだよね
>>658
rebaseされていない保障は無いとか言われてもねえ
ローカルで何も変更してないのにまともに同期できない時点でまともじゃねえわ
646見つけるまで何度かcloneし直したわ

Junioの本だかなんだかしらねえけどさ
こちとら仕方なく使う羽目になってるだけでgitなんかには興味ねえのよ
0661デフォルトの名無しさん2014/01/02(木) 13:30:38.52
japan.blogs.atlassian.com/2013/11/git-team-workflows-merge-or-rebase/
そのリポジトリがマージを一切せずにリベースだけでいくと決めてるならそれはそれでアリ。そのプロジェクトの方針ぐらいは尊重してやれ。
pullに--ff-onlyでも付けとけ。
0662デフォルトの名無しさん2014/01/02(木) 13:39:22.53
windows用の単純なgit.exeって配布されて無いの？
インストーラーとかcygwinとかはできれば避けたいんだけど
0663デフォルトの名無しさん2014/01/02(木) 13:44:12.70
gitの中身は半分bashスクリプトとpythonなんで、シェル環境ごと持ってこないと㍉
0664デフォルトの名無しさん2014/01/02(木) 13:51:59.77
プロジェクトの方針とか関係無く、公開してるブランチのコミットを改変するとか普通は有り得ないよ
リベースだけで運用するとしても、公開ブランチにリベース済みのコミットをpushすることになるだけで、
公開したコミットを改変することは普通しない

でも管理上どうしても改変したいときもあるから、それをgitは許してる
うちとか止むを得ずそれやるときはpullしてるみんなに平謝りして回る
頻繁に公開ブランチ改変してるとしたら管理が糞すぎる
0665デフォルトの名無しさん2014/01/02(木) 14:04:50.69
ウチはこうしてる(から他のプロジェクトもこうするべきだ)なんてのはgit以前に傲慢過ぎやしないか
0666デフォルトの名無しさん2014/01/02(木) 14:11:05.28
>>665
公開ブランチの改変のことを言ってるの？
公開ブランチのコミットを改変することの意味を理解してる？
0667デフォルトの名無しさん2014/01/02(木) 14:21:03.73
メリットデメリットは>>661のリンク先でも論じられてるだろ
わかってやってるなら問題ない、そういうことだ

機能ブランチではrebaseしまくってmasterへはcherry-pickのみでもいいというかそっちが普通だろうけど
0668デフォルトの名無しさん2014/01/02(木) 14:32:54.66
わかってなくてやってるから馬鹿が騒いでるんだろｗ
わかってるならpullしてる馬鹿全員にちゃんと説明して回れｗ
0669デフォルトの名無しさん2014/01/02(木) 14:36:22.57
上の奴は、pullしてるだけのプロジェクト外の人間じゃないのか？w
0670デフォルトの名無しさん2014/01/02(木) 14:38:03.65
>>660
cloneの必要ないだろｗ
resetだって必要無いｗ
ローカルなブランチ消して作りなせばいいだけじゃないかｗ
0671デフォルトの名無しさん2014/01/02(木) 14:43:04.72
>>660
ローカルで変更してないわけない。
コミットしてないだけで何かしらの変更をワークツリーに加えてるから>>646で解決出来る状態になる。
おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの？
0672デフォルトの名無しさん2014/01/02(木) 14:46:04.19
>>667
いやなんか勘違いしてるぞ
rebaseチームポリシーでも公開してるブランチの履歴をリベースして改変しちゃダメだ
公開ブランチへのpushはつねにFFで行う。
pushの前に非公開ブランチでリベースはすましておく。
当然ながら非公開ブランチで行うリベースは公開ブランチのコミットを巻き込んではいけない。
(公開ブランチへのpushがFFでなくなるから)
0673デフォルトの名無しさん2014/01/02(木) 14:53:35.74
まあ公開してた機能ブランチをリベースしてマスターにpushするとかもありだと思うけどね
その時点で機能ブランチはクローズすべきだよ
もしくは機能ブランチはそのまま残して、機能ブランチから作った非公開ブランチ上でリベースしてpushするとか
公開したブランチを改変してそのまま履歴をさらに伸ばすとか絶対良いことないからやめとけ
0674デフォルトの名無しさん2014/01/02(木) 15:03:21.18
公開ブランチをrebaseするのと
rebaseしたコミットを公開ブランチにFFでpushするのを区別できてない奴がいるのか
0675デフォルトの名無しさん2014/01/02(木) 15:04:51.46
ちなみに、一体どんな差分がコンフリクトするの？
pullしたときの、状況の方が気になるな。
0676デフォルトの名無しさん2014/01/02(木) 15:10:54.53
>>673
masterとの差が離れてきたとかここらで一旦履歴を可読にしたいとかで
rebaseしてmasterと足並みを揃えてから機能ブランチは継続もアリと思うけどね
0677デフォルトの名無しさん2014/01/02(木) 15:21:00.37
>>676
自分だけがその機能ブランチを使うならそれでいいと思うよ
その機能ブランチを公開してるならブランチを変えた方がいい
0678デフォルトの名無しさん2014/01/02(木) 15:30:38.09
お正月から賑やかだなｗおまえらｗ
0679デフォルトの名無しさん2014/01/02(木) 15:55:43.22
>>671
たぶん上流が履歴を改変してる
origin/upstream_worktreeへのfetchはデフォルトの+つきで行われるから自動的に上書きされるけど、
それでorigin/upstream_worktreeとローカルのupstream_worktreeのFF状態が崩れるから、
非FFなマージが走ることになって失敗するんじゃないかな
本来pullしてるだけなら非FFマージは走らないからコンフリクトとか有り得ないからね
0680デフォルトの名無しさん2014/01/02(木) 16:56:55.46
ところで、上流がpush -fされた時のメッセージはforced updateなんちゃらであって
>>646のYour local changes to the following files would be overwritten by mergeってのは出ない気がする
手元で確認して確かめた

なのでやっぱり、手元で何かしちゃってるはず
0681デフォルトの名無しさん2014/01/02(木) 17:53:58.95
>>680
そう思うだろうけどしてないんだよね
つーか上と下関係なくね?
覚えてないけどYour local changes云々は違うかもしれんよ
そのログは参考にした対処だからね

何か月も過ぎてるから良く覚えてないけどgitと破棄で検索して見つけたのかなあ
0682デフォルトの名無しさん2014/01/02(木) 19:30:19.89
周知もせず履歴の改変を行う管理者と
適当に検索してその場しのぎの対処で誤魔化すプログラマとか最悪だな
0683デフォルトの名無しさん2014/01/02(木) 20:40:34.46
上から権限をスター的な構成にしたいけど難しいよな
0684デフォルトの名無しさん2014/01/02(木) 20:50:57.58
>>683
Gitoliteとか使うんじゃダメなのか？
0685デフォルトの名無しさん2014/01/02(木) 23:22:59.71
>>681
関係あるだろ、だってYour local～ってのは将に手元で変更してたときのメッセージだもの
0686デフォルトの名無しさん2014/01/03(金) 00:48:30.57
>>638
うるせーはげ
0687デフォルトの名無しさん2014/01/03(金) 11:47:32.11
>>671
> おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの？

AndroidのカスROM作ろうとしてAPIにメソッド追加したりすると、ビルド生成物の一部が管理対象に含まれてるんで、こうなる。
API変更しておいて生成物の更新を忘れてたままpushすると顰蹙もの。
0688デフォルトの名無しさん2014/01/03(金) 16:09:05.10
git reset --hard HEAD
0689デフォルトの名無しさん2014/01/05(日) 02:30:52.82
Githubって無料じゃプライベートリポジトリ作れないの？
なんか使えねーな。
個数制限３つとかできりゃいいのに。
0690デフォルトの名無しさん2014/01/05(日) 02:42:44.34
BitBucketの存在も知らずに「Githubって使えねえゴミ」とか罵倒する奴にGitを使ってほしくない
0691デフォルトの名無しさん2014/01/05(日) 02:46:04.88
>>689
bitbucketとかでやればいいんじゃね
0692デフォルトの名無しさん2014/01/05(日) 02:48:43.30
>>690-691
情報ご苦労
使えねえGithubはbitbucketに潰されろ
0693デフォルトの名無しさん2014/01/05(日) 03:14:40.68
↓機能してるスレかは分からんが、Gitで無料でプライベートリポジトリ作れるとこ教えてくれるかもしれんぞ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
0694デフォルトの名無しさん2014/01/05(日) 03:21:21.01
>>692
わざわざ煽りご苦労。
0695デフォルトの名無しさん2014/01/05(日) 08:33:05.15
プライベートリポジトリって秘密にしたいもの置くんだろ
無料のサービスを信用するって頭沸いてるとしか思えない
0696デフォルトの名無しさん2014/01/05(日) 09:32:28.75
誰も信用するとは書いていないが
0697デフォルトの名無しさん2014/01/05(日) 09:35:32.12
そこに秘密のファイル置くんだろ
0698デフォルトの名無しさん2014/01/05(日) 09:40:39.34
無料を信用するより、信用してないとこに秘密のファイル置く方が、よりヒドイと思うんだがw
0699デフォルトの名無しさん2014/01/05(日) 10:01:38.12
自分でGit鯖立てればいいじゃん
GitLabでもGitoliteでも好きなの選べ
0700デフォルトの名無しさん2014/01/05(日) 10:22:28.47
アホかこいつ
0701デフォルトの名無しさん2014/01/05(日) 10:31:16.72
プライベートでなけりゃ、無くなる心配だけすればいいけど
プライベートだと、それに加えて盗まれる心配もしなきゃならない
0702デフォルトの名無しさん2014/01/05(日) 14:58:33.54
Github「お前のものは俺のもの」
0703デフォルトの名無しさん2014/01/05(日) 15:01:27.82
「アトリエのどか式 Git入門」
ttp://www.atelier-nodoka.net/2013/12/c85-information/

この本ってお勧めですか？
0704デフォルトの名無しさん2014/01/05(日) 15:04:45.53
>>703
表紙が気に入ったら買えばいいのでは？
内容はネットで読めるみたいだし。
0705デフォルトの名無しさん2014/01/05(日) 15:11:47.14
>>702
金も払わずにプライベートリポジトリが使えて当然とか、乞食かよ
0706デフォルトの名無しさん2014/01/05(日) 16:11:14.76
Evernote, Dropbox 「ウェルカム乞食」
0707デフォルトの名無しさん2014/01/05(日) 17:06:07.43
>>706
EvernoteとDropboxは無料で体験してもらって有料プランに引き込むビジネスモデルだから全く話が違う。
GitHubは、まず根底に「全てのソフトウェアは自由であるべき」っていうフリーソフトウェア運動の理念があって、
フリーソフトウェアの要件のひとつである「オープンソース化」を促進するのがそもそもの存在意義なんだな。
でもそれだけじゃサービスを維持できないから、金をとってクローズドソースでのリポジトリホスティングもやってるわけ。
有料と無料の違いはプライベートにできるかどうかだけなんで、機能とかを体験するならオープンのリポジトリでやってもらえばよくて、
無料でプライベートリポジトリを提供する理由がない。文句あるなら金払うかオープンソースでどうぞって話。
0708デフォルトの名無しさん2014/01/05(日) 17:19:36.92
自由であるべき理想、というより、お前の自由は俺に金を払わなきゃ与えない、ってことだよな。
0709デフォルトの名無しさん2014/01/05(日) 17:25:08.24
>>708
なんで自分のことしか考えない(=金を払わない&ソースも公開しない)人間に無銭の宿(リポジトリ)を提供しなきゃならんのさ。
世の中ギブ&テイク。リポジトリを使わせてくれというのなら対価は必要だ。
GitHubの場合はそれが単なる金か、あるいは世の中への貢献(=ソースコードの公開)ということさ。
金も払わない、世の中への貢献もしない、でもリポジトリは使わせろってそっちの方が無茶苦茶言ってるぞ?
0710デフォルトの名無しさん2014/01/05(日) 18:15:54.46
「使えねえ」なら見かけたが「使わせろ」とは誰も書いてない
0711デフォルトの名無しさん2014/01/05(日) 18:20:10.94
>>710
?
有料でしかプライベートリポジトリ使えないのかよ、使えねぇな=無料でプライベートリポジトリ使わせろ
ってことでしょ?
0712デフォルトの名無しさん2014/01/05(日) 18:28:32.04
>>711
使えねえから使わない。だろ
おまえホント使えなさそうだな
0713デフォルトの名無しさん2014/01/05(日) 19:13:38.03
正確に言うと、

無料で使えないから、使わない

という話。

別にgithubの機能が劣っているわけじゃない。
むしろ優れている。

だが金かかるので使わない。
0714デフォルトの名無しさん2014/01/05(日) 19:22:51.35
使えねえのは貧乏な俺だったというオチ
0715デフォルトの名無しさん2014/01/05(日) 19:31:23.04
gitに無料のお試しプライベートリポジトリサービスがあればいいのに、って書いただけで
どうしてそこまで発狂できるのかふしぎ
0716デフォルトの名無しさん2014/01/05(日) 20:04:57.67
>>715
おまえが最初に煽ったからだろ
> Githubって無料じゃプライベートリポジトリ作れないの？
> なんか使えねーな。
0717デフォルトの名無しさん2014/01/05(日) 21:33:45.92
Githubって無料じゃプライベートリポジトリ作れないの？
なんか金払えない俺には使えねーな。
0718デフォルトの名無しさん2014/01/05(日) 21:35:29.19
つまり、使えねえのは貧乏な俺だったというオチ
0719デフォルトの名無しさん2014/01/06(月) 00:25:11.50
>>706
Google大先生も入れてあげて
0720デフォルトの名無しさん2014/01/06(月) 04:46:08.61
Gitはスナップショットだから、無駄に大量にコミットしまくるとゴミデータが溜まりまくる・・・
0721デフォルトの名無しさん2014/01/06(月) 05:00:12.07
ブランチの切り替えは大量のファイル移動があってHDD負荷が
0722デフォルトの名無しさん2014/01/06(月) 11:50:47.99
>>720
過去のコミットは圧縮がかかるので、
差分を保持してるのとほとんど代わらない程度のディスクスペースしか消費しない
0723デフォルトの名無しさん2014/01/06(月) 11:53:05.51
>>721
かなり大規模なプロジェクトでも、
問題になるほど大量のファイル書き換えが起こることはマレだよ
0724デフォルトの名無しさん2014/01/06(月) 12:56:06.48
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
git関係ないんだから、こっちでやれよ
0725デフォルトの名無しさん2014/01/06(月) 14:04:11.57
BitBucket使えばいいじゃん
0726デフォルトの名無しさん2014/01/06(月) 15:25:56.39
723までで流れが元に戻ってんのに蒸し返す馬鹿なんなの
0727デフォルトの名無しさん2014/01/06(月) 15:36:14.89
燕返し！
0728デフォルトの名無しさん2014/01/07(火) 04:04:08.39
> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。

友人や家族からも軽蔑されるのかよ！
0729デフォルトの名無しさん2014/01/07(火) 04:10:23.48
リベース、つまり今までプッシュしてないブランチにマージしたい先のブランチの最新状態を取り込むってことやな
0730デフォルトの名無しさん2014/01/07(火) 13:55:51.90
>>728
公開したコミットをリベースする奴なんてもううちの子じゃないよ
0731うちの子2014/01/07(火) 14:02:50.88
お前の子だった覚えがないわ>>730
0732デフォルトの名無しさん2014/01/07(火) 14:10:17.62
J( 'ｰ`)し＜ごめんね。おかあさんはじめてpull失敗して散々だったから、ごめんね
0733デフォルトの名無しさん2014/01/07(火) 15:21:34.71
リモートブランチに含まれているコミットをrebaseしようとしたら警告が出るとか無いのか
0734デフォルトの名無しさん2014/01/07(火) 15:50:50.86
使ったこと無いの？普通はpushできない設定になってる
リモート側で直接リベースすることはできるけど、
普通は公開してるリポジトリのブランチを直接操作しない
0735デフォルトの名無しさん2014/01/07(火) 17:32:17.99
>>734
誤読だ
rebase段階での警告が無いと不便と思うだろう？
0736デフォルトの名無しさん2014/01/07(火) 17:54:08.19
pushの段階のエラーで十分だわ
Gitの仕組み的にそれをチェックしようとすると実装も使い勝手も面倒なことになる
0737デフォルトの名無しさん2014/01/07(火) 18:35:49.21
使ったこと無いのはどっちなんだ
紐付いてるupstreamと比べるだけだろ
0738デフォルトの名無しさん2014/01/07(火) 19:33:28.65
Git使ったことないんだけど、自分だけがバージョン管理に使いたい場合、
SourceTreeとかインストールすればローカルのリポジトリって作れるの？
0739デフォルトの名無しさん2014/01/07(火) 19:47:05.02
作りたいディレクトリの場所で
git init
と打つだけで準備はOK。
git add somefile
でステージングエリアに、
git commit
でコミット可能。　等といった要領でローカルリポジトリ作れる。
0740デフォルトの名無しさん2014/01/07(火) 19:52:41.07
githubのプライベートリポジトリの話ではないだろうか

まさかね
ははは、かんがえすぎだよね
0741デフォルトの名無しさん2014/01/07(火) 20:09:32.06
>>739
サンクス
やってみる
0742デフォルトの名無しさん2014/01/07(火) 20:10:42.83
その場にリポジトリができるのは便利ではあるんだけど
バックアップ的な意味では不安なんだよな…
0743デフォルトの名無しさん2014/01/07(火) 20:14:32.60
>>737
リベースするときに上流のリポジトリにアクセスするとかありえんわ
ローカルのremotes/originはpushした上流の情報をつねに保持してるわけじゃないからな
0744デフォルトの名無しさん2014/01/07(火) 21:10:49.21
>>743
どーせpushまでに間が空くんだからそこまでやらんでいい
既にfetchしてる分だけで単純ミス避けには充分
0745デフォルトの名無しさん2014/01/07(火) 21:12:06.70
>>742
バックアップとる分には不安はないのだけれど、戻し方がどうすればいいか悩むんだよね。

/直下に、.git作れば複数のサーバで同じ設定維持するの楽かも！
と、考えた時期もありましたorz
0746デフォルトの名無しさん2014/01/07(火) 21:25:12.24
>>742
pushがバックアップでは。
0747デフォルトの名無しさん2014/01/07(火) 22:11:18.86
>>745
設定共有目的ではないがetckeeperとかあるぞ
0748デフォルトの名無しさん2014/01/08(水) 11:55:19.56
git diff で、すでに消したファイルが
空のファイルとみなして差分表示されるんだけど
cvsみたいに ファイルが増えた/減った だけ表示できない？
0749デフォルトの名無しさん2014/01/08(水) 13:38:16.29
>>748

--diff-filter=AD とか --summary とか?
0750デフォルトの名無しさん2014/01/08(水) 23:28:22.35
なんだよSourceTreeってXP じゃ動かねえじゃんかよ
激おこぷんぷんだわもう
0751デフォルトの名無しさん2014/01/09(木) 00:26:12.31
>>748
たぶん git diff -D
0752デフォルトの名無しさん2014/01/09(木) 11:42:22.01
84 デフォルトの名無しさん [sage] 2014/01/09(木) 07:03:24.99 ID: Be:
Github が落ちて世界中のプログラマが発狂してるｗ

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
0753デフォルトの名無しさん2014/01/09(木) 11:58:06.87
>>752
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
0754デフォルトの名無しさん2014/01/09(木) 12:57:00.39
>>752
開発者ならcloneしてるのだから、svnとかほどの問題にはならないだろう。
0755デフォルトの名無しさん2014/01/09(木) 13:09:12.10
落ちてたの気付かなかった
っていうか気づいてなくて良かった
気付いてたら発狂してるとこだった
0756デフォルトの名無しさん2014/01/09(木) 13:11:19.43
分散型なのになんで発狂するの？
cvsをまったく笑えないよね
0757デフォルトの名無しさん2014/01/09(木) 13:29:37.03
pushしたら自動でfetchしたいんだけどできる？
0758デフォルトの名無しさん2014/01/09(木) 14:57:36.23
なんでgitおちたん
0759デフォルトの名無しさん2014/01/09(木) 15:03:12.27
githubをgitと略すにわかはかえれ
0760デフォルトの名無しさん2014/01/09(木) 16:07:55.87
>>758
せつこ、それgitちゃう! githubや!
0761デフォルトの名無しさん2014/01/09(木) 17:10:39.99
なんの疑問も抱かずgitと打ってしまった
0762デフォルトの名無しさん2014/01/09(木) 18:26:48.31
githubとかしょっちゅう落ちてるよ
0763デフォルトの名無しさん2014/01/09(木) 23:47:07.74
GitってVSSみたいにファイルのチェックイン、チェックアウトを厳密に
アトミックにロックするやり方の管理もできるの？

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。
0764デフォルトの名無しさん2014/01/10(金) 01:11:34.53
ロックの管理はGit以外の方法でやればいい
0765デフォルトの名無しさん2014/01/10(金) 02:04:57.98
アンチはGithubが落ちた、と鬼の首でも取ったように大騒ぎしたがるけど、
むしろリモートに接続しなくてもローカルのリポジトリで作業ができてしまう
Gitのすごさが立証された事象だったんだよな。
0766デフォルトの名無しさん2014/01/10(金) 02:12:31.59
gitの凄さが立証されただけで
Githubが落ちたこととは関係ない。
0767うちの子2014/01/10(金) 03:45:56.32
リモートが落ちただけで作業ができなくなる奴が致命的に馬鹿なだけ
0768デフォルトの名無しさん2014/01/10(金) 07:16:28.52
WikipediaをWikiと略すやつがいるように、そのうちGithubもGitと略される日が来るんだろう
0769デフォルトの名無しさん2014/01/10(金) 09:42:34.96
だがこのスレにおいてはハブとかサバとかサブとかホモとかそういう感じで
0770デフォルトの名無しさん2014/01/10(金) 11:54:00.94
それはWikipediaがpediaと呼ばれるくらい非現実的だな
0771デフォルトの名無しさん2014/01/10(金) 13:26:07.49
WikipediaでないただのWikiを使う人は限りなく少ないけど、
Githubとは関係なくGitを使う人は多いからなあ
0772デフォルトの名無しさん2014/01/10(金) 17:31:58.59
>>771
いやいやwiki使う人めちゃくちゃ多いだろ。wikipediaで使ってるmediawikiに限定するならともかく。
0773デフォルトの名無しさん2014/01/10(金) 18:17:01.09
Wikipedia以外にWikiってものを意識して使わないような人が沢山いるって話だろ？そりゃWikiをなんらかの形で使ってる人は沢山いるだろうけど。
0774デフォルトの名無しさん2014/01/10(金) 18:25:23.58
Wikipediaではない他のWikiをWikipediaと呼ぶ奴までいるんだぞ
0775デフォルトの名無しさん2014/01/10(金) 18:30:37.18
mediawiki使ってるとこをWikipediaと勘違いしちゃうのは仕方ないと思うけどねー
0776デフォルトの名無しさん2014/01/10(金) 18:47:32.96
wordpressのことをwikiって言ってる人もいたな
0777デフォルトの名無しさん2014/01/10(金) 19:32:41.57
知ってる人とでも面倒臭がって間違いを正してあげないからなー。ホームページやハッカーに続くのか。
0778デフォルトの名無しさん2014/01/11(土) 00:31:31.16
Bitkeeper使えよ貧乏人ども
0779デフォルトの名無しさん2014/01/11(土) 01:54:16.94
irane
0780デフォルトの名無しさん2014/01/11(土) 15:10:37.04
とにかく自動でfetchするようにしたいんだけどどうしたらいい？
0781デフォルトの名無しさん2014/01/11(土) 15:27:06.55
10 fetch
20 goto 10
0782デフォルトの名無しさん2014/01/11(土) 16:07:38.53
githubかgitlabにNGユーザーと通報機能みたいな荒らしを排除する仕組みはある？
それっぽいのなくて荒らされても止められず不特定多数のユーザーのリクエストをすべて拒否するしかなさそうだけど
0783デフォルトの名無しさん2014/01/11(土) 16:13:21.04
荒らされる奴って荒らされる方にも問題があるんだろ
0784182014/01/11(土) 16:25:50.53
煽り抜きで、みんなドキュメントとか画像とかの管理はどうしてるの？
マジで >>764 しかないの？
0785デフォルトの名無しさん2014/01/11(土) 16:40:10.75
>>1
このURLアクセスできる？
http://progit.org/book/ja/

こっちのURLならアクセスできる
http://git-scm.com/book/ja/
0786デフォルトの名無しさん2014/01/11(土) 16:41:09.32
>>784
しかないの
0787デフォルトの名無しさん2014/01/11(土) 16:53:48.75
>>783
自分も荒らされてるところ見たことないけど実際攻撃されたら
ただのgitとしてしか使えなくなるのはあまりに脆弱で不安
たとえば領土問題のある地名をデータとして持つか受け入れるプログラムの
リポジトリにクレーマーが粘着するというケースはありえるしそのとき
普通のユーザーごとリクエストを拒否するしかないのは欠陥でしょ
0788デフォルトの名無しさん2014/01/11(土) 17:00:49.11
>>787
おまえら自分がGitスレ荒らしてるって認識はある？
Githubのことはこっちに行けよ
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
0789デフォルトの名無しさん2014/01/11(土) 17:28:42.04
git diff --color で
空白のみ違うときに 豆腐を表示してくれるけど
あれウザいんでなんとかならんかな

かといって、 -w をつけると空白のみの差分を無視しちゃうので
空白は豆腐でなく空白で表示してほしい
0790デフォルトの名無しさん2014/01/11(土) 17:40:32.33
git diff FETCH_HEAD
と書いたらfetchした分との差分になるけど
git diff
と書いたら何との差分になるの？
git diff △△△△△△
あえて明示的に書くとしたら
△△△△△△ は何になるの？
0791デフォルトの名無しさん2014/01/11(土) 17:42:45.25
HEAD
0792デフォルトの名無しさん2014/01/11(土) 17:43:42.68
>>789
いいアイデアがあるぜ
自分でソースを書き換えてgitを再構築するんだ
Coolだろ？
0793デフォルトの名無しさん2014/01/11(土) 17:46:34.09
>>792
あぁ、そんなことは知ってる。

それをやらずにする方はないのかって意味なんだが、
理解できなかったか？
0794デフォルトの名無しさん2014/01/11(土) 18:02:12.96
git config color.diff.whitespace normal
0795デフォルトの名無しさん2014/01/11(土) 18:55:11.30
>>790
ありがとうございます
HEAD かー
0796デフォルトの名無しさん2014/01/11(土) 19:29:54.10
>>794
ありがとうございます
こういうデフォルトで設定されているオプションを一覧したいけど
表示させる方法ってあるんですかね
0797デフォルトの名無しさん2014/01/11(土) 22:40:19.25
>>788
すまんそのスレ知らんかった
0798デフォルトの名無しさん2014/01/12(日) 00:09:33.77
>>784
CVSやSubversionじゃだめなの？

確かにGitってテキスト主体のオープンソースの分散開発ならいいけど、
社内とかの仕事で使うにはあまり意味ないよね。

各人勝手にソースいじることないし、最終的にどこを取り入れるか判断する
人の負担が大きいし。
0799デフォルトの名無しさん2014/01/12(日) 00:57:44.96
>>784
textやsvgをふつーにgitで管理してる。
別にバイナリでもロックする必要性を感じない。
0800デフォルトの名無しさん2014/01/12(日) 01:07:08.37
gitって画像のやりとりにも使えそうな気がするけど
やってはイカンのだろうな
0801デフォルトの名無しさん2014/01/12(日) 01:22:02.26
いいんじゃないの？
本でも漫画でも同人誌でも。
著作権法に違反しないなら。
0802デフォルトの名無しさん2014/01/12(日) 01:33:25.17
>>798
gitにかぎった話じゃないけど、内部管理とプロジェクト管理を別々のリポジトリ使うことはよくあるよ。
そういうとき、分散型の方が楽にマージできる。

一応、バイナリファイルも管理できる。
コンフリクトしやすいから--oursとか必要になるけど
0803デフォルトの名無しさん2014/01/12(日) 04:55:03.09
>>798
お前、ソースコードの管理にしか使ってないだろ？

CVSやSubversionでどうやって
一日数回のコミットと複数のブランチを作ってマージが出来るっていうんだ？
不可能ではないが面倒くさすぎるだろ。
0804デフォルトの名無しさん2014/01/12(日) 07:29:28.39
>>796
git config --help
では？
0805デフォルトの名無しさん2014/01/12(日) 08:04:40.71
>>798
> CVSやSubversionじゃだめなの？

いまは Subversion 使ってるんだけど、git のローカルコミットは確かに便利なので、みんなどうしてるのかと。

>>799
> 別にバイナリでもロックする必要性を感じない。

運用でカバーできてるってこと？
0806デフォルトの名無しさん2014/01/12(日) 08:34:10.62
>>805
バイナリ入れるのはデザイナの作った画像くらいだし、滅多に更新しないから。
0807デフォルトの名無しさん2014/01/12(日) 09:32:23.79
>>803
コミットもブランチ分けも全部紙ベースの申請と会議で許可が出るんだよ
察してやれ…
0808デフォルトの名無しさん2014/01/12(日) 10:21:59.90
素人が好き勝手にやるにはGitが便利
組織のなかできちんとした管理をするにはCVSが便利
って結論か。
0809デフォルトの名無しさん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　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶
0810デフォルトの名無しさん2014/01/12(日) 10:58:37.50
>>806
ああなるほど。
仕様書とかマニュアルはどうしてます？
0811デフォルトの名無しさん2014/01/12(日) 12:16:37.86
>>810
よくよく考えると、文書類はwikiがほとんどだ。小さいアプリだとtext/plainなくらい。
マニュアルはhtmlだな。またはwikiからpdfを生成とか。
0812デフォルトの名無しさん2014/01/12(日) 12:59:36.68
組織もでかくなって人の出入りが多かったりするとロック方式のVCSとか面倒だよ
0813デフォルトの名無しさん2014/01/12(日) 14:10:34.66
ドキュメントのフォーマットに合わせてコードの管理方式を選択するとかアホすぎると思わんのか
コードの管理はロックの無い分散管理が便利過ぎて集中管理なんかに戻る気になれん
0814デフォルトの名無しさん2014/01/12(日) 16:00:00.05
大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
大事だから、やっぱGitは向いてないよ。

別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている（その
ために作られた）わけでさ。
0815デフォルトの名無しさん2014/01/12(日) 16:10:12.56
Linuxカーネルはいい加減な開発体制
弊社は中小にすぎないがLinuxカーネルのようないい加減なソフトは作っていない
よってGitなど使っては開発体制が崩壊する
0816デフォルトの名無しさん2014/01/12(日) 16:15:57.54
Linusみたいな独裁者がいるとGitは上手くいく。
北朝鮮型。
0817デフォルトの名無しさん2014/01/12(日) 16:16:17.98
馬鹿には無理
0818デフォルトの名無しさん2014/01/12(日) 16:51:23.17
馬鹿には使いこなせない
0819デフォルトの名無しさん2014/01/12(日) 16:55:14.09
分散型は個々の作業を重視した開発に向いているよね
そういう意味でオープンソフト向けなのは確かだと思う
自由気ままに各自で開発して、良ければマージしてねってスタイル向け

個々のスキルを重視できる職場向きとも思う
だけど日本の職場には向かないんじゃないかな
理由はお察s(ry
0820デフォルトの名無しさん2014/01/12(日) 18:35:04.93
>>814
> 大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
> 大事だから、やっぱGitは向いてないよ。

なんで？　その理由を書かないのはなんで？
0821デフォルトの名無しさん2014/01/12(日) 18:51:57.96
大きな組織でのスケジューリングや担当分けの調整で
集中型のバージョン管理ツールが大活躍してるんですか？ｗｗｗ
0822デフォルトの名無しさん2014/01/12(日) 19:12:21.30
ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。
0823デフォルトの名無しさん2014/01/12(日) 19:32:09.59
ウォーターフォール型のプロジェクトでコンフリクトが多発とかマジですか？ｗ
0824デフォルトの名無しさん2014/01/12(日) 19:42:26.69
>>822
gitでコンフリクトが起こるようならsvnでも起こるでしょ
コンフリクトは分散や集中とかとは関係ないよ
ただ集中型ツールならロックというコンフリクト回避手段が用意されているだけで
0825デフォルトの名無しさん2014/01/12(日) 19:43:08.28
ウォーターフォール開発でGitのコンフリクトは基本的には起こらないだろ
どういうときにコンフリクトするのか理解してないのか？
0826デフォルトの名無しさん2014/01/12(日) 20:06:29.51
オープンソースなら見知らぬ他人からプルリクエスト来たりするじゃん
どうやって回避してるの？
0827デフォルトの名無しさん2014/01/12(日) 20:21:25.64
下手っ糞なコードであちこち改編されて
プルリクエストが来た日には殺意を覚えたもんです
0828デフォルトの名無しさん2014/01/12(日) 20:23:07.80
何を回避するんだ？
0829デフォルトの名無しさん2014/01/12(日) 20:27:09.83
気に入らない pull request は無視すれば良いだけ
0830デフォルトの名無しさん2014/01/12(日) 20:35:41.89
なんかGitと関係あるの？
昔からメーリングリストにパッチ投げるとか普通にあるんだが
0831デフォルトの名無しさん2014/01/12(日) 20:53:10.12
gitでpull requestってどうやるんですか？
0832デフォルトの名無しさん2014/01/12(日) 20:58:50.54
m９ prpr
0833デフォルトの名無しさん2014/01/12(日) 21:01:25.84
>>831
リポジトリをクローンして修正して相手がアクセスできる場所に置いてから、
相手に連絡をつけて、レポジトリを置いた場所とマージしてちょ！という意思を伝えます。
0834デフォルトの名無しさん2014/01/12(日) 21:34:34.91
うちも同じ感じで コミットしました って電話してる。
0835デフォルトの名無しさん2014/01/12(日) 21:48:11.94
うちはコミットしたら課長のハンコもらって社内便でPR！
0836デフォルトの名無しさん2014/01/12(日) 22:41:41.76
>>821
> 大きな組織でのスケジューリングや担当分けの調整で
> 集中型のバージョン管理ツールが大活躍してるんですか？ｗｗｗ

？ バージョン管理ツールはスケジューリング用のツールじゃないよ？
だから全く関係ない話で、大活躍もしないし、逆に向かないってこともない。
だって全く関係ないから。
0837デフォルトの名無しさん2014/01/12(日) 22:45:20.41
うちは予定と予定完了をコミットして管理してる
0838デフォルトの名無しさん2014/01/12(日) 23:07:39.95
あー、わざとらしいｗ
0839デフォルトの名無しさん2014/01/12(日) 23:34:50.18
予定日のコミット位置は未来になるからコミットの位置では進捗確認できないのでは
0840デフォルトの名無しさん2014/01/12(日) 23:36:42.83
そのコミットじゃねーよ。バーヤ
0841デフォルトの名無しさん2014/01/12(日) 23:49:25.02
TODOリストをバージョン管理してるだけなんだけど？
基本的にメモとか全部Gitのレポジトリの中
0842デフォルトの名無しさん2014/01/12(日) 23:49:28.42
Gitは～には向かないのでは？　という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。

大組織での開発にも、いや、Gitってこういう使い方すれば役に立つよ、という書き込みなら
まだ建設的な議論が出来そうだけど、具体的な内容ゼロの当てこすりや小馬鹿にしたような
書き込みばかり。

まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね？
と思う。
0843デフォルトの名無しさん2014/01/12(日) 23:59:57.42
バージョン管理ツールで予定する前提で話してる奴とスケジューリングツール前提のやつ入り混じってて
話がかみ合ってないのに自信満々で語ってるアホがいるからややこしい
0844デフォルトの名無しさん2014/01/13(月) 00:01:25.93
～には向かないのでは？っていう書き込みに、
別にそんなことないよ？って答えが返ってきてるだけじゃない
それ以上の情報が欲しいとか、炎上させて情報得ようとかの糞野郎でしかないね
0845デフォルトの名無しさん2014/01/13(月) 00:05:40.38
>>842
小馬鹿にするっていうか、「～には向かないのでは？」って書いてる奴が馬鹿過ぎるんだものｗ
0846デフォルトの名無しさん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/
0847デフォルトの名無しさん2014/01/13(月) 00:10:41.62
×　Gitは～には向かない
○　～はGitには向かない

管理者、利用者含めて、運用システム構築できないんだったら、git使わないほうがいい
使う側も管理する側もgit理解してないといけないぐらいgitって自由度高すぎるんだよ
ていうのを
mercurial→gitにきて思った
0848デフォルトの名無しさん2014/01/13(月) 00:11:27.67
草生やした会話が普通だと思ってるお客様は巣から出てこないでね
迷惑だから
0849デフォルトの名無しさん2014/01/13(月) 00:12:20.08
Gitに向かない用途なんてないだろ
使いこなせない奴がバカなだけ
だいたい一流企業ではGit使ってる
0850デフォルトの名無しさん2014/01/13(月) 00:14:35.00
わかってるだろうけど>>849=>>845
自演してるだけ
0851デフォルトの名無しさん2014/01/13(月) 00:17:09.99
敵は一人妄想の奴とか自演妄想の奴って、自分に自信がないもんだから、
「自分は多数派である」という幻想にしがみつくしかないのかな？
なんか哀れっぽいw
0852デフォルトの名無しさん2014/01/13(月) 00:21:59.90
なんで>>849=>>845だと自演なんだ？

ちなみに
Googleは独自ソース管理システムを持っててGitを使ってない
MSはVisual StuidoがようやくGitサポートし始めたとこだから、社内でも本格的には使ってないんじゃないかな？
Appleはよく知らんが使ってそう
0853デフォルトの名無しさん2014/01/13(月) 00:23:46.26
日本のIT関係だとどうなの？使ってる率高いの？
0854デフォルトの名無しさん2014/01/13(月) 00:30:08.19
>>852
一人二役で論争作って炎上させようとしてるからだよ
>>851で化けの皮はがれたからこんな場違いに低能な奴もう相手にされないだろうがね
0855デフォルトの名無しさん2014/01/13(月) 00:44:11.92
>>852
MSがTFS使ってなかったら笑い話やな
0856デフォルトの名無しさん2014/01/13(月) 00:59:10.80
また敵は一人妄想か。
0857デフォルトの名無しさん2014/01/13(月) 01:05:09.50
>>854
いやべつに、849と845が同じ奴の書き込みでも違う奴の書き込みでも大勢に影響無いと思うのだが…？
0858デフォルトの名無しさん2014/01/13(月) 01:07:29.98
割と大手電機メーカー子会社系列のソフト屋だけど、まわりじゃGitは使われてないね。
MSDNのライセンスを買っているからSourceSafeを使うことが多い。
WORDとかのドキュメントは差分取っても意味ないので、MSSみたいなチェックイン、チェックアウト式で充分。
ちなみにGithubはファイル交換サイト扱いでアクセスできない（w
これは大手はどこでもそうじゃないかな？
0859デフォルトの名無しさん2014/01/13(月) 01:08:06.21
>>853
SIerは案件毎に違うだろうね
Webとかソーシャル系はほぼ使ってるだろう
0860デフォルトの名無しさん2014/01/13(月) 01:13:24.41
上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

上でGitのコンフリクトの意味が分かってない人がいたけど、別にGitのツールとしてのコンフリクト回避機能に問題があるってわけじゃないんですよ。
大手だと誰がどこを直すのか決めてからやるわけで（そのミスを減らすためにバージョン管理ソフトを使うわけで）、ファイルのロックやロールバックがきちんと行われる方が大事なんですな。

Gitだと複数の人が同じところ勝手に直しだしたりしても検出できないでしょ。無駄な作業が発生するわけ。
どっちが悪いとかじゃなくて、Gitが向いてないタイプの管理が企業内にはあるってこと。
おわかりかな？
0861デフォルトの名無しさん2014/01/13(月) 01:18:07.05
>>860
大手のウォーターフォール型の開発だと
どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ
誰かどこを弄るとかはコード弄る前にレビューとかして明確になってるんだから
0862デフォルトの名無しさん2014/01/13(月) 01:23:30.89
だからさ、それが完璧に機能するなら単にファイル共有でいいでしょ。
あくまでミスをなくす（あるいはミスが起きたときにリカバーする方策）目的だよ。
ほんとに頭悪いの？
0863デフォルトの名無しさん2014/01/13(月) 01:24:06.89
誰がどこを直すかのミスを減らすためにロックを使うって、
みんながコーディング終わるまでずっとロック取り続けたりするのか？
0864デフォルトの名無しさん2014/01/13(月) 01:26:35.03
>>863
はぁ？
お前本当にバージョン管理システム使ったことあるの？

とんだけ的外れな質問だよ？
0865デフォルトの名無しさん2014/01/13(月) 01:30:20.70
>>860
GitHubは1人の責任者でなくメンバーそれぞれで採用を決める方法で開発運用できてるのだから独裁にこだわる必要はないでしょ
日本の慣習に合わないってだけで
0866デフォルトの名無しさん2014/01/13(月) 01:33:06.24
>>864
Gitにはロック無いんだからここでそんなこと言われてもねえ
それともGitはバージョン管理ツールじゃないの？
0867デフォルトの名無しさん2014/01/13(月) 01:37:44.01
また繰り返しかよ。

>>866
>Gitにはロック無いんだからここでそんなこと言われてもねえ
だからGitには向いてない組織あるよね、という話をした。

>それともGitはバージョン管理ツールじゃないの？
誰がそんなバカなこと書いているんだ？
そう読めるなら病院行け。

ほんとバカだよな。
0868デフォルトの名無しさん2014/01/13(月) 01:39:40.67
アスペかな？
0869デフォルトの名無しさん2014/01/13(月) 01:42:43.97
Gitにはロック無いという前提の話をしているので貼れば、
gitにロックがあるということを説明すれば話は覆る。


gitにおいてロックとは、許可がない限りマージできないということ。
これがロックと同等になる。

マージする時に、マージ担当者に「今からマージします」って言って
マージ担当者に他のマージを待ってもらうようにすればいいだけ。

subversionでもロックを掛けられるからといって
勝手にマージしたらダメだろう？
どっちみちマージ担当者に許可を得ているのだから同じことである。
0870デフォルトの名無しさん2014/01/13(月) 01:43:14.25
いやちょっとまてよお前話の流れ掴めてないだろ
まじでお前に反論してるのが一人だと思ってるのか？

おれ
＞誰がどこを直すかのミスを減らすためにロックを使うって、
＞みんながコーディング終わるまでずっとロック取り続けたりするのか？

おまえ
＞はぁ？
＞お前本当にバージョン管理システム使ったことあるの？
＞とんだけ的外れな質問だよ？

おれ
＞Gitにはロック無いんだからここでそんなこと言われてもねえ
＞それともGitはバージョン管理ツールじゃないの？

おまえ
>>867
0871デフォルトの名無しさん2014/01/13(月) 01:47:10.48
>>869
>gitにおいてロックとは、許可がない限りマージできないということ。
>これがロックと同等になる。

だからさあ、それ自体は間違ってないって。

もうわざとやってるだろうけど、それで良い用途と、そういう作業が発生する「無駄」を避けたい
用途があるってだよ。

もう嫌になっちゃうな頭の悪い人に説明する徒労感って（笑）
いちど読み直してみなよ、流れを。
0872デフォルトの名無しさん2014/01/13(月) 01:49:41.19
流れって860の俺の書き込みからの、ってことね。
念の為。
0873デフォルトの名無しさん2014/01/13(月) 01:49:58.05
> >gitにおいてロックとは、許可がない限りマージできないということ。
> >これがロックと同等になる。
>
> だからさあ、それ自体は間違ってないって。

いやこれは全然違うだろｗ
0874デフォルトの名無しさん2014/01/13(月) 01:53:41.15
>>871
こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが
0875デフォルトの名無しさん2014/01/13(月) 01:54:55.69
ファイルのロックで修正箇所ミスを偶然検知できることを期待して
集中管理方式使うとか、さすがにアホすぎる
0876デフォルトの名無しさん2014/01/13(月) 01:57:17.72
>>871
Gitじゃなくてロックのない分散管理方式を否定したいなら
>>846 のとこへ行ってやってくれる？
0877うちの子2014/01/13(月) 01:58:25.22
否定したいわけじゃなくても>>846 のとこへ行ってやれ
0878デフォルトの名無しさん2014/01/13(月) 01:59:15.63
分散じゃないsvnだって、普通のソースコードの管理に関してはロック無しが推奨なんだがな
0879デフォルトの名無しさん2014/01/13(月) 01:59:33.15
上にもあったがGitが向いてない用途という話をされただけで、気が狂ったみたいなに真っ赤になって発狂する奴がいるんだな。
おまけに頭が悪くて、話も通じない。
勝手に曲解してはまともな反論したつもり（笑）
少しは恥を知れよ、まあ無理なんだろうが。
0880デフォルトの名無しさん2014/01/13(月) 02:01:21.29
noob
0881デフォルトの名無しさん2014/01/13(月) 02:01:40.61
大草原から来た土民の相手するのもうやめたら？
0882デフォルトの名無しさん2014/01/13(月) 02:02:14.44
まあGitに限らず信者ってそんなもん
0883デフォルトの名無しさん2014/01/13(月) 02:03:43.19
>>879
>>870は無視かよ。ロックの無いGitしか知らないおれに、ロックをどういう風に使ってるか教えてくれよ
0884デフォルトの名無しさん2014/01/13(月) 02:10:18.53
そいつスレ読んで知ってるふりしてるだけのバカだから聞くだけ無駄
どのみちGitが向いてないなら向いてる管理ツールのスレに行けば用は済む
0885デフォルトの名無しさん2014/01/13(月) 02:12:42.37
そういうことにしたいのですね
0886デフォルトの名無しさん2014/01/13(月) 02:14:32.97
ロックをどういう風に使ってるか説明しないならそういうことになっちゃうね
0887デフォルトの名無しさん2014/01/13(月) 02:25:21.45
>>885じゃないけど煽りを煽りと見抜けないお前らの純粋さに驚きだよ
9割が悪口のレスを律儀に相手するなんて
0888デフォルトの名無しさん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　　　　　　　　／　　　　 ＼
　　　　　　　　＼　　|　,!　　　　　 , -''~　　　　　　　＼
.　　　　　　　　　 ＼ `''　　,,.. -'''~
　　　　　　　　　　　 ￣￣
0889デフォルトの名無しさん2014/01/13(月) 02:26:56.15
そういうことにしたいのですね
0890デフォルトの名無しさん2014/01/13(月) 02:27:24.63
>>874
>こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが
むしろスレの切り貼りで分かるレベルのことを理解できないバカがいるのが不思議なんだが（笑）
0891デフォルトの名無しさん2014/01/13(月) 02:29:17.80
>上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
>世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。

Gitに「開発思想」があるとしたらこれだよな
Githubはまた異なるが
0892デフォルトの名無しさん2014/01/13(月) 02:41:43.72
pushしてきたのをどれを採用するか決めるのって
どうやって実現すればいいの？
これすごくやりたいんだけどやり方が全然わからない
0893デフォルトの名無しさん2014/01/13(月) 02:48:12.53
マージ

タイミングと内容的に教えてくんのふりした荒らしにしか見えんな
0894デフォルトの名無しさん2014/01/13(月) 02:52:57.77
>>860
バージョン管理システムっていうのは、修正の履歴を残すことと、過去に逆戻って取り出せる事が必要なんだよ。

だから、バージョン管理システムとしては本来ファイルをロックするという行為は必要ない。
その点は理解するべき。
まして、gitの場合、最新のものに対して以外はコミットできないのだから、なんでファイルをロックできなきゃいけないのか理解できない。

複数の人が修正すればコンフリクトは発生するものだから、組織の中で修正担当を決めるのはコンフリクトを運用回避しているだけだよ。
バージョン管理の仕組みとは次元が違う。
0895デフォルトの名無しさん2014/01/13(月) 03:01:02.19
>>892
修正したコミットをどこかに置いてもらって、
それをチェックしてからマージするなり突っ返すなりするだけ

コミットをどこに置くかは、クローンした別のリポジトリを用意してそこにpushするのが一般的だけど、
同じレポジトリの別のブランチでもいい

別のリポジトリならpullする必要があるからpullリクエストだね
同じレポジトリの場合はpullする必要ないけど、やってることはあまり変わらん
0896デフォルトの名無しさん2014/01/13(月) 03:12:54.70
>>892
君が独裁者となり、どれを採用するか却下するか決めれば良い。
0897デフォルトの名無しさん2014/01/13(月) 03:39:15.82
subversionなら独裁者なんていないから
誰でも好き勝手コードをコミットできるのに。
0898デフォルトの名無しさん2014/01/13(月) 03:52:01.41
>>895
A→B でpushしてもらって、それを見てパッチを作って
Cに適用してC→D にpushするってこと？
0899デフォルトの名無しさん2014/01/13(月) 08:06:46.44
>>897
いや、それこそ崩壊せんかw
0900デフォルトの名無しさん2014/01/13(月) 09:48:03.23
うわー、何か伸びとるなー
話が噛み合ってないように見えるけど
0901デフォルトの名無しさん2014/01/13(月) 10:07:53.06
宗教戦争は神が命じなくても起きるものなのです
0902デフォルトの名無しさん2014/01/13(月) 11:15:27.64
独裁スイッチ
0903デフォルトの名無しさん2014/01/13(月) 11:27:18.03
>>898
Git使ってるのにパッチ作って適用する必要とかないだろ
どこかにpushしてもらったら、それを自分のローカルなレポジトリの適当なブランチに
pullして内容を確認すればいい
問題なければ正式なブランチにマージして公開レポジトリにpushだな
0904デフォルトの名無しさん2014/01/13(月) 11:41:04.55
>>855
MSがVSS使ってないっていう笑い話があったな。
0905デフォルトの名無しさん2014/01/13(月) 11:52:47.31
また根拠のない中傷か
0906デフォルトの名無しさん2014/01/13(月) 12:33:54.27
そもそもVSSが酷すぎるからMSはTFSを作ったんだろ
0907デフォルトの名無しさん2014/01/13(月) 13:06:03.71
一方Bitkeeperが只で使えなくなったと言ってライナスはGitを作った
0908デフォルトの名無しさん2014/01/13(月) 13:22:06.92
OSS界隈でGitが使われる政治的理由は、Google臭やMicrosoft臭、IBM臭がしないから
あのコミュニティはソフトウェア技術者になれなかったものたちの怨恨で膨れ上がっている
何をするにもベストとは言い難い選択肢にも関わらず、それが使われ続けるには、
スタートアップって場所に集まるような連中が何らかのコンプレックス持ちで、
TFSとかBitkeeperみたいなプロフェッショナルたちの使う道具に反感を持ってんだよ。
何者にも成れなかった連中は何かに向いた道具なんて使いたくなかった。
親世代たちへの謀反で反逆者たちの集まり。特にその劣等感の強いのがGitコミュニティ。
0909デフォルトの名無しさん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コミュニティ。
0910デフォルトの名無しさん2014/01/13(月) 13:33:28.15
>>908
なにか凄い怨念を感じます！！
0911デフォルトの名無しさん2014/01/13(月) 13:38:54.51
さすがスレ監視員の仕事は早いなw
0912うちの子2014/01/13(月) 13:43:10.25
>>885 糞壁乙
0913デフォルトの名無しさん2014/01/13(月) 14:03:31.14
>>858
MSSなんて初めて聞いたわwww
0914デフォルトの名無しさん2014/01/13(月) 14:07:08.56
>>811
なるほど、そう言う運用なら管理対象はほぼテキストだけだからロックとかはなくても大丈夫そうですね。

>>861
> どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ

なんでそんな発想になるの？
ロックで取り合いするんじゃなくて、予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。
0915デフォルトの名無しさん2014/01/13(月) 14:27:35.27
上でも書いてる人がいるけど
あらかじめ決めた人以外が間違って編集しないようにする目的には、ロックはあまり役に立たなくない？
あらかじめ決めた人がロックして編集はじめる前に、他の人が間違えて編集してコミット終えちゃったら意味ないよね？
ほんとにそんな機能が必要なら、ファイル毎にアクセス権を指定するとかの仕組みを用意した方がいいと思うんだけど
0916デフォルトの名無しさん2014/01/13(月) 14:43:15.16
>>915
ちょっと何を言ってるのかわからない

ファイル毎のアクセス権を一時的に指定する仕組みがロックでしょ
0917デフォルトの名無しさん2014/01/13(月) 15:00:39.60
ブランチに権限設定するだけで十分じゃないすかね
プルリクエストならチェックしてからしか編集されないからロックもいらないし
0918デフォルトの名無しさん2014/01/13(月) 15:06:18.53
>>916
普通、ロックは誰でも取得できるよね？間違えて取得してしまう可能性もあるわけだ。
アクセス権は普通は管理者がまとめて設定する。
0919デフォルトの名無しさん2014/01/13(月) 15:11:18.54
>>916
Aさんがfoo.cを担当することになりました。
Bさんはfoe.cを担当することになりました。
Aさんは他に作業があったのでまだfoo.cをロックしてませんでした。
Bさんは間違えてfoo.cをロックしてコミットして作業を終えてロックを開放しました。
0920デフォルトの名無しさん2014/01/13(月) 15:20:26.34
それ非同期で分業できてます？
0921デフォルトの名無しさん2014/01/13(月) 15:27:27.64
Aさんがfoo.cのa関数を担当することになりました。
Bさんがfoo.cをb関数を担当することになりました。

Aさんはa関数を作るためにfoo.cをロックします。
ロックされているのでBさんはb関数を作れません

こういうことになると思うけど、これどうやって解決するの？
0922デフォルトの名無しさん2014/01/13(月) 15:31:52.66
>>920
非同期に分業するとしても全員が完全に同時に作業を始めるわけじゃないし、
複数の案件を抱えてれば一時的に作業を遅らせることもあるわけよ
0923デフォルトの名無しさん2014/01/13(月) 15:36:17.51
>>922
遅らせる”ことも” あるわけってことは
遅らせないこともあるんだろ？

同時に作業を始められて、その方が良い場合はどうするのさ？
0924デフォルトの名無しさん2014/01/13(月) 15:42:30.91
>>922
つまり並行して作業しないと書いてるように見えるが
どのみちリポジトリ落として作業してたらよそでロックされても関係ないよね？
0925デフォルトの名無しさん2014/01/13(月) 15:44:40.21
>>923
同時に始めることもあれば、同時に始めないこともある。
各個人が行うロックは、同時に始めたときしか間違って編集するのを防げないから、
そんな中途半端な方式に頼るのをやめてファイル単位にアクセス権を設定した方がいいですね。
0926デフォルトの名無しさん2014/01/13(月) 15:46:47.03
>>924
並行して作業が行われるかどうかは確定できないと書いてる。
0927うちの子2014/01/13(月) 15:47:47.64
馬鹿には無理
0928デフォルトの名無しさん2014/01/13(月) 15:53:40.62
マージベースになったSVNでもオプションでロックが用意されてるのは
マージが難しいファイルの同時編集を避ける目的であって、
ファイルを間違えて編集するのを防止するためとかどっかズレてるんだよ
ファイル間違えて編集しちまったら諦めてリジェクトされてやり直せ
0929デフォルトの名無しさん2014/01/13(月) 15:54:25.13
>>925
そのロックもうGitの役割じゃないというかGitの機能を損ねてると思う
Gitじゃなくて自分がやりたい開発管理でしょ
0930デフォルトの名無しさん2014/01/13(月) 15:56:20.78
つまりさ、ロックをすると
同じファイルを平行して作業できないってことだよね？

それって不便だと思うけど。
0931デフォルトの名無しさん2014/01/13(月) 15:59:21.82
>>919
Aさんが作業開始する前にBさんがロックを解放したなら何の問題ないし、
そうでないなら、Aさんがロックできないことに気付くので、Bさんに直接間違いを指摘すればいい。

>>921
二つのやり方がある。

1、ロックを使わない。後でマージする。

2、同一ファイルに書かれているということは、関数同士に関連があり、
マージで不具合が発生する可能性が高いので、
Aさんが作業完了した後にBさんが作業を開始する。
もし、関連がないなら別のファイルに分離し、それぞれのファイルをロックして同時に作業する。

ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。
0932デフォルトの名無しさん2014/01/13(月) 16:07:43.00
>>931
問題あることになるだろう。
予め編集すると決めた人以外が間違って編集することを防げないんだから。
>>919や>>915は、>>914のこれに対する書き込みだぞ？話の流れ読めてる？
＞予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。
0933デフォルトの名無しさん2014/01/13(月) 16:13:42.03
「予め編集すると決める」 -> 「ロックを取る」ことなんだよ
>>931は日本語不自由なんだからそのぐらい察してやれｗ

>>860のこの書き込みからはズレちゃってるが
「大手だと誰がどこを直すのか決めてからやるわけで（そのミスを減らすためにバージョン管理ソフトを使うわけで）、
ファイルのロックやロールバックがきちんと行われる方が大事なんですな。」
こいつは話の流れ無視して好きなこと書き込んでるだけだからしょうが無い
0934デフォルトの名無しさん2014/01/13(月) 16:18:33.41
常にサーバーにあるオリジナルのリポジトリを参照（してロック状態を確認）しながらしか作業できないGit
退化しすぎ
コンフリクトの発生は間違えて指示出した奴と間違えて作業した奴が悪いのであってロックがないせいじゃない
0935デフォルトの名無しさん2014/01/13(月) 16:19:14.19
緊急のバグフィックス入れたいが、開発者がロック取りっぱなしだから入れられない。しょうがないからパッチファイルにしといて後でコミットするか。あー変更されてるからマージしなきゃ。と、gitがしてくれることを手動でやることになりそう。
0936デフォルトの名無しさん2014/01/13(月) 16:19:20.36
>>931
> ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。

じゃあ、ロック使わないでやればいいんじゃね？

ロックされていても出来る方法をあなたが書いたでしょ？
> 1、ロックを使わない。後でマージする。

常にこれをやれば、ロックは不要だよね？
0937デフォルトの名無しさん2014/01/13(月) 16:22:56.27
排他制御であるロックと、アクセス制御は違いますよ、
っていう当たり前の事をわざわざ主張してたの？

そりゃ想定外だわ。

vcsの話なんだから、
「予め編集すると決める」はアクセス制御目的ではなく、排他制御目的で言ってるのかと思ってたよ。
0938デフォルトの名無しさん2014/01/13(月) 16:25:07.22
後でマージすればいいだけなんだから
排他制御する必要はないと思うけどな。
0939デフォルトの名無しさん2014/01/13(月) 16:26:37.73
まあ普通そうだけど話の発端は>>860だからね
0940デフォルトの名無しさん2014/01/13(月) 16:28:07.09
担当者と常に連絡が付くならロックでもいいんだよね。

普段はロックでできるだけマージを排除しつつ、
緊急時はロックを解除してもらって、後からマージ。
同時にリスケジュールなどの調整も行う。

問題は担当者が不在の時。
それを考えると、最初からロックしなくていいか・・・って話になる。
0941デフォルトの名無しさん2014/01/13(月) 16:35:09.91
昔のVSS思い出すなあ
0942デフォルトの名無しさん2014/01/13(月) 16:44:00.04
もう当分ロックの話題は見たくないわ
0943デフォルトの名無しさん2014/01/13(月) 16:49:30.33
「ロック」・・・そんな事はする必要がねーんだ。
なぜなら、オレや、オレたちの仲間は、
ロックするファイルがわかった時には！
実際に編集しちまって、もう既に終わってるからだ！
だから使った事がねェーッ。

「コミットする」なら使ってもいいッ！
0944デフォルトの名無しさん2014/01/13(月) 17:12:52.23
>>943
なんで大事な最後で噛むんだよ兄貴
0945デフォルトの名無しさん2014/01/13(月) 17:14:13.11
じゃあ、次はキーワード展開の話題に移ります＾＾
0946デフォルトの名無しさん2014/01/13(月) 17:22:34.86
またエライ伸びててビビったぞ

なんの脈絡も無くね？
>キーワード展開
0947デフォルトの名無しさん2014/01/13(月) 18:13:55.77
>>946
釣りネタに釣られる阿呆に対する皮肉じゃないの

その次はタイムスタンプの話題
0948デフォルトの名無しさん2014/01/13(月) 18:29:09.38
実行属性は保存されるのにタイムスタンプは保存されない
ってのはたしかに片手落ちな感じはするな・・・
これってgit界では定番の問題なの？
0949デフォルトの名無しさん2014/01/13(月) 18:34:03.18
MSはWindowsも使ってないんじゃないかな
0950デフォルトの名無しさん2014/01/13(月) 18:38:52.85
タイムスタンプはmakeが使うわけで、意図的にやってると思うが。
0951デフォルトの名無しさん2014/01/13(月) 18:39:16.15
>>948
タイムスタンプを見てビルドする前提のソースコードを管理する仕組みだから、
タイムスタンプが維持されてブランチ切り替え後のビルドがうまく走らないのは問題がある
0952デフォルトの名無しさん2014/01/13(月) 18:40:57.13
なるほど。gitはタイムスタンプの問題点を
解決しているわけで、これは進化なのか。
0953デフォルトの名無しさん2014/01/13(月) 18:45:23.97
進化というか、UNIXで動くソース管理ツールは昔からこうじゃないの？
0954デフォルトの名無しさん2014/01/13(月) 19:01:24.39
>>951
それは強制される話ではない気がする
タイムスタンプを保持するかしないかは選択できるべきだよね
0955デフォルトの名無しさん2014/01/13(月) 19:08:28.64
>>954
ソースコード管理のために必要最小限の機能だけを用意するのがGitのポリシー
実装が簡単になるし、関連ツールなんかも作りやすい
0956デフォルトの名無しさん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のバグを修正するより簡単だと感じる。
0957デフォルトの名無しさん2014/01/13(月) 19:15:32.78
>>955
＞必要最小限の機能だけを用意
そんなポリシーあったのか・・・ 知らなかった

diff周りとかゴチャゴチャとどんどん機能増量してっから
わりと行き当りばったりな思想だと思ってた。
0958デフォルトの名無しさん2014/01/13(月) 19:20:14.72
てゆーか タイムスタンプを残す ってのはそんなに大変なことなの？
シンプルイズベストを理由に拒むだけの複雑さがあるとは思いにくい

簡単な実装でシンプルに実現できると思うけど、やろうとしたら
案外と難しいもんなんかな
0959デフォルトの名無しさん2014/01/13(月) 19:22:52.42
馬鹿には無理
0960デフォルトの名無しさん2014/01/13(月) 19:24:34.22
>>957
diffなんて枝葉部分はいいんだよ
リポジトリの構造なんかに関連するコアの部分に余分なメタデータとか肥大化させるなってことだ

diffはある意味コアな部分をシンプルに保つために機能が肥大化されたりしてるからな
リネーム関連の追跡とか
0961デフォルトの名無しさん2014/01/13(月) 19:29:31.88
ファイルの属性ってメタデータとして別途保持してんの？
0962デフォルトの名無しさん2014/01/13(月) 19:30:08.46
>>958
少なくともリポジトリの構造が変わるのに対応する必要がある
関連ツールは新旧リポジトリを見分けて対応する必要がでてくるな
>>956とか読んでみてよ。barはそういうのを吸収するために分厚いレイヤーをもった
複雑な構造をしててそれが開発コミュニティーにとっては障害になってたそうだ
0963デフォルトの名無しさん2014/01/13(月) 19:47:19.05
>>961
ファイルの属性に関しては、ディクレトリの情報を保存するtreeオブジェクトの中に
「ノードの型(実行属性とか含む100644みたいなの)、実体を指すハッシュ、ファイル名」の三つの情報を保存してて、
実体のほうでヘッダにファイルサイズが保存されてるだけかな
スゲー簡単
0964デフォルトの名無しさん2014/01/13(月) 20:07:54.72
内容のほうにファイル名がぶら下がってるのはgitの特徴ではなかろうか。
0965デフォルトの名無しさん2014/01/13(月) 20:37:02.84
ファイル名変えるとgit追ってくれなくないか？
0966デフォルトの名無しさん2014/01/13(月) 20:40:23.65
>>940
連絡つくのならそれこそ、ロックはいらないでしょ。
当事者間でちゃんと調整しようよ。

ロックにしろ、タイムスタンプ保持にしろ本来バージョン管理には必要ない機能だから無いことを当然として、運用を考えるべき。

それにしても、ここたまに爆発するなw
0967デフォルトの名無しさん2014/01/13(月) 21:07:25.21
>>965
--find-renames
完璧に追跡してくれるわけではないが
0968デフォルトの名無しさん2014/01/13(月) 21:19:58.26
git mv で変えれば追ってくれるとかじゃないのか?
0969デフォルトの名無しさん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

ファイルの実体を指すハッシュが一致
0970デフォルトの名無しさん2014/01/13(月) 21:25:19.35
>>968
関係無い
git mvしてもリネームしたっていう情報が保存されるわけじゃない
diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる
logなんかにもおなじように推測する機能がある
0971デフォルトの名無しさん2014/01/14(火) 00:13:51.57
そもそも当てにならないマシン毎の時計を元にしたタイムスタンプや、タイムゾーンを
超えた地域とも共同開発するのがあたりまえのGitなんだから、そんなものを重視する方が
おかしい。
あくまでファイルの内容そのものだけを判断の基準にするのが優れた典なのだから。
昨日から長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込みして
るのはプログラマになれなかったアホが板で暴れてるようだな。他のスレまでコピペして
ご苦労なことだ。自演してもすぐわかるのにな。
0972デフォルトの名無しさん2014/01/14(火) 01:38:33.21
>>971
＞長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込み
0973デフォルトの名無しさん2014/01/14(火) 02:11:44.12
バカはすぐ文系とかレッテル貼りたがるよな（笑）
0974デフォルトの名無しさん2014/01/14(火) 03:10:26.47
svnだとファイル移動する時にsvn mvしないと追跡しないけど、
gitだと別にgit mvしなくても、普通にmvなどで名前変えるだけで
いいから便利なんだよな。
通常のファイル処理してるだけなのに、特殊なコマンド使わなくていいからね。
0975デフォルトの名無しさん2014/01/14(火) 10:57:43.15
mvで名前変えるとgit rmとgit addしないといけないから面倒だろ？
0976デフォルトの名無しさん2014/01/14(火) 13:50:43.75
>>966
> 無いことを当然として、運用を考えるべき。

で、君のところはバイナリファイル (要するにマージできないファイル) の管理はどうしてるの？
git 以外を使ってるとか？
0977デフォルトの名無しさん2014/01/14(火) 13:59:15.82
>>970
> diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる

必要最小限の機能とかいいながらこんな余計な機能をつける奴ってバカじゃね？
0978デフォルトの名無しさん2014/01/14(火) 14:11:28.69
>>977
だからコアな部分の機能を必要最小限と言ってるだろ

リネームに関する機能をコアな部分に組み込めば、コアだけじゃなく関連するいろいろな部分に影響がでる
diffとか一部コマンドだけで対応できれば他はシンプルななままに保てる
0979デフォルトの名無しさん2014/01/14(火) 14:21:24.10
>>976
うちは、画像とかは担当決まってるんで複数の人が同じものを編集することは無いし、
ドキュメントはテキストベースのHTMLやらMarkdownで管理してるんでマージ可能なので、
特に問題にならない
0980デフォルトの名無しさん2014/01/14(火) 14:29:59.26
どうしてもエクセルファイルで管理したいって部署があって
そこはエクセルファイル自体はファイル共有してるのをみんなで触って
担当者が定期的にそのファイルをコミットしてるらしい
0981デフォルトの名無しさん2014/01/14(火) 18:41:21.98
それテキストと違って差分が分かるわけじゃないから、Gitで管理する意味ないよね。
チェクイン、チェックアウトでやった方が無駄な作業が発生しないのでは？
0982デフォルトの名無しさん2014/01/14(火) 18:47:45.48
GitであることよりわかりやすいGUIで版を管理できることがニーズに合ったんじゃないの
0983デフォルトの名無しさん2014/01/14(火) 19:25:40.45
progitというのを6章まで読んだが
gitって難しそうだな(vcs自体が俺にとっては初めてでもあるが)
末端開発者は実に気楽だがメンテナというマージ担当者の負担が重そうだ
0984デフォルトの名無しさん2014/01/14(火) 20:04:53.26
>>983
負担になるようなマージ処理が発生するようなコンフリクトがあるときは
末端にリベースしてもらうから問題無い
計画的に開発してるならそういうコンフリクトはほとんど起こらないけどね
0985デフォルトの名無しさん2014/01/14(火) 20:09:21.19
コンフリクトってテキスト的なコンフリクトの検出だけでしょgitが出来るのって
コード上の整合性での問題は検出してくれない
0986デフォルトの名無しさん2014/01/14(火) 20:18:59.30
そんな便利なものを検出するのはVCSだけじゃ不可能だわな
ファイルを跨ってプログラムの処理がコンフリクトしてる可能性もあるわけだし
だからコミットしたら自動的にテストが走るような仕組みを作るわけで
Gitの関連ツールの作りやすさはその辺にも役立つ
0987デフォルトの名無しさん2014/01/14(火) 20:24:52.78
ファイルロックが必要だ！
0988デフォルトの名無しさん2014/01/14(火) 21:08:06.94
テストツール使え
0989デフォルトの名無しさん2014/01/14(火) 21:10:03.76
次スレよろ
0990デフォルトの名無しさん2014/01/14(火) 21:18:23.73
立てたよ

Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
0991デフォルトの名無しさん2014/01/15(水) 00:45:23.04
Windowsで使うのに、どのツールを使うのが一番？
日本語メニューを希望
0992デフォルトの名無しさん2014/01/15(水) 00:46:50.10
Eclipseに入ってるEGitは結構お気に入り
0993デフォルトの名無しさん2014/01/15(水) 00:59:25.85
スタッシュとかフェッチとかいうカタカナメニューが並んでるツールとか
使い方を覚えられる気がしない
0994デフォルトの名無しさん2014/01/15(水) 01:10:57.14
埋め
0995デフォルトの名無しさん2014/01/15(水) 01:11:28.71
埋め
0996デフォルトの名無しさん2014/01/15(水) 01:19:45.62
埋め-
0997デフォルトの名無しさん2014/01/15(水) 01:20:44.44
埋め
0998デフォルトの名無しさん2014/01/15(水) 01:23:19.03
働けど働けどなお我が暮らし楽にならざりGit手を見る
0999デフォルトの名無しさん2014/01/15(水) 01:23:38.61
埋め
1000デフォルトの名無しさん2014/01/15(水) 01:37:18.06
1000
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。