トップページtech
984コメント273KB

Git 6

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2013/05/21(火) 11:26:36.94
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/
0666デフォルトの名無しさん2013/10/03(木) 12:29:18.26
>>665
それをやっちまったら使いにくいだろう
gitやhgも他のUnixコマンドに合わせて
サブコマンド指定なんてやめて全部オプションでやれって言ってるようなもんだ
0667デフォルトの名無しさん2013/10/03(木) 12:40:43.18
普通のコマンドはサブコマンド指定なんか無しでオプション指定だけの方がいいね
でもgitやhgみたいな複雑なコマンドは、オプションよりもサブコマンドにしたほうがいいね

普通のサブコマンドは2段階のサブコマンド指定なんか無しでオプション指定だけのほうがいいね
でもgit stashやgit bundleみたいな複雑なサブコマンドは、オプションよりも2段階のサブコマンドのほうがいいね
0668デフォルトの名無しさん2013/10/03(木) 12:55:36.79
なんつう一貫性のなさ。
tagもstashもbranchも、中に作成、リネーム、削除、一覧などを内包してるという意味では揃えるべき。
>>667の論で言うならbundleなんかオプションでいい
0669デフォルトの名無しさん2013/10/03(木) 13:09:09.41
stashやbundleのサブコマンドを適当にオプションなんかに割り振られたら泣くわw
やたら一貫性を重視するやつのUIは使いにくくてかなわん
0670デフォルトの名無しさん2013/10/03(木) 13:12:18.92
全部をサブサブコマンド化は勘弁だし
全部をサブコマンド+オプションにするのもサブコマンドが増えてくるとオプションのパターンが増えすぎだと思うし

昔から存在するよく使われるコマンドはサブコマンド+オプションで、
あとから追加された新しい概念のコマンドはサブサブコマンドみたいな感じなのは、わりと妥当だと思うけどね
0671デフォルトの名無しさん2013/10/03(木) 13:28:10.86
git branch -D ブランチ名
git branch -d ブランチ名
git branch ブランチ名
git branch
git stash save
git stash list
git stash apply

branchとstashでよく使うのはこの辺か
branchが2段階コマンドになったら面倒そうだし、
stashが-sとか-aとか--listになったら使いにくそうだな・・・
どっちかに揃えるとか却下だな
0672デフォルトの名無しさん2013/10/03(木) 14:33:01.22
まあ、要するに直感的を目指すと一貫性を追求することになって冗長かつ使いにくくなるんだよ
だからgitには慣れるしかない
0673デフォルトの名無しさん2013/10/03(木) 14:52:05.89
冗長で結構
使いやすさに関しては好きにエイリアス作ればええねん
git brd (git branch -D) とか
git std (git stash drop) とか
0674デフォルトの名無しさん2013/10/03(木) 15:01:59.39
慣れれば良いだけならどっちでも良いだろ
0675デフォルトの名無しさん2013/10/03(木) 15:27:14.37
AndroidとiPhoneの2つのスマートフォンを使っていますという感じか。
どっちももはやスマートフォンってレベルじゃねーよというw
0676デフォルトの名無しさん2013/10/03(木) 15:35:45.39
スレが超加速しててワロタ
0677デフォルトの名無しさん2013/10/03(木) 16:22:09.47
>>664
gitの良さを味わっちゃったら他のクソCVSにはもう触りたくない
そんな話でしょ
0678デフォルトの名無しさん2013/10/03(木) 16:24:00.55
またgit信者が来たか・・・
お互いの利点を確認できるって意味だろ
gitしか知らない奴はホント屑ばっかだな
0679デフォルトの名無しさん2013/10/03(木) 16:26:48.07
個人でCVSを使う分には好きなのを選べばいいし
他人のプロジェクトに参加したいんならそこの流儀に合わせればいい
何の議論の余地もない
0680デフォルトの名無しさん2013/10/03(木) 16:27:19.41
CVS?
0681デフォルトの名無しさん2013/10/03(木) 16:37:18.46
>>680
Version Control SystemのVCSのつもりでした 恥ずかしい

>>678
はい、煽りに対して煽りを書いた屑です。サーセン
0682デフォルトの名無しさん2013/10/03(木) 16:57:50.79
ttp://gitolite.com/gcs/index.html
0683デフォルトの名無しさん2013/10/03(木) 17:46:28.94
cvsでできてgitではできないこと って結構多いからな
その機能を必要としていた人にはちょっとつらい
0684デフォルトの名無しさん2013/10/03(木) 17:48:47.56
たとえば?
0685デフォルトの名無しさん2013/10/03(木) 17:50:51.07
その機能の必要性は?(ニヤァ
0686デフォルトの名無しさん2013/10/03(木) 17:52:19.87
今日のお祭り会場はこちらですか?
0687デフォルトの名無しさん2013/10/03(木) 19:13:08.80
svnからの移行が自然なのはhg
gitは何でもやろうとして何がなんだか分からなくなる
0688デフォルトの名無しさん2013/10/03(木) 19:24:24.27
つまり、githubはオワコン?
0689デフォルトの名無しさん2013/10/03(木) 19:30:56.97
>>683
任意のmodule単位のcheckoutは便利だな。それを想定して作ったリポジトリは未だにcvsで運用してる。
多いとは思わないけど。
0690デフォルトの名無しさん2013/10/03(木) 21:54:06.23
・スペース区切りの順番で混乱することがあるので、hgみたいに-rオプションでコミット指定できたらいいと思う
 git log branch filename
 git grep pattern branch
・git show branch:filename に対して git blame branch filename という統一性のなさ
・標準入出力 git bundle create - branch はOKで git bundle unbundle - は不可能というのも不思議
0691デフォルトの名無しさん2013/10/03(木) 22:03:49.67
https://code.google.com/p/git-core/downloads/list
git 1.8.4.1
0692デフォルトの名無しさん2013/10/03(木) 22:26:08.52
C言語とJavaと違うからって文句言うのか!gitとcvsが違うからって文句言うわがままな奴は
0693デフォルトの名無しさん2013/10/03(木) 22:42:19.78
すいません!
前回commitしたファイルを全部知りたいんですがどうやって調べるのか教えてください
0694デフォルトの名無しさん2013/10/03(木) 22:52:21.16
こう?
git log --stat
0695デフォルトの名無しさん2013/10/03(木) 23:03:40.18
git log --name-stat HEAD~1..HEAD
0696デフォルトの名無しさん2013/10/03(木) 23:30:15.65
>>694-695
たすかりました!
0697デフォルトの名無しさん2013/10/04(金) 11:05:23.93
Rubyにgollumっていうwikiエンジンがあるじゃないですか
あれはgitにコミットするとデータが反映するそうなんですが
どうやって最新の内容を取得しているのでしょうか?
0698デフォルトの名無しさん2013/10/04(金) 11:08:59.92
ソース嫁
0699デフォルトの名無しさん2013/10/04(金) 11:41:58.92
リポジトリへのコミット時にリポジトリからデータ取り込むスクリプト起動?とか想像したが
こいつはHTTPアクセス時にリポジトリから直接データ取って来てページ作ってんのかな
0700デフォルトの名無しさん2013/10/05(土) 13:47:01.95
github、RubyとMVCの限界を悟りC#とMVVMに全面移行 / オープンソース界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1380941226/
0701デフォルトの名無しさん2013/10/05(土) 13:52:53.27
ビックウェーブきたなwww
0702デフォルトの名無しさん2013/10/05(土) 16:36:44.30
twitterもRuby使うのやめたって言ってたし
Rbyってそんな使えないんか
0703デフォルトの名無しさん2013/10/05(土) 16:37:59.12
日本人は役立たずってことか
0704デフォルトの名無しさん2013/10/05(土) 16:46:35.63
GitHubやってる?
http://kohada.2ch.net/test/read.cgi/prog/1363523309/
0705デフォルトの名無しさん2013/10/05(土) 17:52:43.51
>>702
立ち上げには良いけど、長期的にメンテし続けるには向かないってことでしょ
0706デフォルトの名無しさん2013/10/05(土) 23:17:18.40
処理系として気が効いてる分、負荷は高い。
rubyでさっさと立ち上げて、アクセス集中して負荷に耐えられないくらいになれば
大成功ってわけで。

まあ、実際はそのままぽしゃるプロジェクトが大量に存在してるんだけどな。
0707デフォルトの名無しさん2013/10/05(土) 23:25:47.85
railsってそんなに生産性高いの?
0708デフォルトの名無しさん2013/10/05(土) 23:38:17.57
全面移行とかデマじゃないか
0709デフォルトの名無しさん2013/10/05(土) 23:53:35.57
>>707
素のRubyに比べたら
そうとう生産性高いよ。

他のフレームワークと比べたら
同じぐらいだけど。
0710デフォルトの名無しさん2013/10/07(月) 03:26:42.80
>>705
railsは立ち上げはもちろん長期的にメンテし続けるのにもそんな悪くないよ
問題はサービスの規模が大きくなるのに合わせて拡張しようとするとき、
主にコスト的な面でより効率的な選択肢が他にいろいろあるというだけ
0711デフォルトの名無しさん2013/10/07(月) 12:35:54.01
>>710
railsというかrubyの問題だけど長期間メンテナンスしてるとinstance_ofだらけになる。
0712デフォルトの名無しさん2013/10/08(火) 00:40:20.10
railsはやっぱり覚えるべきか・・・
0713デフォルトの名無しさん2013/10/08(火) 09:37:27.60
しかしC#だとmono必須か、、環境によってはRailsより入れにくい
0714デフォルトの名無しさん2013/10/08(火) 09:40:35.16
C#やるならどうせwin鯖だろ
0715デフォルトの名無しさん2013/10/08(火) 09:46:28.75
githubがC#使うとか言ってるのはクライアントの話だから鯖とか関係ない
0716デフォルトの名無しさん2013/10/08(火) 09:51:16.29
今までクライアントにRuby使ってたのか
0717デフォルトの名無しさん2013/10/08(火) 09:53:26.81
クライアントとサーバーのコードを共通化出来るに越したことないから、そのうちサーバーサイドもc#になるかもね
mono使ってるんだから、サーバーはそのままunixサーバーでいいわけだし
0718デフォルトの名無しさん2013/10/08(火) 10:24:47.74
>>716
いままではC++とかJavaとかかな
0719デフォルトの名無しさん2013/10/08(火) 11:16:06.91
つまりmsysgitっていうのをインストールするとき.NETフレームワークがないと使えないってことですか?
0720デフォルトの名無しさん2013/10/08(火) 11:24:04.94
Gitに関係ないから>>704でやれ
0721デフォルトの名無しさん2013/10/08(火) 12:26:45.32
>>720はgithubスレを立てた>>1
07227202013/10/08(火) 13:43:10.99
>>721
https://github.com/hub2ch/hub2ch
こんな恥ずかしいやつと一緒にするなw
0723デフォルトの名無しさん2013/10/08(火) 13:46:34.06
forkボタン押すとforkした連中が見られるのな
0724デフォルトの名無しさん2013/10/08(火) 16:28:12.37
najeira: Gitの運用ルール、ワークフローを考えてみた 2
http://najeira.blogspot.jp/2013/04/git-2.html


これってどうなん?妥当な方法なん?
0725デフォルトの名無しさん2013/10/08(火) 19:29:15.12
うんこ
0726デフォルトの名無しさん2013/10/08(火) 23:40:47.47
指定した二つのコミットの間で変更、追加、削除したファイルの一覧を表示する方法は?
0727デフォルトの名無しさん2013/10/09(水) 00:13:07.35
git logを自分好みでguiに表示したいんですけど
apiみたいなのってないんですか?
0728デフォルトの名無しさん2013/10/09(水) 01:14:06.53
git logに--formatオプション食わせれば好きなフォーマットでデータ吐いてくれる
0729デフォルトの名無しさん2013/10/09(水) 02:59:26.76
>>726
こう?
git diff --name-stat commit1..commit2
0730デフォルトの名無しさん2013/10/09(水) 09:46:15.04
git log --format=jsonとかxmlとかcsvってやってみたけどデータとれなかった
嘘を教えられたのだ!
0731デフォルトの名無しさん2013/10/09(水) 09:54:14.20
>>730
man読めよ。
0732デフォルトの名無しさん2013/10/09(水) 10:14:36.95
>>730
ほんまもんのアホがいる
0733デフォルトの名無しさん2013/10/09(水) 10:59:34.25
非分散型のgitって無い?
0734デフォルトの名無しさん2013/10/09(水) 11:02:21.67
>>733
svnとか使えばいいだろ
0735デフォルトの名無しさん2013/10/09(水) 12:11:51.81
svnはあの開発陣のCVSヘイトっぷりが怖くてキモくて嫌だった
0736デフォルトの名無しさん2013/10/09(水) 12:16:11.60
>>735
ならCVS使っとけ
というかというかこっちのスレに行け

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

非分散型が目当てならgitには全く関係無い
0737デフォルトの名無しさん2013/10/09(水) 12:29:15.77
分散型でも一点のみで使ったら事実上は非分散では?
0738デフォルトの名無しさん2013/10/09(水) 12:43:44.47
gitはローカルリポジトリだけだと一人でしか使えないじゃん
0739デフォルトの名無しさん2013/10/09(水) 13:44:08.60
>>733
非分散(集中?)な時点でgit のメリットの8割を失ってね?
0740デフォルトの名無しさん2013/10/09(水) 16:11:11.59
そうか
開発中はgitで自由に開発して、リリースの段階になったら
svnにコミットすればいいのか。

これですべての問題が解決しそうだぞ。 検討してみる
0741デフォルトの名無しさん2013/10/09(水) 17:08:47.75
それなら中央もgitでいいじゃん
0742デフォルトの名無しさん2013/10/09(水) 17:20:03.03
中央までgitにしたら困らない? 大丈夫?
0743デフォルトの名無しさん2013/10/09(水) 17:26:52.31
サーバがsvnのときとgitのときで大きく違うのはリポジトリ作成と公開の部分だよね
0744デフォルトの名無しさん2013/10/09(水) 18:07:35.30
複数人で使うときに使うコマンドを全部おしえて
0745デフォルトの名無しさん2013/10/09(水) 18:13:02.62
>>744
流石に全部となると、git入門 とかでググったほうがいいんじゃね
0746デフォルトの名無しさん2013/10/09(水) 19:25:45.68
>>742
何が困るんだ?
0747デフォルトの名無しさん2013/10/09(水) 22:42:54.73
>>740
オールgitに比べて、中央svnローカルgitにする利点ってなんだ?
中央svnローカルgitは分散管理のままなのは理解してるかな?
0748デフォルトの名無しさん2013/10/09(水) 23:01:38.55
オールgit・・・gitだけを覚えれば良い
git+svn・・・gitとsvn、そしてgitとsvnの連携の三つを覚えないといけない。

たとえsvnの経験者であったとしても
git+svnは、svnを忘れてgitだけを覚えればいいのと違い
gitとsvnの連携という、余計なことを覚えないといけない。
0749デフォルトの名無しさん2013/10/09(水) 23:22:06.54
非分散管理希望とか言っといて
svn+gitで問題解決とかわけがわからんなw
0750デフォルトの名無しさん2013/10/10(木) 00:00:56.81
今Gitサーバをインストールするなら何がお勧め?
数人程度の単一プロジェクトで
0751デフォルトの名無しさん2013/10/10(木) 00:17:49.15
Gitを入れるのがいいんじゃないかな?
0752デフォルトの名無しさん2013/10/10(木) 00:34:04.52
>>750
gitlabお勧め
0753デフォルトの名無しさん2013/10/10(木) 00:37:06.29
その数人がUnixアカウントやssh使うのに抵抗が無ければ、
特別なものを入れる必要もないけどねえ
0754デフォルトの名無しさん2013/10/10(木) 00:46:07.25
>>753
じゃあ聞くが、中央リポジトリどうやってんの?
そこにコミットされたものの把握とかどうやってんの?
コミットされたコードに対するコメントやレビューどうやってんの?
複数人で共有しているリポジトリの管理どうやってんの?
masterへのマージどうやってんの?
不正(質の悪い)コードのマージをどうやって管理してるの?

人が数人集まるってことは、
コミュニケーションが生まれるってこと。
gitだけでどうやってコミュニケーションするの?
0755デフォルトの名無しさん2013/10/10(木) 00:58:44.32
> 中央リポジトリどうやってんの?
> そこにコミットされたものの把握とかどうやってんの?
> masterへのマージどうやってんの?
このへんは別に特別なものはいらんな
UNIXアカウント+sshだけでおk

> 複数人で共有しているリポジトリの管理どうやってんの?
リポジトリの管理って具体的に何?

> 不正(質の悪い)コードのマージをどうやって管理してるの?
> コミットされたコードに対するコメントやレビューどうやってんの?
> 人が数人集まるってことは、
> コミュニケーションが生まれるってこと。
> gitだけでどうやってコミュニケーションするの?

Gitはバージョン管理ツールであって、
コミュニケーションツールではありません
0756デフォルトの名無しさん2013/10/10(木) 01:06:18.13
例えばこんな場合。

ローカルだけで開発していたら他人の進捗状況がわからない。
だから中央リポジトリは必要。

中央リポジトリにあるものをだれでも勝手に
消したりできたらまずいから権限の概念が必要になる。

ただし管理者のみが中央リポジトリを作成できるなら
中央リポジトリを作るために管理者にお伺いを建てないといけなくなる
これは良くない。

理想は誰でも中央リポジトリをサクッと作れて、
権限がある人だけが消したりできる。
プロジェクトに参加者を登録して、参加者に
閲覧専用権限を与えたり、コミット権限を与えたりしたい。
コミットに関するコメントを付けたい。
それらを自動的にメールで通知したい。

ということで、gitだけではできないことを行うために
サーバーが必要になる。
0757デフォルトの名無しさん2013/10/10(木) 01:08:13.41
>>755
> Gitはバージョン管理ツールであって、
> コミュニケーションツールではありません

だから、git以外のgitサーバーを使うって話になるんだろ?
こっちは最初からgitではない物=特別なものを入れるって話をしてるんだが?

お前は、git以外に入れる必要はない=gitでコミュニケーションも
できるっていいたいんだろう?
0758デフォルトの名無しさん2013/10/10(木) 01:10:58.32
なんで「Gitサーバをインストールする」が
コミュニケーションツールを導入するまで飛躍するんだよwアホかw
0759デフォルトの名無しさん2013/10/10(木) 01:17:40.34
>>758
Gitサーバーに役目にコミュニケーションツールまで含まれるからだよ。

Gitサーバーがどんな機能を持っているのか調べなさい。

http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

http://git-scm.com/book/ja/Git-サーバー-GitWeb
http://git-scm.com/book/ja/Git-サーバー-Gitosis
http://git-scm.com/book/ja/Git-サーバー-Gitolite

http://git-scm.com/book/ja/Git-サーバー-Git-のホスティング
GitHub
0760デフォルトの名無しさん2013/10/10(木) 01:19:27.65
>>756
誰でも中央リポジトリを作れるのと権限がある人だけが消せるを両立させるのは難しいかな
閲覧専用権限もちょっと難しい
でも質問の「数人程度の単一プロジェクト」ならこんなのいらんだろ

>コミットに関するコメントを付けたい。
>自動的にメールで通知したい。
全部メールでやればいい

それ以外はUNIXアカウント+ssh+gitだけでできるから
0761デフォルトの名無しさん2013/10/10(木) 01:20:59.61
>>760
いるかいらんかは
お前が決めるな。
0762デフォルトの名無しさん2013/10/10(木) 01:24:16.33
>>759
そこで述べてるGitサーバの主要な機能はUNIXアカウント+ssh+gitで実現可能
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

4.6からのオプショナルな機能を実現するために
他のものをインストールする必要があるわけ
0763デフォルトの名無しさん2013/10/10(木) 01:25:18.79
>>761
いるかいらんをお前も決めるな
おれはできると可能性を述べているにすぎないぞ
0764デフォルトの名無しさん2013/10/10(木) 01:25:32.88
単一プロジェクトでも
自分用ツールを皆と共有するために
リポジトリ作りたくなるし、
gitサーバーがあったほうが柔軟で便利だろ。

メール? 送信するのが面倒だろ。
どうやって掲示板のやりとりみたいなものを
数人でメールでやるんだ?

できるのと、簡単に便利にできるのとでは
わけが違う。

入れないほうがいいという理由がない。
0765デフォルトの名無しさん2013/10/10(木) 01:27:50.27
>>762
実現可能 かどうかは論点じゃないんだよ。

実現可能かどうかで言えば
ソースコード管理もディレクトリコピーで実現可能。

そういうことじゃないだろ?
どれだけ簡単にできるかが重要なんだよ。

頑張ってgitサーバー相当のことが出来るようになりました!
は意味が無い。最初からgitサーバー使えばいいと言われて終わり。
■ このスレッドは過去ログ倉庫に格納されています