[表示 : 全て 最新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/

830 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:26:21.34 ID:NS7eKWAh.net]
ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。

831 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:36:06.16 ID:I4ZYtafb.net]
>>817
ウォーターフォール型のプロジェクトで、
ソースファイルの同じ位置を複数の人で編集しまくることとかあるの?
コンフリクトが簡単に解決できないようなファイルの編集が複数の人の間で頻繁に発生するとか、
有り得ないと思うんだけど

832 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:40:22.58 ID:qnngGCyM.net]
>>817
頻繁にコンフリクトが起きるようなプロジェクトならsvnだろうが他のだろう関係なく
起きるよ。 コンフリクト以前にsvnのマージ作業なんて、作った奴死ねって思う
くらいひどいし。そういうマージやらコンフリクトの解消のコストがgitは他のに
比べて圧倒的に低いからgitは使う価値があると思う。 svn使ってるならローカルで
git svn使う方がはるかに楽だし。

833 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:45:26.37 ID:GmndHch1.net]
自分だけしか使ってないリポジトリで
今までコミットしてきた時の名前を変更したいんですが
どうやるのか教えてください
適当に名前をつけてたのですが、今後他の人もコミッターに加わるので名前を変えたいんです

834 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:45:46.71 ID:08KdAoTS.net]
何でコンフリクトが起きる事を問題視してる人がいるのかよくわからん。
gitというツールを運用する環境をどう構築するかを考えた方がいいんじゃないの
そもそも、svnで問題なかったのならsvnでいいでしょ
svnもgitもツールなんだし、適材適所

835 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:46:16.32 ID:I4ZYtafb.net]
>>819
簡単に解決できないようなコンフリクトって例えばどんな場合におこるの?
けっこう複雑な関数を同じ人がいじりまくるとかするの?

836 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:46:17.65 ID:GmndHch1.net]
.gitconfigで名前を変えとけば過去の名前も変わると思ったんですがダメでした

837 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 00:57:11.44 ID:Aw1WhgbR.net]
正直同じ関数に対する修正みたいなのは被らないようにチケット割り振りしたいわな
オープンソースみたいにいつ誰がどんな修正してるかわからんようなのはともかく
チームでやってる時は少なくともわかってる範囲内では影響範囲かぶらないようにしてる

838 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 01:01:23.41 ID:I4ZYtafb.net]
>>823
git filter-branch



839 名前:デフォルトの名無しさん [2014/04/10(木) 01:34:13.89 ID:1wauUDTZ.net]
オープンソースならメールなり掲示板なりircなりでやりとりしてるのが普通だよ

840 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 01:40:17.05 ID:u/ao0IlG.net]
>>821
コンフリクトというのはいわばバグですよ。
バグは起きてはいけない
コンフリクトも起きてはいけない。





subversionを使っている人はそう言ってました。
馬鹿ですよねw

841 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 01:46:32.26 ID:67sTFnF/.net]
>>826
開発が活発なOSSについてはそうだろうけど
開発者が実質1人だとかメンテナ不在ってのが
OSSの「普通」(圧倒的多数)だと思うけどね

842 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 01:58:20.93 ID:67sTFnF/.net]
作業が無駄になろうがマージがめんどくさかろうが
コンフリクトが顕在化するのはまだ幸運な方だよね

構文上はコンフリクトしてなくても機能上コンフリクトしていて
回帰テストに漏れがあると悲劇の始まり

gitには悲劇を早く終わらせるのに役立つ機能はあっても
現状のバージョン管理システムでは悲劇の発生は阻止できそうにない

843 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 02:01:03.17 ID:u/ao0IlG.net]
>>829
その為にテストを自動化するんでしょ?

それに二人の人が作業するのであれば
ロックをかけていたとしても
機能上コンフリクトは起こるわけだし。

844 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 02:01:31.21 ID:o2rx8JxT.net]
>>729の燃料投下から100レス目か

845 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 02:08:15.66 ID:67sTFnF/.net]
>>830
gitだろうとロック機能のあるツールだろうと
顕在化するコンフリクトなんて可愛いもんで
熱く議論するほどのことじゃないよねって言いたかった

846 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 02:15:53.96 ID:uhNdSeYA.net]
ロックでなんとかなると思ってるのは、コード書いてない証拠。
書き始めたら結局マージするはめになる。

847 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 02:40:10.12 ID:UBKps7J1.net]
ま、適切に機能分割されてて、関数やファイルで構造化されていれば、酷いコンフリクトなんかそうそう起きないわな

848 名前:デフォルトの名無しさん [2014/04/10(木) 04:06:22.99 ID:1wauUDTZ.net]
実質1人だとかメンテナ不在ならそもそも
いつ誰がどんな修正してるかわからん
みたいな♪心肺ないからね



849 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 07:51:39.22 ID:1X5BHIzm.net]
>>810
つまんないなら、スルーしとけよ (w

>>814
> 背景を共有せずに

バイナリ (=マージできない) ファイルを管理したいと言うことでしょ。
アイコン、ちょっとしたイメージファイル、ワードやエクセルなんかの文書をソースと一緒に管理したい人は多いと思うよ。
ここら辺の認識も共有されてないの?

>>815
git-annex ざっとしか読めてないけど、ファイル本体を Key-Value Store に突っ込んでリンクを git で管理するって感じ?
まあ、共通的なストレージあればなんとかなるわな。

> ムービーくらいのでかいものを管理しようと思ったらいきなりリポジトリのサイズがどんどんでかくなってまともに使えなくなる

みんなが動画を管理する訳じゃないでしょ。
なんか無理矢理できない例を探してない?

850 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 08:01:21.07 ID:1X5BHIzm.net]
>>824
同じファイルならまだしも、同じ関数を複数の人が同時に触るとかなんかの間違いでもない限り 100% あり得ないよね。
コンフリクト心配してる人はどんな管理してるんだろう?

>>829
ひょっとして、バグ見つけたら担当者が勝手にちゃちゃっと修正してるの?
他に影響するような修正なら、仕様書の修正とかレビューするだろ、普通。

851 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 12:25:06.48 ID:NS7eKWAh.net]
上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

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

Gitだと複数の人が同じところ勝手に直しだしたりしても検出できないでしょ。無駄な作業が発生するわけ。
どっちが悪いとかじゃなくて、Gitが向いてないタイプの管理が企業内にはあるってこと。
おわかりかな?

852 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 12:34:43.21 ID:IB1wq0Eb.net]
ハサミでネジが締められないからハサミはクソと喚いてるわけだな

853 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 13:36:34.66 ID:tZxH7aP+.net]
立派な大企業様なら、クソみたいなOSSを使わないで、自分達で作るなり買うなりすれば
いいのにねー。2chでアレがデキない、コレがデキナイと喚いているだけなら、無職に
も劣る。

854 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 13:43:39.90 ID:I4ZYtafb.net]
どこを直すかの管理をバージョン管理ツールに頼るとかありえないんだけど

855 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 13:59:14.88 ID:WPYZbZRA.net]
ユーザーとタスク管理までさせられるVCSは大変ですね

856 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 14:59:48.19 ID:vqBRkjrb.net]
開発効率をUPする Git逆引き入門 [単行本(ソフトカバー)]
www.amazon.co.jp/dp/4863541465/

>サイバーエージェントで開発に携わっている著者が、Gitの使い方を速習できるように逆引きという
>形でわかりやすく解説しています。Gitコマンドとあわせて、GUIツールのSourceTreeでの操作方法も
>掲載しているので、コマンド入力が苦手という方も安心です。もちろん、Git独特の基本用語や概念に
>ついてもきちんと解説していますので、初心者でも理解できる内容になっています。これからGitを
>使いたいと考えている方におすすめの1冊です。

昨日三省堂で見つけてパラパラめくってみたが、なかなか良さそうな本だった。
と書くとまたステマだ、俺はWEBで充分だ、とか気が狂ったみたいな顔をして口から泡を吹きながら
怒りだす奴でてくるんだろうけど。

こっちは親切で情報を提供しているのに、なんで本の紹介されると発狂する奴っているんだろうな?
まあ、身の回りみていても、本代ケチるようなのにろくな技術者いないけど。

857 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 16:12:50.21 ID:Aw1WhgbR.net]
難癖つけるやつの方が声がでかいだけの話しだから気にすんな

858 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 17:41:18.36 ID:8TUEkxNY.net]
すばらしい技術書を親切心で紹介します!異論を唱えるのはキチガイだけ!
この本が手に入るのにたかが数千円のはした金も出さないのはまともな技術者じゃありません!
いますぐ買ってまともな技術者になりましょう!

あほか



859 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 17:43:40.06 ID:N3vuTs56.net]
フォークして修正を送る時ってブランチの名前はなんてつけていいのか教えてください
例えばさtestってブランチで送った場合、他の人もtestで送ってたらダブっちゃいますよね
ダブった場合もコンフリクトしちゃうんですか?

860 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 17:55:01.85 ID:B7i8mwfP.net]
>>843
まあこのスレじゃないけどステマっぽいのはあったし、実際あなたの書き込みがステマかどうか判断しようがないからね。
そんな風に言われるのが嫌ならこの手の掲示板は避けた方がいいと思うよ。

そもそも、人から批判されるのは嫌だけど、人に嫌みは言うぞって言う態度もどうかと思うし。

> まあ、身の回りみていても、本代ケチるようなのにろくな技術者いないけど。

861 名前:デフォルトの名無しさん mailto:sage [2014/04/10(木) 18:02:26.77 ID:3faYMJHc.net]
>>843
知らなかったので本の紹介には感謝する
ただ、余分な書き込みは必要なかったかな
何にでも文句を言う人はどこにでもいるから
それをスルーできない人は書き込まない方が精神衛生上いいのかも

ともあれ今から本屋行って立ち読みしてくるよ

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
そもそもプロジェクト内のメール数百通とか、そんなに暇なんですか?






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

前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