[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 05/07 21:30 / Filesize : 266 KB / Number-of Response : 1019
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 8



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
小馬鹿にするっていうか、「〜には向かないのでは?」って書いてる奴が馬鹿過ぎるんだものw

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]
> 君の主張は事故に遭う確率低いから保険に入る必要性は少ないと

これを一般化すると
○が起きる可能性は低いから、□の対策は必要ない。
ということ。

これが正しいかどうかは、○が起きた時のリカバリ△にどれだけのコストがかかるかどうかである。

リカバリコスト△が少なければ、□対策は必要ない
リカバリコスト△が大切れけば、□対策が必要

事故はリカバリコスト△が大きいので対策は必要だが、



だからさー、コンフリクト起きても直すだけじゃん。
それ普通の開発作業なんだが?コストなんて超少ない。
ロックかけていてもコンフリクトが起きるってことは結局同じ場所を修正する必要があるってわけだろ?
どっちみち同じ作業をやるしかないんだが。
こんぐらいもわからんのかな?馬鹿じゃない?w

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
ほら、ちゃんと説明してやったぞ?
反論できるかな?w

所で君、明日太陽が登らないかもしれないんだぞ。
対策はちゃんとしているのかな?w

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]
「コンフリクト怖い病」という用語を普及させようぜ?w

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とかさ
チケット管理システムとかさ
そういうのだよ。

普通一つのシステムを作る時に、それをいくつかのサブ機能に分けて
担当者を決めると思うけどさ、どうやってるの?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<266KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef