Git 7
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/10/16(水) 22:15:47.64Git - 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.73Git 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.38Gitによるバージョン管理
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前スレ984以降何かあった？
0005デフォルトの名無しさん
2013/10/16(水) 23:48:41.610006デフォルトの名無しさん
2013/10/17(木) 15:29:47.880007デフォルトの名無しさん
2013/10/17(木) 18:35:24.25インターネット側からも自分の gitlab 鯖につなげられるようにしたいのですが
とりあえず 22/tcp を開いておくだけで大丈夫ですか
注意点としては、ubuntu 上に作成したユーザーで
SSH不要なユーザーはSSH利用停止、
SSH使うユーザーはパスワードをガチガチにする
それくらい？？
0008デフォルトの名無しさん
2013/10/17(木) 19:06:40.73sshdのポート変更、パスワード認証の禁止。
0009デフォルトの名無しさん
2013/10/17(木) 23:57:29.21gitlab使ったことないけど、sshに限った話なら
公開するならポート変更しなくていい
そのかわりパスワード認証じゃなくて公開鍵認証にしないと危ない
0010デフォルトの名無しさん
2013/10/18(金) 13:14:53.920011デフォルトの名無しさん
2013/10/18(金) 13:21:30.070012デフォルトの名無しさん
2013/10/18(金) 14:40:56.02そのマシンを勝手に使われたり、乗っ取られたら結局終わりですよね。
勝手に使われたり、乗っ取られないのが前提なら安全と言うことですか？
0013デフォルトの名無しさん
2013/10/18(金) 15:29:01.72後はどうしたいかによるので自分で判断してください。
0014デフォルトの名無しさん
2013/10/18(金) 16:09:33.18SSHのパスワード認証は攻撃多いからね
ユーザーが1人でも弱いパスワードを設定したらあっという間に入られて、
そのマシンを踏み台にして新たな攻撃が始まるよ
ガチガチにしろと言うより公開鍵認証に限定するほうが簡単で確実
0015デフォルトの名無しさん
2013/10/18(金) 18:53:09.120016デフォルトの名無しさん
2013/10/18(金) 20:53:47.400017デフォルトの名無しさん
2013/10/18(金) 23:40:59.49端末に侵入されたら、キーロガーとかでパスワードも盗まれるでしょうし、セッションジャックもある。終わってる。
入られない前提で困るのはサーバにアクセスされ続けること。
ブルートフォースでは、鍵だと相手にも強度が伝わるので諦めてくれるが、パスワードだと弱いかもなので責められ続ける。パスワードだと当然辞書も来る。
あと管理が楽。
0018デフォルトの名無しさん
2013/10/19(土) 00:54:45.55なんか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それは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あまり引きずる話でもないけど
パスワード認証を許容すれば、関係ない端末からもブルートフォースが成立してしまう。
公開鍵認証のみにしておけば、パスワード+秘密鍵になるから、その分安全になる。
ノンパスワードの鍵作成は止めましょう。
あれは、バッチシステム用です。
0024デフォルトの名無しさん
2013/10/19(土) 11:27:07.260025デフォルトの名無しさん
2013/10/19(土) 11:29:04.860026デフォルトの名無しさん
2013/10/19(土) 11:43:36.13意味が無いじゃないですか！
0027デフォルトの名無しさん
2013/10/19(土) 12:15:44.550028デフォルトの名無しさん
2013/10/19(土) 12:18:56.14100%安全だと所有者も使えないだろうから意味がない。100%は有り得ない。
0029デフォルトの名無しさん
2013/10/19(土) 16:34:27.140030デフォルトの名無しさん
2013/10/19(土) 23:04:37.060032デフォルトの名無しさん
2013/10/20(日) 05:19:41.960033デフォルトの名無しさん
2013/10/20(日) 14:21:28.25以前のコミットに戻した後，コミットを戻す前の状態に戻すことは出来ないという認識でいいのでしょうか？
0034デフォルトの名無しさん
2013/10/20(日) 14:38:18.93戻す事はできるという認識に改めてください。
0035デフォルトの名無しさん
2013/10/20(日) 15:04:59.360036デフォルトの名無しさん
2013/10/20(日) 15:21:03.72できるんですか！
調べ方が悪かったみたいです
もうちょっと調べてみます
>>35
そうです
コミットのキャンセルのキャンセルです
0037デフォルトの名無しさん
2013/10/20(日) 16:48:39.060038デフォルトの名無しさん
2013/10/21(月) 10:47:39.82ここ落とし穴だから気をつけろ的な注意事項とかある？
0039デフォルトの名無しさん
2013/10/23(水) 00:18:19.590040デフォルトの名無しさん
2013/10/23(水) 00:18:51.100041デフォルトの名無しさん
2013/10/23(水) 00:28:00.700042デフォルトの名無しさん
2013/10/23(水) 02:35:44.61git svn clone時に空ディレクトリを無視せず取ってくる方法はないでしょうか？
git svn dcommit時に削除する方法は、ググったら出てきたのですが、、、
0043デフォルトの名無しさん
2013/10/23(水) 07:24:17.370044デフォルトの名無しさん
2013/10/23(水) 08:24:02.25ググってわかりやすいと思ったサイトを印刷して
本のように綴じたら？
0045デフォルトの名無しさん
2013/10/23(水) 09:48:11.53ありがとうございます。
最初から書いておくべきで申し訳ないんですが、
空のファイルを入れておく話につきましては検索して知ってました。
しかし、自分の管理していないモジュールだったら空のファイルといえど勝手にコミットできませんよね。
それに些細なことですが、空のファイルのコミットのためにだけはsvnを直接 使わないとダメなので少々面倒です。。
0046デフォルトの名無しさん
2013/10/23(水) 10:31:11.42これを気合で嫁
http://git-scm.com/book/ja
0047デフォルトの名無しさん
2013/10/24(木) 02:03:12.36githubで管理してる自分のプロジェクトに、海外の方からpull requestが来ました。
本来のコードへの影響を最小限にするためか、（または本人が面倒だったのか）
「既存のロジックコピペで必要なところ改変」みたいな「追加」のソースが来てます。
おかげで、似たような処理をしているロジックが結構あります。
実装された機能のアイディアはいいのですが、
改変内容が気に入らない場合、皆さんはどんな対応をしているでしょうか。
一旦受け入れて、後でガッツリ自分で改変するか、
理由を述べて却下して、相手に実装しなおしてもらうか、
どんな対応が望ましいのか、参考までに聞かせてください。
海外でどんな対応するのが一般的なのかも知りたいです。
よろしくお願いします。
0048デフォルトの名無しさん
2013/10/24(木) 04:49:30.60GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/
0049デフォルトの名無しさん
2013/10/24(木) 13:00:03.35このコマンドだと自分のところが中央リポジトリになるように
思えるんですが、中央サーバに登録するには
どうしたらよいのでしょうか
0050デフォルトの名無しさん
2013/10/24(木) 13:02:43.700051デフォルトの名無しさん
2013/10/24(木) 13:10:01.12サーバ側の実装による
リポジトリを作成する権限が与えられてるなら、何らかの案内があるはずだから
管理者に確認したらいいよ
0052デフォルトの名無しさん
2013/10/24(木) 13:17:20.74すみません、わたしが管理者です
どう案内すればいいかいま検証中なんです
0053デフォルトの名無しさん
2013/10/24(木) 13:19:46.720054デフォルトの名無しさん
2013/10/24(木) 13:30:46.61末端PCでプロジェクトを作ったのでそれを中央サーバに
新規に登録したいのですが
cvsのinitに相当するコマンドはgitにはないので
プロジェクトのファイルを中央サーバにコピーして
中央サーバでgit initして、それを
末端PCで git clone する という動きでよいですか？
0055デフォルトの名無しさん
2013/10/24(木) 13:48:24.27よくない。空のリポジトリが作られるだけ
基本、サーバでgit initして、ローカルからpushだけど
実装によるから、それかかないと答えようがない
0056デフォルトの名無しさん
2013/10/24(木) 13:50:34.290057デフォルトの名無しさん
2013/10/24(木) 15:45:42.37ローカルでinitしてサーバにpushすべきというのは理解しました
でも、最初の手順で空のリポジトリが作られるだけという
動きの理由がよくわかりません。
0058デフォルトの名無しさん
2013/10/24(木) 15:46:31.03じゃあ理解できてませんすみません
0059デフォルトの名無しさん
2013/10/24(木) 15:51:56.91それをサーバに作った直後に、末端からcloneしたところで、エラーしか出ません
初回は必ず末端のローカルリポジトリから、コミット情報をpushしてやる必要があるのです
ということかと
0060デフォルトの名無しさん
2013/10/24(木) 15:54:31.600061デフォルトの名無しさん
2013/10/24(木) 16:05:04.70したがって中央サーバーで行う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ファイルコピーして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.21git-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中央サーバと呼んでるマシンのOSとサーバーソフトウェア次第で
その中央サーバにリポジトリを作る方法はいろいろあるってことだよ
君がそれを言わないから、Unixサーバのsshアカウントを利用する方法をみんな説明してる
0068デフォルトの名無しさん
2013/10/24(木) 19:14:17.41gitでリポジトリを作る方法はsshでログインして作るのしか
知らなかったので質問の意図がわかっていませんでした。
おっしゃるとおりsshアカウント経由で作業する予定です
gitにも、cvsのようなpserver的なものがあるのですか？
0069デフォルトの名無しさん
2013/10/24(木) 19:41:50.45Gitoliteとか良く使われてる
ここに目を通しておくといい
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ていうか、ちょっとぐらいドキュメント読めよ
0071デフォルトの名無しさん
2013/10/24(木) 20:16:58.730072デフォルトの名無しさん
2013/10/24(木) 21:01:48.59同じことを同じやり方で解説してるところがほとんどなくて
その情報が古いのかモダンなのか間違ってるのか
とんとわからない状態でした
0073デフォルトの名無しさん
2013/10/24(木) 21:22:26.01どのページってどこのこと。知らんよ
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生のsshアカウントでやるのは権限とか考えるといろいろ面倒
0075デフォルトの名無しさん
2013/10/24(木) 22:08:37.590076デフォルトの名無しさん
2013/10/24(木) 22:11:08.350077デフォルトの名無しさん
2013/10/24(木) 22:31:26.71gitoliteには組み込まれてないよ
だから、好きなウェブベースのgitクライアント使えばいいと思う
ていうか、普段使ってるgitクライアント使うのが一番いいと思うけど
turtoiseなり、sourcetreeなり
0078デフォルトの名無しさん
2013/10/24(木) 22:37:17.99gitlabおすすめ。
gitolite＋githubクローンと
言ってもいいぐらいの
ウェブシステムだよ。
githubを使っている人や
逆に将来github使うって人には
いいとおもうよ。
0079デフォルトの名無しさん
2013/10/24(木) 22:39:05.26gitoliteはリポジトリとユーザ管理をgitolite-adminっていうリポジトリで行うから
そのリポジトリを自分が使いたいクライアントで触ればいいだけ
0080デフォルトの名無しさん
2013/10/24(木) 22:55:54.47自前でいれるなら、1.8消さなくてもgitlabが使えるように入れたらいいのに
0081デフォルトの名無しさん
2013/10/24(木) 22:58:55.50Linuxはディストリがたくさんあって、
すべての環境がどうなってるのか把握できないから。
Rubyが二つ入っていると、何が起きるかわからない。
0082デフォルトの名無しさん
2013/10/24(木) 23:04:25.26Git手を見る
0083デフォルトの名無しさん
2013/10/24(木) 23:15:01.41>>81
ruby2を/opt/ruby2とかに入れて、gitlabでruby実行する時はそこを使うようにもできると思うんだけど
0084デフォルトの名無しさん
2013/10/24(木) 23:16:12.50よくわからん。
ファイルと同様に極普通に使うものだろう？
0085デフォルトの名無しさん
2013/10/24(木) 23:16:44.18歌人さんかな？
0086デフォルトの名無しさん
2013/10/24(木) 23:42:16.74かなり無茶な感じに特定rubyの特定ライブラリに依存させたもの作って運用することができるけど、
OSのパッケージマネージャでそれらを管理するのは地獄の苦しみだな
0087デフォルトの名無しさん
2013/10/24(木) 23:47:24.39パッケージマネージャ揃ってるだろう？
0088デフォルトの名無しさん
2013/10/24(木) 23:49:22.020089デフォルトの名無しさん
2013/10/24(木) 23:50:49.400090デフォルトの名無しさん
2013/10/24(木) 23:56:25.07>ファイルと同様に極普通に使うものだろう？
そうかな
データベースサーバ新しく立ち上げるとか、既存のデータベースサーバにアクセスできるようにするとか
色々考えることあると思う
0091デフォルトの名無しさん
2013/10/25(金) 11:15:13.640092デフォルトの名無しさん
2013/10/25(金) 16:23:50.440093デフォルトの名無しさん
2013/10/26(土) 03:52:42.91WebページやWebアプリを作っているのですが、サーバ側のリモートリポジトリはそのプロジェクト毎に作成し、使うものなのでしょうか？
それとも他に一括で管理する方法があるのでしょうか？
0094デフォルトの名無しさん
2013/10/26(土) 08:53:18.880095デフォルトの名無しさん
2013/10/26(土) 11:37:13.47質問がよくわからん
ローカルもサーバも違いはないよ
0096デフォルトの名無しさん
2013/10/26(土) 14:49:08.12一つのリポジトリの中にディレクトリを掘って、
複数のプロジェクトのファイルを突っ込んでもいいし、
プロジェクトごとにリポジトリを作ってもいい。
どちらも一長一短ある。
プロジェクト間でファイルを共有しているなら一つのリポジトリにして、
そうでないならわけた方がいいかもしれん。
わけておけばプロジェクトごとにリポジトリのcloneが可能だが、
そうでないなら全部cloneすることになる。
0097デフォルトの名無しさん
2013/10/26(土) 17:44:41.640098デフォルトの名無しさん
2013/10/26(土) 18:48:46.48>一括で管理する方法があるのでしょうか？
って聞いてるから、管理方法をしりたいんじゃなかろうか。。
0099デフォルトの名無しさん
2013/10/26(土) 19:32:00.07ありがとうございます。
プロジェクトごとに分けることにします。
0100デフォルトの名無しさん
2013/10/26(土) 21:09:35.51「アリスとボブのGit入門レッスン 」という本がよさそうなんだけど
この本macで解説してるんで聞いてみた。
gitってなんでこんなに名が知られていないんでしょうかね？
010196
2013/10/26(土) 21:17:57.89俺ならsubmoduleを使うが、あの使いこなすのが難しい機能を
「使い始めた」と言っている>>93に勧める気にはなれなかったので。
■ このスレッドは過去ログ倉庫に格納されています