- 1 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 21:16:57.41 .net]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 7
toro.2ch.net/test/read.cgi/tech/1381929347/
- 862 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:13:00.11 ID:PAL5W9yR.net]
- >>843
ステマ言われるのそんなにないやろ
こないだGitHubの本でステマ言われてたやつはあったけどアレは本当にいろんなところでみたからな…
- 863 名前：デフォルトの名無しさん [2014/04/10(木) 18:18:14.35 ID:2hD55smI.net]
- そろそろ誰か寸評とか星付きのGit本リスト作ってテンプレに入れてよ。
- 864 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:25:00.33 ID:B7i8mwfP.net]
- >>839
う～ん、ハサミに例えると、たまに 3cm とかの幅で切りたいから、目盛りみたいのがついてたら便利じゃね？ って感じかな。
そんなことしない人には不要なんだけど、使わなきゃ邪魔になるわけでもないしね。
- 865 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:32:01.98 ID:I4ZYtafb.net]
- GitHub実践入門はGit本体についての説明はゴミみたいなもんだし、
あれを入門書の決定版とか紹介したら叩かれて当たり前だな
逆引き入門の方は、ちょっと立ち読みしてきたけど、
これから始める人にもある程度使ってる人にもいいと思うよ
- 866 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:40:25.42 ID:sy5Vj+v2.net]
- >>851
うーん、その例えも何か違う気がするなあ
Gitに付けるのは変だと思う、でもGithubに付けるならアリだと思うんよね
ハサミで言うなら、ハサミの歯のパーツを作ってるトコが目盛り付けちゃう感じがする
- 867 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:50:01.99 ID:8TUEkxNY.net]
- たまに話題になるくらいならいいが新刊出るたびにレビューするのは尼でやってくれ
- 868 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 19:24:24.61 ID:B7i8mwfP.net]
- >>853
ああなるほど、そうかも。
別にツールでやろうが、システムでやろうが、できればいいじゃんというスタンスなので。
- 869 名前：デフォルトの名無しさん mailto:sage [2014/04/10(木) 19:57:43.91 ID:N3vuTs56.net]
- 846おねがいします
- 870 名前：デフォルトの名無しさん [2014/04/10(木) 20:42:39.14 ID:1wauUDTZ.net]
- 目的とか自分のid的なものとか組み合わせたり
- 871 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 00:18:39.32 ID:MhGpUxGc.net]
- Gitは～には向かないのでは？ という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。
大組織での開発にも、いや、Gitってこういう使い方すれば役に立つよ、という書き込みなら
まだ建設的な議論が出来そうだけど、具体的な内容ゼロの当てこすりや小馬鹿にしたような
書き込みばかり。
まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね？
と思う。
- 872 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 00:20:54.93 ID:tDVfunDo.net]
- 自分は違うんだぞ、って言う自意識過剰なレス乙
- 873 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 04:46:00.71 ID:KAyUJDly.net]
- >>858
小馬鹿にするっていうか、「～には向かないのでは？」って書いてる奴が馬鹿過ぎるんだものｗ
- 874 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 05:10:33.92 ID:dLUSGIri.net]
- >>846
上流が何か命名規則を指定してるならそれに従う
してないならなんでもいいが、ブランチの意図を端的に表した名前にするのがお勧め
技術的にはマージするときのブランチ名は単にコミットを指すポインタなのでコンフリクトは起こらない
GitHub上の詳細は知らんがユーザなり何なりで別の名前空間に分離されてるはず。
プルリクが活発なリポジトリの画面眺めてみろ
- 875 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 05:31:32.87 ID:dLUSGIri.net]
- ロック必要だよ派は
1. 簡単にマージできない類のファイルを扱う必要がある
2. その手のファイルに対する編集作業を黙って初めてしまうとあと
で大変なので、編集しようとしたやつがいたら競合の可能性があ
ることを作業前に警告したい
と言ってるように思えるが、そういう要件は分散VCSというか分散作
業とは相性悪い。誰かも言ってたが、実現には技術的に困難が伴う
し、分散作業時に他人の作業に足を引っ張られないことを重視する
人からしたら、分散作業の良さをスポイルする機能を実装して誰得
状態なわけだし
解決方法は様々だが、会社で使うんなら「今からこのファイル編集
します」ってメールなりでコミュニケーションとれよと思う。
いちいちそんなコミュニケーション取ってらんねーよとおもった？
分散作業の世界へようこそ。
- 876 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 07:17:31.56 ID:tDVfunDo.net]
- >>862
> コミュニケーションとれよと思う。
ロックはそのための仕組みなんだが...
そもそも、誰が編集するかわからないのに誰にメールするんだ？
関係者全員とか迷惑なんですけど。
- 877 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 08:29:42.74 ID:KpoPG81P.net]
- >>863
＞そもそも、誰が編集するかわからないのに誰にメールするんだ？
自社開発だろうが、人売りで売られた先だろうがオプソだろうがなんだろうが
ある程度以上の規模になったらプロジェクト全員が入っているMLなりIRCなり
Skypeなりのプロジェクト全員への共有連絡先位あるだろ。 プロジェクトの
関係者以外にコミット権限を渡しているのなんて普通ないからそういう所に
一報を入れておけば事足りし。
- 878 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 08:36:31.74 ID:eJqQZ1pt.net]
- >>864
都合の悪いところを読み飛ばす癖直した方がいいぞ。
> 関係者全員とか迷惑なんですけど。
- 879 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 10:06:53.15 ID:Hu21eWhF.net]
- issue tracker ってそんなに普及してないのかな
- 880 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 10:15:31.46 ID:pXE62EYm.net]
- bug tracker ですら怪しいぞ。
とりあえず今までのやり方で回ってる大きな所はリスクとってやり方かえないし。
その気持ちもわからんでもないしなー。
- 881 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 11:10:30.81 ID:057GiJd2.net]
- githubでパッチを送る時ってぷるリクエストとフォークどっちのほうがいいのかおしえて
- 882 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 11:31:59.99 ID:pXE62EYm.net]
- fork しても結局 pull request になる。
勿論直接 pull request 書いてもいい。
- 883 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 12:37:49.14 ID:5a7Ytf0i.net]
- >>534
これ完全に騙されたわ。
専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。
おまけに本に書かれてる詳しい解説をネットにしているURLが間違ってるのか見れない。
この本買うつもりなら、一回本屋で立ち読みして欲しい。
間違ってもネットで注文はしない方がいい。
- 884 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 14:53:09.67 ID:H+z7YdpC.net]
- 茶色い本とgit-scm.comがあれば十分でしょ。
- 885 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 18:50:58.20 ID:dLUSGIri.net]
- >>865
メールに限定してないだろ。ちゃんと読め？
> 都合の悪いところを読み飛ばす癖直した方がいいぞ。
ブーメラン乙
- 886 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 19:05:04.23 ID:ZfLpKqnY.net]
- ロックしてれば後から編集しようとした人はその場で分かるからな
Gitなんかはソースコードを管理する為のツールだから、ロックせずとも後でパッチをマージすればいいって考えるのは妥当だけど、バイナリファイルを管理する場合、その考えは通じない
- 887 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 19:10:14.32 ID:im4bHUKa.net]
- >>872
全員に通知することを問題視してるんだが？
で、メールでなくてどうやるのさ。
掲示板にでも書いといて、編集の前にいちいち確認するのか？ (w
- 888 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 21:38:28.22 ID:TfGD3Njm.net]
- git clone git@～:～
WindowsからはcloneできるのにLinuxからは出来ないんです助けてください。
ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
ブラック企業でまだ会社なんですがやめたいですorz
- 889 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 21:50:10.15 ID:mRoalEfA.net]
- >>875
接続先をgithub.com:22からssh.github.com:443に切り替えてトライ。
- 890 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:14:05.98 ID:TfGD3Njm.net]
- 接続先を変えるのは・・こまります・・・
- 891 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:26:00.91 ID:mRoalEfA.net]
- いいからやってみ。
- 892 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:35:44.27 ID:gZGZUewy.net]
- *Gitに*バイナリのロックが必要かどうかについて議論するんじゃなくて、
バージョン管理システム一般にロックが必要かどうかについて話してる奴はスレチなの認識してる？
誰もバージョン管理一般についてロックが不要だと強弁するつもりないし、一般的な話ならなぜここでやる必要があるのか説明してくれ。
- 893 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:37:52.84 ID:gZGZUewy.net]
- ロック疑問派「Gitみたいな分散管理システムとファイルのロックは相性が悪い、メールとかで連絡すべき」
ロック必要派「メールで連絡するとかありえない、ロックがあればそれで全て解決する」←はて分散管理との相性の悪さという根本的な問題はどこいった？
関係者全員とか迷惑を読み飛ばされたことに対して都合の悪いとこ読み飛ばすなとか批判するなら、まず相性が悪いものをどうやって実装するのかについて説明してからにしろよ
(忍法帖が消えてレスを分割せざるを得なかった、すまん)
- 894 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:53:57.78 ID:TfGD3Njm.net]
- どう変えるのかわかりません・・・
git@github.com:443:アカウント名.リポジトリ名.git
ってやりましたがだめです
ssh -t git@github.comをやっても接続されないしずっと接続を頑張っているのか何も表示されません
- 895 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 22:56:34.43 ID:bQVZn08t.net]
- >これ完全に騙されたわ。
>専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
>見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。
普通専門書ってそういうものだよ。
注釈とか用語解説はまとめて巻末とか当たり前、それとクロスリファレンスしながら読むって
やり方になれておいた方がいい。
普段固い本をまったく読んだことがないんだろうけど、こんなピント外れな批判されちゃう書籍
も可哀想だ。
「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。
- 896 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 23:40:30.41 ID:nUaUWR93.net]
- >>873
つまりソースコードのロックは百害あって一利なしでいいよね？
- 897 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 23:43:39.52 ID:nUaUWR93.net]
- >>882
> 「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。
そういう用途ならこれがいい。
なんかタイトルからクソ本みたいな印象を受けるかもしれないけど
読んでみるとふつうに良い。
アリスとボブのGit入門レッスン-川野辺-正博
www.amazon.co.jp/dp/4798035009/
- 898 名前：デフォルトの名無しさん mailto:sage [2014/04/11(金) 23:48:43.96 ID:GvHlzSSy.net]
- サルでもわかるGit入門 ?バージョン管理を使いこなそう? | どこでもプロジェクト管理バックログ
www.backlog.jp/git-guide/
これじゃないの
- 899 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 00:33:16.71 ID:cB842cS/.net]
- >>884
開発の流れに沿ってシーンごとに必要なコマンドがわかるのがいいな
トレードオフで要点が複数ページに散らばっててぱっと読みにくいが
そこはネットかリファレンスを使うべきだし良書
>>885
本が至上という権威主義発言でしょ
難しい本を買うほど偉いという
- 900 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 00:53:51.35 ID:lUY660Yq.net]
- 875です
すいませんconfigでポート443したらいけました
Windowsでは指定しなくてもsshでclone出来るのに
Linuxでは指定しないと接続出来なくてタイムアウトするんですね
やっと接続できたので今から始発まで？仕事です
- 901 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 00:58:42.39 ID:+ggEbXVl.net]
- > 本が至上という権威主義発言でしょ
ん～？ 単にページ数の問題。
一般的に本のほうが情報量が多い。
- 902 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 00:59:15.38 ID:+ggEbXVl.net]
- 情報量じゃなくて、情報の密度に言い換えよう。
- 903 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 01:07:41.37 ID:cB842cS/.net]
- 背伸びしてる中学生感が痛々しいからやめて
- 904 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 01:22:43.30 ID:9dlKXrRX.net]
- ページ（画面）あたりでなくページ「数」の問題なら
本の方が密度が低いような
「こんなの本買うまでもなかったじゃん！」
って読後に思えるくらい�
- 905 名前：ﾌ情報量・密度の方が
入門書としては成功な気がする
そして手元に残るのは入門書ではなく
黒魔術満載のチートシート…… [] - [ここ壊れてます]
- 906 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 03:03:51.85 ID:BW6c4MFF.net]
- >>874
＞全員に通知することを問題視してるんだが？
多人数でのプロジェクトをしたことないの？コンフリクトが頻繁に起きるような
共有ファイルの編集が必要な場面で通知がない方が問題だし、メールなんて
飛び交ってる状況なんだから適切なフィルタリングをしないと仕事にならんし。
＞掲示板にでも書いといて、編集の前にいちいち確認するのか？ (w
場所によっては普通にそういう運用をしてるところもあるな。
掲示板に編集します、編集終わりましたとか書いて、そういうのが目で見て
分かる状況になってないと、おちおちトイレにも行ってられんわ。
- 907 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 05:04:02.28 ID:U3ze+O2N.net]
- >>892
もっぽど無能な設計者とリーダーだったんだな。もしかして君が…。
- 908 名前：デフォルトの名無しさん [2014/04/12(土) 05:33:31.04 ID:hrYZFkTS.net]
- 延々とスレチ続けてる時点でお前ら全員知障か気違い
- 909 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 07:29:31.34 ID:gbb+IGlp.net]
- 仮に、Gitに理想的なロック
(例えばあるファイルをロックしたら、
clone済みの全てのローカルリポジトリにおいてアトミックにロックされるようなロック)
が実装されたとしても、
人間様がロックの獲得と開放を制御する限り、
どこかで人間のレイヤへの割り込みは不可避なんだよね。
「御社の××さんがここ数日△△ファイルのロック取ってらっしゃるようですが、
編集中というステータスでよろしいでしょうか？
また、可能でしたら早めに解除していただけますか？」
とかね。もしそうなったとき、
開発体制公式の連絡手段が掲示板ならいちいち掲示板にかくしかない。
でもそんなの面倒でやってらんないよねって話でしょ。
ロックを強制解除する？
もし相手が本当に編集中で相手の作業が無駄になったらどうするの？
ロックって無駄な編集作業を避けるためのものじゃなかったの？
- 910 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 08:11:11.12 ID:12W5Y+Qh.net]
- 必要な人たちでロック機構ありのgitをフォークすればいいんじゃないかな。なんだか
凄腕の人達があつまってるみたいだし、すばらしいソフトが誕生すると思うよ。
わかったら早くやれ。
- 911 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:21:16.15 ID:ul/EWy73.net]
- バイナリの場合にロックが必要ということは
要するに、ソースコード（テキスト）に関しては
ロックは不要ってことでいいよね？
- 912 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:22:08.45 ID:zuiRAUii.net]
- 分散型はロックと相性悪いし、gitの開発陣がロックを必要としてるようには思えない
ロックが必要なプロジェクトはsvnを使えば良い
- 913 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:25:48.39 ID:ul/EWy73.net]
- ロックが必要な場合はあるかもしれないとして
それはバイナリに限るわけで
ソースコード（テキスト）にロックは不要。
もし必要だとしたら、それはソースコードの質が悪いから。
質が悪くて単一責任の原則（SRP）を満たしていないから
複数の人が一つの関数を修正することになる。
- 914 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:27:28.33 ID:s4x1CSLN.net]
- >>892
> 多人数でのプロジェクトをしたことないの？
今 50名規模のプロジェクトに放り込まれてますが何か？
この規模になるとメールでそんな連絡されてもマジで迷惑なだけ。
で、フィルタリングするとか意味不明なこと言ってるし。
そのフィルタリングどうやってやるのさ、書いてみな。
> 場所によっては普通にそういう運用をしてるところもあるな。
そうでないところは、どうしてるんだい。
- 915 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:32:41.33 ID:ul/EWy73.net]
- 多人数のプロジェクトがあるとして、
まずやるべきタスクがある（githubで言えばIssueに相当する）
そのタスクには担当者が書いてある。
だから同じタスクを複数の人がやることはない。
別々のことをやっているのだから、同じ関数をいじることは少ない。
もし別々の作業をやっていて同じ関数をいじることがあればマージすればいいだけである。
（ロックがあると別々の作業をやってるはずなのに、ロックされていて作業ができないという問題が発生する！）
マージできないバイナリだけが問題なので
ソースコード（テキスト）にロックが必要になることはない。
- 916 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:37:08.34 ID:s4x1CSLN.net]
- >>880
> 関係者全員とか迷惑を読み飛ばされたことに対して都合の悪いとこ読み飛ばすなとか批判するなら、まず相性が悪いものをどうやって実装するのかについて説明してからにしろよ
ホントに都合の悪いレスは読み飛ばすんだな...
折角 >>815 が調べたのにな (w
>>883
いいんじゃね？
てか、それに反対してる奴なんていたか？
- 917 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 09:38:47.48 ID:s4x1CSLN.net]
- >>895
頻度って知ってる？
- 918 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 10:02:01.28 ID:BW6c4MFF.net]
- >>900
＞そのフィルタリングどうやってやるのさ、書いてみな。
普通にsubjectに「[ファイルロック]」とでも入れるルールを作っておけば、
そのタイトルがあるメールを適当なフォルダに突っ込むなり、ラベルを
付けるなりすれば無視出来るだろ。それかロック専用のMLを作って
そこに投げるようにするとか。
50人もいるプロジェクトなら毎日のメール数なんて数十～数百通位に
なるなんて当たり前だろうから、そういうルール無しにやれるわけ無いと
思うのだが。
- 919 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 10:51:32.55 ID:2EpMpbWe.net]
- プロジェクトのメールも読まんで仕事する奴いるよ
まともな人間だけだと思うのは間違い
- 920 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 10:53:37.73 ID:gbb+IGlp.net]
- >>903
ロックなら人間が介入する必要の生じる頻度が
相対的に低いって言いたいんだろ？
その低い頻度で十分に面倒だって言ってるんだよ
無駄な編集開始を避けようと思ったら
(つまりロックし�
- 921 名前：謔､と思ったら)
人間同士のコミュニケーションは避けられない
これが必須の要件の場合の現実的な方法の例は >>904 が示してる
ちなみに >>815 で紹介されてるツールについて議論するのは歓迎だよ。
フィットするユースケースや効果的な作業フローの考察を期待する。
ただし「やっぱロックさえあれば」って言うならボケがって思うわ。 [] - [ここ壊れてます]
- 922 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:04:03.85 ID:DOhnBRW9.net]
- >>901
> ソースコード（テキスト）にロックが必要になることはない。
それはマージが神の如く万能な時に限る
どうマージすればいいか担当者間で話し合わなきゃならないことがある
(それ以前に手元のソースがごちゃごちゃになって自分が面倒な事になる)
その手間を考えるとソースがロックされている間はいじらないようにしておこうと判断出来る
ロックがはずれた後変更内容を確認して自分で必要な変更をコミットできる
ただロックが必要なプロジェクトはgitよりもsvnを使うべきだろうね
- 923 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:11:06.10 ID:ul/EWy73.net]
- >>904
一般的な話をすると、必要ないメールは、減らす方がいい。
減らす努力をしないとダメだ。
メールがたくさんあると埋もれて重要なメールを見逃す。
たとえば、自分と関係ないファイルのロック情報のメールは
重要なメールを隠すゴミでしかない。
- 924 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:12:26.73 ID:ul/EWy73.net]
- 基本的な話として、コンフリクトが起きるのは
多人数のプロジェクトであっても少ないという
この前提があることを忘れないように。
つまりはロックをかける必要性は
少ないということである。
- 925 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:16:35.51 ID:ul/EWy73.net]
- >>907
> それはマージが神の如く万能な時に限る
95%うまくいく。
> どうマージすればいいか担当者間で話し合わなきゃならないことがある
ロックはファイル単位なので
「他の人が触っている時にそのファイルをいじれない」という大問題が、
プロジェクトの人数が増えれば増えるほど大きくなる。
つまり担当者間で調整する必要が増えるが
マージの95%はうまくいく、つまり
「他の人が触っている時にそのファイルを触っても問題ない」ので
担当者間での調整が殆ど発生しない。
「他の人が触っている時にそのファイルを触っても問題ない」のに
「他の人が触っている時にそのファイルをいじれない」ことが起きる原因がロック。
- 926 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:19:01.06 ID:zMh1JnO5.net]
- バイナリファイルであろうと、ロックなんてかけずに各々が編集して、編集後の状態を元に誰かが「マージ」すりゃいいんじゃねえのっていうのはだめなの？
- 927 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:19:55.82 ID:vy3cH3fd.net]
- >>863
＞解決方法は様々だが、会社で使うんなら「今からこのファイル編集
＞します」ってメールなりでコミュニケーションとれよと思う。
それで100%解決できるのなら、単にファイル共有でいいじゃんw
というか、だいたいはそれで機能するんだろうけど、万一の事故が起きないように、ソースが
クリーンであることを確実にしたいためにロック型の共有が必要になるんだよ。
なんか本当に仕事でチームで開発したことあるのか、と疑わしくなるような幼稚なレベルの
意見が多くて萎えるな、ここは。
- 928 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:20:45.20 ID:ul/EWy73.net]
- ロックをかけていれば、プログラムが壊れないかというとそうではない。
同時に作業をしている時、
Aさんがaというファイルを
Bさんがbというファイルを修正した時、
ロックをかけていても、ファイルが違うので
当然同時に作業できる。
a単体、b単体なら修正しても問題ないが、
aとbの両方が修正された時、プログラムが壊れることはある。
つまり、
> それはマージが神の如く万能な時に限る
> どうマージすればいいか担当者間で話し合わなきゃならないことがある
というのは、ロックをかけていても発生する問題。
ロックがあれば万能なんだということにはならない。
- 929 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:23:00.27 ID:ul/EWy73.net]
- >>912
> というか、だいたいはそれで機能するんだろうけど、万一の事故が起きないように、ソースが
> クリーンであることを確実にしたいためにロック型の共有が必要になるんだよ。
たしか、ソースコード（テキスト）のロックは百害あって一利なしって
コンセンサスを得られたと思ったんだけど？（笑）
ロックを使ったとしても確実にクリーンになることはない。
ただ他の人の作業を妨げるだけ。
本来同時に出来る作業（それが大部分）ができなくなる。というデメリットが発生するだけ。
- 930 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:24:57.83 ID:s4x1CSLN.net]
- >>904
で、編集し始めるときにメールをいちいち確認するのな (w
そもそもプロジェクト内のメール数百通とか、そんなに暇なんですか？
- 931 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:30:34.96 ID:Jis7Bk7Q.net]
- ロックなんて考えがあると、
誰かがこのファイル修正していたらどうなるんだろう？という
心配しなくていい心配をすることになる。
その発想を逆にして、コンフリクトが起きれば直せばいいという発想をすると、
ロックそのものが不要になる。
同時にファイルを修正しても問題ないことが殆どなので
ロックという発想そのものがだめということ。
svnを使ったロックもメールでロックしますって通知も同じ。
どちらであっても、ロックによって作業を妨げられる。
プロジェクトの参加人数が増えるたびに、他の人によって作業が妨げられる。
- 932 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:31:13.51 ID:s4x1CSLN.net]
- >>906
> ロックなら人間が介入する必要の生じる頻度が相対的に低いって言いたいんだろ？
> その低い頻度で十分に面倒だって言ってるんだよ
大抵のケースで介入の必要ないのに面倒ってどう言うこと？
- 933 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:31:24.03 ID:Vp3GiluJ.net]
- 接続先をgithub.com:22からssh.github.com:443にすることはセキュリティ的に良いことですか？
- 934 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:33:20.12 ID:s4x1CSLN.net]
- >>912
君の主張には同意するけど、なんで俺にアンカーしてんの？
- 935 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:37:39.89 ID:FjWpH3tq.net]
- ロックが面倒、ロックの調整が大変とか、そんな些細なことより
ロックによって開発作業が妨げられるということの方が問題。
開発作業をする時間のほうが長いんだよ。わかってるのかな？
なんかさ、作業しない人が、同時に同じファイルを修正したらどうしよう？
わからん？ コンフリクトとか知らん（←馬鹿）
だからもうロックかけちゃえって思ってるんじゃないか？
ロックかければもう全部解決ーみたいな（全然そんなことない）
開発作業が妨げられることが一番の問題なのに、開発作業をしていないから、
どうでもいいロック（コンフリクトの解決）の話にばかり気にしている。
重要な事だからもう一度言うね。
ロックによって「長時間開発を妨げられる」ことが一番の問題
- 936 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:38:17.54 ID:s4x1CSLN.net]
- >>909
× つまりはロックをかける必要性は少ないということである。
○ つまりはロックが問題になる場合は少ないと言うことである。
君の主張は事故に遭う確率低いから保険に入る必要性は少ないと言ってるアホと変わらない。
- 937 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:39:01.79 ID:FjWpH3tq.net]
- >>921
それは保険の話。全く関係ないものに例えるな。
- 938 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:39:31.56 ID:U3ze+O2N.net]
- ロックしてても、解除された後に次のやつがマージするだけ。
- 939 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:39:41.59 ID:s4x1CSLN.net]
- >>911
それが現実的な時間と労力でできればね。
- 940 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:39:55.27 ID:FjWpH3tq.net]
- だから結局ロックしていても何も問題は解決しない。
- 941 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:42:03.74 ID:s4x1CSLN.net]
- >>922
> それは保険の話。全く関係ないものに例えるな。
ひょっとして、バカなの？
- 942 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:44:55.59 ID:FjWpH3tq.net]
- > 君の主張は事故に遭う確率低いから保険に入る必要性は少ないと
これを一般化すると
○が起きる可能性は低いから、□の対策は必要ない。
ということ。
これが正しいかどうかは、○が起きた時のリカバリ△にどれだけのコストがかかるかどうかである。
リカバリコスト△が少なければ、□対策は必要ない
リカバリコスト△が大切れけば、□対策が必要
事故はリカバリコスト△が大きいので対策は必要だが、
だからさー、コンフリクト起きても直すだけじゃん。
それ普通の開発作業なんだが？コストなんて超少ない。
ロックかけていてもコンフリクトが起きるってことは結局同じ場所を修正する必要があるってわけだろ？
どっちみち同じ作業をやるしかないんだが。
こんぐらいもわからんのかな？馬鹿じゃない？ｗ
- 943 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:45:35.66 ID:s4x1CSLN.net]
- >>925
ソースの話してるのか？
だったら、それでいいんじゃね？
だれも反対してないと思うし。
- 944 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:46:38.96 ID:ANARd0H4.net]
- >>926
ほら、ちゃんと説明してやったぞ？
反論できるかな？ｗ
所で君、明日太陽が登らないかもしれないんだぞ。
対策はちゃんとしているのかな？ｗ
- 945 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:49:21.39 ID:vy3cH3fd.net]
- テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。
大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
大事だから、やっぱGitは向いてないよ。
別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている（その
ために作られた）わけでさ。
- 946 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:50:50.05 ID:s4x1CSLN.net]
- >>929
> だからさー、コンフリクト起きても直すだけじゃん。
頑張って、としか言いようがない (w
- 947 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:53:24.86 ID:T5pqGmWJ.net]
- ソフトウェア開発において
バイナリよりもソースコードのほうが多いのです。
ならば、ソースコードをうまく管理できる方がいい。
gitがいいのはロックだけが理由ではない。
ローカルでソースコード管理できて履歴を直せることこそが重要
subversionでありがちな。
* ○機能完成
* ○のバグ修正
* ○のバグ修正2
* △機能完成
* ○機能バグってた
* △もバグってた
* ○の仕様が変わった
みたいな役に立たない履歴をなくせる
- 948 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:54:45.70 ID:T5pqGmWJ.net]
- >>931
あー、ほら、やっぱりそういうことだろ！
ロック必要とかいってるのは、コンフリクト怖い病なんだ。
コンフリクト怖い。直し方分からない。
起きたらどうしよう。頭爆発。
結局、こういう技術力不足が原因なんだろ！
- 949 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 11:55:31.68 ID:T5pqGmWJ.net]
- 「コンフリクト怖い病」という用語を普及させようぜ？ｗ
- 950 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:04:09.11 ID:MzN5Zxxd.net]
- 今から出かけるけど、返って来たら
コンフリクト怖い病患者の特徴をまとめてみようかな
次スレになりそうだから、まあテンプレにしよう。
- 951 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:07:34.60 ID:s4x1CSLN.net]
- >>933
だから、君はソースの話してるのか、バイナリの話してるのか、明確にしなよ。
指摘しづらいわ。
- 952 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:08:38.34 ID:MzN5Zxxd.net]
- バイナリのファイルは忘れろよ。
ソースコード管理ツールだろ。
例外であるバイナリの場合だけ
バイナリと明確に書くように。
- 953 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:08:41.20 ID:vy3cH3fd.net]
- 仕事と遊びとは違う
- 954 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:09:54.70 ID:gbb+IGlp.net]
- >>933
いや、お前および何人かは >>931 の主張の前提を共有できてない。
* マージ・コンフリクトの解決が難しい種類のファイルは現実的に存在する
* そういうファイルの編集を誤って開始してしまうのを防ぐためにロックが欲しい
と >>931 は言ってる。
>>931 はソースコードに関してはロック不要とも(暗に)言ってる。
なぜならお前がいうようにマージすればいいだけだからな。
これに対して「コンフリクトしてもマージすればいいだろ」と言っても
>>931 としても「頑張れ」としか言えんだろう。
- 955 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:10:15.79 ID:vy3cH3fd.net]
- ID: s4x1CSLN はGit脳かなんか知らんが発狂しすぎだろ。
適材適所、という言葉さえ知らないのか？
トンカチを持った奴はなんでも釘に見える、というけど、Gitを持つと、Git以外の管理方法が
目に入らなくなるらしい。
- 956 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:11:55.24 ID:MzN5Zxxd.net]
- > * マージ・コンフリクトの解決が難しい種類のファイルは現実的に存在する
だがそれはロックしても解決できない
- 957 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:13:01.95 ID:BW6c4MFF.net]
- >>930
＞大事だから、やっぱGitは向いてないよ。
gitに向いていないものをgitでやる必要は無いわけで。バージョン管理ツール自体は
ロックが出来るsvnなんかは無料で使えるんだからライセンス料の心配をする必要は無い。
バイナリファイル等のコンフリクトした際のマージ作業が面倒なファイルだけ
そういうツールで管理すればいいだけ。
gitというか分散管理ツールははオフラインで作業が捗るように作られている
わけだから、オンラインじゃなきゃ機能しないロック機構とは相性が悪い。
オフラインの人への通知をどうするのか考えたら別のツール使えよって
普通はなるよな。
- 958 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:15:34.46 ID:jnsRXNx1.net]
- まず、>>895の
＞仮に、Gitに理想的なロック
＞(例えばあるファイルをロックしたら、
＞clone済みの全てのローカルリポジトリにおいてアトミックにロックされるようなロック)
＞が実装されたとしても、
が分散型の仕組み上無理なことを誰も突っ込まないんだろうか…
だってそれできたら、もう分散型じゃないようなw
- 959 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:16:30.70 ID:MzN5Zxxd.net]
- ロックをすることでマージが簡単になるんじゃないことに注意な。
二人が同じファイルを修正する必要があったとして
ロックしたからといって、二人が同じファイルを修正できるようになるわけじゃない。
マージが難しい物は、どちらかを取るしかないわけだが、
どちらかを選択する行為はロックをかけなくできる。
マージする時にコンフリクトが起きたら、今あるやつを使うか
自分のやつを使うかを選択すればいいだけ。
ではロックで何が解決されるのか？
その答えが些細な事だって話。
- 960 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:17:24.13 ID:U3ze+O2N.net]
- バイナリをロックしても、解除された後に結局マージするんだろ。
テキストは自動マージがあるだけだが、マージされたからと言ってその結果が正しいとは言えないのだから、テストかレビューが必要。バイナリの手動マージと同じ。
- 961 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:21:57.16 ID:gbb+IGlp.net]
- >>917
> 大抵のケースで介入の必要ないのに面倒ってどう言うこと？
無駄な編集開始を避けようと思ったら
(つまりロックしようと思ったら)
人間同士のコミュニケーションは避けられない
ここまではいいよな？ Gitのような分散VCSに、
1. 同時編集を許容しない(ロック)機能を実装するかわりに、
それに付随するコミュニケーションが頻度の差はあれ必須になる
2. 同時編集を許容する代わりに、コミュニケーションは不要。
もし許容できないシチュエーションがあるなら
別のレイヤでコミュニケーションとるほうがいい
1は面倒なので2のほうがマシ、と言ってる。
- 962 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:25:31.35 ID:MzN5Zxxd.net]
- > 無駄な編集開始を避けようと思ったら
> (つまりロックしようと思ったら)
> 人間同士のコミュニケーションは避けられない
無駄な編集開始になぜロックが必要になるのか？
別な方法で、無駄な編集開始を避けられるのなら
ロックは必要ない。
君、作業分担にツールは何も使ってないの？
たとえばgithubのIssueとかさ
チケット管理システムとかさ
そういうのだよ。
普通一つのシステムを作る時に、それをいくつかのサブ機能に分けて
担当者を決めると思うけどさ、どうやってるの？
- 963 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:30:48.20 ID:MzN5Zxxd.net]
- 根本的な原因がわかってきたんじゃねーの？
バージョン管理以前の問題だって。
無駄な編集開始を避けるのに使うのはチケット管理システム。
作業を開始する前、作業中。
そのどちらであっても、ソースコード以外の
コミュニケーションツールが必要。
たとえば、仕様の確認とかバグ詳細の確認とかさ、
（まさかいちいちメールでやってるわけないよね？ｗ）
コミュニケーションツール出やるべきことを
ソースコード管理ツールでやろうとするのが根本的な間違い。
無駄な編集開始を避ける話しは、ここまでの話だよ。
- 964 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:32:07.50 ID:gbb+IGlp.net]
- >>947
> 無駄な編集開始になぜロックが必要になるのか？
ロックが必要だと言ってるのは >>936 だよ
>
> 別な方法で、無駄な編集開始を避けられるのなら
> ロックは必要ない。
>
> 君、作業分担にツールは何も使ってないの？
> たとえばgithubのIssueとかさ
> チケット管理システムとかさ
> そういうのだよ。
そうそう、無駄な編集開始を避けたいなら
そういうツールなりでコミュニケーションとれよって話。
「Gitにロックがあれば」なんて話にもっていくのはおかしい、
って俺は言っている。
- 965 名前：デフォルトの名無しさん [2014/04/12(土) 12:44:54.37 ID:BW6c4MFF.net]
- >>948
＞（まさかいちいちメールでやってるわけないよね？ｗ）
お前がメールに親を殺されたか、恋人をNTRされたか分からんがメールへの
恨みだけは他の誰にも負けないことは分かったから黙ってろ。
- 966 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:47:55.69 ID:DvVB/wNe.net]
- >>950
次スレ建てろ
すぐやれ
- 967 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:48:02.86 ID:s4x1CSLN.net]
- とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
あと、分散では原理的に実現できないと言うのもいいよね。
これに反対する奴はいないと思うんだが、いいかな？
>>948 とかが不用意にソースコードとか書くから話がおかしくなってるので、確認させてくれ。
- 968 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:51:17.45 ID:gbb+IGlp.net]
- >>952
おｋ
- 969 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:51:58.82 ID:MzN5Zxxd.net]
- > とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
ちょっと違うな。バイナリがマージできなかったとして、
自分の修正を取るか、相手の修正を取るかの二つしか選択できない。
それはgitであってもできること。
ロックで防げるのは、無駄な編集開始を避ける事ではあるが、
それはチケット管理ツールを使うべき話。
バイナリであったとしても、どちらかを取ればいいので
ロックを使う理由はない。
- 970 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:07:00.16 ID:BW6c4MFF.net]
- >>951
無理だった。
ＥＲＲＯＲ：Lvが足りなくてスレッド立て(ら)れません。
Git 9
名前： デフォルトの名無しさん
E-mail：
内容：
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 8
toro.2ch.net/test/read.cgi/tech/1389701817/
- 971 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:22:55.97 ID:B/06XIsq.net]
- >>902
>>880=>>815なんだが。
そのあとろくにgit-annexについて考察もしないのに「都合の悪いレス�
- 972 名前：ﾇみ飛ばすな」とか批判する資格ないだろ。
大体git-annexにだって問題点は沢山あるわけで。つーかgit-annexで解決してるならもういいだろ。
単にgitにロックがないということで無駄な論争を起こそうとしてるとしかおもえない。 [] - [ここ壊れてます]
- 973 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:23:23.64 ID:s4x1CSLN.net]
- >>955
立てといた
Git 9
toro.2ch.net/test/read.cgi/tech/1397276540/
- 974 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:31:12.71 ID:s4x1CSLN.net]
- >>954
> ロックで防げるのは、無駄な編集開始を避ける事ではあるが、
ここまでは同意。
> それはチケット管理ツールを使うべき話。
ロックの対象はファイルなので、SCM の方がより適切と思う。
あるファイルを編集する時にロックされてないかを確認するのにどのチケット見ればわかるの？
該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
- 975 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:36:24.72 ID:s4x1CSLN.net]
- >>956
本人なのか。
マジで何を言いたいのかよくわからんのだが。
- 976 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:41:55.23 ID:kSIcd9mI.net]
- 見てて結構面白いんだけどレッテル貼りだけは負け逃げみたいだからアカンよ。
- 977 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:49:00.36 ID:EipzA34R.net]
- >>958
ロックしなくて問題ない。
作業がかぶっていなければ、修正内容がかぶることはない。
かぶったらコンフリクトを解消すればいいだけ。コンフリクトを解消するのは、小さな作業。
（コンフリクトを解消した、つまり修正後のテスト等はロックがあっても結局やるべきことだから違いはない）
たとえロックしていたとしてもコンフリクトは発生する。
バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ
それはロックしなくてもできること。
> 該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。
複数のチケットで、たとえば画像を赤くしろ、青くしろなんてのがあったら
作業前にどちらのチケットをやるかを決めるべきこと。
ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。
だからこれはチケットで解決するべき問題。
複数のチケットから参照されてるなんて、具体的でないケースを言うからわからなくなる。
複数のチケットで、同じものに対する修正があるとき、それをどうするかはチケットで解決するべき問題だってわかるはずだ。
- 978 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:54:07.45 ID:EipzA34R.net]
- 考えれば考えるほど、ロックの意味がなくなってきたな。
AとBを同時に修正して、AをマージしてからBをマージするか
Aを修正してマージしてから、Bを修正してマージするかの違いしかないじゃないか。
この場合コンフリクトはどちらでも起こりうるし、
単に修正作業が直列化したに過ぎない。
（マージだけを見ればどちらも直列化している）
- 979 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:02:32.23 ID:s4x1CSLN.net]
- >>961
> バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ
はあ？
どっちかの編集の労力を捨てろって言ってるの？
> ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。
だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？
実際の運用考えてないのか？
> ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。
上半分と下半分の両方が修正されるというケースは思い付かないのか。
- 980 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:05:42.24 ID:EipzA34R.net]
- > どっちかの編集の労力を捨てろって言ってるの？
その為にチケット管理しろって言ってるの。
どのファイルを修正するかなんて
作業前にわかるだろ。
- 981 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:06:23.64 ID:s4x1CSLN.net]
- >>962
> 単に修正作業が直列化したに過ぎない。
当たり前だろ、直列化するための仕組みなんだから (w
普通にやるとそうならない場合があるから困ってるわけで...
- 982 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:09:32.79 ID:s4x1CSLN.net]
- >>964
お前が一人で修正するならな。
あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？ についても、書いてね。
- 983 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:10:19.82 ID:kSIcd9mI.net]
- まあ平行作業しないで済むならそれに越したことはないよね
- 984 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:10:25.33 ID:EipzA34R.net]
- > だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？
要らない。
チケットベースで作業管理していて、作業内容が違うから、
内容はかぶらないのですんなりマージできる。
まれにマージできない場合だけコンフリクト解消するだけでOK
それよりも問題なのは、マージできない場合＝ロックする必要がある時に
本当にロックしてしまうと、並列で作業できるはずのことが
並列で作業できなくなってしまう。
それは開発の遅れを引き起こす。
ロックしないから並列で開発できる VS ロックするから並列で開発できない
こういいう話。
> 上半分と下半分の両方が修正されるというケースは思い付かないのか。
上半分を青くして、下半分を赤くする修正の二つが終わった時、
本当に、上半分を青くしてといった人の意図したとおりなっているかはわからない
やっぱり修正を始める前に、チケットで解決しておくべき問題だったな。
- 985 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:11:50.26 ID:EipzA34R.net]
- >>966
> あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？ についても、書いてね。
書かなくていいというか、書いたらダメ。
書いたら並列で開発できなくなる。
"一人で開発しているから" 並列で開発することは出来ないからどうでもいいが、
"複数人で開発しているなら" 並列で開発できなくしてはいけない。
並列で開発できなくなったら待ちが発生する。
- 986 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:20:20.28 ID:gbb+IGlp.net]
- スレ立て乙
しばらく離れるのでまた次スレで。
- 987 名前：デフォルトの名無しさん [2014/04/12(土) 14:24:48.81 ID:UapBJj1i.net]
- Git 9
toro.2ch.net/test/read.cgi/tech/1397276540/
- 988 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:05:13.12 ID:s4x1CSLN.net]
- >>968-969
マージできるファイルの話ならいちいちレスしなくてもいいよ。
誰もマージできるファイルにロックが必要とは言ってないから。
- 989 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:23:49.87 ID:qyNsAYgL.net]
- とりあえずだ。
gitにロックが必要か？という問題については、答え、必要ない。
バージョン管理にロックが必要か？については、答え、必要なこともある。
ってことでいいな。
つまり、ロック機能がほしいファイルを分散型のバージョン管理に突っ込むなということだ。
gitにロック機能必要といってるやつは、まず分散型の仕組みから復習しろ
- 990 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:39:46.69 ID:s4x1CSLN.net]
- >>973
> gitにロックが必要か？という問題については、答え、必要ない。
そうなんだろう、お前の中ではな。
- 991 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:45:39.17 ID:zMh1JnO5.net]
- 必要かどうかってより、gitのような分散型バージョン管理でロック実装はひどいことになるんじゃないの
- 992 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:54:45.04 ID:8wXT0UMc.net]
- 何でもできて重くもないツールにできるんだったら、
分散型でも集中型でも管理できてロック使用要否も選択できてissue管理もできて
ってすればいいよ
自分もExcelやWordを後からマージ作業はやりたくないからロックありで管理したいものがあるのはわかるけど
それをソースと同じくgitで管理したい、とは思わない
別のツールでいいじゃん
- 993 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:16:06.70 ID:iNxrw8O2.net]
- ume
- 994 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:19:24.13 ID:s4x1CSLN.net]
- >>975
分散だと原理的に無理だと思う
ただ、分散諦めても普段使い慣れた git を使うという選択肢があってもいいと思う
企業内だとそういう使い方は多いと思うしね
>>976
> それをソースと同じくgitで管理したい、とは思わない
仕様書を Word/Excel で管理していたり、リソースとかはソースと一緒に管理したい人もいるんよ
- 995 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:52:24.54 ID:U3ze+O2N.net]
- まだ一人でがんばってんのか。無駄に。
- 996 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:59:26.37 ID:zuiRAUii.net]
- officeドキュメントの管理は、本来ならSharePointを使った方が良い
ただ、ソースコードと一緒にドキュメントも管理したい場合もあるのは確か
svnでもgitでもhgでもドキュメントの管理にはあんまり向いてるとは思わないが、あえて言えばsvnが一番使いやすいと思う
ロックもそうだし、Windowsクライアントが優れてたり、日本語ファイル名とか、部分チェックアウトとか
- 997 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:04:58.66 ID:qyNsAYgL.net]
- >>978
そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。
リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、仕様書だけ、必要な人の方がおおい。
まぁ、まだ個人的にしかやったこと無いから、pj単位で運用したときはどうなるかわからんけど。。。
試してみるなら、リビジョンの不整合にはよう注意な。
ブランチ運用をちゃんとやらないと、svn側が大変なことになる。
- 998 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:11:43.01 ID:1eEiGLxS.net]
- なんでもエクセル使って書くバカと同じで
なんでもVCSで管理しようとするバカがいるのだろうか？
VCSはソースコードを管理するために作られたツールだ
ソースコード以外を入れようと考えるな。
そもそもバイナリを入れるという考えが間違いであることに気づけ。
- 999 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:22:34.14 ID:1G+VXwG6.net]
- >>982
間違ってはないと思うが。
- 1000 名前：デフォルトの名無しさん [2014/04/12(土) 17:28:45.84 ID:UuzLKOtw.net]
- レポジトリa,bがあり、bはaのサブモジュールになっています。
aのブランチを切り替えると、bの一部ファイルが消えるのですが、原因はわかりますか？
bでコミットをしたら、aでbについての「subproject commit ハッシュ」という変更もコミットする必要があるのでしょうか？
- 1001 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:34:28.48 ID:1eEiGLxS.net]
- >>984
サブモジュールについての理解が甘いようだね。
サブモジュールはライブラリなど自分以外の
誰かが作っているリポジトリだと考えよう。
誰かが作っているということは、勝手にバージョンが上がるということだ。
そしてだ、君のそのコード。
それはサブモジュールのライブラリの
どのバージョンのコードで正しく動くのだ？
他人が作っているライブラリのバージョンが変わった時、
勝手に新しいバージョンを使ったら困るだろう？
- 1002 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:36:55.18 ID:NV9wCwyl.net]
- >>981
> そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。
ごめん、それなんの意味があるのかさっぱりわからん。
管理だけなら git svn の方がいいと思うけど。
> リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、
なんで？
コミットは別かもしれないけど、一緒に管理してもいいと思うけど。
>>982
はいはい (w
- 1003 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:38:50.24 ID:1eEiGLxS.net]
- 仕様書というのは膨大である。
仕様書はバージョンが有り
更新されると、一部だけが変わる。
その更新はどうやって知るか？
バイナリでは比較が困難なので
テキストで書くのが良い。
仕様書はテキストで書くべきというのが正解。
- 1004 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:45:50.74 ID:kSIcd9mI.net]
- テキストだけより図とかも使った仕様書の方がわかりやすくて好きだなあ
- 1005 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 18:09:05.83 ID:1rmX5tVh.net]
- >>987
> 仕様書はテキストで書くべきというのが正解。
自分だけで閉じる奴はそうしてる (ascildoc + graphviz)
- 1006 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 18:18:17.28 ID:zMh1JnO5.net]
- リポジトリにバイナリ突っ込んでるけどなあ、複数人が同時に編集するようなもんほぼないけど
- 1007 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 19:07:55.75 ID:U3ze+O2N.net]
- バイナリでも自分と相手のデータをアプリで開いてマージするだけだな。ロックがあろうとなかろうと。
作業が被るかどうかはプロジェクトマネジメントの領域で、同じ作業でも違うファイル名で新規に作ったりしたらロックしようがない。
- 1008 名前：984 mailto:sage [2014/04/12(土) 21:32:17.16 ID:UuzLKOtw.net]
- >>985
そうだったんですね、勘違いしてました。
a,bともに自分のレポジトリで、
a,bわけて管理したいときはどうすればいいのでしょうか。
aのディレクトリにbが存在しています
- 1009 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 21:36:24.94 ID:1eEiGLxS.net]
- >>992
別人になったつもりで作業すればいいだけ。
- 1010 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 21:53:11.54 ID:gbb+IGlp.net]
- まだ埋まってなかったのか。
ロック必要だよ派はまだ居る？
(宗旨替えした結果いなくなったのなら、それはそれで良いけど)
- 1011 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:21:13.23 ID:gbb+IGlp.net]
- 早ければ来週あたり 2.0-rc0 がでるっぽい。
これで新機能追加はほぼ終わり。
つっても 2.0 正式リリースまでまだ1ヶ月以上あるだろうけど。
- 1012 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:27:45.81 ID:gbb+IGlp.net]
- つーか今朝の6時か7時ごろ 1.9.2 がリリースされてるな。
- 1013 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:28:49.82 ID:gbb+IGlp.net]
- ちがった。2日くらい前か。
- 1014 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:47:13.21 ID:qyNsAYgL.net]
- >>986
仕様書とソースじゃ工程が違うからコミットは当然別々になる。もし一緒にコミットしているならレビューのやり方がおかしい。
んで、バージョン管理されるファイルはコミットされたタイミングで全体の整合性が取れているべきなので、ソースと同じところに仕様書の類があるとどっちを信じていいかわからなくなるよ。
というわけで、僕は参照リポジトリの位置付けで、チェックアウトしたしたsvnとかのモジュールを取り込んでる。
ソースをコミットしたタイミングの仕様書も記録できるから。。。
変更するときは、大本だけどねー
- 1015 名前：デフォルトの名無しさん mailto:sage [2014/04/13(日) 01:01:16.17 ID:pwayVEBU.net]
- 梅
- 1016 名前：デフォルトの名無しさん [2014/04/13(日) 01:04:55.07 ID:pwayVEBU.net]
- 1000なら日本国の少子化問題が解決する
- 1017 名前：１００１ [Over 1000 Thread.net]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
- 1018 名前：過去ログ ★ [[過去ログ]]
- ■ このスレッドは過去ログ倉庫に格納されています
|
 |
