２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

Git 8

1 ：デフォルトの名無しさん：2014/01/14(火) 21:16:57.41 .net: ソースコード管理を行う分散型バージョン管理システム、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 7
http://toro.2ch.net/test/read.cgi/tech/1381929347/
2 ：デフォルトの名無しさん：2014/01/14(火) 21:20:22.69 .net: >>1乙
3 ：デフォルトの名無しさん：2014/01/14(火) 21:20:45.94 .net: 関連スレ
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
4 ：デフォルトの名無しさん：2014/01/14(火) 21:27:03.07 .net: ◆前スレ
Git 6
http://toro.2ch.net/test/read.cgi/tech/1369103196/
Git 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/
5 ：デフォルトの名無しさん：2014/01/14(火) 21:30:38.30 .net: ◆関連書籍
Gitによるバージョン管理
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
6 ：デフォルトの名無しさん：2014/01/14(火) 22:24:08.76 .net: >>1
乙
7 ：デフォルトの名無しさん：2014/01/14(火) 22:31:50.25 .net: >>1乙だけど
http://progit.org/book/ja/
にアクセスできないなくない？
8 ：1：2014/01/14(火) 23:59:15.95 .net: >>7
すまねえ、スマホからたてたので、リンクの確認サボっちまった。

http://progit-ja.github.io/ でいいのかな？
9 ：デフォルトの名無しさん：2014/01/15(水) 00:12:46.62 .net: >>8
>>1が指してたページはたぶんこれでアクセスできるとこだな
http://git-scm.com/book/ja/
git-scm.comの中に統合されたってことかね？

というか http://progit-ja.github.io/ このページもいいね！
こっちは次スレでは >>4 の関連書籍に含めたらいいのでは
10 ：1：2014/01/15(水) 00:32:02.79 .net: 了解、よろしくね ⇒ >>950
11 ：950：2014/01/15(水) 00:36:01.11 .net: よっしゃ
12 ：デフォルトの名無しさん：2014/01/15(水) 00:45:03.32 .net: GitHubの質問する奴も多いしテンプレに誘導先としてリンク入れておいたほうがいかったんじゃないの

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
13 ：デフォルトの名無しさん：2014/01/15(水) 02:16:16.42 .net: 刈り込むとか何するのか全然わからねえよな
14 ：デフォルトの名無しさん：2014/01/15(水) 14:45:56.11 .net: |....,,__
|＿::;; ~"'ヽ
|　//^''ヽ,,)
|　　i⌒"
| ∀｀）　＜誰もいないきのこるならいまのうち
|⊂
| ノ
　　　　　 _,,,......,,__
　　／_~　,,...:::＿::;; ~"'ヽ
　(,, '"ヾヽ　 i|i　//^''ヽ,,)
　　^ :'⌒i　　　　i⌒"
　　　　　 |（　´∀｀）　＜きのこのこーのこげんきのこ ♪
　　　　　 |（ﾉ　　 |つ
　　　　　 | 　　　 |
　　　　　⊂ ＿ノ
　　　　　　　""U
　　　　　 _,,,......,,__
　　／_~　,,...:::＿::;; ~"'ヽ
　(,, '"ヾヽ　 i|i　//^''ヽ,,)
　　^ :'⌒i　　　　i⌒"
　　　　（´∀｀　）|　＜エリンギまいたけブナシメジ ♪
　　　　⊂|　　（ﾉ |
　　　　　 | 　　　 |
　　　　　ヽ＿ ⊃
　　　　　　.U""
|
| ミ
| ミ　ｻｯ!
| ミ
|
15 ：デフォルトの名無しさん：2014/01/15(水) 18:01:45.55 .net: Git 1.8.5.3 がリリースされたね
https://code.google.com/p/git-core/downloads/list
16 ：デフォルトの名無しさん：2014/01/20(月) 22:34:37.54 .net: Gitをはじめて勉強するときってみんな何で覚えたん？
>>1にあるようなサイトか書籍？
17 ：デフォルトの名無しさん：2014/01/21(火) 00:55:54.96 .net: 俺はこの２つのサイトで覚えた

http://git-scm.com/book/ja/
http://www.backlog.jp/git-guide/
18 ：デフォルトの名無しさん：2014/01/21(火) 01:42:33.50 .net: >>16
man git
19 ：デフォルトの名無しさん：2014/01/24(金) 19:29:22.73 .net: 今からおこなう作業にあらかじめタグをつけておくことは可能？
20 ：デフォルトの名無しさん：2014/01/25(土) 00:25:55.65 .net: >>19
それはブランチだよ。
21 ：デフォルトの名無しさん：2014/01/25(土) 02:09:56.81 .net: タグはコミットにつけるものだから
22 ：デフォルトの名無しさん：2014/01/25(土) 08:38:24.13 .net: gitの場合はブランチもコミットに付くフラグなんだけどな
23 ：デフォルトの名無しさん：2014/01/25(土) 19:48:06.04 .net: >>20
自動的にブランチ名をタグ名にしてタグを付けろってこと？
24 ：デフォルトの名無しさん：2014/01/25(土) 20:09:14.11 .net: >>19
今から行う作業っていうのがどういう意味なのかわからない。
これから新しく作るひとつのコミットのことなのか？

これから新しく作っていく複数のコミットの履歴の最新につける名前なら、
それはブランチを作ればよいのでないか？
25 ：デフォルトの名無しさん：2014/01/25(土) 20:20:02.47 .net: なんかさぁ、
もう、朝ごはんなのか昼ごはんなのか
わからないよ。
26 ：デフォルトの名無しさん：2014/01/25(土) 20:34:08.34 .net: リベースというのは誰かと共有してるブランチではやってはまずいってことかな
masterからdevelopのラインで共同開発してる最中
臨時改修にmasterからfixで直してmasterへマージしたら
developをmasterからリベースしたら共同開発する全員が影響受けるから
masterかfixからdevelopにマージするってことをしないとダメってことか
27 ：デフォルトの名無しさん：2014/01/25(土) 21:02:42.94 .net: 朝ごはんを作るときに朝ごはんブランチを作成したあとに
朝ごはんが完成したらそのまま朝ごはんというタグをつけたら
それは朝ごはんブランチの方につくんだよね？
メインにマージしてから朝ごはんというタグをつければいいの？
28 ：デフォルトの名無しさん：2014/01/25(土) 21:09:33.15 .net: タグは１つのコミットに対してつけるものだから
29 ：デフォルトの名無しさん：2014/01/25(土) 21:10:29.19 .net: Ｇｉｔの仕組みを理解すればタグやブランチやコミットがどういうものなのか分かるよ

Git - Book
http://git-scm.com/book/ja
30 ：デフォルトの名無しさん：2014/01/25(土) 21:18:30.48 .net: >>29
それは読んで理解してるので大丈夫です！
31 ：デフォルトの名無しさん：2014/01/25(土) 21:19:45.77 .net: 理解してたらタグがどうのこうのなんて質問せんやろ・・
32 ：デフォルトの名無しさん：2014/01/25(土) 21:34:08.28 .net: >>26
リベースは原則としてローカリポジトリでやるもの。
リモートにあってもそれが個人で専有しているならありだが。

>>27
gitにおいてブランチは消すもの。
メイン以外にタグを付けることはまず無い。
33 ：デフォルトの名無しさん：2014/01/25(土) 21:36:57.38 .net: >>27
マージした後につけるべきかどうかはマージの方法に依存する

マージコミットが作られるマージの場合には、
そのマージコミットにタグをつけないと不味いだろうから、
マージの後じゃないとダメ

マージコミットが作られないマージの場合には、
マージするコミットがそのままマージ先のコミットになるので、
マージする前でもいい
34 ：デフォルトの名無しさん：2014/01/25(土) 21:48:50.60 .net: >>32
ブランチは作業ごとに毎回消したほうがいいってことか
了解しました
35 ：デフォルトの名無しさん：2014/01/25(土) 23:40:22.40 .net: git flowつかえばいいのに
36 ：デフォルトの名無しさん：2014/01/26(日) 02:01:21.45 .net: git flowは無意味に複雑すぎ。

それに変わるものとして生まれた
github flowがいい。
37 ：デフォルトの名無しさん：2014/01/26(日) 04:47:48.64 .net: 毎回厳密にテストしてバグを最小限に抑えてリリースするならgit-flow
簡単なテストだけしてユーザーにバグ出しさせるならgithub-flow
どっちでもいい
38 ：デフォルトの名無しさん：2014/01/26(日) 04:59:07.84 .net: 小さな修正で不具合がでても被害を最小限にし
ユニットテストとCIによって毎日テストを行い
リリースを早めるのがgithub-flowだよ。

簡単なテストしかできないのは、単にお前の会社に
ユニットテストがないってだけの話。
39 ：デフォルトの名無しさん：2014/01/26(日) 05:01:30.31 .net: GitHub Flow

git-flowの問題点 (Issues with git-flow)
https://gist.github.com/Gab-km/3705015

ここ読めば納得できると思うけど、
github-flowに簡単なテストだけして
ユーザーにバグ出しさせるなんてことは一切書いてない。
逆に自動化されたモダンなテストを行っている。
40 ：デフォルトの名無しさん：2014/01/26(日) 05:39:51.29 .net: なるほど
それぞれ確立されたフローだったのか
gitは最初GitHubから始めたからGitHubのヘルプページのそのGitHub Flowというのが標準のやり方かと思ってたけど
gitについて調べてくうちにそっちのgit Flowのほうの話題が多くてgit Flowのほうが普通なのかと改め直したばかりだったが
どっちでもよかったのか
41 ：デフォルトの名無しさん：2014/01/26(日) 06:00:06.53 .net: >>39
＞小さなバグが入ることはあるだろうが、そういったものは素早く修正して再デプロイすることができる
42 ：デフォルトの名無しさん：2014/01/26(日) 06:07:04.58 .net: 複数バージョンを保守したりする必要があると、
github flow みたいに単純にはできないね
各個人のフューチャーブランチのマージ先として、
masterとは別のブランチが1本は欲しい
43 ：デフォルトの名無しさん：2014/01/26(日) 06:10:35.30 .net: >>41
デプロイするものに小さなバグが混じることを容認してる
デプロイしたものはユーザに触れるわけでそのバグを見つけるのはユーザである可能性があるということ
44 ：37：2014/01/26(日) 06:31:27.58 .net: 突っ込み入った点は知ってたがflowを知らない人向けに超訳して書いた
なので特に反論はないです流してどうぞ
45 ：デフォルトの名無しさん：2014/01/26(日) 07:21:50.62 .net: 未来ブランチ?
46 ：デフォルトの名無しさん：2014/01/26(日) 09:27:02.68 .net: テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。
47 ：デフォルトの名無しさん：2014/01/26(日) 10:28:32.82 .net: >>45
featureブランチのことか？
futureじゃないぞ
48 ：デフォルトの名無しさん：2014/01/26(日) 10:29:43.25 .net: >>46
普通最初にテストを失敗させてテスト自体のテストもすると思うけど
49 ：デフォルトの名無しさん：2014/01/26(日) 10:49:17.69 .net: >>43
> デプロイするものに小さなバグが混じることを容認してる
> デプロイしたものはユーザに触れるわけでそのバグを見つけるのはユーザである可能性があるということ

Linuxだってそうだろ？
リリース版にバグがまじるのは当たり前だし、
リリースされたんだからをユーザーが見つける可能性がある。

バグがないソフトなんてあるのか？
50 ：デフォルトの名無しさん：2014/01/26(日) 10:50:36.70 .net: >>46
> テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
> 開発形態

誰でも勝手に直せるOSSってどれのことだよ？ｗ

wikipediaみたいにだれでも書き換えるものが
存在すると思ってるんだよな？
51 ：デフォルトの名無しさん：2014/01/26(日) 11:25:21.46 .net: 小さなバグが入ることを許容する時点で馴染めないな・・・
全テスト通さないの？
そりゃ、テスト項目漏れは許すけども、許されるのはそこまでだろ
52 ：デフォルトの名無しさん：2014/01/26(日) 11:30:51.70 .net: >>51
まさにそのテスト項目漏れのことを言ってんじゃん。
53 ：デフォルトの名無しさん：2014/01/26(日) 11:32:01.04 .net: >>51
頭悪そう…
54 ：デフォルトの名無しさん：2014/01/26(日) 12:07:58.89 .net: Linuxはガチガチの独裁型プロジェクトで、独裁者と奴隷しかいないからなんか楽しくない
55 ：デフォルトの名無しさん：2014/01/26(日) 12:17:43.13 .net: >>51
誰が許容するなんて言ってるの？
許容するって言ってる奴は馬鹿だよ。

当たり前だけどgithubフローにバグを許容するなんて書いてない。
さあ、誰が言ってるのかな？
スレ検索すればわかるね。
56 ：デフォルトの名無しさん：2014/01/26(日) 12:18:48.02 .net: 「許容」でスレ検索したら、許容という
言葉を最初に使ってるのは、>>51でした。

なんだ自作自演かｗ
57 ：デフォルトの名無しさん：2014/01/26(日) 12:29:47.44 .net: すぐ喧嘩するなお前ら
まあ俺もだけど
58 ：デフォルトの名無しさん：2014/01/26(日) 12:57:52.00 .net: ＼　　　　　　／　　／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　　　＿　　　　　　＿
＿　　　　　　　＿　　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、ヽ| : i : : :,　　　＿　　　　　　＿
＿　　　　　　＿　／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　　　　＿
＿　　　　　　　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　＿　　　　　　＿
　　　　　　　　　　〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ￢ト､: :| : : ! : : : : :,
／　　　　　　＼　　 /.: :/.: : : : /ｌ : |/Гト､　　　　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　　　　＼
　／　 |　　|　　＼　　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　　　ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　い、: :＼/ 　￣￣　　　　　　　　　　 ', : : i : : : : : : : : ,　　　　 _, -‐'　　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣フ　　　　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　　くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　　　　　　／| : : :i : : : : :_, -‐'　　 |　／
　　ｒ―'　　　ヽ、　　　　　　 | : : : ＼　　　　　　　　　　　イ: : :| : : :i_,. -‐　　　　　　 |／
　　｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　　 .:〔: : :|: : :r┬'　　　　　　　 |
59 ：まっくろ、くろすけ、でてこい：2014/01/26(日) 13:15:08.05 .net: ＼　　　　　　／　　／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　　　＿　　　　　　＿
＿　 O　　O　　＿　　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、ヽ| : i : : :,　　　＿　　O　　O　＿
＿　　　　　　＿　／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　　　　＿
＿　　　　　　＿　　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　＿　　　　　　＿
　　　　▽　　　　〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ￢ト､: :| : : ! : : : : :, 　　　　　 ▽
／　　　　　　＼　　 /.: :/.: : : : /ｌ : |/Гト､　　　　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　　　　＼
　／　 |　　|　　＼　　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　　　ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　い、: :＼/ 　￣￣　　　　　　　　　　 ', : : i : : : : : : : : ,　　　　 _, -‐'　　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣フ　　　　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　　くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　　　　　　／| : : :i : : : : :_, -‐'　　 |　／
　　ｒ―'　　　ヽ、　　　　　　 | : : : ＼　　　　　　　　　　　イ: : :| : : :i_,. -‐　　　　　　 |／
　　｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　　 .:〔: : :|: : :r┬'　　　　　　　 |
60 ：デフォルトの名無しさん：2014/01/26(日) 13:20:23.06 .net: >>50-60 は全員同レベルの存在
61 ：オラに力を！：2014/01/26(日) 13:21:21.86 .net: ＼　　　　　　／　　／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　　　＿　　　　　　＿
＿　　　　　　　＿　　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、ヽ| : i : : :,　　　＿　　　　　　＿
＿　　　　　　＿　／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　　　　＿
＿　　　　　　　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　＿　　　　　　＿
　　　　　　　　　　〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ￢ト､: :| : : ! : : : : :,
／　　　　　　＼　　 /.: :/.: : : : /ｌ : |/Гト､　　　　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　　　　＼
　／　 |　　|　　＼　　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　　　ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　い、: :＼/ 　￣￣　　　　　　　　　　 ', : : i : : : : : : : : ,　　　　 _, -‐'　　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣フ　　　　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　　くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　　　　　　／| : : :i : : : : :_, -‐'　　 |　／
　　ｒ―'　　　ヽ、　　　　　　 | : : : ＼　　　　　　　　　　　イ: : :| : : :i_,. -‐　　　　　　 |／
　　｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　　 .:〔: : :|: : :r┬'　　　　　　　 |
62 ：デフォルトの名無しさん：2014/01/26(日) 13:47:13.19 .net: >>47
>>42 へのツッコミだろ。
63 ：デフォルトの名無しさん：2014/01/26(日) 15:02:33.35 .net: >>62
見えてなかった。吊ってきやす
64 ：デフォルトの名無しさん：2014/01/26(日) 17:10:09.63 .net: 誰とは言わんがマルチしてるのばればれだからな
65 ：デフォルトの名無しさん：2014/01/26(日) 17:13:21.10 .net: マルチ・・・？
66 ：デフォルトの名無しさん：2014/01/26(日) 17:18:53.39 .net: ポスト
67 ：デフォルトの名無しさん：2014/01/26(日) 17:20:26.48 .net: はわわ
68 ：デフォルトの名無しさん：2014/01/26(日) 17:22:51.00 .net: >>61
これ何てキャラ？
69 ：デフォルトの名無しさん：2014/01/26(日) 17:43:54.29 .net: 自演とマルチの違いもわからない奴が許容だのなんだの偉そうに言ってたのか
恥ずかしい
70 ：デフォルトの名無しさん：2014/01/26(日) 18:30:34.12 .net: ※前スレから粘着してる頭の悪い荒らしがいるだけなので取り合わなくて結構です
71 ：デフォルトの名無しさん：2014/01/26(日) 19:02:40.25 .net: ※馬鹿のレスは馬鹿にしか見えません
72 ：デフォルトの名無しさん：2014/01/27(月) 21:22:44.12 .net: addしてから編集すると、ちゃんとバレるんだな
かしこいじゃないか
73 ：デフォルトの名無しさん：2014/01/28(火) 05:26:30.62 .net: 先日のはこれの影響？

Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
http://www.atmarkit.co.jp/ait/articles/1401/21/news042.html
74 ：デフォルトの名無しさん：2014/01/28(火) 08:23:13.78 .net: 今読んだけどGithub-flowではリクエストをいったん取り込んで細かいとこ修正という流れができないから
オープンソース開発には向いてないんじゃないか
75 ：片山博文MZ無能 ◆T6xkBnTXz7B0 ：2014/01/28(火) 17:46:12.56 .net: 日本語ファイル名使うなら、非公式Unicode版使うしかないか。古いんだよね
76 ：デフォルトの名無しさん：2014/01/28(火) 18:43:24.12 .net: msysGit でいけるよ
77 ：デフォルトの名無しさん：2014/01/28(火) 18:44:22.63 .net: しまった
NGにレスしてしまった
78 ：デフォルトの名無しさん：2014/01/28(火) 20:09:26.94 .net: あるブランチの内容をまるまるメインに取り込んで
コミットして用済みのブランチを削除
ってやり方は普通なの？
79 ：デフォルトの名無しさん：2014/01/28(火) 20:28:14.38 .net: ブランチがどんどん溜まっていって邪魔
おまえんちゴミ屋敷
80 ：デフォルトの名無しさん：2014/01/28(火) 20:43:25.61 .net: ありがとう
ブランチって削除できないのかぁ
81 ：デフォルトの名無しさん：2014/01/28(火) 20:46:06.48 .net: タグに重要度みたいなのをつけられる？

重要なタグと重要じゃないタグをあとから区別したいんだけど
どうすらいいか
82 ：デフォルトの名無しさん：2014/01/28(火) 20:55:54.41 .net: まるまるメインにコミットしたなら消してもいいだろ
試行錯誤して採用しなかった結果を個人的に残しておきたいときもあるんで、
リポジトリを別に作ってpushしておいたりもするが
83 ：デフォルトの名無しさん：2014/01/28(火) 20:56:38.29 .net: >>80
ブランチ削除できるだろ
84 ：デフォルトの名無しさん：2014/01/28(火) 20:58:15.64 .net: >>74
> 今読んだけどGithub-flowではリクエストをいったん取り込んで細かいとこ修正という流れができないから
> オープンソース開発には向いてないんじゃないか

なんで？

そのリクエストが動作に問題がないのであれば、取り込んで後から修正すればいいじゃん。
動作に問題があるのなら、github-flowでなくても取り込んじゃいけないし（ちゃんとテストしてから取り込む）
そういうのは、取り込まずに修正させればいいし、別ブランチで修正してから取り込んでもいい。
85 ：デフォルトの名無しさん：2014/01/28(火) 21:40:54.79 .net: >>81
タグ名にルールをつけて、後でgrepすればいいんじゃない。
86 ：デフォルトの名無しさん：2014/01/28(火) 22:05:55.02 .net: >>84
リクエストはマスターに来るだろうから即デプロイ可能な品質のコード以外は一度破棄することになる
マスタに入れる前に信用できるメンバーがテストをしないといけないが修正とテストをするためには相手か自分でブランチを切らないといけない
git-flowならデベロップにガンガン突っ込んで自分で直していけるのにリクエスト1個1個にブランチ切るのは効率悪すぎるしコンフリクトの温床になるだろ
ならメンバーはホットフィクスその他はデベロップでgit-flow流用したほうがいいんじゃないの
87 ：デフォルトの名無しさん：2014/01/28(火) 22:13:06.06 .net: git-flow打つの面倒だから略語くれ
88 ：デフォルトの名無しさん：2014/01/28(火) 22:37:37.91 .net: >>86
それのどこがgithubフローと関係あるの？

即デプロイ可能な品質のコード以外を一度破棄するのは
どのフローでも同じじゃん。

> マスタに入れる前に信用できるメンバーがテストをしないといけないが
信頼できるメンバーがテストしていないコードをマスターに入れていいフローなんてあるの？

> git-flowならデベロップにガンガン突っ込んで自分で直していけるのに
コードは手に入ってるんだからマスターに入れずに直せばいいだろ。

> リクエスト1個1個にブランチ切るのは効率悪すぎるし
gitでブランチ切るコストはほぼ0だろ？いくら切っても効率は下がらない。

> コンフリクトの温床になるだろ
それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
開発者が一人しかしないというのなら話は別だが？
89 ：デフォルトの名無しさん：2014/01/28(火) 23:26:32.45 .net: > 即デプロイ可能な品質のコード以外を一度破棄するのは
> どのフローでも同じじゃん。
OSS開発で集まる技術レベルのまばらな人間に十分な品質のコードを求めるのは非現実的
修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い

> 信頼できるメンバーがテストしていないコードをマスターに入れていいフローなんてあるの？
デベロップに入れるなら動かなくてもかまわないがgithubはマスタしかないのでそれができない

> コードは手に入ってるんだからマスターに入れずに直せばいいだろ。
マージしないで手で拾っていくのはGitの効率性を捨ててるし協力してくれる人もいなくなる

> gitでブランチ切るコストはほぼ0だろ？いくら切っても効率は下がらない。
なくていいブランチが増えまくって見通しが悪くなるのは明らかに余計な負担
バグフィクスのリクエスト100個のために100個のブランチがある状態にしたいか？

> それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
順次修正するならそうだが複数のリクエストをまとめて取り込んで修正する方法の選びやすさが違う
温床は書きすぎたのでもとになる程度にしとく
90 ：デフォルトの名無しさん：2014/01/28(火) 23:40:11.08 .net: コンフリクトの量じゃなくて解消しやすさだな
91 ：デフォルトの名無しさん：2014/01/28(火) 23:47:20.75 .net: git-flowやgithub-flowに替わる新しいflowを誰か考えてくれや
92 ：デフォルトの名無しさん：2014/01/28(火) 23:54:17.71 .net: >>89
> バグフィクスのリクエスト100個のために100個のブランチがある状態にしたいか？

それgitでは普通だけど？

言っておくけど、gitではブランチは消すものなので、
バグがフィクスされれば、ブランチはなくなる。
93 ：デフォルトの名無しさん：2014/01/28(火) 23:56:07.46 .net: >>89
> デベロップに入れるなら動かなくてもかまわないがgithubはマスタしかないのでそれができない

デベロップでも入れたらダメだろ。

なんで、自分のレポジトリで修正するって考えが浮かばないのかな？

> マージしないで手で拾っていくのはGitの効率性を捨ててるし協力してくれる人もいなくなる
完成してから、ブランチをマージすればいいだけ。
Gitの効率性＝分散開発なのだから別リポジトリで作業すれば良い。
94 ：デフォルトの名無しさん：2014/01/28(火) 23:56:59.26 .net: >>89
> 修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い

自分のリポジトリで、自分で直してからマージすれば？

つか、なんでマージしてからじゃないと修正できないと思うんだよ？
95 ：デフォルトの名無しさん：2014/01/29(水) 00:08:22.02 .net: なんでケンカ腰なの？戦闘民族なの？
96 ：デフォルトの名無しさん：2014/01/29(水) 00:25:36.01 .net: 　　 ' ,　＼､、|　　　　ヽ　　l / ／　　　ヽ, 　／　/　 /
　｀`ヽ　　ヽヽ!　, 　 lj　　ヽ　i／ ,　' 　u　　!／　／　　/
　　、　ヽ＼｀ l_/ /｀ヽ､　　ヽ/ ／ ,. ' ´ヽ l ,'／'´　　／__
　､ヽ、　,へ､/ ,ﾍ｀`ヽ､ヽ. ｀　/ ／,. -‐,´ _!,-､／／'´／
　ヽ＼｀` l l^ヽ,',　 ',　　oヽ`､} ﾚ／o 　 ,'　〉"^l/／'´／
　　＼､　l l r'　',　ー―‐",｀ｰ´`ｰ―‐'　 //_',/_,. -;ｧ
　　　 ,.ゝ-＼ｰ､ ','"""""　　ﾉ_　゛゛゛゛｀　/'_j /　／
　　　　｀`,ゝ-ゝ､_',u 　　 r====ｮ　　　 /-／_／
　　　　　´￣｀`ｰ,ﾍ　　　 `====''　　 /=''"´
　　　　　　　　 ,'､｀ヽ、,:'　-‐-　　,　'｀`>、
　　　　　　　　ﾉ`::ｰ-､_＼＿＿,／_,. ::'´:::::冫二ニ７7ｰ-
　　,...-､‐ニ二{{:::::::::::::::::::::::::::::::::::::::::::::::::::::/ニニﾆ〃::::::::
　　:::::::::ヽニ二ヽ:::::::::::::::::::::::::::::::::::::::::::::::/二二ﾆ〃:::::::::::
97 ：デフォルトの名無しさん：2014/01/29(水) 01:49:37.30 .net: こんな感じでもめるから *-flow が出来るわけなんだよな
98 ：デフォルトの名無しさん：2014/01/29(水) 02:03:40.19 .net: 何か実装するときにはみんなdevelopブランチから新しいブランチ作って始めるんだから、
developブランチに動かないものマージするなんて言語道断
99 ：デフォルトの名無しさん：2014/01/29(水) 02:07:30.71 .net: すぐ喧嘩するなお前ら。まあ俺もだけど。
100 ：デフォルトの名無しさん：2014/01/29(水) 03:25:17.30 .net: メジャーなリポジトリの使用例見てきた

> それgitでは普通だけど？
仕事でやれば普通でも通りすがりの他人にそこまでやらせんだろうと思ったけどやらせるのか・・・？
実際は完成させてから入れてるからそんな状況にはならないようだけど

終わったブランチは消してる

> なんで、自分のレポジトリで修正するって考えが浮かばないのかな？
自分のリポジトリ

> 完成してから、ブランチをマージすればいいだけ。
要求レベル高すぎと思ってたけどほかの人みたらそれで回してるようなのでそうします

> つか、なんでマージしてからじゃないと修正できないと思うんだよ？
気分的に投げられたコード放置しづらかったので

> 何か実装するときにはみんなdevelopブランチから新しいブランチ作って始めるんだから、
> developブランチに動かないものマージするなんて言語道断
そういや担当を決めないからとんでもないことになるか
やめよう

夜更かししすぎた
101 ：デフォルトの名無しさん：2014/01/29(水) 21:40:58.44 .net: >>85
ありがとう
それしか方法がないのか
意外とかゆいところに手が届かないね
102 ：デフォルトの名無しさん：2014/01/29(水) 22:00:17.62 .net: ふつうのひとは
そんなところ
かゆくならない
103 ：デフォルトの名無しさん：2014/01/29(水) 22:03:07.40 .net: 世の中便利ツールが増えすぎて人間が不精になってきてるのな
grep程度を手間とか
104 ：デフォルトの名無しさん：2014/01/29(水) 22:07:25.84 .net: >>103
grepが手間とかじゃあないんだよんべ
タグ名にそういう意味も持たせるってのがちょっと嫌なだけ
みんな大好きなハンガリアン記法でしょ
105 ：デフォルトの名無しさん：2014/01/29(水) 22:17:35.92 .net: つgit notes
106 ：デフォルトの名無しさん：2014/01/29(水) 23:37:14.60 .net: jpegやbmpみたいなバイナリファイル、ワードやエクセルのファイルを
管理するにはどうすればいいの？
企業内開発では避けては通れないんだけど、チェックイン＆チェックアウト
みたいな管理はできるの？
107 ：デフォルトの名無しさん：2014/01/29(水) 23:38:47.49 .net: あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
108 ：デフォルトの名無しさん：2014/01/29(水) 23:41:34.39 .net: あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
109 ：デフォルトの名無しさん：2014/01/30(木) 00:08:24.68 .net: 開発用と社内アーカイブ用で分けるとか？
110 ：デフォルトの名無しさん：2014/01/30(木) 00:20:52.94 .net: >>108
1度言えばわかる
111 ：デフォルトの名無しさん：2014/01/30(木) 00:35:08.71 .net: >>110
すまぬ
タイムアウトして、リロードせずに再度投稿しちゃったもんだから…
112 ：デフォルトの名無しさん：2014/01/30(木) 01:22:17.29 .net: あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
113 ：デフォルトの名無しさん：2014/01/30(木) 01:36:43.35 .net: gitってどの辺がperlに依存してんの？
今一分からん
114 ：デフォルトの名無しさん：2014/01/30(木) 01:52:33.89 .net: >106
SVG
115 ：デフォルトの名無しさん：2014/01/30(木) 02:28:21.77 .net: >>101
Excelとか何でもかんでも詰め込んだアプリでも使っとけ。
俺は今のgitでも詰め込みすぎててちょっと不安。キープシンプル。
116 ：デフォルトの名無しさん：2014/01/30(木) 03:58:50.02 .net: あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
117 ：デフォルトの名無しさん：2014/01/30(木) 17:16:32.69 .net: >>106
シェアポイント
118 ：デフォルトの名無しさん：2014/01/30(木) 23:51:55.27 .net: あるタグから後ろのコミットのメッセージの一覧
ってどうやって取得できるんだっけか
119 ：デフォルトの名無しさん：2014/01/31(金) 00:06:29.73 .net: 後ろって？
120 ：デフォルトの名無しさん：2014/01/31(金) 00:11:14.15 .net: >>118
git log tag..
でカレントブランチのtag以降のコミットを見れる。

git log tag..branch
で任意のブランチのtag以降のコミットを見れる。
121 ：デフォルトの名無しさん：2014/01/31(金) 00:28:16.85 .net: 後ろって言えば、そりゃ、右を90度回転させたところよ。
122 ：デフォルトの名無しさん：2014/01/31(金) 00:30:58.29 .net: >>121
おかしいな、前にみえる。
123 ：デフォルトの名無しさん：2014/01/31(金) 00:33:43.32 .net: どんな規模のプロジェクトだろうと一番の問題はコミュニケーション齟齬、あいまいな言葉を使うなどで生じやすい
124 ：デフォルトの名無しさん：2014/01/31(金) 01:29:51.93 .net: >>120
おっサンキュウ
125 ：デフォルトの名無しさん：2014/01/31(金) 10:01:32.16 .net: 右手の親指と人差し指を90度に開いてL字にして
親指を垂直上方向に向けて人差し指を正面に向けた時に
人差し指を反転した方向が後ろ
126 ：デフォルトの名無しさん：2014/01/31(金) 10:04:31.35 .net: 右京区は地図の上では左
127 ：デフォルトの名無しさん：2014/01/31(金) 10:37:43.01 .net: ITpro
伝わる文章：5日目「曖昧な曖抽象的表現の多い文章」はダメである 2014年01月31日
http://www.nikkeibp.co.jp/article/news/20140131/382014/

　相手に伝えやすくする方法の一つに「曖昧に書かない、抽象的表現を使わない」ということがあります。
曖昧な表現や抽象的な表現は、読み手の理解を妨げます。「かなりよい」、「とても大変」、
「我々には考えつかない程の大きな考慮点が必要」などの表現は、
相手に正しく理解してもらえないダメ文章に繋がります。
128 ：デフォルトの名無しさん：2014/01/31(金) 23:49:10.43 .net: Gitを使い始めてから俺の生産性が500%上がった
129 ：デフォルトの名無しさん：2014/01/31(金) 23:59:44.14 .net: >>127
フェルミ推定をディスってるな。

フェルミ推定は曖昧な情報で
相手を納得させる技術だからな。
130 ：デフォルトの名無しさん：2014/02/01(土) 00:18:36.80 .net: フェルミ推定 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A
> 手掛かりを元に論理的に推論し、短時間で概算することを指す

「曖昧」や「抽象」とは異なる
フェルミ推定を誤解してると言わざるを得ない
131 ：デフォルトの名無しさん：2014/02/01(土) 08:04:08.63 .net: ～すると、大変なことになります。[EOF]

という文章を見ると殺意がこみ上げてくる
132 ：デフォルトの名無しさん：2014/02/01(土) 08:12:37.83 .net: 禿丸ω
133 ：デフォルトの名無しさん：2014/02/01(土) 09:19:35.19 .net: ～すると幸せになれる

ブログなんかの解説でこれ見たらファビョりそうになる
134 ：デフォルトの名無しさん：2014/02/01(土) 09:44:53.70 .net: でお前らはどこにリポジトリをぶん投げてるの？
GitHub？
135 ：デフォルトの名無しさん：2014/02/01(土) 10:39:24.08 .net: githubでしか使ってない
会社はsvn
136 ：デフォルトの名無しさん：2014/02/01(土) 10:59:58.72 .net: >>134
GitLab
137 ：デフォルトの名無しさん：2014/02/01(土) 17:22:58.76 .net: 最近色々な同様のサービスのサイトが出来てきて迷うよな
GitLabはGitLab cloud?
138 ：デフォルトの名無しさん：2014/02/01(土) 18:27:59.15 .net: GitLabはサービスじゃないよ。
GitHubのEnterprise相当の機能をもった
オープンソースのウェブアプリ
139 ：デフォルトの名無しさん：2014/02/01(土) 18:29:31.06 .net: >>134
どこってVPSとかそういうことか?
140 ：デフォルトの名無しさん：2014/02/01(土) 20:21:27.39 .net: リモートはSourceForge.JPの作業部屋っていう個人リポジトリとGitHubの個人リポジトリ使ってる
GitLab cloudやbibucketも最近気になってる
141 ：デフォルトの名無しさん：2014/02/01(土) 23:53:17.42 .net: Dropboxにベアリポジトリ置くの超便利
142 ：デフォルトの名無しさん：2014/02/02(日) 00:03:37.19 .net: 自動同期はあまり好きじゃない
143 ：デフォルトの名無しさん：2014/02/02(日) 04:25:13.05 .net: azure
144 ：デフォルトの名無しさん：2014/02/02(日) 04:57:28.17 .net: そこらにある普通の無料レンタルホームページサービスじゃ
gitのベアリポジトリの公開は無理そうだな
OSSのホスティングサービス使うしかないのか
145 ：デフォルトの名無しさん：2014/02/02(日) 05:56:10.49 .net: なんでGitLab cloudがあるのに
レンタルサーバーなんか使わんといかんのだ？
146 ：デフォルトの名無しさん：2014/02/02(日) 06:29:58.87 .net: サーバーに対する信用性の問題じゃね
そこらのレンタルサーバーのほうが信用性がおけるならレンサバのほうでGitLabなりを構築する
レンサバよりもGitLab cloudなどの非公開リポジトリ可のサービスのほうが信用たるならそっち使う
という感じだろ
147 ：デフォルトの名無しさん：2014/02/02(日) 06:30:52.13 .net: あとレンサバ使う理由としては独自ドメインを使いたいとかもあるんじゃないかな
148 ：デフォルトの名無しさん：2014/02/02(日) 06:38:11.08 .net: あとは費用の問題とか
GitLab cloudなどのサービスだとgitサーバー以外の出来ることが限られるけど
サーバーマシンそのものを借りるレンサバなら色々好きに構築できるし
149 ：デフォルトの名無しさん：2014/02/02(日) 06:39:36.24 .net: おいおい、前提として
「そこらにある普通の無料レンタルホームページサービス」
だろ？

専用サーバーとかVPSの話はするなよ。
150 ：デフォルトの名無しさん：2014/02/02(日) 06:50:00.38 .net: >>149
勝手に前提つけるなよ
151 ：デフォルトの名無しさん：2014/02/02(日) 06:56:15.17 .net: 「そこらにある普通の無料レンタルホームページサービス」

これは自動挿入される広告とかで収入上げてんだろ？
gitみたいなダウンロードだけのことは規約違反だろＪＫ
152 ：デフォルトの名無しさん：2014/02/02(日) 06:58:10.48 .net: >>150

>>144にかいてあるじゃないか
> そこらにある普通の無料レンタルホームページサービスじゃ
153 ：デフォルトの名無しさん：2014/02/02(日) 07:52:02.69 .net: >>152
もともとの>>134の話題にレスしてる人もいるんだからってことだよ。
154 ：デフォルトの名無しさん：2014/02/02(日) 14:28:11.08 .net: 現在のブランチから分岐している(=fast-forwardの関係にない)ブランチを簡単に
リストアップする方法ってありますか？
155 ：デフォルトの名無しさん：2014/02/02(日) 19:18:24.63 .net: 現在のブランチのHEADから分岐してる別のブランチは、fast-forwardの関係にあるだろ？
156 ：デフォルトの名無しさん：2014/02/02(日) 21:38:19.41 .net: >>154をどう読んだら「HEADから」と思うんだ？
157 ：デフォルトの名無しさん：2014/02/02(日) 21:38:35.69 .net: git branch --no-merged
とかじゃだめ？
158 ：デフォルトの名無しさん：2014/02/03(月) 00:00:05.83 .net: >>156
「現在のブランチから分岐している(=fast-forwardの関係にない)」
159 ：デフォルトの名無しさん：2014/02/03(月) 00:01:18.39 .net: >>158
それのどこにHEADの要素が？
160 ：デフォルトの名無しさん：2014/02/03(月) 00:06:23.60 .net: それのどこにHEADを除外すると書いてあるんだ？
161 ：デフォルトの名無しさん：2014/02/03(月) 00:14:50.84 .net: 　 ┌──────────　　←　fast-forwardでないブランチ
┬┴─────┬────　　←　現在のブランチ
└─┬────┘　　　　　　　　←　マージされたブランチ
　　　└─────────　　←　fast-forwardなブランチ

こんな感じ？
162 ：デフォルトの名無しさん：2014/02/03(月) 00:17:14.79 .net: 　　　　　　┌─■──■──■─────　　←　fast-forwardでないブランチ
┬─■─┴─■─■───┬────　　←　現在のブランチ
└─■─┬───────┘　　　　　　　　←　マージされたブランチ
　　　　　　└──■──■─────　　←　fast-forwardなブランチ

こんな感じ？
163 ：デフォルトの名無しさん：2014/02/03(月) 00:18:23.13 .net: fast-forwardになってない
164 ：￣￣￣∨￣￣￣￣￣￣￣￣￣：2014/02/03(月) 00:23:28.23 .net: 　　 ┌■─■─■─■─■──　　←　fast-forwardでないブランチ
┬■┴■─■─■─■┬───　　←　現在のブランチ
│　　　　　　　　 │　　　└■─■─　←　fast-forwardなブランチ
└■┬■─■─┘　
　　　└■─■─■─■─■──　　←　fast-forwardでないブランチ

こんな感じ？
165 ：デフォルトの名無しさん：2014/02/03(月) 00:23:57.45 .net: fast-forwardは重要な概念だからちゃんと理解しとけよ
>>161-162は落第
166 ：デフォルトの名無しさん：2014/02/03(月) 00:30:19.95 .net: fast-forwardの解説おながいしまうｓ
167 ：デフォルトの名無しさん：2014/02/03(月) 00:30:24.95 .net: 一番下のブランチは派生元のブランチがマージされてるから現在のブランチの分岐扱いになるのかな
168 ：デフォルトの名無しさん：2014/02/03(月) 00:32:23.03 .net: >>166
fast-forwardとは
HEADが指すコミットを最新のコミットを指すようにするだけで済むマージ

fast-forwardでないとは
マージコミットが発生する
169 ：デフォルトの名無しさん：2014/02/03(月) 00:34:23.66 .net: ブランチ切った後にそれぞれにコミットが発生すると初めて分岐が発生して
fast-forward じゃなくなる、でOKじゃないのかね
170 ：デフォルトの名無しさん：2014/02/03(月) 00:44:11.57 .net: 　　 ┌■─■─■─■─■──　　←　ノーマルエンド
┬■┴■─■─■─■┬───　　←　ハッピーエンド
│　　　　　　　　 │　　　└■─■─　←　真のエンディング
└■┬■─■─┘　
　　　└■─■─■─■─■──　　←　バッドエンド
171 ：デフォルトの名無しさん：2014/02/03(月) 00:48:50.26 .net: >>169
それぞれ、だけと片方だけでもよさそうだからダメだな。
それぞれに異なるコミットが、にすればいい。

あと、さっきからHEADをsvnみたいな意味で使ってるやつがいるのか？
172 ：デフォルトの名無しさん：2014/02/03(月) 00:57:32.30 .net: >>168
よくある説明だけど、わかっている人にはわかって
わからない人には全然わからない答えだよな。

たとえば、オープンソースのコードをcloneして
手元にソースコードをダウンロードしているとする。
数日後バージョンアップしてソースコードが更新された。

fast-forwardとは最新のソースコードまで更新履歴を単純に進めること（早送り）
fast-forwardをするとソースコード消して取りなおしたのと同じことになる。

それとは別にfast-forwardをしないでマージコミットを作るやり方があって
これは現在から最新までの変更分を一つ（ないし複数の）コミットとしてつけたすもの。
fast-forwardの代わりにマージコミットを使っても最終的に同じになるのだが変更履歴内容が違う。

またfast-forwardはclone元から単純に遅れている時にしか使えない。
clone元には無い修正を加えてしまうとfast-forwardできない。
173 ：デフォルトの名無しさん：2014/02/03(月) 01:34:49.46 .net: こんな感じ？

http://ideone.com/hvgkDV
174 ：デフォルトの名無しさん：2014/02/03(月) 01:43:15.60 .net: 全然違う
175 ：デフォルトの名無しさん：2014/02/03(月) 01:57:26.57 .net: 以下のようにコミットの履歴が番号順に育っていて、AブランチのHEADが4で、BブランチのHEADが6だとする。

1─2─3─4─5─6

その状態では、BブランチをAブランチへマージするにはAブランチのHEADを6に変更するだけで済む。
その状態をfast-forwardマージ可能な状態と呼び、
そのHEADを変更するだけのマージを、fast-forwardマージと呼ぶ。

fast-forwardマージ可能で無い状態では、「マージコミットを作成することによるマージ」しかできない。
fast-forwardマージ可能な状態では、「fast-forwardマージ」と「マージコミットを作成することによるマージ」
のどちらかを任意に選択可能。
176 ：デフォルトの名無しさん：2014/02/03(月) 02:04:08.14 .net: リスト構造の概念が分かってればgitも似たようなもんだから理解は難しくないと思われ
177 ：デフォルトの名無しさん：2014/02/03(月) 02:11:48.62 .net: 全然違うよ
178 ：デフォルトの名無しさん：2014/02/03(月) 02:12:10.74 .net: >>174,177
なにがだ。
179 ：デフォルトの名無しさん：2014/02/03(月) 04:47:05.44 .net: 　　┌I─J─K─L─M　　←　ノーマルエンド
┬A┴B─C─D─E─┬──F　　←　ハッピーエンド
│　　　　　　　　　　　└G─H　←　真のエンディング
└N┬O─P　←　鬱エンド
　　 └Q─R─S─T─U　　←　バッドエンド

左から初めて右へと進む。左へは戻れない。

現在Aにいるのであれば、ノーマルエンドやハッピーエンド、真のエンディングに辿れる＝fast-forward
しかしNに入り込んでしまったら、鬱エンドかバットエンドにしかならない＝fast-forwardできない。

AルートにきてもIルートに来てしまったらノーマルエンドになる。
IからJ,K,L,Mまではメッセージスキップ（fast-forward）で進めるが、
ハッピーエンド、真のエンディングにはfast-forwardで進めない。

Oまで来てしまったら鬱エンドは回避不可能。
180 ：デフォルトの名無しさん：2014/02/03(月) 05:02:40.54 .net: 現在Fにいるとして、ここからG、H、にはfast-forwardではいけない。
だが無理やりFにG、Hをマージすることが出来る。
そうすると、ハッピーエンドを見た後で、真のエンディングを見ることが可能になる。
単純にG、Hにくるだけでは真のエンディングしか見れない。
また逆にHにいるときにFをマージすることで、真のエンディング＋ハッピーエンドになる。

だが、ハッピーエンドにO、Pをマージするのは不可能ではないが辛いだろう。
そもそもの分岐点はヤンデレ化した彼女から逃げるとき山に逃げるか谷に逃げるかの選択肢にある。
山に逃げればAルートに入るが、谷に逃げるとNルート。

さすがに同じ選択肢で違う答えを選んでルートが別れたので単純にはマージできない。
これがコンフリクトである。もしコンフリクトが解消できたのなら
真のエンディングと鬱エンドを合わせた別のストーリーができるかもしれない。
181 ：デフォルトの名無しさん：2014/02/03(月) 05:45:10.10 .net: おまえも人生巻き戻すべきだな
182 ：154：2014/02/03(月) 08:09:59.68 .net: >>157
まさにこれでした。ありがとうございました。
183 ：デフォルトの名無しさん：2014/02/03(月) 08:16:29.86 .net: これよかったよ。
http://www.slideshare.net/kotas/git-15276118
fast-forward な関係理解できた。
184 ：デフォルトの名無しさん：2014/02/03(月) 18:57:41.27 .net: git でファイルモードの変更を無視するには
なにを設定すればいいんだっけか
185 ：デフォルトの名無しさん：2014/02/03(月) 19:26:59.54 .net: ググればいいだろ。
http://tetsuwo.tumblr.com/post/36066698390/git-chmod-git-config
186 ：デフォルトの名無しさん：2014/02/03(月) 22:09:30.15 .net: 一つのディレクトリ、リポジトリを複数のサービスに上げることって出来る？
例えばgithubやgitlab cloudに
187 ：デフォルトの名無しさん：2014/02/03(月) 22:14:51.83 .net: リモートリポジトリを複数持てるかってことなら当たり前のようにやれる
普通にgithub使うだけでも本家とforkした自分ので2つ使う参照するし
188 ：デフォルトの名無しさん：2014/02/03(月) 22:15:29.70 .net: push 先選べばいいだけの話
189 ：デフォルトの名無しさん：2014/02/03(月) 22:24:38.77 .net: git remote addでリモートリポジトリを追加登録すれば楽だな
しなくてもいいけど
190 ：デフォルトの名無しさん：2014/02/03(月) 22:26:46.22 .net: GitHubはEclipseと連携出来るようだけど、GitLab、GitLab Cloudとかは出来る？
191 ：デフォルトの名無しさん：2014/02/03(月) 22:33:26.12 .net: sshの公開鍵認証でリモートリポジトリとして使うだけなら、
Githubだろうがなんだろうが全部一緒だろ
192 ：デフォルトの名無しさん：2014/02/03(月) 22:41:15.75 .net: なるほど
じゃぁEGit使ってGitLab Cloud試してみます
193 ：デフォルトの名無しさん：2014/02/04(火) 00:12:31.81 .net: gitのpushを2回行った場合ってリポジトリに何か変更起こる？
git push -u origin hoge
ここでうっかり２回目のpush
git push -u origin hoge
変更というか書き換え？
194 ：デフォルトの名無しさん：2014/02/04(火) 00:20:31.54 .net: 試してみればいいよ
195 ：デフォルトの名無しさん：2014/02/04(火) 00:21:45.63 .net: アレ？
俺根本的にgitのこと勘違いしてたのかな？
commitって言葉だけから、Subversionと同じ仕組みかと思ってたんだけど、
ファイルのバージョン管理は出来ないの？
あるリビジョンに復旧させたり、diffしたり...
SVNと昔から比較されてたからそういう事も出来るのかと思ってたんだけど
196 ：デフォルトの名無しさん：2014/02/04(火) 00:23:48.80 .net: Git - Book
http://git-scm.com/book/ja

2のgitの基本を読むといいよ
197 ：デフォルトの名無しさん：2014/02/04(火) 00:26:49.28 .net: Branch master set up to track remote branch master from origin.
Everything up-to-date
適当に作って2回pushしたら表示された
これってリポジトリでは何らかの変更が行われてるの？
それともヘッダのハッシュが同じだから弾かれてる？
198 ：デフォルトの名無しさん：2014/02/04(火) 00:30:20.73 .net: 英語ちゃんと読めよ
199 ：デフォルトの名無しさん：2014/02/04(火) 00:32:12.43 .net: GitはSubversionとは用語の意味や使い方違うから
感覚で使わずちゃんと導入のための読み物があるのだからそれ読んでから使え

Git - Book
http://git-scm.com/book/ja
200 ：デフォルトの名無しさん：2014/02/04(火) 00:33:09.00 .net: pushの -u オプションは毎回つける必要なくね？
201 ：デフォルトの名無しさん：2014/02/04(火) 00:33:09.30 .net: 大した分量でもないから基本的な部分の話だけなら２～３時間くらいあれば読めるだろう
202 ：デフォルトの名無しさん：2014/02/04(火) 00:34:02.30 .net: subversion と同じ感覚で使うと間違いなく事故る
203 ：デフォルトの名無しさん：2014/02/04(火) 00:38:32.46 .net: >>197
送信の通信量をチェックするか
リモートブランチを自前サーバーにでも作ってチェックするか
Gitのソースコードでpushで何やってるかを直に見るか
すればいい
204 ：デフォルトの名無しさん：2014/02/04(火) 00:42:13.92 .net: 無駄に通信コストのかかる設計にしてるとはとても思えないがな
205 ：デフォルトの名無しさん：2014/02/04(火) 00:43:28.75 .net: ところがどっこい
206 ：デフォルトの名無しさん：2014/02/04(火) 00:51:57.24 .net: プロトコル次第なんだな、面白い
ttp://git-scm.com/book/ja/Git%E3%81%AE%E5%86%85%E5%81%B4-%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B9%E3%83%95%E3%82%A1%E3%83%BC%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB
207 ：デフォルトの名無しさん：2014/02/04(火) 01:07:07.82 .net: Gitのソースコード見てたが案外やっつけだな
208 ：デフォルトの名無しさん：2014/02/04(火) 03:26:03.37 .net: くそぅ、うんこがしたいのに３日我慢してんだぜ...
209 ：デフォルトの名無しさん：2014/02/04(火) 11:07:45.50 .net: 味噌を食うと良い
210 ：デフォルトの名無しさん：2014/02/04(火) 14:19:52.08 .net: EGitからpushする際、毎回URIの入力をしないといけないんだけど、これ何とかならない？
GitLab Cloudに送りたいんだけど、毎回URIを確認しにファイルだかサイトだかにアクセスしないといけないんだけど
211 ：デフォルトの名無しさん：2014/02/04(火) 14:45:41.55 .net: >>210
Eclipseスレで聞いたら？EGitの話題も多いよ
212 ：デフォルトの名無しさん：2014/02/04(火) 15:13:50.09 .net: 分かった
ありがと
213 ：デフォルトの名無しさん：2014/02/04(火) 19:50:17.43 .net: git status
で見ると、変更があることになってるんだけど
git diff
で見ると、変更がない（属性も同じ）

これってなにが原因なの？
214 ：デフォルトの名無しさん：2014/02/04(火) 19:57:59.72 .net: >>213
git add 済みとかじゃないの？
215 ：デフォルトの名無しさん：2014/02/04(火) 20:12:13.46 .net: よくわからん
CRLFかな
216 ：デフォルトの名無しさん：2014/02/04(火) 20:27:44.21 .net: 普通はstatusの方が正しいかな
diffの方は差分をいろいろ無視するオプションがある
217 ：デフォルトの名無しさん：2014/02/05(水) 11:06:21.69 .net: gitでdiffを見るときに
@@ -133,20 +128,17 @@
みたいな行の後ろが改行されないんだけど
これってなにが原因だと思う？
218 ：デフォルトの名無しさん：2014/02/05(水) 11:23:16.98 .net: LFとCRLF改行の混在じゃね？
219 ：デフォルトの名無しさん：2014/02/05(水) 11:41:15.63 .net: cvswebのdiff表示もそんな状態になってたな。
行番号の後にさらにその差分の部分がどこのCの関数内であるかを
付けられるとかなんとかそういうフォーマットもあるらしい。
220 ：デフォルトの名無しさん：2014/02/06(木) 04:31:31.21 .net: CR/LFを多数決で判断するようなエディタなんか捨てちまえ。
221 ：デフォルトの名無しさん：2014/02/06(木) 04:41:42.53 .net: 改行コードくらいプロジェクトで統一しろよ・・・
222 ：デフォルトの名無しさん：2014/02/06(木) 10:54:55.53 .net: >>218
CRLFの混在が原因ではなさそう
LFのみのプロジェクトでも @@ の後ろに改行がつかない
223 ：デフォルトの名無しさん：2014/02/06(木) 10:58:58.23 .net: SourceTree使ってる人いる？
224 ：デフォルトの名無しさん：2014/02/06(木) 10:59:22.34 .net: 1ファイル内で混在みたいなアホなことになってるとか
225 ：デフォルトの名無しさん：2014/02/06(木) 11:38:08.94 .net: >>224
仮にCRLFの混在があったとしても、
diffコマンドの出力にLFがつかない理由にはならないと思う
226 ：デフォルトの名無しさん：2014/02/06(木) 11:40:29.41 .net: commitはしたけどpushはまだしていない分について
git status コマンドで状況見たいんだけど
どうしたらいいかな
227 ：デフォルトの名無しさん：2014/02/06(木) 12:02:53.24 .net: remote との差が知りたいってこと？
228 ：デフォルトの名無しさん：2014/02/06(木) 13:01:18.51 .net: >>222
>>219も言ってるけど、@@の直後に改行無しで表示される部分は、差分が属するクラスなんかの定義のことじゃないの？
差分を見やすくするためにdiffがソースを解析してくっつけてくれる。
229 ：デフォルトの名無しさん：2014/02/06(木) 13:15:34.10 .net: >>226
ブランチがリモート追跡ブランチになってれば、
pushしてないコミットがあるときにgit statusに表示されるだろ
こんな感じに
# Your branch is ahead of 'origin/master' by 4 commits.

おれはgit logに(HEAD, master)とか(origin/master)が表示されるようにして
差があるかどうかを判断してる
こっちはremote追跡ブランチになってる必要は無いな
230 ：デフォルトの名無しさん：2014/02/07(金) 11:35:30.89 .net: >>228
なるほど
その定義表示部分が空文字列になってて
改行表示されなくなってる可能性があるのか
231 ：デフォルトの名無しさん：2014/02/07(金) 14:21:28.13 .net: いや定義表示部分が空文字列になってるとかじゃなくて、
@@ に続いて改行無しで定義部分が表示される。

こんな風に表示されることを言ってるんだろ？
diff --git a/Hello.java b/Hello.java
index 5dcc23b..047aa5f 100644
--- a/Hello.java
+++ b/Hello.java
@@ -5,7 +5,7 @@ public class Hello {

これは @@ -5,7 +5,7 @@ の差分部分が、Helloクラスの定義内に含まれてますよって意味だ
232 ：デフォルトの名無しさん：2014/02/07(金) 15:39:11.94 .net: あああーなるほどー
そういうことか・・・
恥ずかしい発言だった・・・
233 ：デフォルトの名無しさん：2014/02/07(金) 19:48:28.21 .net: cvswebの方はガチで1つ下にあるべき行がそこに入っていたけど、
そんなものを今も使ってるところが見つからないからもういいやｗ
234 ：デフォルトの名無しさん：2014/02/08(土) 11:15:03.96 .net: http://code.google.com/p/git-core/downloads/list
１．８．５．４
235 ：デフォルトの名無しさん：2014/02/09(日) 12:44:10.31 .net: 空のフォルダに.gitkeepを追加しようと思ってます。
しかしフォルダ数が多いため時間がかかります。

自動で追加してくれるフリーソフトかなにかありませんか？
236 ：デフォルトの名無しさん：2014/02/09(日) 12:52:08.51 .net: find . -type d -empty -not -path './.git*' -exec touch {}\/.gitignore \;
237 ：デフォルトの名無しさん：2014/02/09(日) 18:08:11.46 .net: >>236
.gitignoreではないです。
238 ：デフォルトの名無しさん：2014/02/09(日) 20:08:52.67 .net: >>237
横レスだが、ignoreでも問題ないし、以前はignoreだった。
気に入らないならkeepに変えればいいだけだろう。ちゃんとお礼言えよ。
239 ：デフォルトの名無しさん：2014/02/09(日) 20:12:38.54 .net: 空のディレクトリを見つけてそこに.gitkeepという空ファイルを配置する
スクリプトで簡単に書けそうな気もするけど
240 ：デフォルトの名無しさん：2014/02/09(日) 22:55:57.48 .net: シェルスクリプトとか find だの test だの組み合わせるのがない世代なんだろ
もしくは Windows だとか
241 ：デフォルトの名無しさん：2014/02/09(日) 23:08:16.39 .net: WindowsならWSHがあるじゃん
242 ：デフォルトの名無しさん：2014/02/09(日) 23:24:41.55 .net: WindowsってGitBashがインストールされるじゃん
243 ：デフォルトの名無しさん：2014/02/09(日) 23:39:20.75 .net: >>241
もう wsh は死んだのだよ
今は powershell だ
244 ：デフォルトの名無しさん：2014/02/09(日) 23:49:47.60 .net: GitBashにfindもgrepもtouchも入ってるよね
245 ：デフォルトの名無しさん：2014/02/09(日) 23:56:56.77 .net: 要するに無能
246 ：デフォルトの名無しさん：2014/02/09(日) 23:59:41.82 .net: 何故唐突にgrep?
247 ：デフォルトの名無しさん：2014/02/10(月) 17:03:57.48 .net: .gitignoreはバージョン管理しないファイルを指定するgitで決められたファイル
.gitkeepは空ディレクトリも作らせるための慣例的なファイル

という違いはさておき、 >>237 はその程度読み替えてほしいもんだ。
248 ：デフォルトの名無しさん：2014/02/10(月) 17:11:43.10 .net: しれっといつのまにか vundle のメンテナ化するのかな
249 ：デフォルトの名無しさん：2014/02/11(火) 05:11:32.98 .net: Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
システムだよな。
大手SIerで使わないのはそこにも原因があるんだろうね。
上ででていた、誰がどこを直すのかしっかり決まっている組織や開発体制では、その
作業のミスをふせぐMSSみたいなファイルのロック・アンロックのような
バージョン管理システムの方が向いている。
ExcelやJpegと行った、差分を取ってもしょうがないバイナリファイルの編集も必要だし。
250 ：デフォルトの名無しさん：2014/02/11(火) 05:24:34.71 .net: GitHub-Flowだと独裁者が決めるって感じでは無いようだけど
251 ：デフォルトの名無しさん：2014/02/11(火) 08:56:55.81 .net: またおまえか
ファイルロックで担当ミスを防ぐとか
いい加減勘違いに気付け
252 ：デフォルトの名無しさん：2014/02/11(火) 09:28:48.04 .net: だからMSSて何だよ
253 ：デフォルトの名無しさん：2014/02/11(火) 10:20:23.74 .net: WSSのましがい
254 ：デフォルトの名無しさん：2014/02/11(火) 10:29:01.51 .net: google先生に質問した結果を最大限に好意的に解釈しても
　MSS=Maximum Segment
　WSS=Windows SharePoint Services
だな。
255 ：デフォルトの名無しさん：2014/02/11(火) 10:29:45.12 .net: ×MSS=Maximum Segment
◯MSS=Maximum Segment Size
256 ：デフォルトの名無しさん：2014/02/11(火) 11:09:35.76 .net: >>249
VSSでチェックアウトするとデフォルトでロックするのが不便なのは周知の事実で、
TFSではデフォルトではロックしないようになった。
ロックを使わずにワークフローで重複作業を防ぐのが今のベストプラクティス。
新しいものに拒絶反応を示すのはやめて勉強した方がいいよ。
257 ：デフォルトの名無しさん：2014/02/11(火) 13:38:51.11 .net: 会社でベストプラクティスとかいう単語を使う奴は信用しない。
258 ：デフォルトの名無しさん：2014/02/11(火) 13:43:14.72 .net: じゃあワーストプラクティス
259 ：デフォルトの名無しさん：2014/02/11(火) 13:45:42.45 .net: お前は信頼はできないが信用は出来そうだな
260 ：デフォルトの名無しさん：2014/02/11(火) 13:55:17.31 .net: 信用は金で買えるからな
261 ：デフォルトの名無しさん：2014/02/11(火) 13:57:29.98 .net: 信用金庫でお取扱しております。
262 ：デフォルトの名無しさん：2014/02/11(火) 14:02:46.32 .net: 「情報共有」、「コミュニケーション力」、「本音ベース」
263 ：デフォルトの名無しさん：2014/02/11(火) 14:34:50.71 .net: >>250
github flowに限らずgit flowとかも、いわゆる中央リポジトリーのようなものを
作ってそこからpull、pushしてという感じになる。pushに関してもただ単に権限の
問題だからやろうと思えば好きなモノをpush出来る。ただそれだと色々問題が
起きるかも知れないからっていうのでレビュアーを置いてチェックするルールで
運用しているだけ。 svnなんかもライブラリ管理者やゲートキーパーなんて
呼ばれている人がいたわけで、ある意味独裁者だったでしょ？
264 ：デフォルトの名無しさん：2014/02/11(火) 14:46:55.43 .net: 独裁って言葉に過剰飯能する奴いるけど、Linusの独裁モデルに都合の良い仕様だから当然でいちいち反論しなくてよろしい

ジョブズでもなんでも、良い製品は民主的体制じゃなくて独裁から生まれる
265 ：デフォルトの名無しさん：2014/02/11(火) 15:02:03.96 .net: ＞Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、ってシステムだよな。
まずはここが間違ってるよね。GitではPull-Request方式しかできないと思ってる？

Gitでもマージしてpushの手順で各個人が中央リポジトリに各々修正を追加していくことができる。
SVNと別に変わらんよ。
266 ：デフォルトの名無しさん：2014/02/11(火) 15:06:03.44 .net: >>249
　「Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
　　システムだよな。」
そんなことはまったくない。
別にlinux kernelの開発スタイルでなくてもgitは使えるよ。

このスレで独裁者モデルの話をするのはやめたらどうかね。
OSSの開発モデルの一つでしかなく、gitとは直接関係のない話だ。
267 ：デフォルトの名無しさん：2014/02/11(火) 15:07:09.46 .net: 天才がいれば独裁が一番なのは当たり前
でも天才自体少ない上に、万人に都合の良い天才なんてそうそういないから困るんだよね
すると多数決的な体制にならざろうえない
268 ：デフォルトの名無しさん：2014/02/11(火) 15:15:56.88 .net: きちんとした独裁者モデルを構築したいんだけど
gitだとちょっと難しいんだよね
269 ：デフォルトの名無しさん：2014/02/11(火) 15:22:22.48 .net: UNIX板で遊ぶのに飽きてこっちに来たのか
270 ：デフォルトの名無しさん：2014/02/11(火) 16:42:26.54 .net: > 天才がいれば独裁が一番なのは当たり前

それは違う。どんな天才でも大量のコードを
一人でこなせるわけがない。
ジェバンニじゃないんだからｗ

独裁が一番なのは、小さなプロジェクトにおいての話。
271 ：デフォルトの名無しさん：2014/02/11(火) 16:51:01.84 .net: >>270
なんで独裁者が一人でコード書くの？
コードを書かせないと独裁にならないでしょ。
ちょっと認識がずれてるみたいだけど大丈夫？
272 ：デフォルトの名無しさん：2014/02/11(火) 17:00:48.88 .net: 船頭多くして船山に登るっていうことわざがあるくらい昔から意思決定の
人間は少ないほうがいいって事が言われてるのに。
273 ：デフォルトの名無しさん：2014/02/11(火) 17:13:42.10 .net: >>271
誰も一人で書くとは言ってないよ。
こなせないといったの。
レビューをこなせないと言ったんだよ。

でもどうやら君はコードを書かせれば、
それでやれると思ってるみたいねｗ
274 ：デフォルトの名無しさん：2014/02/11(火) 17:21:22.63 .net: >>273
Linusの独裁モデルがどんなものか
ちょっと勉強してきたほうがいいよ？
275 ：デフォルトの名無しさん：2014/02/11(火) 17:22:34.30 .net: >>274
調べてきた結果、俺の言ってることに
何も問題ないことがわかったよ。
276 ：デフォルトの名無しさん：2014/02/11(火) 17:22:51.97 .net: Linusはもちろんコードを全部書いてるわけでもないし、
全部のレビューをLinus一人でやってるわけでもない
しかし独裁と言われている。
277 ：デフォルトの名無しさん：2014/02/11(火) 17:24:52.55 .net: >>275
ちゃんと理解してたら>>270みたいなことは言わないでしょう。
だめね。やりなおし。
278 ：デフォルトの名無しさん：2014/02/11(火) 17:26:01.35 .net: >>277
いや、理解して言ってるよ。
違うっていうのなら、
ちゃんと君が説明したら？
279 ：デフォルトの名無しさん：2014/02/11(火) 17:28:02.42 .net: >>278
>>276に書いたとおり、独裁モデルっていうのは独裁者が全部レビューしなくても成り立つの。
280 ：デフォルトの名無しさん：2014/02/11(火) 17:29:38.86 .net: そもそもLinusのやり方は独裁じゃないから
論点がずれてる。

今は独裁の話をしている。
281 ：デフォルトの名無しさん：2014/02/11(火) 17:30:29.84 .net: この「独裁」の話をしている。

249 名前：デフォルトの名無しさん[sage] 投稿日：2014/02/11(火) 05:11:32.98
Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
システムだよな。
282 ：デフォルトの名無しさん：2014/02/11(火) 17:36:05.15 .net: 前提が違うｗアホか逃げるなｗ
Gitの独裁モデルと言えば普通Linux kernelの独裁モデルだろｗ
283 ：デフォルトの名無しさん：2014/02/11(火) 17:41:48.07 .net: 一体誰がLinuxの独裁モデルの話を始めたんだ？
どう見てもあとから言い出しただろ。
284 ：デフォルトの名無しさん：2014/02/11(火) 17:42:00.94 .net: >>263
結局まともな運用しようとしたら、集中型でってことなのか...
ローカルコミットさえサポートしてくれれば svn で充分だな。
285 ：デフォルトの名無しさん：2014/02/11(火) 17:43:43.43 .net: svnがgitと同じになれば、svnで十分だな。
286 ：デフォルトの名無しさん：2014/02/11(火) 17:44:36.68 .net: ローカルコミットがあったらそれは分散型だろ
287 ：デフォルトの名無しさん：2014/02/11(火) 18:27:49.57 .net: >>283
gitに限らず、普通に独裁モデルと言えば
Linusがやってるモデルを指すのが一般的よ
288 ：デフォルトの名無しさん：2014/02/11(火) 18:28:42.32 .net: >>286
なにそれこわい
cvsも分散モデルになれるってこと
289 ：デフォルトの名無しさん：2014/02/11(火) 19:07:48.58 .net: あほか
290 ：デフォルトの名無しさん：2014/02/11(火) 19:19:22.46 .net: >>284
いや、リリース用のプロダクトは一つに収斂されるから中央のようなものが
あると都合がいいってだけ。コミュニケーションパスが太ければ、次のは
○○さんの所に集めてそれを使いましょうってことも出来る。

まあ、少なくともsvnのあのマージの苦行に戻るくらいなら多少難有りでも
gitを使いますよ。
291 ：デフォルトの名無しさん：2014/02/11(火) 19:24:29.28 .net: gitのシステムに文句を言うのではなく
git導入を決意した上司などに文句を言うべき
292 ：デフォルトの名無しさん：2014/02/11(火) 19:29:41.56 .net: (優しい)独裁者モデルというのは、適切なリーダーシップが無ければプロジェクトは成功しないという意味だぞ
toolで制限をかける方法は、平等で民主的に見えるが、いずれ破綻する
293 ：デフォルトの名無しさん：2014/02/11(火) 19:32:18.62 .net: >>292
逆だろ
toolで制限かけないといずれ破綻する
294 ：デフォルトの名無しさん：2014/02/11(火) 19:36:35.49 .net: toolで制限かけるしかコントロールできないなら、何やっても無駄
295 ：デフォルトの名無しさん：2014/02/11(火) 23:59:46.12 .net: >>249
そうだよ
Gitみたいな分散型をSubversionの上位概念みたいに言ってる、はてなの連中とかウザいって前から思ってた
296 ：デフォルトの名無しさん：2014/02/12(水) 00:16:34.50 .net: まだいたのかキチガイ
297 ：デフォルトの名無しさん：2014/02/12(水) 00:19:17.86 .net: だからgitに文句言うのでなくgitを採用決定した上司に文句言え
298 ：デフォルトの名無しさん：2014/02/12(水) 00:26:44.77 .net: OSS開発には向いてると思うなのGi
299 ：デフォルトの名無しさん：2014/02/12(水) 02:01:12.59 .net: gitの分散型なんてどうでもいいわ。実際の所、分散開発なんてしねえし。
gitが重要なのは分散型ではなく小さいコミットの積み重ねで開発が可能というところ。

そのための機能である
・ブランチの作成が高速。
・コミットを後から修正できる。
・ブランチの中の一部のコミットを抜き出せる。
・ブランチの起点コミットを移動できる。
・自分の開発中の汚いブランチを他人に見せなくて済む
・バグが発生したコミットを探索できる。
などの機能がある所。

誰でも経験あると思うが開発してコミットした後に
「あ、忘れてたみたいな」修正を直したり、
作ってる最中で、この部分だけ先にリリースしたい。
ってのを出来るのがいいんだよ。

gitはソースコード管理ツールじゃねぇ。
開発とリリースのためのツールだ。
300 ：デフォルトの名無しさん：2014/02/12(水) 02:12:10.43 .net: お前がそう思うんならそうなんだろう（ry
301 ：デフォルトの名無しさん：2014/02/12(水) 02:13:37.12 .net: 反論がないのならそうなんだろうな。
302 ：デフォルトの名無しさん：2014/02/12(水) 02:50:44.58 .net: GitやMercurialのような分散管理が向く場合もあれば、Subversionのような中央管理が向く場合もある
303 ：デフォルトの名無しさん：2014/02/12(水) 04:06:45.55 .net: いや、管理だけでなく開発のことも考えろよ。
Subversionでどうやって間違ったコミットの修正とか
大きな開発を小さなコミットに分割とかするんだよ。

ソースコードを中央に上げる前の
手元の開発作業の話だよ。
304 ：デフォルトの名無しさん：2014/02/12(水) 04:35:40.67 .net: 馬鹿には無理
305 ：デフォルトの名無しさん：2014/02/12(水) 05:44:31.87 .net: ソーシャルゲーム，ボードゲーム，ファミコンまで!?　Global Game Jam 2014参加レポート：レポート｜gihyo.jp … 技術評論社
http://gihyo.jp/news/report/2014/02/0601?page=3&ard=1392151422
> 今回，メンバーのプログラマ全員がGitを使ってソースコードを管理していたのですが

git人気すぎだんろ
306 ：デフォルトの名無しさん：2014/02/12(水) 08:17:47.91 .net: Windowsでgitも日本語ファイル名使えるようになったみたいだけど
GUIはどれがお勧め？
307 ：デフォルトの名無しさん：2014/02/12(水) 08:20:31.76 .net: CUIと同じくらい軽いGUIクライアントってないの？
308 ：デフォルトの名無しさん：2014/02/12(水) 09:02:56.10 .net: SourceTreeでいいだろ
309 ：デフォルトの名無しさん：2014/02/12(水) 09:04:06.19 .net: そのSourceTreeが重いんだよ
なんかしらんが過去データか何かに
アクセスしすぎ
310 ：デフォルトの名無しさん：2014/02/12(水) 09:34:10.15 .net: >>307
そんな軽いツールキット自体がないだろ。gitに限らず。PCの性能によっては無視できるだろうけど、それはあなたが鈍感である必要がある。

>>299
cvsやsvnの時代から、リポジトリを持ち出せるようにする追加のソフトあったろ。そういう需要があったと言う事。
311 ：デフォルトの名無しさん：2014/02/12(水) 09:36:32.03 .net: >>308
いいよね、SourceTree。
ちなみにbitbucketも最高。
312 ：デフォルトの名無しさん：2014/02/12(水) 11:09:54.29 .net: gitはmercurialと比べても履歴を修正出来過ぎて、余計な混乱を招く
高機能が常に低機能に勝るわけじゃない
313 ：デフォルトの名無しさん：2014/02/12(水) 11:12:50.74 .net: > 履歴を修正出来過ぎて
え？出来・・・すぎ・・・？

じゃあ、ちょうど良い程度の
履歴修正機能もあるのかよ？

修正できるならば、全てを修正できるのは
当たりまえだろ？

一体どの程度の履歴修正機能がほしいんだ？
なんの履歴修正機能が欲しくて、どの修正機能は
つけたらダメだというのだ？それを具体的にいいなよ。
でないと、無知が叫んでるだけだって思っちゃうよ？
314 ：デフォルトの名無しさん：2014/02/12(水) 11:21:00.88 .net: >>312
うちはポリシーで対応してるが、できないって方がゴネたり誤魔化すやついなくて良いかもな。
リポジトリの設定で変えられるくらいなら、高性能もいいな。
315 ：デフォルトの名無しさん：2014/02/12(水) 11:34:58.55 .net: 普通、共有リポジトリはdenyNonFastforwardsとdenyDeletesを設定して
履歴の巻き戻し禁止にするから
混乱なんてしない
316 ：デフォルトの名無しさん：2014/02/12(水) 11:41:11.18 .net: だから”ソースコードの管理”ではなく
ローカルで一人でやってる開発作業が
やりやすくなるんだよ。

中央にアップする前に、区切り区切りで
ローカルでコミットしていって、
問題があれば修正できる。一部分だけ
先に中央にアップしたりも出来る。

ソースコードの管理なんて考えているから
gitを理解できないんだよ。
317 ：デフォルトの名無しさん：2014/02/12(水) 11:48:56.23 .net: >>314
ゴネたり誤魔化す奴のために機能を削れってか？
糞だな。
確かにそういう環境ならgit使わなくていいよ
318 ：デフォルトの名無しさん：2014/02/12(水) 12:00:16.05 .net: >>317
リーダーとかマネージャーやるようになったら、そういう苦労もわかるようになるよ
319 ：デフォルトの名無しさん：2014/02/12(水) 12:03:21.74 .net: そこまで考えてクソだと思うなら使わなきゃいいだけなのに
いったいどうしたいんだろう
320 ：デフォルトの名無しさん：2014/02/12(水) 12:11:30.31 .net: 馬鹿には無理
321 ：デフォルトの名無しさん：2014/02/12(水) 12:35:12.28 .net: >>318
まずは、誤魔化したりゴネたりする部下の態度を改める努力はしたのか？
それが面倒くらいだけなんだろ？
その面倒を避けるためにgitという他に余りあるメリットを切り捨てるという愚策。
つまり本質的なところでお前はマネージャーとしての苦労を放棄してるんだよ。
322 ：デフォルトの名無しさん：2014/02/12(水) 12:58:54.22 .net: リーダーとかマネージャ側の都合でGit使えないとか情けなさすぎて涙が出る
323 ：デフォルトの名無しさん：2014/02/12(水) 13:02:24.34 .net: 折衷案としては
「履歴書換申請書」（専門部署による決裁）
かなｗ
324 ：デフォルトの名無しさん：2014/02/12(水) 13:26:37.62 .net: >>321
いや、想像だから。うちはポリシーで対応してるって書いてる。
まあ、誤魔化しとかチェックしないとわからないけど。
325 ：デフォルトの名無しさん：2014/02/12(水) 13:29:32.60 .net: 共有リポジトリの改変許可は>>323のレベルの非常事態対応だけでいい
好き勝手やっていいのはローカルリポジトリだけだ
共有リポジトリとローカルリポジトリに明確な線引きをして
ローカルリポジトリ側で好き勝手やれるのがGitのメリット
326 ：デフォルトの名無しさん：2014/02/12(水) 13:32:20.21 .net: >>324
共有リポジトリへの直接ログインを制限してさらに>>315の設定してあれば、
誤魔化すとかできないだろ？
327 ：デフォルトの名無しさん：2014/02/12(水) 14:00:22.11 .net: >>326
それは俺が>>314で言ってること。
高機能と低機能の比較の話で、gitがって話ではない。
328 ：デフォルトの名無しさん：2014/02/12(水) 15:17:51.75 .net: あ、話をまとめるとだな。
「subversion」 = 「gitのリモートリポジトリ」
こういうことだよ。

subversionでできることはgitのリモートリポジトリでもできるので
リーダーとかマネージャーとかマージする時にチェックが必要とか
そういう問題については解決だ。

で、重要な違いはここから

「gitのローカルリポジトリ」　これはsubversionには無い。
subversionではローカルで作業している間は昔ながらの
ファイルコピーでバックアップ（笑）をしていなきゃならないし
作業中の特定の地点のコードに戻すのは大変だが、
gitではリモートリポジトリに加えて、ローカルにも
個人専用のリポジトリがあるので開発作業が格段に楽になる。
329 ：デフォルトの名無しさん：2014/02/12(水) 15:43:45.82 .net: robocopy使えよ捗るぞ
好きなタイミングで突っ込めるし何よりわかりやすい
330 ：デフォルトの名無しさん：2014/02/12(水) 15:44:38.64 .net: robocopyじゃ捗りません。
どれだけ低機能で満足してるんだよｗ
331 ：デフォルトの名無しさん：2014/02/12(水) 15:45:58.04 .net: 結局アレだ、subversionをファイル倉庫として
バックアップ機能としてしか見ていないから
コミットをマージして開発する流れが理解できんのだ。
332 ：デフォルトの名無しさん：2014/02/12(水) 15:51:00.22 .net: むしろそういう旧態然の人が居てくれるお陰で
ご飯を食べるチャンスが増える
333 ：デフォルトの名無しさん：2014/02/12(水) 17:17:26.77 .net: robocopyみたいなツールじゃ特定地点に戻したりとかしかできないもんな。

Gitなら特定地点から現在までのコードの差分を機能別に分類。
分類した差分を任意の組み合わせで適用して試すとか出来るからなあ。
そして必要な差分だけを一つのコミットとして共有リポジトリにpush。
残りの差分はまたローカルにいじくり回す作業を続ける。
こんなのを手作業でやるのは気が遠くなるけどGitなら簡単にできる。
334 ：デフォルトの名無しさん：2014/02/12(水) 17:20:34.88 .net: git でリモートブランチとのアクセスが生じるのって push と pull 以外にあるかしら？
335 ：デフォルトの名無しさん：2014/02/12(水) 17:29:04.93 .net: ローカルとリモートのリポジトリ間で情報をやりとりするのはpushとfetchだな
pullはfetch+mergeでしかない
後はcloneで丸ごとリモートリポジトリをローカルにコピーとか
ls-remoteでリモートリポジトリを参照するとか
336 ：デフォルトの名無しさん：2014/02/12(水) 17:35:56.45 .net: >>335
ありがとう。
ls-remote を知らなかったよ。peek-remote とか色々あるんだな・・・
337 ：デフォルトの名無しさん：2014/02/12(水) 21:44:27.44 .net: repoA　　　repoB
リモート　　ローカル
俺が指摘したのはこの間をrobocopy使えつー話なのに
robocopyでバックアップ管理だとしかおもえなかったんだね

やはり馬鹿には無理だね(笑)
338 ：デフォルトの名無しさん：2014/02/12(水) 21:46:59.74 .net: そう。無理無理。わかったよ天才だ君は。
339 ：デフォルトの名無しさん：2014/02/12(水) 22:14:40.24 .net: >>337
なにそれ？ローカルが一つなの？
340 ：デフォルトの名無しさん：2014/02/12(水) 22:16:54.79 .net: svn使ってるなら、git-svnでかなりの事が出来るのに。
まあ、オレの周りでも禁止してるわけじゃないのに頑なに使わずにコミットミスや
コミット漏れを続けてるのがいるけどね。
341 ：デフォルトの名無しさん：2014/02/12(水) 22:34:59.03 .net: commitしてpushまでしちゃったら
もう取り返しはつかないよね？

つくかもしれないけど
下手にごちゃごちゃやるよりは
忘れてもっかいcommitすべきだよね
342 ：デフォルトの名無しさん：2014/02/12(水) 22:35:31.22 .net: それは使わないんじゃなくて、使えないんだろ。
343 ：デフォルトの名無しさん：2014/02/12(水) 22:41:16.96 .net: git-cvs は便利だね
344 ：デフォルトの名無しさん：2014/02/12(水) 22:58:42.71 .net: >>337
馬鹿には無理wwwwwwwwｗｗｗｗ
345 ：デフォルトの名無しさん：2014/02/12(水) 23:27:27.46 .net: robocopyは便利だな
というかrsyncのコマンド体系が分かりづらすぎる
346 ：デフォルトの名無しさん：2014/02/13(木) 00:08:11.05 .net: >>337
それで何がしたいの？
347 ：デフォルトの名無しさん：2014/02/13(木) 00:09:58.47 .net: アンチって何でわざわざ自分から嫌いなものに関わろうとするんだろうね、よく分からない
348 ：デフォルトの名無しさん：2014/02/13(木) 00:46:03.94 .net: rebase するときって一つ前のコミット ID を指定するけど、
一つ前のコミットが存在しない初回のコミットって内容の修正は出来ないのかな。
349 ：デフォルトの名無しさん：2014/02/13(木) 00:53:59.26 .net: rebaseの引数にコミットIDなんか書いたこと無いなぁｗ
350 ：デフォルトの名無しさん：2014/02/13(木) 00:59:46.37 .net: rebase -iを使うときは書き換え始める位置のひとつ前のコミットIDを指定するかな
351 ：デフォルトの名無しさん：2014/02/13(木) 01:02:21.03 .net: 質問の意味がよく分からない
図で説明してくれ
352 ：デフォルトの名無しさん：2014/02/13(木) 01:05:00.67 .net: え？一つ前ならHEAD^じゃん？
353 ：デフォルトの名無しさん：2014/02/13(木) 01:11:03.20 .net: イニシャルコミットの一つ前のコミットが存在しないから
イニシャルコミットは書き換え出来ないってことだろ
354 ：デフォルトの名無しさん：2014/02/13(木) 01:13:24.26 .net: git init直後の最初のコミットは空にするようにしてる
355 ：デフォルトの名無しさん：2014/02/13(木) 01:19:58.57 .net: 空のコミットってどうやるん？
356 ：デフォルトの名無しさん：2014/02/13(木) 01:23:04.70 .net: git commit --allow-empty
357 ：デフォルトの名無しさん：2014/02/13(木) 02:01:03.09 .net: お、さんきゅー
358 ：デフォルトの名無しさん：2014/02/13(木) 02:02:02.05 .net: >>348
最初のコミットの書き換えはメンドクサイことすればできるよ
最初のコミットからブランチを作ってそれをcommit --amendで書き換え
(この時点で起点を共有しないブランチがリポジトリに存在することになる)
その後もとのブランチに戻って、書き換えた最初のコミットのブランチへrebaseする
359 ：デフォルトの名無しさん：2014/02/13(木) 02:22:14.50 .net: はぁ？ git rebase -i -root これだけじゃん。
何が面倒くさいのか。
360 ：デフォルトの名無しさん：2014/02/13(木) 02:47:35.96 .net: >>359
うちのgitにはそんなオプションないな
バージョンいくつよ？
361 ：デフォルトの名無しさん：2014/02/13(木) 02:52:49.96 .net: Git - git-rebase Documentation
http://git-scm.com/docs/git-rebase
> --root
> Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>.
362 ：デフォルトの名無しさん：2014/02/13(木) 02:54:45.78 .net: 1.7.xだとgit rebase -i --rootもダメだ
363 ：デフォルトの名無しさん：2014/02/13(木) 02:55:26.77 .net: ああ、1.7.12から使えるようになったらしい
364 ：デフォルトの名無しさん：2014/02/13(木) 02:55:44.94 .net: gitは最新版を使った方がいい。
365 ：デフォルトの名無しさん：2014/02/13(木) 03:03:25.78 .net: rebase: learn to rebase root commit ・ 190f532 ・ git/git ・ GitHub
https://github.com/git/git/commit/190f53232d1e92a57843df90e889bcfea39620d3
> Teach git-rebase a new option --root
366 ：デフォルトの名無しさん：2014/02/13(木) 03:06:14.41 .net: debian squeezeだとbackportsでも1.7.10が最新なんだよなあ
そろそろ新しくするか
367 ：デフォルトの名無しさん：2014/02/13(木) 03:14:09.08 .net: debianとかねーわ
368 ：デフォルトの名無しさん：2014/02/13(木) 03:14:32.42 .net: コンパイルして入れればいいのに。
gitは仕組み的に、ファイルにアクセスして
ネットワーク通信するだけだから簡単にコンパイルできるよ。
369 ：デフォルトの名無しさん：2014/02/13(木) 03:14:32.86 .net: >>365
そのへんのバージョンだと-i --rootじゃダメで、--ontoを指定しないと叱られる
370 ：デフォルトの名無しさん：2014/02/13(木) 08:00:01.28 .net: >>368
> ファイルにアクセスしてネットワーク通信するだけ

そんな言い方したらほとんどのソフトが当てはまるわけだが (w
371 ：デフォルトの名無しさん：2014/02/13(木) 08:39:06.72 .net: 数百を超えるソフト使ってるのに、いちいち手動で入れてられんわ
372 ：デフォルトの名無しさん：2014/02/13(木) 08:47:43.84 .net: 必要な物だけ手動で入れればいいのでは？
373 ：デフォルトの名無しさん：2014/02/13(木) 09:00:12.35 .net: お、新しいバージョンだと最初のコミットもいじれるのか
374 ：デフォルトの名無しさん：2014/02/13(木) 14:21:01.59 .net: squeezeなんてもうすぐeolだぞ
375 ：デフォルトの名無しさん：2014/02/13(木) 17:31:20.08 .net: filter-branchって
既に
・master
・develop
・feature/hoge
ってブランチがリモートにあったら
git branch -t -b xxx origin/xxx
って手元に全部持ってきてから
git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch keshitai.txt' -- --all
をしてから全部をpush -fする必要がある？
376 ：デフォルトの名無しさん：2014/02/13(木) 18:02:11.12 .net: >>372
じゃあgitは不要だ。
377 ：デフォルトの名無しさん：2014/02/13(木) 23:47:25.44 .net: 最新安定バージョンのwheezyでも1.7.10なんだけどな
378 ：デフォルトの名無しさん：2014/02/13(木) 23:49:44.46 .net: 無駄に用心深いdebianじゃどうしようもない、捨てろ
379 ：デフォルトの名無しさん：2014/02/14(金) 00:06:06.24 .net: backportsに1.8.5.3あるじゃん
380 ：デフォルトの名無しさん：2014/02/14(金) 00:16:15.53 .net: >>377
フリーズしてから1年以上立つんじゃないか。
安定版は機能追加しないぞ?
381 ：デフォルトの名無しさん：2014/02/14(金) 05:41:16.11 .net: tortoiseGit1.8.7使っているんだけど、一度コードを変更してから前の状態に戻したら大抵は
変更無しとみなしてくれるんだけど、ちょくちょく変更ありのままになってどうしようもなくなる。
これってどうやったら巻き戻せるの？checkoutしてもresetしてもrevertしても戻せない。
結局面倒になって全部消してcloneしなおす感じになっているんだけどなんか納得いかないんだよな。
Subversionだとrevertするか一度消して取りなおせばokだったけどどうも思う様にいかん・・・。
382 ：デフォルトの名無しさん：2014/02/14(金) 06:09:27.03 .net: 馬鹿には無理
383 ：デフォルトの名無しさん：2014/02/14(金) 06:20:22.73 .net: デスマおつかれさまです。
さっさと寝たら？
384 ：デフォルトの名無しさん：2014/02/14(金) 11:06:14.85 .net: git config core.filemode false
git config core.symlinks false

ローカルでの変更全破棄
git checkout -- *
面倒なことが起きてる場合
git reset --hard origin/upstream_worktree
385 ：デフォルトの名無しさん：2014/02/14(金) 13:59:33.24 .net: >>384
ダメだった・・・
386 ：デフォルトの名無しさん：2014/02/14(金) 19:26:59.57 .net: コミットの打ち消しってなにをするんだろう
どうなるのか実験するの怖い
387 ：デフォルトの名無しさん：2014/02/14(金) 19:54:17.77 .net: revertは、過去のコミットで追加した部分を削除する、新しいコミットを作るだけだよ
あまり高度なことをやってるわけじゃないから
revertしようとするコミットで追加した部分が既に変更されてたりするとコンフリクトする
その場合は手作業でコンフリクト解消しないといけない
388 ：デフォルトの名無しさん：2014/02/14(金) 22:52:05.12 .net: git って差分じゃないのによくマージとかできるなと思う。
389 ：デフォルトの名無しさん：2014/02/14(金) 23:02:10.42 .net: gitは圧縮されたスナップショットだがsvnと違ってブランチ切りで大量のコピーは生み出さない
390 ：デフォルトの名無しさん：2014/02/14(金) 23:02:48.56 .net: メインのブランチがある。
そのブランチからの派生が二つあって
それぞれブランチAとブランチB

ブランチAは正しく作られテストもOK
ブランチBも正しく作られテストもOK

この二つのブランチをマージしてコンフリクトも起きないが
マージされたブランチにバグが発生するってこと起こりえるよな？

なんでみんなそんなほいほいマージできるんだ？
391 ：デフォルトの名無しさん：2014/02/14(金) 23:03:07.76 .net: 2つのファイルから差分情報を作るのと、
1つのファイルと差分情報からもう1つのファイルを再現するのと、
難度に違いがあるの？
392 ：デフォルトの名無しさん：2014/02/14(金) 23:06:34.35 .net: >>390
そのためにレグレッションテストを用意しておくんじゃね？
ほいほいマージっていうけどなんの検証も保証も無しにほいほいやってる人はよっぽどの自信家なんだろう。
393 ：デフォルトの名無しさん：2014/02/14(金) 23:07:24.76 .net: プルリクエストをマージする権限のある人がちゃんと検証するもんじゃないの？
394 ：デフォルトの名無しさん：2014/02/14(金) 23:08:23.67 .net: プルリクエストって・・なんで github 前提なんだよ
395 ：デフォルトの名無しさん：2014/02/14(金) 23:08:44.65 .net: 複数人で開発してる場合にはどちみちマージしなけりゃいけないんだから
それを手作業でやるかツールでやるかの違いにしか過ぎない
396 ：デフォルトの名無しさん：2014/02/14(金) 23:53:29.96 .net: マージかよ
397 ：デフォルトの名無しさん：2014/02/15(土) 00:19:15.38 .net: >>389
svnもコピーを作ってるわけじゃないぞ。ブランチ切っても変更したやつだけが
格納される。ただローカルに落とすときに実体としてのファイルが必要になる。
svn copyとか処理自体はgitのブランチと同じですぐに終わる。
398 ：デフォルトの名無しさん：2014/02/15(土) 00:21:11.45 .net: gitのブランチ切りはすぐ終わるという謳い文句は一体何だったのか
399 ：デフォルトの名無しさん：2014/02/15(土) 00:27:19.10 .net: Gitのブランチ切りは管理してるファイルとか一切変更しないからマジはやいよ
400 ：デフォルトの名無しさん：2014/02/15(土) 00:54:23.16 .net: >>398
ブランチ切りは速いよ。切り替えは遅いこともある
401 ：デフォルトの名無しさん：2014/02/15(土) 01:07:59.97 .net: 簡単に切れちゃうからこんどは使い終わったブランチを消すべし消さないべし論争が
402 ：デフォルトの名無しさん：2014/02/15(土) 02:32:22.58 .net: 昔みたいに安定版と開発版みたいな2本のラインで無理なく開発出来るくらいの
開発スピードだったらsvnでも良かったんだけど、今だと無駄に並行開発して、
リリースもまちまちだったりするからsvnだと取り回しがしんどいって部分も
結構あるからなぁ。
403 ：デフォルトの名無しさん：2014/02/15(土) 12:07:43.91 .net: 　　↓　　↓　　↓　　↓　　↓　　↓
http://kohada.2ch.net/test/read.cgi/prog/1190866177/816
404 ：デフォルトの名無しさん：2014/02/15(土) 23:18:20.85 .net: >>401
保守するなら残す。しないなら、する必要ないなら削除する。
それがgitのブランチ運用じゃん？
マージ済みとかで開発の終わったブランチを残す理由って何だろ。
405 ：デフォルトの名無しさん：2014/02/16(日) 00:52:30.25 .net: >>404
テンポラ
406 ：デフォルトの名無しさん：2014/02/16(日) 02:08:55.31 .net: >>404
マージの仕方にもよると思うけど試行錯誤の跡が見えた方が履歴を追う時に
良いというのは考えられるけど・・・大抵は古い作業データなんぞ見ても意味ないし
殆ど理由は無いと思われ。なかなか物を捨てられずに整理できない人と同じじゃない？
407 ：デフォルトの名無しさん：2014/02/16(日) 02:53:00.67 .net: 隠し状態に出来れば一番いいんだけどな
そういう痒いところにはなかなか手が届かないな
408 ：デフォルトの名無しさん：2014/02/16(日) 03:15:36.94 .net: どこかに適当なリポジトリ作っといてpushすればいい
それで手元からは消す
409 ：デフォルトの名無しさん：2014/02/16(日) 03:51:37.16 .net: 人間は消してもいい、という判断が適切にできるもんじゃないという思想が
根底にあるんじゃないのGitって。とにかくとにかく過去にやったことは極力
追えるようにしておきたい、というのがデフォ。

自分一人でやってることならそれでいいんだろうけどさ、多人数でやる以上
絶対はない、必ずさかのぼれるようにしておきたいという思想があるんだと思う。
410 ：デフォルトの名無しさん：2014/02/16(日) 08:45:19.90 .net: git svn cloneで、svnの同一階層のディレクトリから
一部のディレクトリについてだけcloneすることってできませんか?
たとえばsvn側が以下のようなディレクトリ構成だとして
DirAとDirBについての履歴だけいっしょにcloneしたい状況です。

　Dir
　 |-DirA
　 |-DirB
　 `-DirC

git svn clone Dirしてしまうと
不要なDirC含めてすべての履歴がクローンされますけど
DirCの差分は不要な場合、どうしたらいいでしょう?
411 ：デフォルトの名無しさん：2014/02/16(日) 10:02:21.18 .net: マージコミットの粒度がすごく荒いとブランチ消したくなくなる
412 ：デフォルトの名無しさん：2014/02/16(日) 11:25:23.06 .net: >>409
うーんどうだろ
gitの場合は過去を改ざんする手段が割と豊富にあるし
その気になったらなんでもさせる気構えなのがイヤだよ
413 ：デフォルトの名無しさん：2014/02/16(日) 12:30:51.95 .net: >>409
それはVCSの存在意義みたいなものだし…

むしろgitは性善説に則って人間側の自由を重んじている感があるけどなあ
VCSの中でもgitは何でも出来ちゃう部類だと思う
414 ：デフォルトの名無しさん：2014/02/16(日) 12:44:28.39 .net: マージするとき XX な時以外は fast-forward するな！とかみたいな
運用フローをプログラムレベルで保証するようなラッパーとかあったらいいのかもね。

github のプルリクエストみたいなのはうまくいってる例じゃないかなあ。
415 ：デフォルトの名無しさん：2014/02/16(日) 13:06:56.02 .net: >>406
バグ修正してる時に、なんでその変更したか読み取るのに必要。BTSと連携してるので特に。
416 ：デフォルトの名無しさん：2014/02/16(日) 19:28:42.49 .net: >>415
それあるね
消されるとわからなくなる
消せないフラグがあるといいのかね
417 ：デフォルトの名無しさん：2014/02/17(月) 00:01:18.89 .net: >>410
cloneしたあとgit filter-branch --subdirectory-filter dirA --prune-empty -- --all
すればdirAだけの(かつdirAをrootとする)履歴に書き換えられる。
もしくはgit filter-branch --index-filter 'git rm --ignore-unmatch -r --cached dirC' --prune-empty -- --all
すればdirCのみ履歴から消すことができる
418 ：デフォルトの名無しさん：2014/02/17(月) 01:48:19.18 .net: >>410
sparse checkout
419 ：デフォルトの名無しさん：2014/02/19(水) 01:20:06.23 .net: 1.9がキター
420 ：デフォルトの名無しさん：2014/02/19(水) 01:22:37.97 .net: ほんまや
421 ：デフォルトの名無しさん：2014/02/19(水) 11:06:52.13 .net: >>312
元々、mercurial使ってからgit使い始めたけど、ほんまこれ
gitを理解してる上で、これやろうならいいけど
あんま理解してない状態で、あれやりたい！とりあえずググろう、みたいなスタンスで使って泥沼に嵌ってる人をたまにみかける
422 ：デフォルトの名無しさん：2014/02/19(水) 14:32:01.28 .net: 理解さえしてしまえば、かなり大胆にいろいろ自由にやっても破綻しない
そして、構造自体は比較的簡単なので理解するのはそれほど難しくない
423 ：デフォルトの名無しさん：2014/02/19(水) 16:30:52.77 .net: GithubってGithub自身のソースは公開してないのかよ！
424 ：デフォルトの名無しさん：2014/02/19(水) 19:02:13.55 .net: おまえのものはおれのもの
おれのものはおれのもの
425 ：デフォルトの名無しさん：2014/02/20(木) 20:02:00.54 .net: \\hoge\fuga\bar\.git というサーバーをwindowsでcloneするにはどうすればいいのでしょうか？

httpsやhttpでアクセスできないと思うのですが・・・
426 ：デフォルトの名無しさん：2014/02/20(木) 20:22:02.28 .net: フォルダごとコピー
427 ：デフォルトの名無しさん：2014/02/20(木) 20:47:14.29 .net: >>425
cloneの展開先はローカル限定だけど、展開元はリモートでもローカルでもどっちでもいいぞ
hogeサーバのフォルダをローカルで参照できるんだろ？
ならばローカルからローカルへのcloneで何も問題無いんじゃ？
428 ：デフォルトの名無しさん：2014/02/20(木) 20:48:50.35 .net: ローカルなリポジトリの参照方法を聞いてるのかね
429 ：デフォルトの名無しさん：2014/02/20(木) 20:57:34.67 .net: 試してみたけど、Cygwinなら普通にこんな感じでできるな
git clone //hoge/fuga/bar/.git bar
最後のbarは何でもいい
430 ：425：2014/02/20(木) 21:28:12.14 .net: ありがとうございました。
できました。
431 ：デフォルトの名無しさん：2014/02/20(木) 22:56:33.96 .net: >>426
.gitごと含めてまんまフォルダをコピー
そのあとoriginをコピー先に変更

これとgit cloneって違いはありますか？
こんな方法で使用継続しちゃってもいいのでしょうか・・・
432 ：デフォルトの名無しさん：2014/02/21(金) 15:20:36.94 .net: >>431
違いはある。が実用上問題ない。
433 ：デフォルトの名無しさん：2014/02/21(金) 16:57:45.51 .net: コピー元のOSが違ったら改行コード問題が起きね？
434 ：デフォルトの名無しさん：2014/02/21(金) 17:12:24.91 .net: 件の件はローカルのコピーだろうから問題なさそうな気もするけど
確かに config で設定してる色々なフィルタ処理を考えると clone した方がよさそう
435 ：デフォルトの名無しさん：2014/02/21(金) 17:16:24.84 .net: core.autocrlf=trueの設定に依存してる人はワーキングコピーに変換が反映されてなくて問題になるかもね
まあ俺はWin環境でもソースファイルの改行は原則LFにしてるから問題にならんが
436 ：デフォルトの名無しさん：2014/02/21(金) 17:23:07.89 .net: ああ、でもｗ逆に俺のcore.autocrlf=falseの環境では、
core.autocrlf=trueのワーキングコピーをそのままコピーしてきて、
改行コードCRLFのままファイルを編集コミットpushして、
顰蹙を買う可能性があるのかｗ
437 ：デフォルトの名無しさん：2014/02/22(土) 06:33:44.87 .net: 分散バージョン管理システム「Git 1.9」が公開 | SourceForge.JP Magazine
http://sourceforge.jp/magazine/14/02/17/153000
438 ：デフォルトの名無しさん：2014/02/22(土) 16:51:46.58 .net: git pushでエラーが出るの治った？
439 ：デフォルトの名無しさん：2014/02/22(土) 18:43:15.70 .net: >>438
それはあんたが勉強して
正しい使い方を学ばないとだめだよ。
440 ：デフォルトの名無しさん：2014/02/22(土) 19:45:04.57 .net: バグなんよ

http://orangeclover.hatenablog.com/entry/2014/01/15/215758
https://github.com/msysgit/msysgit/issues/153
441 ：デフォルトの名無しさん：2014/02/22(土) 19:47:04.04 .net: close されてんじゃん
442 ：デフォルトの名無しさん：2014/02/23(日) 00:06:03.98 .net: なんかさ、一生懸命チェックしてこれでよしと思っても
pushした瞬間にキャンセルしたくなるよな

今pushしたのだけ大至急キャンセルするにはどうしたらいいかな
443 ：デフォルトの名無しさん：2014/02/23(日) 00:08:19.35 .net: どういうflowか知らんがpushを戻したくなる状況ってよく分からんな
444 ：デフォルトの名無しさん：2014/02/23(日) 00:10:59.07 .net: revert して、push すればいいじゃん
445 ：デフォルトの名無しさん：2014/02/23(日) 00:13:46.91 .net: コメントの書式微妙に間違ってた！なんてとき差し戻したくなるよな
ローカルリポジトリならそういうのやりたい放題なんだが
446 ：デフォルトの名無しさん：2014/02/23(日) 00:15:11.46 .net: ドジっ子が多いんやな
447 ：デフォルトの名無しさん：2014/02/23(日) 00:21:27.56 .net: 説明文の英語ミスったりとかな・・
git push -f でなかったことにして修正してるんですけどね
448 ：デフォルトの名無しさん：2014/02/23(日) 00:23:51.26 .net: ネイティブすら気にしない英文のミスを日本人は気にし過ぎる
449 ：デフォルトの名無しさん：2014/02/23(日) 00:42:59.76 .net: 立つ鳥後を濁さず的な精神強すぎるんよ
過去を消したりしてまでやる価値あるんか？
450 ：デフォルトの名無しさん：2014/02/23(日) 00:45:21.02 .net: そうはいっても amend みたいなのでちゃちゃっと直す癖ついちゃってるしなぁ
451 ：デフォルトの名無しさん：2014/02/23(日) 01:09:11.40 .net: コメントだけなら、サーバにリモートログインして rebase -i で変更したらいいんじゃね
452 ：デフォルトの名無しさん：2014/02/23(日) 01:33:46.98 .net: その潔癖がクレーマーを生み出す原因なんだけどね
453 ：デフォルトの名無しさん：2014/02/23(日) 01:35:13.51 .net: 飛躍しすぎだ
454 ：デフォルトの名無しさん：2014/02/23(日) 07:21:35.07 .net: おまえらって↓これをチェックしてたりすんの？

github/gitignore ・ GitHub
https://github.com/github/gitignore
455 ：デフォルトの名無しさん：2014/02/23(日) 08:33:09.72 .net: マルチうぜー
http://toro.2ch.net/test/read.cgi/tech/1354608228/859
456 ：デフォルトの名無しさん：2014/02/23(日) 18:06:07.80 .net: >>417, 418
情報ありがとうございました。
反応遅くなってすみません。

最終的には以下のようにしてみました。

DirA, DirB, DirCの3ディレクトリが存在するsvnレポジトリのとある階層から
DirA, DirBのみのGitリポジトリをつくるにあたって、、、

git svn clone --ignore-paths='^(?!DirA/|DirB/)' /path/to/svn_repository...
→　頭に"DirA/"や"DirB/"がこない　パスをignore
git filter-branch --prune-empty
→　DirCに対する変更のみのコミットが空コミットとして入っているので、
　　それらを削除
457 ：デフォルトの名無しさん：2014/02/24(月) 10:40:25.19 .net: fetch面倒くさい
458 ：デフォルトの名無しさん：2014/02/25(火) 00:00:06.34 .net: git-svnでcloneしようとしたとき、
svnのtagsに日本語名ディレクトリが入ってるとエラーになってcloneできないね。
違うバージョンのgit＋git-svnだとできたりするんでしょうか？

■エラー
$git svn clone -s file:///svn
・・・
r419 = 003942a639a3e0617fec085b4365cf150c620762 (refs/remotes/trunk)
Found possible branch point: file:///svn/trunk => file:///svn/tags/日本語, 419
Found branch parent: (refs/remotes/tags/日本語) 003942a639a3e0617fec085b4365cf150c620762
Following parent with do_switch
assertion "svn_uri_is_canonical(child_uri, NULL)" failed: file "/usr/src/packages/subversion/subversion-1.8.5-1/src/subversion-1.8.5/subversion/libsvn_subr/dirent_uri.c", line 1502, function: uri_skip_ancestor
error: git-svn died of signal 6

■バージョン
git version 1.7.9　（cygwin32bit版）
459 ：デフォルトの名無しさん：2014/02/25(火) 05:59:38.49 .net: 具体的なバージョンは忘れたけど
fedora12環境(つまり結構ふるい)では
ふつうにgit svn cloneできてたよ。

※svnのサーバ側もlinux。バージョン等はよく知らない。
460 ：デフォルトの名無しさん：2014/02/25(火) 06:01:45.05 .net: と思ったけど、やっぱ忘れて。
tagsのことは知らない。。。。
461 ：デフォルトの名無しさん：2014/02/26(水) 02:31:49.75 .net: 昨日新宿西口のドトールで隣りの席の奴がGitポケットブックよみながらMacBook
いじってたので横からずっと覗いてた。
かなりなヘボプログラマだった。
462 ：デフォルトの名無しさん：2014/02/26(水) 02:44:56.66 .net: >>461
いいなあ。そんな暇俺も欲しいわ。
463 ：デフォルトの名無しさん：2014/02/26(水) 05:04:02.17 .net: みんな初めはヘボなんだよ
464 ：デフォルトの名無しさん：2014/02/26(水) 05:19:13.36 .net: 知らない人が隣から覗き込んでくるって怖いね
465 ：デフォルトの名無しさん：2014/02/26(水) 08:51:37.68 .net: tigって使ってる？
466 ：デフォルトの名無しさん：2014/02/26(水) 10:05:38.17 .net: >>461
ボウリングだと隣の香具師が下手でも何も思わんが
プログラマだと隣が下手だと気になるよね不思議だぬ
http://www.nicovideo.jp/watch/sm8562641
http://www.nicovideo.jp/watch/sm8642352
467 ：デフォルトの名無しさん：2014/02/26(水) 11:02:07.20 .net: 結局は争いは同じレベルの以下略と同じだろ。
プログラマという同じ土台に乗ってるという
土台のレベルが同じだったとｗ
468 ：デフォルトの名無しさん：2014/02/26(水) 11:21:24.16 .net: あなたがそうなのですねわかりますω
469 ：デフォルトの名無しさん：2014/02/26(水) 12:17:56.64 .net: わざわざレスを付けに出てくる時点で
見下してるはずのレベルの奴とレベルが同じになると
気づかなかったのだろうか？ｗ
470 ：デフォルトの名無しさん：2014/02/26(水) 17:41:22.66 .net: よくできてるな
ttp://www.nicovideo.jp/watch/sm8532540
ttp://www.nicovideo.jp/watch/sm8638032
ttp://www.nicovideo.jp/watch/sm7715276
ttp://www.nicovideo.jp/watch/sm7607897
ttp://www.nicovideo.jp/watch/sm15899101
471 ：デフォルトの名無しさん：2014/02/27(木) 17:47:52.80 .net: githubはもう古い
時代はgitlab
472 ：デフォルトの名無しさん：2014/02/27(木) 20:25:08.17 .net: EUCで保存されてるリポジトリを
ShiftJISに変換してチェックアウトしたいんだけど
やり方を教えれ
473 ：デフォルトの名無しさん：2014/02/27(木) 22:36:55.65 .net: >>472
ワーキングツリーだけ文字コードを変更する方法などない気がするが。
474 ：デフォルトの名無しさん：2014/02/27(木) 22:49:09.96 .net: フックかけて文字コード変更するとかかねえ
475 ：デフォルトの名無しさん：2014/02/27(木) 23:39:15.74 .net: >>472
他の人はEUC-JPのコードで実行。お前はShiftJISで実行
HTMLはEUC-JPなのでShiftJISで実行したお前は文字化け

コンパイルしたら、バイナリにはEUC-JPで格納。
そのソフトをWindowsで動かすときにはEUC-JPをShiftJISに変換して出力するコードが含まれている。
お前はShiftJISでバイナリに格納され、ShiftJISをEUCｰJPだと思ってShiftJISに変換。もちろん文字化け。
476 ：デフォルトの名無しさん：2014/02/27(木) 23:42:51.61 .net: >>472
cleanとsmudgeフィルタを使えばできそうな気がするが実際にやってみたことは無い。
http://git-scm.com/book/ja/ の「7.2 Git のカスタマイズ - Git の属性」の「キーワード展開」のとこに説明がある。
checkout時とcommit時にそれぞれフィルタをかける方法。
477 ：デフォルトの名無しさん：2014/02/28(金) 02:10:00.65 .net: >>476を参考にして下のような感じで>>472が解決できました
どうもありがとうございました

作業フォルダに.gitattributeを作成
*.c filter=txtconv

git --globalでフィルタプロパティを編集
[filter "txtconv"]
smudge = nkf -s
clean = nkf -e
478 ：デフォルトの名無しさん：2014/02/28(金) 02:12:37.12 .net: .gitattributeじゃない.gitattributesだった
479 ：デフォルトの名無しさん：2014/02/28(金) 09:08:24.21 .net: >>477
git diffとかも問題無く使える？
480 ：デフォルトの名無しさん：2014/02/28(金) 12:04:27.32 .net: リポジトリと作業フォルダの文字コードが変わっても、
その文字コードの差異に関してはdiffは反応しなかったです
テキスト内容を編集した分に関してはdiffが反応します
自分が試した感じでは期待通りの動作でした
481 ：デフォルトの名無しさん：2014/02/28(金) 16:06:24.05 .net: もしや、ascii文字だけでそれを試して、わざわざここに書いたのではあるまいな
482 ：デフォルトの名無しさん：2014/02/28(金) 17:21:01.63 .net: >>481
リポジトリと作業コピーの改行コードが違ってても同じtextとして認識してるだろ？
それはgit内部でフィルタを使ってるからなのよ
上で行ってるのはユーザーがその機能を追加してるだけ
お前は知らないなら自分で試せよ
483 ：デフォルトの名無しさん：2014/02/28(金) 17:54:24.34 .net: http://git-scm.com/book/ja/の7章は役に立つノウハウ満載だな
そんな長くもないし一度読んでおくべき
484 ：デフォルトの名無しさん：2014/03/02(日) 16:45:52.76 .net: ローカルで何もしてないのにコンフリクトが起こる糞vcs
CONFLICT (content): Merge conflict in ...
Automatic merge failed; fix conflicts and then commit the result.
485 ：デフォルトの名無しさん：2014/03/02(日) 17:00:21.38 .net: >>484
git mergeとかしない限りコンフリクトなんか起きねーよｗ
なにもしてないのにコンフリクトが起きるわけがない。

起きたらgit statusとかgit logみれば原因ぐらいわかるだろ。
486 ：デフォルトの名無しさん：2014/03/02(日) 18:25:34.50 .net: IT土方屋のこびと

おじいさんがデスマで疲れ果てて寝ていると
小さな妖精さんがコードを朝までに仕上げてくれました
なお git rebase master はおろか
大量の機能を一本糞コミットにまとめたあげく
コンフリクト解消の途中でばっくれた模様
487 ：デフォルトの名無しさん：2014/03/02(日) 18:29:53.05 .net: 途中でバックレてもpushしてなければローカルだけの話だろうし、pushされてても
そんなのはrevertで打ち消しちゃえばいいだけの話だろ？
488 ：デフォルトの名無しさん：2014/03/02(日) 19:10:02.31 .net: >>484はいつもの人なんで真面目に構ってもムダ
489 ：デフォルトの名無しさん：2014/03/02(日) 19:27:08.03 .net: おじいさんはwizardだったので、
git reset --hard HEAD@{6.hour.ago}
して何を逃れましたとさ。
490 ：デフォルトの名無しさん：2014/03/02(日) 21:14:46.68 .net: 現実提示して批判したら>>485や>>488だからなあ
どんだけ馬鹿だらけなんだろうね(笑)
491 ：デフォルトの名無しさん：2014/03/02(日) 21:29:48.92 .net: ageるやつはキチガイ、はっきりわかんだね
492 ：デフォルトの名無しさん：2014/03/02(日) 21:30:32.10 .net: 「何もしてないのに壊れた」とか素人かよ
493 ：デフォルトの名無しさん：2014/03/02(日) 22:21:12.55 .net: >>492
そりゃ素人だよ
494 ：デフォルトの名無しさん：2014/03/02(日) 22:21:40.77 .net: 素人が質問してはいけない空気
495 ：デフォルトの名無しさん：2014/03/02(日) 22:24:20.92 .net: いやあ、素人が質問はいいけど
素人がわけもわからず見当はずれのdisはいかんでしょ
496 ：デフォルトの名無しさん：2014/03/02(日) 22:25:38.07 .net: そもそも質問じゃない件
497 ：デフォルトの名無しさん：2014/03/03(月) 20:58:04.29 .net: >>484\n君は他のを使った方がいいかもね（ニッコリ
498 ：デフォルトの名無しさん：2014/03/04(火) 01:05:39.72 .net: >>497
特定のプロジェクト限定で*仕方なく*使ってるんだよ
わかるかな?

ついでに言えば489の件はとうの昔にバッチに組み込んである
499 ：デフォルトの名無しさん：2014/03/04(火) 01:06:46.25 .net: ほんとなんでキチガイってageるんだろう。
500 ：デフォルトの名無しさん：2014/03/04(火) 01:07:30.01 .net: イミフ
501 ：デフォルトの名無しさん：2014/03/04(火) 01:36:44.93 .net: たぶん489をバッチに書いて
出社時
昼休憩後
帰宅時
に毎回実行してるんでしょ
502 ：デフォルトの名無しさん：2014/03/04(火) 01:38:17.34 .net: そんな馬鹿なことする馬鹿は501くらいだ
503 ：デフォルトの名無しさん：2014/03/04(火) 03:06:10.11 .net: ネタにマジレス…
504 ：デフォルトの名無しさん：2014/03/04(火) 19:25:20.20 .net: 質問です。
今日変更した分の差分を見たいですが、どうすればいいでしょうか？
505 ：デフォルトの名無しさん：2014/03/04(火) 19:41:02.13 .net: git diff HEAD
506 ：デフォルトの名無しさん：2014/03/04(火) 19:51:54.82 .net: もう既にコミット済みなんで何も表示されないです…
とりあえず git log して昨日の最後のコミット番号をコピって
git diff xxxxxxxxxxxx として確認は出来たんですが、
もう少し簡単に見れればと
507 ：デフォルトの名無しさん：2014/03/04(火) 19:58:02.28 .net: git diff -1
508 ：デフォルトの名無しさん：2014/03/04(火) 20:17:12.29 .net: git diff $(git rev-list -n1 --before="1 day ago" master)
509 ：デフォルトの名無しさん：2014/03/04(火) 22:55:53.72 .net: >>506
git diff master@{one.day.ago}
git diff master@{12.hour.ago}
etc
510 ：デフォルトの名無しさん：2014/03/05(水) 00:00:31.98 .net: >>508
遅くなりましたが、まさにこれでした。ありがとうございました。
511 ：デフォルトの名無しさん：2014/03/05(水) 00:02:10.83 .net: >>509
見逃してました…こんなシンプルな書き方があるんですね。勉強になります。
みなさん、ありがとうございました。
512 ：デフォルトの名無しさん：2014/03/05(水) 00:04:14.95 .net: git-flowとgithub-flow以外にメジャーなgitのflowってある？
513 ：デフォルトの名無しさん：2014/03/05(水) 00:18:02.84 .net: カレントブランチであれば
git diff @{yesterday}
とも書けた。これが最短かな。
514 ：デフォルトの名無しさん：2014/03/05(水) 00:37:19.13 .net: 512
ggrks
515 ：デフォルトの名無しさん：2014/03/05(水) 00:38:10.27 .net: >>513
これって過去のカレントブランチになるの？
過去のHEADになるの？
516 ：デフォルトの名無しさん：2014/03/05(水) 00:53:02.93 .net: revisionのデフォルト指定を考慮すると
git diff @{1}
でよかった。しつこくてごめんなさい…

>>515
gitに詳しくないから今一質問の意味するところが分かりません…
517 ：デフォルトの名無しさん：2014/03/05(水) 00:56:29.11 .net: >>516
24時間前にはdevelopブランチをチェックアウトしていたとして、
現在はmasterブランチをチェックアウトしているとすると、
git diff @{yesterday}
は24時間前のdevelopブランチをさすのか、
それとも24時間前のmasterブランチをさすのかどっちだろってことでした。
518 ：デフォルトの名無しさん：2014/03/05(水) 00:58:29.12 .net: >>517
http://evadeflow.com/2011/04/git-diff-yesterday/
を見るに、
git diff @{yesterday}
git diff HEAD@{yesterday}
は等価みたいなのでdevelopブランチをさすみたいですね
519 ：デフォルトの名無しさん：2014/03/05(水) 03:16:08.01 .net: >>517
gitは24時間前にどのブランチをチェックアウトしてたかなんて管理してないと思う。
520 ：デフォルトの名無しさん：2014/03/05(水) 03:18:44.96 .net: >>519
git reflog show HEADしてみるとわかるよ。
521 ：デフォルトの名無しさん：2014/03/05(水) 11:29:53.46 .net: git diff @{tomorrow} が実装されるのはまだ？
これがあれば開発がずいぶんと楽になると思うんだけど。
522 ：デフォルトの名無しさん：2014/03/05(水) 11:39:16.51 .net: $ git merge @{tomorrow}
Already up-to-date.

$ git merge @{tomorrow} --allow-empty
523 ：デフォルトの名無しさん：2014/03/05(水) 11:46:37.58 .net: >>522
バグってますね。
空なワケがない
524 ：デフォルトの名無しさん：2014/03/05(水) 12:14:20.18 .net: git diff @{tomorrow}が実装された瞬間に時間(歴史)の矛盾が生じるので世界が崩壊します…
525 ：デフォルトの名無しさん：2014/03/05(水) 13:02:12.42 .net: 涙の数だけ強くなれるよ
526 ：デフォルトの名無しさん：2014/03/06(木) 11:12:03.25 .net: $ git merge @{tomorrow}
Already up-to-date.
↑
今日という日に勝るものはない (ゲーテ)
今日を大切にｲ㌔とgitは教えてくれている
527 ：デフォルトの名無しさん：2014/03/09(日) 13:19:13.97 .net: 現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/
528 ：デフォルトの名無しさん：2014/03/09(日) 15:31:35.75 .net: >>523
こういう結果になるがよろしいか
http://p.twpl.jp/show/orig/VJ6m2
529 ：デフォルトの名無しさん：2014/03/12(水) 17:47:09.58 ID:k2RSk+O8.net: どうしてgitにはリモートのタグ一覧を見る機能が無いんだろう
530 ：デフォルトの名無しさん：2014/03/12(水) 17:52:25.96 ID:iuIDUWkr.net: >>529
gitはとってきてから何かするってイメージがある。
531 ：デフォルトの名無しさん：2014/03/12(水) 18:06:31.06 ID:hnG5PeUR.net: >>529
ls-remote --tags
532 ：デフォルトの名無しさん：2014/03/13(木) 13:01:30.94 ID:NA+IXwp9.net: >>529
どうしてそう思ったの？
533 ：デフォルトの名無しさん：2014/03/13(木) 16:03:21.67 ID:2QWInfDW.net: まだ公式サイトにも Google code にもないけど 2.0.0 がリリースされたみたい
Git 2.0.0 released
http://sdt.bz/content/article.aspx?ArticleID=68912&page=1
534 ：デフォルトの名無しさん：2014/03/13(木) 16:51:19.90 ID:mqQuWcqA.net: GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
大塚弘記
http://www.amazon.co.jp/gp/product/477416366X/

いよいよ入門書の決定版が出そうだな。
535 ：デフォルトの名無しさん：2014/03/13(木) 17:17:00.80 ID:dvaQTbQU.net: ステマ？
536 ：デフォルトの名無しさん：2014/03/13(木) 19:34:40.75 ID:NA+IXwp9.net: GitとGithubの違いがわからない人か
それほど厚い本でもないし、Git自体の解説にはあまりページを割けないだろ
537 ：デフォルトの名無しさん：2014/03/13(木) 22:53:41.66 ID:1RS5+8h0.net: git init
ls
fileA
git add fileA
ls
gzip filreA.gz

これしたらfileAが残ったまんまになった
touch fileAしてgit addしてコミットしたら直ったけど
538 ：デフォルトの名無しさん：2014/03/13(木) 23:06:56.94 ID:+lIKaSU4.net: >>537
indexにfileAが残ったまんまになるのは当たり前だろう。
indexが何かがわかってないのかな？
539 ：デフォルトの名無しさん：2014/03/13(木) 23:16:40.40 ID:NA+IXwp9.net: >>537
3行目のfileAは2行目のlsの結果なのだろうか？
とうことは5行目のlsの結果は？ファイルが存在しないってこと？
6行目のgzip filreA.gzってなんだ？仮にfileAを圧縮するならgzip fileAだよね？
fileAが残ったままになったというのはlsするとfileAだけ存在するってこと？

リポジトリの状態はgit statusで確認しろ
540 ：デフォルトの名無しさん：2014/03/13(木) 23:29:41.88 ID:1RS5+8h0.net: git init
ls
fileA
git add fileA
gzip fileA
ls
gzip fileA.gz

こうだった
バージョン管理ソフトってあんまり使い始めたからよくわからない
OSSにプッシュして保存する感じで使ってる
541 ：デフォルトの名無しさん：2014/03/13(木) 23:37:38.11 ID:Z7oT29iq.net: 入力と出力はそれとわかるように % とかのプロンプト付けるとか > で出力っぽくするかしてくれ
542 ：デフォルトの名無しさん：2014/03/13(木) 23:38:02.48 ID:+lIKaSU4.net: >>540
それも間違ってると思うぞ。
543 ：デフォルトの名無しさん：2014/03/13(木) 23:44:11.03 ID:NA+IXwp9.net: >>540
7行目は何なんだ？
544 ：デフォルトの名無しさん：2014/03/13(木) 23:50:06.68 ID:1RS5+8h0.net: $git init
$ls
fileA
$git add fileA
$gzip fileA
$ls
fileA.gz

こうでした
545 ：デフォルトの名無しさん：2014/03/13(木) 23:54:44.81 ID:+lIKaSU4.net: >>544
で、何が君にとって予想外だったの？
546 ：デフォルトの名無しさん：2014/03/13(木) 23:59:18.25 ID:1RS5+8h0.net: 予想は何もしてなかったけどキャッシュを削除すればいいと今わかった
それだけでしたｗ
547 ：デフォルトの名無しさん：2014/03/14(金) 00:50:56.65 ID:ClnHzXXo.net: $git add fileA

これをした理由がよくわからんね
548 ：デフォルトの名無しさん：2014/03/14(金) 07:27:00.43 ID:DebDhZgS.net: >>540
質問する時は何がしたいのかも書いて欲しい。
いったんfileAをgitの管理下に置いたけど、それを取り消してfileA.gzをgitで管理したいってこと？

まず、fileA.gzをgitで管理する理由は？普通はfileAを管理すればいい筈だけど。
次に、git addだけしてgit commitしてないのは何故？単にgitが分かってないだけかな。
あとは何がしたいのかにもよるけど、git addを取り消したいの？
それとも、git commitまでしたものを取り消すまたは削除したいの？
多分、根本的にバージョン管理とは何かを学ぶ必要があるね。
549 ：デフォルトの名無しさん：2014/03/14(金) 09:10:27.66 ID:jnh1VUPi.net: まあここにいる人の大半は知っていると思うけど。

gitがsubversionと違うのは、
gitが現実的であるということ。

つまり、プログラミングをしている時に
「あれ」を作ってる最中に
「これ」を先に直しておかなきゃだめじゃん
という状態が発生することを前提にしている。

だから「あれ」を作ってる最中に「これ」だけを
git addし（git addするのはファイルの一部だけも可能）
そしてコミットできる。

「あれ」の最中に違うことが出来るんだよ。
そのための機能として、他にはrebaseがあったり
stashがあったりする。

計画は思ったとおりに行かない。だから後から修正ができるようになっている。
550 ：デフォルトの名無しさん：2014/03/14(金) 09:14:56.37 ID:jnh1VUPi.net: git addっていうのは、「ファイルが完成したので追加します」ではなく
「一つの修正」に含まれる内容にaddするという意味だからね。
「一つの修正」を登録して完了するのがgit commit
551 ：デフォルトの名無しさん：2014/03/14(金) 09:42:22.32 ID:3AXtQvy9.net: >>550
そこにrmが含まれてない理由はよ
552 ：デフォルトの名無しさん：2014/03/14(金) 12:23:40.41 ID:N9inECXp.net: ステージング
553 ：デフォルトの名無しさん：2014/03/14(金) 13:13:12.01 ID:HKnmhhn0.net: >>551
そこにrmが含まれるとか考えた理由を知りたい
554 ：デフォルトの名無しさん：2014/03/14(金) 15:15:54.97 ID:a+Iqcg5c.net: >>547,548
質問者はステージングされたファイルを削除しても
インデックスに残り続ける事を不思議に思った、と言いたいんでしょ
コミットとか操作の意図とかはどうでもいい話だと思うよ
555 ：デフォルトの名無しさん：2014/03/14(金) 19:36:58.50 ID:N9inECXp.net: ワークとステージが別と理解すべし
556 ：デフォルトの名無しさん：2014/03/14(金) 20:03:40.12 ID:ClnHzXXo.net: >>554
実験してるだけってことね
557 ：デフォルトの名無しさん：2014/03/14(金) 20:04:06.07 ID:vrX/dLqF.net: ワーキングステージックス？
558 ：デフォルトの名無しさん：2014/03/14(金) 22:19:20.44 ID:mqmIxcJs.net: >>551
git rm --cachedしたいの？
559 ：デフォルトの名無しさん：2014/03/14(金) 23:29:54.21 ID:jnh1VUPi.net: >>551
rmとはgit rmのことなのか普通のrmなのか。

まあそれはどうでもいいとして、

・ファイルを修正する → その修正内容をgit addする。
という手順がある。これと同じで、

・ファイルを削除する → その修正内容をgit addする。
ということも出来る。削除したのにaddするとは面白いね！

まあ、git addというのが「ファイルの追加」ではなく
「変更点の登録」と考えれば理解できるだろう。

なお、今のgitではファイルを物理的に削除したものをgit addするときには、
-Aオプションが必要だけどgit 2.0から不要になるとのこと。

俺はgit add -uで変更されたファイル（削除含む）を全て登録することが多いんだが。
560 ：デフォルトの名無しさん：2014/03/16(日) 02:34:16.48 ID:ZaDeQqIr.net: >>549の手順を具体的に教えてほしい
ブランチ切ればいいの？
561 ：デフォルトの名無しさん：2014/03/16(日) 03:00:01.91 ID:CihRTndi.net: >>560
いろんなやり方があるんじゃないの？
ワークツリー上の変更の一部だけをコミットしたいなら add -p 使えばいいし
stash saveでワークツリー上の変更を一旦退避してから、別の修正をコミットして、
その後stash popで退避した変更をワークツリーに戻して元の作業に戻るとか
562 ：デフォルトの名無しさん：2014/03/16(日) 10:36:13.48 ID:rHQmp5Mm.net: コミットしてしまう前か、してしまった後かによって違うね。
コミットしておらず、ファイルの一部分のみをコミットしたいのなら
git add -pだろう。

コミットしてしまった後で、コミットの順番を
変えるだけで済むならrebaseすればいいし、
そうでないのなら、どういう状態でどういうことをしたいかで
いろいろやりかたはあるだろう。

ブランチは作ってもいいけど、小さいなら作る必要はない。
大きな修正がある場合は、過去の何処かでブランチ切って
そっちにマージやcherry-pickしていったほうが早いかもしれない。
563 ：デフォルトの名無しさん：2014/03/16(日) 16:48:29.50 ID:CihRTndi.net: またGitの解説本だ

http://www.amazon.co.jp/dp/4863541465
開発効率をUPする Git逆引き入門
564 ：デフォルトの名無しさん：2014/03/16(日) 17:13:12.82 ID:EOaK1FG8.net: 何冊も解説本が必要な時点で終わっとる
565 ：デフォルトの名無しさん：2014/03/16(日) 17:17:40.87 ID:rHQmp5Mm.net: 何冊も解説本が販売されると、
なんで終わることになるんですか？
多分C言語なんか、一番解説本が多いと思ういますけど？
566 ：デフォルトの名無しさん：2014/03/16(日) 17:21:37.93 ID:YKmk2JvD.net: まあそれだけ多くの人が使い始めてるわけだ
567 ：デフォルトの名無しさん：2014/03/16(日) 17:27:48.29 ID:rHQmp5Mm.net: ちょっとある仮説を思いついたから、Amazonでバージョン管理システムの
解説本がどれくらいあるのか調べてみたよ。

CVSによるオープンソース開発 (2002/6)
実用CVS ジェニファーベスパーマン (2003/12)

「Subversion」解説書 (2004/12)
入門Subversion (2006/7)
Subversion実践入門:達人プログラマに学ぶバージョン管理 (2007/4/21)
Subversionハンドブック (2008/5/30)
実用 Subversion (2009/7/27)
Subversion入門 (2010/5/26)

入門Mercurial (2009/1)
入門TortoiseHg + Mercurial (2013/2) （作者同じなので上のやつの改訂版かも）

入門git (2009/8/12)
入門Git (2009/9/19)
実用Git (2010/2/19)
Gitによるバージョン管理 (2011/10/25)
Gitポケットリファレンス (2012/7/10)
わかる Git (2012/12/7)
アリスとボブのGit入門レッスン (2012/9)
開発効率をUPする Git逆引き入門 (2014/4/8)

ちなみに、仮説っていうのは、本の発行年から、どのように世の中が
移り変わっているかがわかるんじゃないかってこと
568 ：デフォルトの名無しさん：2014/03/16(日) 17:28:55.56 ID:TC2j70a9.net: Pro Gitでだいたい事足りると思うんだけどなあ
569 ：デフォルトの名無しさん：2014/03/16(日) 18:15:28.83 ID:oYfix9gh.net: 入門書
リファレンス
オライリー

本格的に使うならこれは買ってもおかしくない
570 ：デフォルトの名無しさん：2014/03/17(月) 10:47:49.25 ID:iF7/E7LV.net: >>569
入門書ってどれだよ・・・
571 ：デフォルトの名無しさん：2014/03/17(月) 14:16:02.50 ID:ywio8KhI.net: >>567のだとGitポケットリファレンス以外は全部入門書でいいんじゃないの
572 ：デフォルトの名無しさん：2014/03/19(水) 02:53:47.93 ID:g+2MOTll.net: http://1topi.jp/curator/fushimik/1303/04/103271
gitでDropBoxみたいな事できるそうなんですが
Rubyのスクリプトみたいです

WindowsでMyDocmentを自動同期したいなら
起動時に自動で起動すればいいの？

やりかたわからないけど
573 ：デフォルトの名無しさん：2014/03/19(水) 03:07:20.21 ID:OqCH9dx5.net: 素直にDropboxを使うか、Dropboxクローンが
ほしいならownCoudとかを使ったほうがいいよ。
574 ：デフォルトの名無しさん：2014/03/19(水) 13:54:35.23 ID:zGGXKiEK.net: >>572
これ見てガンバレ
https://github.com/kitak/ohajiki/blob/master/README.md
575 ：デフォルトの名無しさん：2014/03/19(水) 14:30:23.66 ID:A9Mq7R78.net: >>572
・タイムスタンプが同期されない
・バイナリ差分転送できない
・テキストであっても、かなり低速
576 ：デフォルトの名無しさん：2014/03/19(水) 14:42:56.09 ID:2bqnpC5d.net: バージョン管理するテキストデータだけ専用のフォルダに分けて共有フォルダと別管理するべき
577 ：デフォルトの名無しさん：2014/03/21(金) 16:15:27.00 ID:Wj+qHZ+v.net: gitでpullとかcloneするときにタイムスタンプも戻したいんだけど
どのオプションだっけか
578 ：デフォルトの名無しさん：2014/03/21(金) 16:24:01.23 ID:o89Np3ew.net: パソコンの日付を変える。
579 ：デフォルトの名無しさん：2014/03/21(金) 16:42:33.56 ID:QY3RInUB.net: >>577
Gitはファイルのタイムスタンプを保存していない
コミットした時間は保存してる
シェルスクリプトとか使えば、ファイルのタイムスタンプをコミットした時間に変更できる
580 ：デフォルトの名無しさん：2014/03/23(日) 15:06:12.02 ID:LwVxNWuC.net: Git神
Subversionはじだいおくれ糞
581 ：デフォルトの名無しさん：2014/03/23(日) 18:40:00.27 ID:nryWnJ89.net: gitはなんで空ディレクトリが扱えないんだよ
偏屈すぎるだろ
それとも実装できない理由でもあるのか？
582 ：デフォルトの名無しさん：2014/03/23(日) 22:16:32.16 ID:hT/roAz6.net: ファイルじゃなくて内容を管理しているから、かなあ(てきとう)
583 ：デフォルトの名無しさん：2014/03/23(日) 22:20:33.95 ID:/rUHJ76N.net: 内容を管理しているならさ、もう少しマシなdiffをだせないものかな？
どうせ外部diffを呼んでるだけなんだろうけどさ、
たとえば長い関数の一部を取り出してを他のファイルに移動した時とか、
ちゃんとそれがわかるようなdiffを出して欲しいんだけど。
584 ：デフォルトの名無しさん：2014/03/23(日) 22:24:28.99 ID:Cwtmew+7.net: >>583がもっとましなdiff作ってるってさ
585 ：デフォルトの名無しさん：2014/03/23(日) 22:29:18.73 ID:SSYwKPLD.net: >>583
期待してるよ
586 ：デフォルトの名無しさん：2014/03/23(日) 22:44:05.05 ID:/rUHJ76N.net: >>584-585

バージョン管理システムはバージョン間の違いの「目的」を理解するべき

diffはテキストファイルにもバイナリファイルにも使える。
だがdiffにも難点があって、ちとアホなのよね。 diffがやってるのは
2つのバージョンを見比べて、単に違いを出してるだけ。

もっとましなdiffでは変更の結果だけでなく
変更の「目的」まで理解する。

たとえばツールを使い、あるクラスに対してメソッドの抽出リファクタリングを行ったとする。
変更を加えたのはそこだけだ。現状のツールはプログラム内のテキストの違いは分かる。
だけど、これがリファクタリングを行ったことまでは分からない。変更の前後でdiffを調べてみると、
変更があったことは伝えてくれるが、これはリファクタリングなんだと伝えるようなことはしてくれない。

これが今のdiffの欠点で、将来はどういう目的で変更したかまで把握できるdiffができる。
587 ：デフォルトの名無しさん：2014/03/23(日) 22:44:22.99 ID:oiqURFTj.net: 空のディレクトリを共有しようとする方がよっぽど偏屈に見える。それって必要？
588 ：デフォルトの名無しさん：2014/03/23(日) 22:47:02.93 ID:SSYwKPLD.net: >>586
だからその「目的」を解釈してくれるエンジンを>>583が作るんでしょ？
589 ：デフォルトの名無しさん：2014/03/23(日) 22:50:51.21 ID:/rUHJ76N.net: >>588
単に今のdiffの欠点と、将来はどうあるべきかを言っているだけだけど？
なに？　問題点をいっちゃダメなの？
590 ：デフォルトの名無しさん：2014/03/23(日) 22:51:53.66 ID:/rUHJ76N.net: 意味を理解するdiffっていうのは
優れたアイデアなんだけど
それぐらい、わからないのかな？
591 ：デフォルトの名無しさん：2014/03/23(日) 22:52:05.60 ID:SSYwKPLD.net: 言い出しっぺやるの法則を知らない国の人か
592 ：デフォルトの名無しさん：2014/03/23(日) 22:52:51.54 ID:oiqURFTj.net: >>583
git diff -C 試した？
593 ：デフォルトの名無しさん：2014/03/23(日) 23:01:31.90 ID:YZGI/DRg.net: >>590
そういうことしたいなら、どう考えてもそのリファクタリングを行ったツールと連動した方が確実で簡単だと思う。
594 ：デフォルトの名無しさん：2014/03/23(日) 23:06:27.71 ID:9GdGP9ts.net: >>590
意味を理解するdiffとか、Git自体にそんなもの組み込む必要はないよ
おなじみの http://git-scm.com/book/ja/ の7章読んできてくれ
「7.1 Git のカスタマイズ - Git の属性」の「外部のマージツールおよび Diff ツール」
595 ：デフォルトの名無しさん：2014/03/23(日) 23:11:29.16 ID:/rUHJ76N.net: あー、お馬鹿なお前らに名乗るの忘れていた。

俺、Martin Fowlerなんだよね。有名人だから知ってるよね？

SemanticDiff
http://martinfowler.com/bliki/SemanticDiff.html

ここで>>586と同じことを英語で書いてるから、
俺の言ったことが理解できない、馬鹿なことを言ってると思うのなら
英語を読むといいよｗ
あと無知はぐぐれ。
596 ：デフォルトの名無しさん：2014/03/23(日) 23:14:09.37 ID:SSYwKPLD.net: >>595
いやだから最初から期待してるって言ってるじゃん。
はやく完成するといいね。
597 ：デフォルトの名無しさん：2014/03/23(日) 23:17:10.68 ID:74vZT6SV.net: >>595
Martin Fowlerさん降臨記念カキコ
598 ：デフォルトの名無しさん：2014/03/23(日) 23:36:31.15 ID:T9zWShXS.net: 結局何が言いたいんだろう
599 ：デフォルトの名無しさん：2014/03/23(日) 23:43:02.22 ID:oiqURFTj.net: diff、取ってみようか。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?SemanticDiff
600 ：デフォルトの名無しさん：2014/03/24(月) 01:18:39.83 ID:0ol5+0pg.net: >>587
普通に必要だろ。git使いだけど不満に思っているよ。
もう少し想像力を働かせて欲しいものだな。
601 ：デフォルトの名無しさん：2014/03/24(月) 01:25:10.36 ID:PVohiAF8.net: >>600
empty_dir/.gitignoreに
!.gitignore
って書くんじゃだめなんすか
602 ：デフォルトの名無しさん：2014/03/24(月) 01:26:55.61 ID:0ol5+0pg.net: >>601
いや、それはちょっとダサいでしょ。
仕方なく、そうやっているんだけどさ...
603 ：デフォルトの名無しさん：2014/03/24(月) 01:28:53.09 ID:PVohiAF8.net: おっと
*
が抜けた
どちらにしろ空のディレクトリを空のまま使うことなんて有り得ないんだから
.gitignoreは必要になるんじゃないのかなあ。
まあgit_root/.gitignoreにまとめて書きたいという需要もあるのか。
604 ：デフォルトの名無しさん：2014/03/24(月) 01:34:37.43 ID:0ol5+0pg.net: >>603
開発スタイルによるけど、たいていの場合はディレクトリ構成って設計段階から決まるから、先に作っておきたい。
仕方なく.gitkeepとか.deletemeとか使っているが、コレジャナイ感がある。
ちなみに、.gitignoreは意味が違うような気がしていて使ってないです。
605 ：デフォルトの名無しさん：2014/03/24(月) 01:56:40.05 ID:k2bvJYlJ.net: >>600
gitでファイルのパスが管理されてるのに、パスの情報しか持たないディレクトリを管理したいだなんて、
ファイルシステムへの理解不足かプロジェクトのマヌケさを疑うね。

コードがなにかファイルをそのディレクトリに放り込む手筈になってるのなら
ディレクトリの作成も一緒にやってしまえばいい。
606 ：デフォルトの名無しさん：2014/03/24(月) 02:07:55.26 ID:k2bvJYlJ.net: >>604
そういうのはせめてREADME入れといてよ…
607 ：デフォルトの名無しさん：2014/03/24(月) 06:19:10.58 ID:cXsOtx6k.net: svnから取得したプロジェクトをgitに登録しようとしてるんだけど
trunkフォルダにあるデータをそのままルートにコピーして、trunkフォルダ削除しちゃった

trunk-[フォルダいっぱい]
branches-[フォルダいっぱい]
tags-[フォルダいっぱい]

これを↓

[フォルダいっぱい]
branches-[フォルダいっぱい]
tags-[フォルダいっぱい]

こんな感じ

こうするとgit-svnで引っ張ってきた過去の履歴と比較できなくなるって言われたんだけど
今から治す方法ない？
608 ：デフォルトの名無しさん：2014/03/24(月) 07:39:05.71 ID:coYvviPW.net: 最初っからtrunk込みのパスをgit-svnに渡しとけ
折角svnはサブディレクトリ単位でもリポジトリ扱いできるんだから
609 ：デフォルトの名無しさん：2014/03/24(月) 07:40:05.59 ID:coYvviPW.net: 或いはgit svn -sか。
610 ：デフォルトの名無しさん：2014/03/24(月) 09:59:32.00 ID:l/qxp3d1.net: >>606
この文脈でREADMEって、何を書く想定なんだ？
611 ：デフォルトの名無しさん：2014/03/24(月) 12:26:30.45 ID:k2bvJYlJ.net: >>610
なんでこの空ディレクトリがコミットされているのかと、どういうモノをここにコミットしていく予定なのか。
ディレクトリがイントロスペクティブなら、後で気が変わってツリーの見直しが発生してもドキュメントと作業ディレクトリの二重管理を防げる。
612 ：デフォルトの名無しさん：2014/03/24(月) 12:33:59.02 ID:rzCer1bD.net: >>586
そんな使えないツール作ってないで、コメントつけろよ。
613 ：デフォルトの名無しさん：2014/03/24(月) 14:56:36.98 ID:x252QyU1.net: Q1とQ2を解説お願いします

git init
空のtest.txtを作成
git add .
git commit -m "Initial commit"
test.txtを編集
git add.
git commit -m "second commit"
git checkout HEAD@{1} で最初の履歴に戻る
test.txtを編集
git add.
git commit -m "third commit"
git statusを実行するとHEAD detached from　"ハッシュ"ってメッセージが表示される（Q1）
そこでgit branch temp & git branch temp & git branch masterってやって
git branch -d temp をやると
error: The branch 'temp' is not fully merged.
If you are sure you want to delete it, run 'git branch -D temp'.
ってメッセージがでます
何故tempに切り替えたときに編集してないのにtempをmasterにmergeさせないといけないのですか？（Q2）
614 ：デフォルトの名無しさん：2014/03/24(月) 16:26:56.74 ID:7xUxQev3.net: >>613
Q1
git checkout HEAD@{1} は最初の履歴に戻るコマンドじゃなくて、別のブランチに移動するコマンド
ただし HEAD@{1} がブランチじゃないので detached HEAD という特殊な状態になる
これを実行したときに You are in 'detached HEAD' というメッセージが出たはず

最初の履歴にもどりたかったら、git reset --hard HEAD@{1}とすべきだった
今から戻るにはこうする
git co master; git reset --hard 最初のコミットのハッシュ

Q2
そのメッセージは、ブランチを消すとまだ他のブランチにマージされていないコミットが消えてしまうよ、という警告
-dじゃなくて-Dを使えばその警告を無視してブランチを消せる
615 ：デフォルトの名無しさん：2014/03/24(月) 18:45:49.12 ID:15T1FlGn.net: >>613
　HEAD(、temp)
　↓
┌C3
↓
C1←C2
　　↑
　　master
Q1
Q1でのC3のようにブランチなどから参照されていないコミットをdetachedという
この状態でHEADをC2などに動かすとどこからも参照されていないC3は失われてしまう(もちろんreflogはできる)ので変更を残したいならブランチなどを作ってね、ということ

Q2
ここではtempはC3を指すように作られる
tempを作った直後は編集していないけど、上図の通りC3がマージされていない
616 ：デフォルトの名無しさん：2014/03/25(火) 00:33:52.38 ID:56htplUz.net: 小保方さんも論文のバージョン管理はGitでやれば良かったのに
617 ：デフォルトの名無しさん：2014/03/25(火) 01:53:12.00 ID:T9JHOn1b.net: gitでもコピペは防げません
618 ：デフォルトの名無しさん：2014/03/25(火) 02:16:02.05 ID:6ItjGCiG.net: >>614-615詳しい解説のおかげで大変わかりやすいです。
立て続けにすみませんマージ後の対応についてQ3とQ4もお願いします。
>>613の状態でgit logすると
9b1062c: 2014-03-25 00:36:20 +0900: Initial commit
c54e4f6: 2014-03-25 00:39:01 +0900: third commit
となります。このあとgit merge tempをしました。
コンフリクトが出るので解消させます。
git add .; git commit -m "four commit"を実行すると"[master 90cd423] four commit"って1行のみのメッセージがでました。(Q3)
いつもなら下記の2行でメッセージが表示されるはずなのにこのコミットのときは1行のみでした
[master 90cd423] four commit
1 file changed, 1 insertion(+), 1 deletion(-)

そしてgit logをすると
cb0ee7d: 2014-03-25 00:42:25 +0900: Initial commit
f082da3: 2014-03-25 00:42:38 +0900: second commit
ae0009b: 2014-03-25 00:43:09 +0900: third commit
90cd423: 2014-03-25 00:45:01 +0900: four commit
ってログが4つあります。3つじゃありません。3つにしたいのですae0009bのコミットはいりません。何故4つになったのか教えてください(Q4)
619 ：デフォルトの名無しさん：2014/03/25(火) 03:33:44.11 ID:FBko2gtk.net: コミット番号についての単純で重要な事を一つ言っておくよ。

コミットの内容には番号が付いているが、このコミットの内容には歴史の内容も含まれている。
たとえばコミット番号がae0009bであれば、その過去のコミットの番号は必ずに同じになる。

つまりだ、rebase等で過去を変えると変更した所より後はすべて書き換わるということ。
また特定のブランチをマージしたり、コミットをチェリーピックしたりすると
（処理結果の過去が変わる場合は）コミット番号はマージ、チェリーピック先では変わるということ。

そして、もうひとつおまけ。

コミットには、通常のコミットとマージコミットに分かれている。(git logをよく見てみよう)

あるブランチ、そこには複数のコミットが含まれている。
それをマージすると、複数のコミットに加えてマージコミットが１つ追加される。
マージを取り消したいときはrevertするわけだけど、このマージコミットを
一つrevertするだけで、複数のコミットがまとめて取り消される。便利。

ただし、マージした時に必ずマージコミットができるかといったら、そうではなく
（処理結果の過去が同じになるので）マージコミット作らなくていいんじゃね？と
gitが判断したらマージコミットを作らない。マージコミットを作らない＝fast forward（早送り）
これはオプションで制御できる。
620 ：デフォルトの名無しさん：2014/03/25(火) 03:37:01.81 ID:FBko2gtk.net: AブランチからBブランチへのマージ・・・Bブランチに含まれていないAブランチのコミットを全てマージする
チェリーピック・・・特定のコミットのみ加える。
621 ：デフォルトの名無しさん：2014/03/25(火) 03:48:52.54 ID:FBko2gtk.net: detachedはなんとなく異常な状態に思ってしまうかもしれないけれど、実は便利な道具なのです。

detachedの使い方その1

「ちょっと俺のコードレビューしてくんない？」
「わかったよ、手元にcheckoutして動かしてみる」
「ブランチ名指定でcheckoutすると、ローカルリポジトリにブランチできちゃって消すのが面倒だからコミット番号でcheckoutするぜ！」

detachedの使い方その2

「いらねーブランチがたくさんローカルリポジトリ残ってるな」
「git branch -D で消しまくっちゃえ！」
「しまった！必要なのまで消しちゃった」
「git reflogみたら、消したりcheckoutしたときのコミット番号が全て記録されている」
「よし、このコミット番号だな。checkoutだ！（detached状態）そしてブランチ名をつけるぞ！」

git reflogとコミット番号には歴史も全て含まれてる。ってことは最初に教えておくべきことだと思う。
間違って消しても、間違ってrebaseしてコミット番号が変わっても、
間違う前のコミット番号さえわかれば（reflogでわかる）復活できるんだから。

reglogはある程度大きくなって30日だっけ？立てば自動的に消えるけど
消えなければコミット番号からコミット（とその歴史）は完全な状態で復活できる。
622 ：デフォルトの名無しさん：2014/03/25(火) 22:19:56.67 ID:snK4TAek.net: >>621
その1はわかるがその2は
git branch ブランチ名コミット番号
でいきなり名前付けちゃうなあ。checkout -bでもいいし
623 ：デフォルトの名無しさん：2014/03/26(水) 16:48:10.35 ID:RExXi/Ym.net: タグでバージョン管理してんだけど
git tag
でタグ一覧表示してるときに
hoge-1.2.9 のつぎに hoge-1.2.10 が来るようにしたいんだけど
どうしたらいいかな
624 ：デフォルトの名無しさん：2014/03/26(水) 17:29:58.38 ID:pRpzj6Hj.net: コミットの日付ごとにソート？
625 ：デフォルトの名無しさん：2014/03/26(水) 18:20:02.12 ID:1lIY7CVQ.net: 自分の好みの順番に並べ替えるフィルタを書けばいいだろ
626 ：デフォルトの名無しさん：2014/03/26(水) 21:34:33.20 ID:j+UsaIor.net: >>623
|sort -n
627 ：デフォルトの名無しさん：2014/03/26(水) 23:44:02.96 ID:aTmW0mN4.net: >>605 ファイルシステムへの理解不足かプロジェクトのマヌケさを疑うね。
お前何言ってんの
628 ：デフォルトの名無しさん：2014/03/27(木) 00:16:47.15 ID:ze0m1e8o.net: 空のディレクトリを管理しないのは、
gitがソースコード管理システムだからだろ。
プロジェクト管理システムじゃない。

diffが全てだと言ってもいいと思う。
diffに意味がなければSCMを使う意味がない。
629 ：デフォルトの名無しさん：2014/03/27(木) 00:24:20.37 ID:gcsG9K2Q.net: > gitがソースコード管理システムだからだろ。
> プロジェクト管理システムじゃない。

これは

gitがソースコード管理システムだからだろ。
デプロイシステムじゃない。

という方が適切だと思う。

ディレクトリが必要なのは、デプロイつまり動作するときであって
動作させるにはディレクトリ作成以外にもパーミッション設定とか
サーバーごとの設定とか色々あるわけで、
こういうのはデプロイとしてやるべきことだと思う。
630 ：デフォルトの名無しさん：2014/03/27(木) 00:28:10.33 ID:gcsG9K2Q.net: 考えてみたら、スクリプト言語のせいなんかな？

gitはカーネル開発のために作られた
つまりC言語、コンパイルする言語。

コンパイルする言語だと、チェックアウトした時に
空のディレクトリを作成する必要ないでしょう？
makeしないと動かさないわけでディレクトリが
必要ならmakeで作成すればいいわけで。

チェックアウトしたソースコードのそのままの位置で
動かそうとするスクリプト言語だから空のディレクトリが
必要だと思っちゃう。
631 ：デフォルトの名無しさん：2014/03/27(木) 00:45:15.61 ID:/J3FM59H.net: 意味がわからん
スクリプト言語でも今どきは DB 初期化だのなんだので make 的なのを掛けるのが一般的だが
632 ：デフォルトの名無しさん：2014/03/27(木) 00:49:53.18 ID:gcsG9K2Q.net: >>631
”今どきは” でしょう？

つまり今どきじゃないやり方では
ソースコードをチェックアウトして
make的なことをせずに、そのまま動かすことに
心当たり、あるでしょう？
633 ：デフォルトの名無しさん：2014/03/27(木) 00:52:45.33 ID:ze0m1e8o.net: あ、なるほど。合点がいった。
rootにmakeファイルがあってREADMEにtestにsrcに…ってのが出発点なのに
いきなりindex.htmlとか放り込んでる連中が空ディレクトリ置けないって嘆いてるのか。

なんかExcel方眼紙思い出した。
634 ：デフォルトの名無しさん：2014/03/27(木) 01:29:37.99 ID:JNLvBr35.net: >>633
makeファイル前提の考え方って、どんだけ限定的な開発しかしてないんだよ。。。
635 ：デフォルトの名無しさん：2014/03/27(木) 01:33:07.62 ID:JNLvBr35.net: >>628
前レス気になってみこっちも見たんだけど、ひどいな。
この解釈はお子様だ。
636 ：デフォルトの名無しさん：2014/03/27(木) 02:05:31.43 ID:ze0m1e8o.net: うわぁ
637 ：デフォルトの名無しさん：2014/03/27(木) 07:23:19.89 ID:vi39ZLyv.net: diffで出てこないものは管理しないってのは合点がいくけど
じゃあ
638 ：デフォルトの名無しさん：2014/03/27(木) 07:24:21.45 ID:vi39ZLyv.net: 失礼途中送信です
じゃあなんで git commit --allow-empty を許可しちゃうんだろ？
639 ：デフォルトの名無しさん：2014/03/28(金) 00:16:43.38 ID:3TELInRM.net: 今日秋葉のヨドバシの中の有隣堂書店行ったら、コンピュータ関係書籍の売り上げ
一位がこの本だった。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
大塚弘記
http://www.amazon.co.jp/gp/product/477416366X/

やっぱ売れているんだな。
640 ：デフォルトの名無しさん：2014/03/28(金) 00:25:33.22 ID:W/hCr5dM.net: 立ち読みしたけどごく初歩的なことしか書いてないのですでに使ってる人間にはいらない
GitHubのファンブック程度のものでしかない
641 ：デフォルトの名無しさん：2014/03/28(金) 00:26:41.92 ID:Ek64RinZ.net: つまり、使ってない人間には～？
642 ：デフォルトの名無しさん：2014/03/28(金) 00:36:46.63 ID:W/hCr5dM.net: 金の無駄
SNSの手引書ごときに何千円も出す価値なんてない
その金でGitの入門書買ってGitHubの使い方は触って覚えろ
643 ：デフォルトの名無しさん：2014/03/28(金) 00:38:50.93 ID:Ek64RinZ.net: 2580円しかしないと思うけど？

時々さ、パソコン系の雑誌の値段（1500円ぐらい）を
高いっていう人がいるんだけど、君も同じ種類の人間？
644 ：デフォルトの名無しさん：2014/03/28(金) 00:51:19.52 ID:W/hCr5dM.net: お前が100円のガムを1000円で買いたがるバカなのはわかった
645 ：デフォルトの名無しさん：2014/03/28(金) 01:30:42.52 ID:HSmI/JHp.net: 売れてるんだから世の中は貴方より馬鹿な人で満ち満ちてるってことなんだよ。
こんなとこでそんな連中を馬鹿にするよりこの本みたいなの執筆して金にする方でも考えたらいいんじゃない？
100円のガムを1000円で売れる錬金術だぞ？
646 ：デフォルトの名無しさん：2014/03/28(金) 01:36:16.36 ID:Ek64RinZ.net: >>644
ん？この程度の本なんだから価格も安くて2580円でしょ？
647 ：デフォルトの名無しさん：2014/03/28(金) 01:50:12.38 ID:W/hCr5dM.net: >>645
本業以外四方八方に手を出して回るほど多芸でも暇でもない

>>646
通常1万円の商品がこのお値段ですってか
値段でしか物の価値がわからないなんていいカモだな

ではおやすみ
648 ：デフォルトの名無しさん：2014/03/28(金) 02:07:57.89 ID:3TELInRM.net: 売り上げ１位ということは注目されているってことで喜ぶべきことだと思うけど。
単に事実を報告しただけなのに、なんでやたらケチ付けないと気が済まない奴がいるんだろう？
心が貧しいのかな？
649 ：デフォルトの名無しさん：2014/03/28(金) 02:16:13.21 ID:MDxZ8QeT.net: その本なあ、正直それ買うくらいならWebDBPressをPDFにまとめたやつ買ったほうが…
そこでやってた記事のリメイクみたいなもんだし
650 ：デフォルトの名無しさん：2014/03/28(金) 03:56:01.18 ID:Ek64RinZ.net: >>647
いやいや、俺は本をさほど評価してないんだよ？
GitHubの紹介程度だから価格も安いと言ってる。

技術書を買い慣れてないんじゃないの？
雑誌1500円、入門書3000円。
（初心者向け以外の）オライリー本4000～5000円
マイナー本6000円、高い本8000円～
これぐらいが普通の感覚でしょう？
651 ：デフォルトの名無しさん：2014/03/28(金) 07:39:31.29 ID:Dn5nxvgF.net: >>638
man git-commitのオプションの項目見た？
空コミット許してる他のVCSとの絡みで存在するとある。
git rebase -iすると空コミットはデフォでコメントアウトされるよ。
652 ：デフォルトの名無しさん：2014/03/28(金) 11:15:20.51 ID:b5I/lc4w.net: 2500円程度の技術書がAmazonで1位になるといくら入るのか教えてくれ
653 ：デフォルトの名無しさん：2014/03/28(金) 11:23:59.96 ID:DJcyO9f1.net: ×100円のガムを1000円で
○0円のガムを1000円で
654 ：デフォルトの名無しさん：2014/03/28(金) 11:25:50.46 ID:HSmI/JHp.net: 適当にぐぐった感じでは技術書の印税率は7～8%ぐらいだとか
一冊あたり \2,500 * 7.5% ≒ \188
出版社や電子出版とかの出版形態、著者の知名度とかでも変わるらしいが。

技術書の発行部数ってどれぐらいなんだろね？累計部数2万部でなかなかすごいとか言われるらしいから
そんだけ売れたとして \188 * 20,000 = \3,760,000。400万いかないんだな。

これにプラス原稿料か。2万部もそれなりに時間かかっての話だし、
夢の印税生活ってわけにはいかないねえ。
655 ：デフォルトの名無しさん：2014/03/28(金) 12:02:43.45 ID:VXkuFG6S.net: Windowsで開発しています
WindowsやLinux,Macといった複数の環境でリポジトリを共有するときの改行コードについて悩んでます。
リポジトリにはLFで記録されていないとパッチのときに困ることになる事がググってわかりました。
Visual StudioでC#を書いているので、このコードの改行コードはIDEで自動的にCRLFになります。
他のRubyなどの言語ではLFで統一して書いてます。
なのでソースコードによって改行が異なるのですが、こういう場合はautocrlfの設定をどうしたらいいのか教えてください。
C#のソースコードの改行を全部LFできれば問題ないんですがプロジェクトがたくさんありすぎて、CRLFからLFに変換することで予期しないバグを生みそうで怖いのでできません。
656 ：デフォルトの名無しさん：2014/03/28(金) 12:11:59.03 ID:4g0iFrkk.net: >>651
知りませんでしたなるほど
空の内容を許可できないとディレクトリだけ追加したコミットがインポートできませんね
657 ：デフォルトの名無しさん：2014/03/28(金) 15:08:39.41 ID:b5I/lc4w.net: >>654
なるほど、どうも
技術書は小遣い稼ぎと執筆実績が目当てなんだろうね
658 ：デフォルトの名無しさん：2014/03/28(金) 15:33:35.02 ID:A6LtV5Yy.net: >>655
MSは互換性を崩すことで囲い込みをする戦略だから基本的に混ぜるな危険。
659 ：デフォルトの名無しさん：2014/03/28(金) 15:45:38.10 ID:Si2wpl68.net: ブログをはしごするより本にまとまってると利用しやすいってのはあるけどね。
660 ：デフォルトの名無しさん：2014/03/28(金) 17:54:41.11 ID:konPatBX.net: 環境とか前提条件を明示してないクソぶろぐはほろぶがいい
661 ：デフォルトの名無しさん：2014/03/28(金) 18:34:12.86 ID:Ek64RinZ.net: >>655
設定変えればいいだけじゃんか、LFに

>>658
くだらない悪口言ってないで
ちゃんとした答えを言えよ。
662 ：デフォルトの名無しさん：2014/03/29(土) 08:41:02.91 ID:kBOeF+dH.net: >>655
VSの設定で改行コードをLFに変更する。
autocrlfは弄るな危険。
どうしてもやりたければsafecrlfとセットで。
共同開発者にニワカが紛れ込んでる場合は、リポジトリに、コードの全行がCRLFだった場合にrejectするhookを置く。

自動変換は、ヒアドキュメントなんかで異なる改行コードが行末に必要になると破綻する。
663 ：デフォルトの名無しさん：2014/03/29(土) 10:16:05.39 ID:LsRDU2hq.net: MS-DOS 1.1のソースコードに変更履歴がコメントで残してあってほっこりした
664 ：デフォルトの名無しさん：2014/03/29(土) 11:28:15.42 ID:NkzYe9SC.net: 技術書の執筆なんて手間ばかり掛かってぜんぜん金にはならないよ。
本を紹介するとやっかみで批判する奴いるけど、むしろボランティアなんだから
感謝しこそすれ、儲けやがってと批判するのは完全にお門違い。
665 ：デフォルトの名無しさん：2014/03/29(土) 12:29:02.98 ID:KQZTo8Ge.net: まともな本書いてるひとには申し訳ないけど
一見してまともじゃない本の方が
内容が糞な割に儲けてる感じがするのも事実
そういうのが多いとやっかみで文句ばかり言う人が
増えるのもやむを得ないと感じる
666 ：デフォルトの名無しさん：2014/03/29(土) 13:10:31.47 ID:2x5p0G/E.net: そりゃそうだろ？
どんなものでも圧倒的に素人の方が多い。
そして素人の方が本を必要とする。
667 ：デフォルトの名無しさん：2014/03/29(土) 13:47:46.32 ID:lUJRfUf3.net: 表面なめただけの粗悪な本でも見当のつかない分野のアウトラインを知るために
藁をもつかむ思いで買うことはあるがそんなときでもなければ買わない
今回買ったのはデザイナーか営業か人事か役員あたりじゃないか
設計やコーディングする人間にはググれば済む程度の内容だし
668 ：デフォルトの名無しさん：2014/03/29(土) 14:16:35.83 ID:V4V3vXLL.net: なんかやたらと買わないアピールが続いてるけどいったいどうしたんだ
669 ：デフォルトの名無しさん：2014/03/29(土) 14:38:51.03 ID:JO2zG+IR.net: 最初にこの本の話題が出たときから、このスレに常駐してるような人には必要ない本だろうって感じだった
670 ：デフォルトの名無しさん：2014/03/29(土) 15:02:29.32 ID:lUJRfUf3.net: 発売前から紹介されてたのに買ってアピールする人が出てこないのはみんな立ち読みしたけど棚に戻したということでしょ
なのにしつこくプッシュされたら反論したくもなる
671 ：デフォルトの名無しさん：2014/03/29(土) 15:44:54.29 ID:Yzk0+u4a.net: つまらない反論なんてしなくて無視しとけばいいのに。プッシュしてる書き込み
なんてほとんどなくて、反論の書き込みの方が多くて邪魔だよな。
672 ：デフォルトの名無しさん：2014/03/29(土) 16:12:45.91 ID:2x5p0G/E.net: http://www.amazon.co.jp/dp/477416366X
どんだけ２ちゃんねるの評判に頼ってるんだよｗ

こんな所に頼るぐらいなら
amazonの方がまだまし。
673 ：デフォルトの名無しさん：2014/03/29(土) 16:14:41.11 ID:2x5p0G/E.net: 俺はそんなこととっくに知ってるから不要

っていうのは、その本を批判していることにはならない。
674 ：デフォルトの名無しさん：2014/03/29(土) 16:53:24.55 ID:PHITCFwf.net: 淡々と本のメリットを紹介するなら反論も出ないだろうけど、
本を買わない奴は糞、という論調だから買わないアピールが出るんだよ。
675 ：デフォルトの名無しさん：2014/03/29(土) 17:31:25.48 ID:V4V3vXLL.net: えっ
買うやつは糞って論調じゃないの？
676 ：デフォルトの名無しさん：2014/03/30(日) 00:03:42.48 ID:S+rtzMEf.net: http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7
wordのdiffの取り方も紹介してんのな
677 ：デフォルトの名無しさん：2014/03/30(日) 00:23:18.46 ID:fw5SYbo4.net: >>676
catdocってツールの存在を知れて有用だったわ
678 ：デフォルトの名無しさん：2014/03/30(日) 00:49:06.16 ID:/CfyfstJ.net: >>676
WindowsならWinMergeのままでいいかな
xdocも読めるし外部だけどExcelにも対応してるし
679 ：デフォルトの名無しさん：2014/03/30(日) 05:53:30.40 ID:db/j9F+A.net: >>677
猫か犬かはっきりしろg
680 ：デフォルトの名無しさん：2014/03/30(日) 09:12:04.66 ID:9HEvX5A8.net: >>677
いつの間にかドキュメントのバージョン上がってたんだな。
たしか前までstringsコマンドが紹介されてて日本語使えねぇと思ったんだけど。
681 ：デフォルトの名無しさん：2014/03/30(日) 09:34:12.90 ID:qidUF1O3.net: Git使ってる人がいつの間にかバージョン上がってたとか曖昧なこと言ってるのは嘆かわしい
https://github.com/progit-ja/progit/commit/120cd6b88bb7bfd54e934d6240a343b42903b399
7ヶ月前だ
682 ：デフォルトの名無しさん：2014/03/30(日) 11:05:41.50 ID:pFwz2/0B.net: >>679
はっきりしてんだろg
683 ：デフォルトの名無しさん：2014/03/30(日) 13:23:37.85 ID:9HEvX5A8.net: >>681
『いつの間にか』日本語の文法もバージョン上がったのか。sha1くれよ。
684 ：デフォルトの名無しさん：2014/03/30(日) 14:34:00.64 ID:53PqKRTP.net: >>669
>このスレに常駐してるような人には必要ない

自分を基準に考えているのかもしれないが、世の中の人はみんながみんな２ちゃんに
粘着しているようなヒマ人ばっかりじゃない。

ネットを廻っていれば分かるようなこと、というのは事実かもしれない。
でも自分が知らないトピックを何千円か払うことで最短距離で知ることができるメリット
は大きい。特に自分の単金が高い人は。

本なんて安いもの、という発想が出来ないうちはいつまでたっても底辺のままだよ。
685 ：デフォルトの名無しさん：2014/03/30(日) 14:58:24.37 ID:KMVNCqdy.net: いやいやごみはごみだよ
686 ：デフォルトの名無しさん：2014/03/30(日) 15:58:28.39 ID:/CfyfstJ.net: 初めからこのスレの住人をコンテキストに書かれてるのも読み取れないで本や仕様書が読めるのかね？
687 ：デフォルトの名無しさん：2014/03/30(日) 16:00:11.26 ID:J3oHNw57.net: コンテキストってな～に？
688 ：デフォルトの名無しさん：2014/03/30(日) 16:03:06.58 ID:Ym7n0+3V.net: それ以前に日本語がおかしいぞ
689 ：デフォルトの名無しさん：2014/03/30(日) 16:13:00.70 ID:lTbLNvca.net: わずか一行の文章でここまでわけのわからないことを書けるのも一種の才能
690 ：デフォルトの名無しさん：2014/03/30(日) 20:06:17.85 ID:AmZWDzue.net: くんこくさいし
691 ：デフォルトの名無しさん：2014/03/30(日) 20:07:17.57 ID:AmZWDzue.net: 誤爆、しかも誤字
692 ：デフォルトの名無しさん：2014/03/31(月) 06:09:15.40 ID:Dx9xREGz.net: >>616-617
gitで複数のリポジトリからpullしたのを合体なんて出来た？
693 ：デフォルトの名無しさん：2014/03/31(月) 10:33:24.64 ID:Jzg3YQa1.net: >>692
fetch
fetch
merge
694 ：デフォルトの名無しさん：2014/04/01(火) 01:36:09.78 ID:HTAg2n1d.net: 1.9系のメンテナンスリリース「Git 1.9.1」がリリース
http://sourceforge.jp/magazine/14/03/25/150000
> バグ修正が中心のメンテナンスリリースで、ユーザーにアップデートを呼びかけている。
695 ：デフォルトの名無しさん：2014/04/01(火) 11:30:36.52 ID:L86dyqvA.net: 　3月18日、Git 1.9系の最新版となる「Git 1.9.1」がリリースされた。
^^^^^^^^^^^^
696 ：デフォルトの名無しさん：2014/04/01(火) 15:28:53.38 ID:zd2Xq/O2.net: ↓を参考にFuelPHPというPHPフレームワークのプロジェクトをサブモジュール化したのですが、
　ttp://qiita.com/L_e_k_o/items/956bd92645769dece5e7
これで作ったリポジトリを別の場所に「git clone --recursive」で持ってこようとすると
以下のようなエラーが発生して途中で失敗します。(git 1.9.1)
error: pathspec 'origin/master' did not match any file(s) known to git.
Unable to setup cloned submodule 'fuel/core'

fuel/coreなど各サブモジュールのブランチとして
一般的に存在するはずのmasterがないのが原因ではないかと推測したのですが
何か考えられる対処方法はありませんか？
697 ：デフォルトの名無しさん：2014/04/01(火) 21:58:10.85 ID:HTAg2n1d.net: >>695
1.9.1ってどうやったら入手できるん？
698 ：デフォルトの名無しさん：2014/04/01(火) 21:59:49.76 ID:HTAg2n1d.net: 自己解決、見つけた

Release v1.9.1: Git 1.9.1 ・ git/git ・ GitHub
https://github.com/git/git/releases/tag/v1.9.1
699 ：デフォルトの名無しさん：2014/04/01(火) 22:03:48.11 ID:L86dyqvA.net: git使ってるはずなのに
gitのソースコードを
gitで取ってこないのってなんで？
700 ：デフォルトの名無しさん：2014/04/01(火) 22:08:00.54 ID:HTAg2n1d.net: Windows使いだから
701 ：デフォルトの名無しさん：2014/04/01(火) 22:09:45.98 ID:HTAg2n1d.net: msysgitがまだ1.9.1に上がってないだけだった
702 ：デフォルトの名無しさん：2014/04/01(火) 22:11:25.10 ID:L86dyqvA.net: Windowsだとgitつかえないのー？
Windows版あるのになんでー？
703 ：デフォルトの名無しさん：2014/04/01(火) 22:17:14.30 ID:HTAg2n1d.net: gitのソースコードなんかWindowsに持ってきてどうするんだよ
704 ：デフォルトの名無しさん：2014/04/01(火) 22:58:03.14 ID:GxYZELvy.net: >>703
最新版使いたいって話なんだから
コンパイルするに決まってるじゃん？
何だと思ったのさｗ
705 ：デフォルトの名無しさん：2014/04/01(火) 22:58:55.23 ID:GxYZELvy.net: > 698 名前：デフォルトの名無しさん[sage] 投稿日：2014/04/01(火) 21:59:49.76 ID:HTAg2n1d
> 自己解決、見つけた
>
> Release v1.9.1: Git 1.9.1 ・ git/git ・ GitHub
> https://github.com/git/git/releases/tag/v1.9.1

↑ソースコード ↓自己批判？ｗ

> 703 名前：デフォルトの名無しさん[sage] 投稿日：2014/04/01(火) 22:17:14.30 ID:HTAg2n1d
> gitのソースコードなんかWindowsに持ってきてどうするんだよ
706 ：デフォルトの名無しさん：2014/04/01(火) 23:15:16.31 ID:HTAg2n1d.net: http://git-scm.com/
↑でDownloadのところが1.9.1になってるのにダウンロードしようとすると1.9.0になるから
おかしいなと思っただけだよ
707 ：デフォルトの名無しさん：2014/04/01(火) 23:18:39.59 ID:HTAg2n1d.net: つまり>>698は1.9.1の存在を確認したってだけのレスだよ
708 ：デフォルトの名無しさん：2014/04/01(火) 23:18:51.75 ID:GxYZELvy.net: ソースコードならgitで取ってくればいいだろって
いっただけだよ。
709 ：デフォルトの名無しさん：2014/04/01(火) 23:26:20.82 ID:HTAg2n1d.net: ソースコードじゃなくビルドされたmsysgitの1.9.1が欲しかったんだよ
710 ：デフォルトの名無しさん：2014/04/01(火) 23:30:34.74 ID:GxYZELvy.net: ソースコードあるんだから存在確認なんかするできるじゃない。

ソースコードあるんだからビルドすればいいじゃない。
711 ：デフォルトの名無しさん：2014/04/01(火) 23:38:47.55 ID:HTAg2n1d.net: gitは1.9.1に上がったけどmsysgitソースコードはまだ1.9.0のままだからmsysgitの1.9.1はビルドできないよ
712 ：デフォルトの名無しさん：2014/04/05(土) 11:16:04.26 ID:ZZXtrAnH.net: 最後にコミットした内容を全文取得する方法を教えてください
713 ：デフォルトの名無しさん：2014/04/05(土) 12:55:51.95 ID:N4PVE6y4.net: >>712
git show のこと？
全文ってなんぞや
714 ：デフォルトの名無しさん：2014/04/05(土) 13:30:22.49 ID:8YtqWgT+.net: 改行のない1行のファイルでコンフリクトした場合と
改行のあい1行のファイルでコンフリクトした場合で
コンフリクトしたときに生成される内容がどっちも同じで、最後に改行があるかどうかわからないんですが
こういうものですか？
715 ：デフォルトの名無しさん：2014/04/05(土) 13:33:18.44 ID:mtBhJ+7L.net: Gitの前に日本語を勉強したほうがいい
716 ：デフォルトの名無しさん：2014/04/05(土) 13:50:35.48 ID:wAOFYyyb.net: >>713
全てのコミットログ
717 ：デフォルトの名無しさん：2014/04/05(土) 13:55:48.72 ID:0fqpc5MM.net: 履歴から特定のキーワードを検索する方法を教えてください
718 ：デフォルトの名無しさん：2014/04/05(土) 15:31:14.94 ID:3X+75WiG.net: git log --grep
719 ：デフォルトの名無しさん：2014/04/05(土) 16:45:57.44 ID:N4PVE6y4.net: >>716
最後のコミットってのと全部ってのはどうも噛み合ってない気がするが、
git log -p でいままでの全てのコミットごとのdiffをみれるよ
720 ：デフォルトの名無しさん：2014/04/05(土) 18:34:57.03 ID:VpVtZpxi.net: 翻訳案:
このスレに書かれているもののコンテキストも読み取れないレベルで、本や仕様書が読めるのかね？
721 ：デフォルトの名無しさん：2014/04/05(土) 18:54:24.39 ID:9C6/NDEr.net: 通常人の知能があれば読める文章をわざわざ翻訳してあげなくていいよ
722 ：デフォルトの名無しさん：2014/04/05(土) 18:58:50.92 ID:mtBhJ+7L.net: 本や仕様書を読んで理解するより
ここの不思議ちゃんの質問の真意を汲み取るほうがはるかに難しいよ
723 ：デフォルトの名無しさん：2014/04/05(土) 19:19:54.97 ID:9C6/NDEr.net: > Gitの前に日本語を勉強したほうがいい
Gitスレで日本語の勉強を指南する人は言うことが違いますね
おわり
724 ：デフォルトの名無しさん：2014/04/05(土) 20:43:51.09 ID:NEyJXYls.net: gitってwindowsじゃ使えないの？
何で使うの？
725 ：デフォルトの名無しさん：2014/04/05(土) 21:14:36.90 ID:L63yQW6X.net: 使えるよ
726 ：デフォルトの名無しさん：2014/04/06(日) 11:59:48.02 ID:1YXnk/KS.net: >>715は普段他人に言われているんだろ
かわいそうだからあんまり>>715をいじめんなよ
ガチな奴を煽ると社会で何するかわからないからな
727 ：デフォルトの名無しさん：2014/04/06(日) 12:58:28.42 ID:hTzu53D+.net: >>726
じゃあ、お前はいじめて良さそうだなｗ
728 ：デフォルトの名無しさん：2014/04/06(日) 13:03:28.76 ID:X8q2hYwd.net: >>726
指摘されて悔しい

まで読んだ
729 ：デフォルトの名無しさん：2014/04/07(月) 05:47:52.87 ID:K/kPFgfw.net: http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%81%AE%E5%AE%9F%E6%96%BD%E4%BE%8B

この機能使えばロック代わりになるんじゃないの？
730 ：デフォルトの名無しさん：2014/04/07(月) 05:51:29.21 ID:dOohTi9z.net: >>729
なるほど、pre-commitフックでどのファイルがlockされているかを調べ、
コミットがそのファイルへの変更を含む場合弾く
ってバカみたいなフック書けばコミットは防げるな
731 ：デフォルトの名無しさん：2014/04/07(月) 06:02:33.93 ID:6r6QSdOH.net: そんなに馬鹿な方法でもないよ。
ロックというのは要するにアクセス権限の制御と同じ。
一時的に特定のユーザーにだけ
読み書きの権限を与えるのがロックの本質。

ロックという言い方のせいでファイルやデータベースの
ロックと勘違いされやすいけど、
本当はアクセス制限なんだよ。
732 ：デフォルトの名無しさん：2014/04/07(月) 06:10:46.35 ID:dOohTi9z.net: >>731
んなもんをわざわざフックでゴリゴリ書くのがバカみたいだって言ってるんだが
733 ：デフォルトの名無しさん：2014/04/07(月) 06:24:41.62 ID:6r6QSdOH.net: >>732
なんで？
734 ：デフォルトの名無しさん：2014/04/07(月) 06:30:17.00 ID:dOohTi9z.net: >>733
メダカにアームスーツ着せてる感じだな
735 ：デフォルトの名無しさん：2014/04/07(月) 06:35:05.14 ID:6r6QSdOH.net: ほらね。ちゃんと説明できないんだよな。
736 ：デフォルトの名無しさん：2014/04/07(月) 06:48:46.00 ID:dOohTi9z.net: 比喩がわるかったか。
本来そなわっていない、そぐわない機能を無理矢理に御仕着せてるのがバカらしいって話。
737 ：デフォルトの名無しさん：2014/04/07(月) 09:20:18.38 ID:kxzBrPRi.net: こう言う奴って標準でロックサポートしてたらなんも考えずに使うんだろうな (w
738 ：デフォルトの名無しさん：2014/04/07(月) 09:30:01.18 ID:KFUO0v2u.net: あっても使わないだろ
739 ：デフォルトの名無しさん：2014/04/07(月) 09:30:26.53 ID:tRBXTETn.net: いや、別にサポートされてたら使ったって問題ないだろそりゃ
もしわざわざサポートしたんだとしたら使うべきフローが見出されたってことなんだろうし
740 ：デフォルトの名無しさん：2014/04/07(月) 09:34:37.77 ID:KFUO0v2u.net: 事前の根回しとか、ロックしっぱなしの奴とか面倒くさくて使ってられない。
741 ：デフォルトの名無しさん：2014/04/07(月) 09:46:56.99 ID:16UD3OAF.net: なぜ人はコンフリクトにびびるのか
742 ：デフォルトの名無しさん：2014/04/07(月) 10:25:43.28 ID:7LBFjO6B.net: LinuxパッケージのGitがバージョン1.7.10なんだけど
ソースコードをコンパイルしてでも1.9を使ったほうがいいですか？
743 ：デフォルトの名無しさん：2014/04/07(月) 14:16:31.37 ID:6r6QSdOH.net: >>736
だから本来そなわっていない、そぐわない機能であるという
理由を言えって。
744 ：デフォルトの名無しさん：2014/04/07(月) 14:38:45.62 ID:jtMm82dE.net: >>739
git の仕様決めてる奴は常に正しいと言うわけか
宗教じみてるな
745 ：デフォルトの名無しさん：2014/04/07(月) 18:22:52.19 ID:xiERRsDS.net: 俺は便所の落書きより天才独裁者を信じるよ
746 ：デフォルトの名無しさん：2014/04/07(月) 19:21:54.19 ID:dOohTi9z.net: >>743
ああ、それすら理解できないアホなのか。
一生CVS使っててください。
747 ：デフォルトの名無しさん：2014/04/07(月) 19:40:02.08 ID:i4xTX3V0.net: Windowsでいままで作り上げてきたリポジトリを
LinuxからWindowsにアクセスしてコミットしたら壊れますか？
748 ：デフォルトの名無しさん：2014/04/07(月) 20:03:26.88 ID:Yv3nxM4P.net: >>746
俺が理解しているかどうかではなくて
お前がちゃんと理由を言えるかって問題なんだが？
なに？何も考えてなかったの？
749 ：デフォルトの名無しさん：2014/04/07(月) 21:49:31.82 ID:ELF13Pet.net: >>748
ロックでもアクセス管理でもいいんだけど、分散レポジトリ環境全体でそれを実現するには
全レポジトリが相互に管理情報のやりとりをする必要があるのは理解できてる？
750 ：デフォルトの名無しさん：2014/04/07(月) 23:00:16.22 ID:aZ3ao3+q.net: ロック不要なのは、ロック解除後に前のバージョンに戻す馬鹿がいるからだよ。

(1)書き込もうとしたら何かエラーになった。
(2)取っておこう。
(3)updateしたら出てきた。動くようになったのかな?
(4)元に戻してcommit。

結局、運用ルール必須。
751 ：デフォルトの名無しさん：2014/04/07(月) 23:29:19.10 ID:vR3IoiGJ.net: あるファイルの5番目に編集したハッシュタグを知る方法を教えてください
HEAD@{4}だとマージしたとか関係ないとこに当たるからだめでした
752 ：デフォルトの名無しさん：2014/04/08(火) 01:55:28.06 ID:ne0TjbLI.net: 5番目ってどっからどう数えるの？
普通にログを目で追うんじゃだめなん？
753 ：デフォルトの名無しさん：2014/04/08(火) 02:09:48.67 ID:4nGfwtCH.net: https://github.com/progit/progit/commits/master/README.md
こゆの？
754 ：デフォルトの名無しさん：2014/04/08(火) 03:19:33.60 ID:y9DHWvxi.net: こういう感じです
対象:Aファイル
最後に編集した3番目の例えると・・・

(古い)
git init
Bファイルを編集&コミット
Aファイルを編集& コミット　←５　ここのハッシュタグが知りたい
ブランチ切り替え
Bファイルを編集 & コミット
Aファイルを編集 & コミット ←４
ブランチ切り替え
マージ
Aファイルを編集 & コミット ←３
Aファイルを編集 & コミット ←２
Aファイルを編集 & コミット ←１　ここからカウント
Bファイルを編集 & コミット
git push
(新しい)
755 ：デフォルトの名無しさん：2014/04/08(火) 03:20:42.76 ID:y9DHWvxi.net: x 最後に編集した3番目の例えると・・・
o 最後に編集した5番目の例えると・・・
756 ：デフォルトの名無しさん：2014/04/08(火) 04:24:33.49 ID:czY7oW3r.net: こう？
git log --oneline -- Aファイル
757 ：デフォルトの名無しさん：2014/04/08(火) 05:05:27.05 ID:fyVeu966.net: >>749
>>729 のリンク先も見てないのか
758 ：デフォルトの名無しさん：2014/04/08(火) 05:28:35.31 ID:lmbIx31P.net: >>729で説明してるのは単純な中央リポジトリに対するアクセス制御を実現する方法

Gitの場合は中央リポジトリを持たない運用とか、
中央リポジトリがあってもリポジトリが多段の階層を構成してるような運用とかがあって、
>>729みたいな単純な実装じゃ不十分なんだよね

本格的にやるならリポジトリが相互にアクセス制御情報を交換するような実装が必要になるけど
複雑な仕組みになるからやらないだろうな
759 ：デフォルトの名無しさん：2014/04/08(火) 05:37:37.12 ID:WTPhN4IX.net: っていうか、subversionだって
ローカルでファイルを修正すれば同じことだろ？

ロックがかかった状態と言っても、
ローカルで作業している分にはネットワーク切れてるわけで、
当然ローカルにあるものは読み書き可能。
760 ：デフォルトの名無しさん：2014/04/08(火) 12:42:51.84 ID:EM68hGAU.net: LinuxでおすすめのGUIってなんですか？
SourceTreeがインストールできないので残念です
761 ：デフォルトの名無しさん：2014/04/08(火) 13:08:04.31 ID:1S0CFyLG.net: >>758
> 複雑な仕組みになるからやらないだろうな

難しいかどうか以前に、本質的に無理でしょ。
同時にロックされたときの排他制御が必要だから、なんらかの中央集権は必要。
ただちょっとした開発でもその手のサーバーは持ってると思うけど。
762 ：デフォルトの名無しさん：2014/04/08(火) 15:00:40.14 ID:lmbIx31P.net: >>759
subversionとかのロックはファイルを編集する前にかけるの
ローカルに編集する前に中央のサーバに問い合わせて、自分がファイルを編集できるかどうかを確認する
763 ：デフォルトの名無しさん：2014/04/08(火) 15:16:54.95 ID:L1P7kA7L.net: >>762
いや、ファイルの読み取り専用属性を解除すれば
ロックかかっていても修正できるから。
764 ：デフォルトの名無しさん：2014/04/08(火) 16:06:55.87 ID:lmbIx31P.net: subversionでロックをかけるには中央サーバとの接続が必要で、
お互いがロックをかけてから編集するというルールを守っている限りコンフリクトを抑止できる
ここまではいいかな？

gitで同じような効果を得るには中央サーバが必要になる
しかしgitの場合には>>758で示したように、中央サーバに該当するものが存在しないとか、
中央サーバーが直接ローカルからアクセスできない環境で運用される場合がある
それらに対応できない以上gitにおいては中途半端な実装と言うしかない
765 ：デフォルトの名無しさん：2014/04/08(火) 18:28:01.34 ID:ne0TjbLI.net: そもそも
コンフリクトを抑止して「効率的に開発する」という目的に対しては
ロック機能自体が中途半端な存在ってことでしょ

できる/できないの話とやる/やらないの話が
ごっちゃになってる感じ
766 ：746：2014/04/08(火) 18:30:28.02 ID:9wIzdaaz.net: お前ら親切だなあ。
767 ：デフォルトの名無しさん：2014/04/08(火) 23:59:46.81 ID:Sb5AZ4FB.net: ローカルではgitを使い、本家へのコミットにはsvnを使う
というのがプロのやり方だよね
768 ：デフォルトの名無しさん：2014/04/09(水) 00:46:29.18 ID:Lm8qyw/W.net: >>763
ツールが想定する運用と違う使い方してダメだしとか、頭おかしいのか？

>>764 もそうだけと、いかなる構成に対応できるって言ってるわけじゃないだろ。
ロック使いたいならこんなやり方でできますよって言ってるだけなんだから、必要ないならスルーすればいいだけのこと。
769 ：デフォルトの名無しさん：2014/04/09(水) 00:47:27.96 ID:BYGGYeeL.net: だからロックを使いたいやつをgitに呼びこむのがそもそもの間違いだろ
770 ：デフォルトの名無しさん：2014/04/09(水) 00:48:26.64 ID:hkLzWOQG.net: 何を使うかは上が決める
トップダウン
771 ：デフォルトの名無しさん：2014/04/09(水) 00:56:42.97 ID:yn/sF65z.net: gitでもロックできるみたいだからロック使った運用しろなんて馬鹿な上が言ってくるかもしれないからな
分散管理に対する不自由と引き換えになる不完全なやり方だってことを書き込んでおかないとね
それを承知で使うなら別に構わないんじゃないか？
772 ：デフォルトの名無しさん：2014/04/09(水) 01:42:35.53 ID:S7o8PceK.net: ロックって聞くとすぐ発狂するよなGit信者って
自由の戦士のつもりかなんかなのか？
773 ：デフォルトの名無しさん：2014/04/09(水) 01:52:21.50 ID:BYGGYeeL.net: >>772
だからCVSを死ぬまで使ってろよ、あれだって自由ソフトウェアだぞ
774 ：デフォルトの名無しさん：2014/04/09(水) 02:10:11.00 ID:j9Z2BVsM.net: >>772
ROCKってのは心揺さぶるもんだろう、お前も一緒にシャウトしようぜ

…と言うのは流石に冗談として、lockが無いと発狂してる人に、落ち着けと言ってるだけにしか読めないんだがなあ
何にしても元々オプソ用だったgitにlockなんて百害あって一利も無いだろうし、どうにも必要なら素直に別の使えば良い
775 ：デフォルトの名無しさん：2014/04/09(水) 02:28:49.32 ID:zsoCf0EM.net: lockのあるツールでlockかけたまま会社を休んだのがいて仕事にならなかったのを
経験するとlockのあるツールを積極的に使おうという気はなくなるけどな。
776 ：デフォルトの名無しさん：2014/04/09(水) 02:53:43.97 ID:6tz1smtb.net: >>775
ロックと言ってもただの読み取り専用属性なので
解除すれば編集できるよ。
777 ：デフォルトの名無しさん：2014/04/09(水) 02:57:15.26 ID:TCIMdxjw.net: >>774
> 何にしても元々オプソ用だったgitにlockなんて百害あって一利も無いだろうし

意味わからん
OSS がどう関係するかもわからんし、一利ないと言うのはいいとして、百害ってなんだ？
なんか lock を凄いガチガチの機能だと思ってねーか？
778 ：デフォルトの名無しさん：2014/04/09(水) 03:03:57.78 ID:NE6iElAu.net: まず、ロックを使うという前提だとする。
つまり、ファイルを編集する前には必ずロックをかけるということ。

普通プログラムするときは、編集対象が予め分かるわけじゃない
ソースコード眺めていって、問題があるファイルを修正する。

ここまではいいね？

・ネットワークにつながってない状態でどうやってロックをかけるのか？
・ロックがかかった状態で、そのファイルを他の人が修正したい場合はどうするのか？
・ロックを解除しないまま長期休暇した場合はどうするのか
（ロックを強制的に外すという案は、なら最初から外せばいいのでロックの利点？とは反する）

これに答えて欲しい。

ロックを外せば（無視すれば）運用できるじゃねーか。という意見が正しいなら、
最初からロックはなくていいのではないか？という答えになる。
779 ：デフォルトの名無しさん：2014/04/09(水) 03:43:52.22 ID:j9Z2BVsM.net: と言うか前提が分からんなあ
ローカルコミット出来ないようにロックするのか、プッシュ出来ないようにロックするのか…
780 ：デフォルトの名無しさん：2014/04/09(水) 04:28:13.15 ID:Qxi8LBwl.net: まあコミットするのにいちいち書類提出しなくちゃいけないようなルールの運用もあるっていう噂だし、
ロックが必要だっていう社内論理も同様にあり得るんじゃないの。

けど、ロックの要不要はそもそもどういう運用ルールなのかによってかなり変わってくると思うのに、その前提を共有する以前に
ロックがあったほうが便利だのロックなんて無意味だの言っても平行線をたどって終わりだろう。

そもそもここバージョン管理システムスレじゃないしバージョン管理システムにロックがあったほうがいいのか悪いのかっていう話題はスレチだと思うけどね。
スレチだからやめろとかうるさいことを言いたいわけじゃないが。

けど個人的な意見を言わせてもらえば、特別運用ルールや利用形態を指定しないのならここはGitスレなんだし、
「ロックなんてあったって中途半端で意味ないだろ」っていう意見の方が支配的だと思うけどな。状況限定の例外はもちろん認める。

ロックが必要、って言ってる人はVCSにロックが必要だと思ってるのか、Gitにロックが必要だと思ってるのかどっちなの？
781 ：デフォルトの名無しさん：2014/04/09(水) 04:41:58.28 ID:NE6iElAu.net: 書類提出とか言うのは、そもそも権限の話だから全く違う問題。

ロック禁止というのは、コミットできる権限はあるけど
他の人にコミットさせないと、別の人がコミットを禁止させる行為。

本来コミットしていいはずの人が、コミット禁止される。
なぜ？って話。
782 ：デフォルトの名無しさん：2014/04/09(水) 08:06:53.29 ID:lgQL/971.net: >>778
前提が滅茶苦茶だな。

> まず、ロックを使うという前提だとする。
> つまり、ファイルを編集する前には必ずロックをかけるということ。
> 普通プログラムするときは、編集対象が予め分かるわけじゃない
> ソースコード眺めていって、問題があるファイルを修正する。

なんで全部ロックしようとするんだ？
バイナリ系の (要はツールではマージできない) ファイルだけでいいだろ？

> ・ネットワークにつながってない状態でどうやってロックをかけるのか？

だから、できない状況ならあきらめろよって話。

> ・ロックがかかった状態で、そのファイルを他の人が修正したい場合はどうするのか？

ロックした人と相談しなさいよ。

> ・ロックを解除しないまま長期休暇した場合はどうするのか

連絡つかないとか本人死んだとかなら、ロック解除すればいいだけ。

> （ロックを強制的に外すという案は、なら最初から外せばいいのでロックの利点？とは反する）

意味わからん。
お前さんが考えてるロックの利点ってなんだ？
783 ：デフォルトの名無しさん：2014/04/09(水) 08:14:32.41 ID:lgQL/971.net: >>780
> ロックが必要、って言ってる人はVCSにロックが必要だと思ってるのか、Gitにロックが必要だと思ってるのかどっちなの？

あればいいじゃん、と言うだけのこと。
中途半端で使いにくそうとかいうのならわかるけど、強制解除できるなら意味ないとか、忌み嫌う意図がわからん。

>>781
マージできないからだろ。
784 ：デフォルトの名無しさん：2014/04/09(水) 08:21:10.15 ID:lgQL/971.net: >>781
ちょっと追記

> ロック禁止というのは、コミットできる権限はあるけど
> 他の人にコミットさせないと、別の人がコミットを禁止させる行為。

ロック禁止はロックのことだと仮定して、本来ロックはコミットを禁止させる行為じゃないよ。
編集を開始させないようにするためのもの。
マージできないからその編集は無駄になる可能性が高いからね。
785 ：デフォルトの名無しさん：2014/04/09(水) 08:39:15.17 ID:rnHKJbd8.net: そのうちDBの排他ロックすら許せなくなっちゃうんだろな
786 ：デフォルトの名無しさん：2014/04/09(水) 10:48:27.45 ID:Cs/4QDoa.net: ロックがゲシュタルト崩壊
787 ：デフォルトの名無しさん：2014/04/09(水) 11:54:59.42 ID:Bivk+KoI.net: >>785
RDBMSにはマージという概念がないだろう。
788 ：デフォルトの名無しさん：2014/04/09(水) 11:59:27.20 ID:S7o8PceK.net: 確かにGitってテキスト主体のオープンソースの分散開発ならいいけど、
社内とかの仕事で使うにはあまり意味ないよね。

各人勝手にソースいじることないし、最終的にどこを取り入れるか判断する
人の負担が大きいし。
789 ：デフォルトの名無しさん：2014/04/09(水) 12:49:11.67 ID:Cs/4QDoa.net: >>788
意味ないとまでは思わないが、効果が薄いと言わざるを得んな。

文書は全部Officeでマージできない、開発メンバはSubversionのこ
とをちょっと面倒な共有ファイルサーバくらいに思ってる、といっ
た環境だと、苦労してGitに変える必要もないかなって思う
790 ：デフォルトの名無しさん：2014/04/09(水) 13:32:32.32 ID:Qxi8LBwl.net: >>783
多分、ロックがあった方が美味しいってことが多いシチュエーションでは、Gitなんか使わない方が皆幸せだってことをロックを嫌がる人は思ってるんじゃないのかな？
リソース画像ファイルとかですらGitのリポジトリには含めるべきではないっていう原理主義の人多いし。
自分は原理主義もわかるけど、自分の利用ではリソース画像ファイルとかは必須なので、なんとかうまいことする方法があればいいのにな(他VCS含め)と思っている。

Gitにロックがあればいい、というあなたの立場は理解した上で、どういう実装があり得ると思う？自分は上手い、と思う方法が見つからないよ。
791 ：デフォルトの名無しさん：2014/04/09(水) 14:23:46.87 ID:mAyum7ca.net: ファイルの中にパスワードを書いたままGitHubにプッシュしたんですけど
これはまずいと思ってパスワードを削除したファイルをプッシュしたんです。
でも過去の履歴って閲覧できますよね。
どうやって闇に葬り去ることができますか？
バレたら首になるので誰かヘルプ！
792 ：デフォルトの名無しさん：2014/04/09(水) 14:26:33.92 ID:qA8ouB3T.net: github側リポジトリを消す
自分のローカルリポジトリはパスワード追加前のコミット前の状態revert
githubにプッシュし直す
793 ：デフォルトの名無しさん：2014/04/09(水) 14:30:07.03 ID:iLQ9oAQy.net: github の HEAD を他の誰かが取り込んだら終わりだからな
とりあえず迷ってる暇はない
今すぐ github のアカウントごと消せ
794 ：デフォルトの名無しさん：2014/04/09(水) 14:31:36.72 ID:f1/WUzrS.net: 凍結してfilter-branchの練習かな
795 ：デフォルトの名無しさん：2014/04/09(水) 14:31:48.87 ID:yn/sF65z.net: >>791
最初にやるべきことはそのパスワードそのものを無効にすることだよ
もちろんそのパスワードを外部にさらしてしまったことを回りにちゃんと説明しろ
796 ：デフォルトの名無しさん：2014/04/09(水) 14:54:17.61 ID:mAyum7ca.net: みなさんありがとうございます
入社して7日目で首だけは避けたいのでアドバイスを参考に動いてみます
797 ：デフォルトの名無しさん：2014/04/09(水) 15:03:21.10 ID:TDs0SH97.net: >>790
> 原理主義の人多いし。

たかがツールなんだから便利に使えればいいと思うんだけどね。
まあ、無節操に機能を取り込んで逆に使いにくくなるとかは勘弁してと言うのはあるとは思うけど。

> どういう実装があり得ると思う？自分は上手い、と思う方法が見つからないよ。

排他が必要だから俺も中央サーバーたてる以外の方策は思い付かない。
798 ：デフォルトの名無しさん：2014/04/09(水) 16:32:18.38 ID:Bivk+KoI.net: 入社して7日目に2chに書き込んでいるとか
799 ：デフォルトの名無しさん：2014/04/09(水) 17:55:39.06 ID:n694gffx.net: >>797
>たかがツールなんだから便利に使えればいいと思うんだけどね。

こういうのって自分だけはメタ視点、なつもりで高所から見ているつもりだろうけど、
誰でも分かってる当たり前のこと言ってるだけだよな。
当面の議論には参加する能力がないけど、偉そうな態度だけは取りたいという。
800 ：デフォルトの名無しさん：2014/04/09(水) 19:50:12.68 ID:Qxi8LBwl.net: >>797
> たかがツールなんだから便利に使えればいいと思うんだけどね。
いや、原理主義は大事だと思うよ。本当に無理やり目的を達成したほうがいいのかをそもそも論で考えるのは大事だと思うから。
ただ、原理主義に固執するあまりに状況も把握せずに全否定、ってのは良くないと思うけど。

「便利に」使えればいいというのはその通りなんだけど、ツールの設計思想や構造を無視して「こういう機能があると便利なんだけど」って言ってもしょうがないとも思う。
乗用車にトイレがあったら便利だと思うけど、トイレを実装するには様々な困難があるし、乗用車の存在目的を考えたら外部化したほうがいいでしょ？
そういうところを無視して「便利だと思うからつけたっていいじゃん」ってのもまた、同意できない。
801 ：デフォルトの名無しさん：2014/04/09(水) 19:53:10.76 ID:/il1zge6.net: gitは単なるツールでそれを運用するシステムは別でしょ
そのシステムがgitを前提としてなかった場合、システムがgitに合わせることになる
802 ：デフォルトの名無しさん：2014/04/09(水) 20:03:23.61 ID:TDs0SH97.net: >>799
いきなりどうした？
なんか悔しかったのか？ (w

>>800
まあそこは色々な考え方あってしかるべきだし、使い方は人によって違うしね。
車の例えなら、キャンプ大好きで自家用車をキャンピングカーにしてるような人なら、トイレもあった方がいいと思うかもしれないよね。
設計者には悪いけど個人的に使うなら設計思想関係なく便利に使えばいいと思うよ。
803 ：デフォルトの名無しさん：2014/04/09(水) 20:07:57.73 ID:TDs0SH97.net: >>801
システムって具体的にどんなのを言ってるの？
804 ：デフォルトの名無しさん：2014/04/09(水) 20:24:29.52 ID:yn/sF65z.net: Gitはあくまでもソースコードの分散バージョン管理ツールであって
そのために必須ではない機能を何でもかんでも突っ込むのはUNIX的なやり方じゃないね

バイナリファイルとかの管理のために分散環境ではうまく機能しないロックが必要だっていうなら、
そういう仕組みをGitとは別に新しく作ればいい
もちろんそれを実現するのにGitを利用するのは構わないけど、
Git本体を肥大化させるのはダメだ
805 ：デフォルトの名無しさん：2014/04/09(水) 20:42:11.70 ID:/il1zge6.net: >>803
会社みたいに複数人で開発する場合、集中管理できるようなツール入れることになるでしょ
そこで、どのツールを使うとか、そのツールで管理してる各リポジトリに対して、誰にどれだけの権限を与えるとか
gitをバージョン管理ツールとして導入して運用するのに必要な管理ツールやルール的なものという意味でのシステム
806 ：デフォルトの名無しさん：2014/04/09(水) 20:44:43.35 ID:yIe5cirA.net: そんなに便利な機能なら拡張作れば大人気だろう
807 ：デフォルトの名無しさん：2014/04/09(水) 21:14:14.88 ID:TCIMdxjw.net: >>805
いわゆる運用系の話しかな
なら、ツールにうまく合わせるのは当たり前やね

>>806
便利だとは思うが、本質的に分散システムでは実現が難しいから、かなりの部分を運用でカバーする必要があると思う
808 ：デフォルトの名無しさん：2014/04/09(水) 21:20:04.93 ID:hkLzWOQG.net: 分散システムの本質ってなんだろうな
809 ：デフォルトの名無しさん：2014/04/09(水) 23:01:23.09 ID:vvfK+6uV.net: >>800
原理主義っていうことの意味自体が排他的なネガティブなものなので、原理主義が
大事ってのは普通の感覚だとありえないんだけどね。保守的よりさらに変化を
認めないってのが原理主義だから。
810 ：デフォルトの名無しさん：2014/04/09(水) 23:14:37.88 ID:Sjt9OQJN.net: >>802
いや、お前自分ではドヤ顔だけど、つまんねえだけだよ、と誰か教えてやった方がいいと思ったからさ。
811 ：デフォルトの名無しさん：2014/04/09(水) 23:20:38.44 ID:wiNih1s9.net: GitってVSSみたいにファイルのチェックイン、チェックアウトを厳密に
アトミックにロックするやり方の管理もできるの？

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。
812 ：デフォルトの名無しさん：2014/04/09(水) 23:20:46.34 ID:Il0l8m2A.net: WindowsでGitをインストールすると.gitconfigの[core]の項目が存在しますが
Linuxでソースコードから入れると、入れたばかりだと.gitconfigは存在しません。
名前とメールアドレスを登録したら自動的に.gitconfigが作られますけど
Linuxでは[core]の部分は設定しなくてもいいのでしょうか？
例えばautoCRLFとか
813 ：デフォルトの名無しさん：2014/04/09(水) 23:41:10.33 ID:hkLzWOQG.net: Git - Gitのインストール
http://git-scm.com/book/ja/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB

Git - 最初のGitの構成
http://git-scm.com/book/ja/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-%E6%9C%80%E5%88%9D%E3%81%AEGit%E3%81%AE%E6%A7%8B%E6%88%90

Git - Git のカスタマイズ
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA
814 ：デフォルトの名無しさん：2014/04/10(木) 00:00:04.05 ID:ZuhRq4by.net: >>802
もちろんそれぞれの解があっていいと思うけど、トイレと車での移動を両立しようと思ったら、なにか諦めなくちゃいけないじゃない。
汚物を自分で処理するということなのか、上水下水を駐車時に勝手に流してくれるようなステーションにしか行けないような車を作るのか、諦め方は色々あると思うけど。

どういう方向に諦めるのかってのは設計思想と利用ケースによって最適解が違うから、そこを詰めずに話題にしたら「万能な方法はない」で終わっちゃうよね。
もちろん個人で使うなら自由にすればいいと思うけど、背景を共有せずに不満だけ書かれてもチラシの裏なわけで「で？」ってなってしまう。

>>809
すまん、それは言葉が悪かった。本来あるべき正当な立場に立ってものを考えてみることもときには重要だ、くらいの意味だけど。
ツールを開発してる本人たちは原理主義であるほうが軸がブレブレのツールとかにならなくていいかも、って思って原理主義って言葉が出てきたのかもしれない。
815 ：デフォルトの名無しさん：2014/04/10(木) 00:17:43.20 ID:ZuhRq4by.net: ちっ、ID変わる前に書き込んだほうがわかりやすいと思ってギリギリに書き込んだのにちょっと遅れてID変わってしまった。

>>801とか>>804のような話は正論だと思うんだけど、具体的にそれをうまくやるツールっていうのが定番がないよね。
多分、状況によって必要な実装が変わってくるから定番的なものは用意できないのか、まだみんなツールを開発するのを面倒臭がってだましだましGitを使ってる人が多いのか。
と思って調べてたら、本格的なのだとgit-annex、フィルターで済ませるのとしてはgit-largefileとかあるみたいね。
git-annexにはロック機能もあるみたい。(基本annexで管理してるものはロック状態らしい)

けどやっぱり>>804の言うように、バイナリの管理って小さいものだったらまあなんとかロックさえあればいいのかもしれないけど、ムービーくらいのでかいものを管理しようと思ったら
いきなりリポジトリのサイズがどんどんでかくなってまともに使えなくなるわけで、Git本体を考えなしに肥大化させちゃうような進化の方向はよろしくないと思うな。
結局、便利に使うためには「どういう理由で何を実現したくて、今後何が起きるか」ってことをちゃんと考えなければ便利には使えないわけで。
816 ：デフォルトの名無しさん：2014/04/10(木) 00:19:25.54 ID:cllo9doH.net: >>808
離れた相手の作業に邪魔されないこと
817 ：デフォルトの名無しさん：2014/04/10(木) 00:26:21.34 ID:NS7eKWAh.net: ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。
818 ：デフォルトの名無しさん：2014/04/10(木) 00:36:06.16 ID:I4ZYtafb.net: >>817
ウォーターフォール型のプロジェクトで、
ソースファイルの同じ位置を複数の人で編集しまくることとかあるの？
コンフリクトが簡単に解決できないようなファイルの編集が複数の人の間で頻繁に発生するとか、
有り得ないと思うんだけど
819 ：デフォルトの名無しさん：2014/04/10(木) 00:40:22.58 ID:qnngGCyM.net: >>817
頻繁にコンフリクトが起きるようなプロジェクトならsvnだろうが他のだろう関係なく
起きるよ。コンフリクト以前にsvnのマージ作業なんて、作った奴死ねって思う
くらいひどいし。そういうマージやらコンフリクトの解消のコストがgitは他のに
比べて圧倒的に低いからgitは使う価値があると思う。 svn使ってるならローカルで
git svn使う方がはるかに楽だし。
820 ：デフォルトの名無しさん：2014/04/10(木) 00:45:26.37 ID:GmndHch1.net: 自分だけしか使ってないリポジトリで
今までコミットしてきた時の名前を変更したいんですが
どうやるのか教えてください
適当に名前をつけてたのですが、今後他の人もコミッターに加わるので名前を変えたいんです
821 ：デフォルトの名無しさん：2014/04/10(木) 00:45:46.71 ID:08KdAoTS.net: 何でコンフリクトが起きる事を問題視してる人がいるのかよくわからん。
gitというツールを運用する環境をどう構築するかを考えた方がいいんじゃないの
そもそも、svnで問題なかったのならsvnでいいでしょ
svnもgitもツールなんだし、適材適所
822 ：デフォルトの名無しさん：2014/04/10(木) 00:46:16.32 ID:I4ZYtafb.net: >>819
簡単に解決できないようなコンフリクトって例えばどんな場合におこるの？
けっこう複雑な関数を同じ人がいじりまくるとかするの？
823 ：デフォルトの名無しさん：2014/04/10(木) 00:46:17.65 ID:GmndHch1.net: .gitconfigで名前を変えとけば過去の名前も変わると思ったんですがダメでした
824 ：デフォルトの名無しさん：2014/04/10(木) 00:57:11.44 ID:Aw1WhgbR.net: 正直同じ関数に対する修正みたいなのは被らないようにチケット割り振りしたいわな
オープンソースみたいにいつ誰がどんな修正してるかわからんようなのはともかく
チームでやってる時は少なくともわかってる範囲内では影響範囲かぶらないようにしてる
825 ：デフォルトの名無しさん：2014/04/10(木) 01:01:23.41 ID:I4ZYtafb.net: >>823
git filter-branch
826 ：デフォルトの名無しさん：2014/04/10(木) 01:34:13.89 ID:1wauUDTZ.net: オープンソースならメールなり掲示板なりircなりでやりとりしてるのが普通だよ
827 ：デフォルトの名無しさん：2014/04/10(木) 01:40:17.05 ID:u/ao0IlG.net: >>821
コンフリクトというのはいわばバグですよ。
バグは起きてはいけない
コンフリクトも起きてはいけない。

subversionを使っている人はそう言ってました。
馬鹿ですよねｗ
828 ：デフォルトの名無しさん：2014/04/10(木) 01:46:32.26 ID:67sTFnF/.net: >>826
開発が活発なOSSについてはそうだろうけど
開発者が実質１人だとかメンテナ不在ってのが
OSSの「普通」（圧倒的多数）だと思うけどね
829 ：デフォルトの名無しさん：2014/04/10(木) 01:58:20.93 ID:67sTFnF/.net: 作業が無駄になろうがマージがめんどくさかろうが
コンフリクトが顕在化するのはまだ幸運な方だよね

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

gitには悲劇を早く終わらせるのに役立つ機能はあっても
現状のバージョン管理システムでは悲劇の発生は阻止できそうにない
830 ：デフォルトの名無しさん：2014/04/10(木) 02:01:03.17 ID:u/ao0IlG.net: >>829
その為にテストを自動化するんでしょ？

それに二人の人が作業するのであれば
ロックをかけていたとしても
機能上コンフリクトは起こるわけだし。
831 ：デフォルトの名無しさん：2014/04/10(木) 02:01:31.21 ID:o2rx8JxT.net: >>729の燃料投下から100レス目か
832 ：デフォルトの名無しさん：2014/04/10(木) 02:08:15.66 ID:67sTFnF/.net: >>830
gitだろうとロック機能のあるツールだろうと
顕在化するコンフリクトなんて可愛いもんで
熱く議論するほどのことじゃないよねって言いたかった
833 ：デフォルトの名無しさん：2014/04/10(木) 02:15:53.96 ID:uhNdSeYA.net: ロックでなんとかなると思ってるのは、コード書いてない証拠。
書き始めたら結局マージするはめになる。
834 ：デフォルトの名無しさん：2014/04/10(木) 02:40:10.12 ID:UBKps7J1.net: ま、適切に機能分割されてて、関数やファイルで構造化されていれば、酷いコンフリクトなんかそうそう起きないわな
835 ：デフォルトの名無しさん：2014/04/10(木) 04:06:22.99 ID:1wauUDTZ.net: 実質１人だとかメンテナ不在ならそもそも
いつ誰がどんな修正してるかわからん
みたいな♪心肺ないからね
836 ：デフォルトの名無しさん：2014/04/10(木) 07:51:39.22 ID:1X5BHIzm.net: >>810
つまんないなら、スルーしとけよ (w

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

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

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

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

みんなが動画を管理する訳じゃないでしょ。
なんか無理矢理できない例を探してない？
837 ：デフォルトの名無しさん：2014/04/10(木) 08:01:21.07 ID:1X5BHIzm.net: >>824
同じファイルならまだしも、同じ関数を複数の人が同時に触るとかなんかの間違いでもない限り 100% あり得ないよね。
コンフリクト心配してる人はどんな管理してるんだろう？

>>829
ひょっとして、バグ見つけたら担当者が勝手にちゃちゃっと修正してるの？
他に影響するような修正なら、仕様書の修正とかレビューするだろ、普通。
838 ：デフォルトの名無しさん：2014/04/10(木) 12:25:06.48 ID:NS7eKWAh.net: 上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

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

Gitだと複数の人が同じところ勝手に直しだしたりしても検出できないでしょ。無駄な作業が発生するわけ。
どっちが悪いとかじゃなくて、Gitが向いてないタイプの管理が企業内にはあるってこと。
おわかりかな？
839 ：デフォルトの名無しさん：2014/04/10(木) 12:34:43.21 ID:IB1wq0Eb.net: ハサミでネジが締められないからハサミはクソと喚いてるわけだな
840 ：デフォルトの名無しさん：2014/04/10(木) 13:36:34.66 ID:tZxH7aP+.net: 立派な大企業様なら、クソみたいなOSSを使わないで、自分達で作るなり買うなりすれば
いいのにねー。2chでアレがデキない、コレがデキナイと喚いているだけなら、無職に
も劣る。
841 ：デフォルトの名無しさん：2014/04/10(木) 13:43:39.90 ID:I4ZYtafb.net: どこを直すかの管理をバージョン管理ツールに頼るとかありえないんだけど
842 ：デフォルトの名無しさん：2014/04/10(木) 13:59:14.88 ID:WPYZbZRA.net: ユーザーとタスク管理までさせられるVCSは大変ですね
843 ：デフォルトの名無しさん：2014/04/10(木) 14:59:48.19 ID:vqBRkjrb.net: 開発効率をUPする Git逆引き入門 [単行本（ソフトカバー）]
http://www.amazon.co.jp/dp/4863541465/

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

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

こっちは親切で情報を提供しているのに、なんで本の紹介されると発狂する奴っているんだろうな？
まあ、身の回りみていても、本代ケチるようなのにろくな技術者いないけど。
844 ：デフォルトの名無しさん：2014/04/10(木) 16:12:50.21 ID:Aw1WhgbR.net: 難癖つけるやつの方が声がでかいだけの話しだから気にすんな
845 ：デフォルトの名無しさん：2014/04/10(木) 17:41:18.36 ID:8TUEkxNY.net: すばらしい技術書を親切心で紹介します！異論を唱えるのはキチガイだけ！
この本が手に入るのにたかが数千円のはした金も出さないのはまともな技術者じゃありません！
いますぐ買ってまともな技術者になりましょう！

あほか
846 ：デフォルトの名無しさん：2014/04/10(木) 17:43:40.06 ID:N3vuTs56.net: フォークして修正を送る時ってブランチの名前はなんてつけていいのか教えてください
例えばさtestってブランチで送った場合、他の人もtestで送ってたらダブっちゃいますよね
ダブった場合もコンフリクトしちゃうんですか？
847 ：デフォルトの名無しさん：2014/04/10(木) 17:55:01.85 ID:B7i8mwfP.net: >>843
まあこのスレじゃないけどステマっぽいのはあったし、実際あなたの書き込みがステマかどうか判断しようがないからね。
そんな風に言われるのが嫌ならこの手の掲示板は避けた方がいいと思うよ。

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

> まあ、身の回りみていても、本代ケチるようなのにろくな技術者いないけど。
848 ：デフォルトの名無しさん：2014/04/10(木) 18:02:26.77 ID:3faYMJHc.net: >>843
知らなかったので本の紹介には感謝する
ただ、余分な書き込みは必要なかったかな
何にでも文句を言う人はどこにでもいるから
それをスルーできない人は書き込まない方が精神衛生上いいのかも

ともあれ今から本屋行って立ち読みしてくるよ
849 ：デフォルトの名無しさん：2014/04/10(木) 18:13:00.11 ID:PAL5W9yR.net: >>843
ステマ言われるのそんなにないやろ
こないだGitHubの本でステマ言われてたやつはあったけどアレは本当にいろんなところでみたからな…
850 ：デフォルトの名無しさん：2014/04/10(木) 18:18:14.35 ID:2hD55smI.net: そろそろ誰か寸評とか星付きのGit本リスト作ってテンプレに入れてよ。
851 ：デフォルトの名無しさん：2014/04/10(木) 18:25:00.33 ID:B7i8mwfP.net: >>839
う～ん、ハサミに例えると、たまに 3cm とかの幅で切りたいから、目盛りみたいのがついてたら便利じゃね？って感じかな。
そんなことしない人には不要なんだけど、使わなきゃ邪魔になるわけでもないしね。
852 ：デフォルトの名無しさん：2014/04/10(木) 18:32:01.98 ID:I4ZYtafb.net: GitHub実践入門はGit本体についての説明はゴミみたいなもんだし、
あれを入門書の決定版とか紹介したら叩かれて当たり前だな

逆引き入門の方は、ちょっと立ち読みしてきたけど、
これから始める人にもある程度使ってる人にもいいと思うよ
853 ：デフォルトの名無しさん：2014/04/10(木) 18:40:25.42 ID:sy5Vj+v2.net: >>851
うーん、その例えも何か違う気がするなあ
Gitに付けるのは変だと思う、でもGithubに付けるならアリだと思うんよね
ハサミで言うなら、ハサミの歯のパーツを作ってるトコが目盛り付けちゃう感じがする
854 ：デフォルトの名無しさん：2014/04/10(木) 18:50:01.99 ID:8TUEkxNY.net: たまに話題になるくらいならいいが新刊出るたびにレビューするのは尼でやってくれ
855 ：デフォルトの名無しさん：2014/04/10(木) 19:24:24.61 ID:B7i8mwfP.net: >>853
ああなるほど、そうかも。
別にツールでやろうが、システムでやろうが、できればいいじゃんというスタンスなので。
856 ：デフォルトの名無しさん：2014/04/10(木) 19:57:43.91 ID:N3vuTs56.net: 846おねがいします
857 ：デフォルトの名無しさん：2014/04/10(木) 20:42:39.14 ID:1wauUDTZ.net: 目的とか自分のid的なものとか組み合わせたり
858 ：デフォルトの名無しさん：2014/04/11(金) 00:18:39.32 ID:MhGpUxGc.net: Gitは～には向かないのでは？　という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。

大組織での開発にも、いや、Gitってこういう使い方すれば役に立つよ、という書き込みなら
まだ建設的な議論が出来そうだけど、具体的な内容ゼロの当てこすりや小馬鹿にしたような
書き込みばかり。

まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね？
と思う。
859 ：デフォルトの名無しさん：2014/04/11(金) 00:20:54.93 ID:tDVfunDo.net: 自分は違うんだぞ、って言う自意識過剰なレス乙
860 ：デフォルトの名無しさん：2014/04/11(金) 04:46:00.71 ID:KAyUJDly.net: >>858
小馬鹿にするっていうか、「～には向かないのでは？」って書いてる奴が馬鹿過ぎるんだものｗ
861 ：デフォルトの名無しさん：2014/04/11(金) 05:10:33.92 ID:dLUSGIri.net: >>846
上流が何か命名規則を指定してるならそれに従う
してないならなんでもいいが、ブランチの意図を端的に表した名前にするのがお勧め
技術的にはマージするときのブランチ名は単にコミットを指すポインタなのでコンフリクトは起こらない
GitHub上の詳細は知らんがユーザなり何なりで別の名前空間に分離されてるはず。
プルリクが活発なリポジトリの画面眺めてみろ
862 ：デフォルトの名無しさん：2014/04/11(金) 05:31:32.87 ID:dLUSGIri.net: ロック必要だよ派は

1. 簡単にマージできない類のファイルを扱う必要がある

2. その手のファイルに対する編集作業を黙って初めてしまうとあと
で大変なので、編集しようとしたやつがいたら競合の可能性があ
ることを作業前に警告したい

と言ってるように思えるが、そういう要件は分散VCSというか分散作
業とは相性悪い。誰かも言ってたが、実現には技術的に困難が伴う
し、分散作業時に他人の作業に足を引っ張られないことを重視する
人からしたら、分散作業の良さをスポイルする機能を実装して誰得
状態なわけだし

解決方法は様々だが、会社で使うんなら「今からこのファイル編集
します」ってメールなりでコミュニケーションとれよと思う。

いちいちそんなコミュニケーション取ってらんねーよとおもった？
分散作業の世界へようこそ。
863 ：デフォルトの名無しさん：2014/04/11(金) 07:17:31.56 ID:tDVfunDo.net: >>862
> コミュニケーションとれよと思う。

ロックはそのための仕組みなんだが...
そもそも、誰が編集するかわからないのに誰にメールするんだ？
関係者全員とか迷惑なんですけど。
864 ：デフォルトの名無しさん：2014/04/11(金) 08:29:42.74 ID:KpoPG81P.net: >>863
＞そもそも、誰が編集するかわからないのに誰にメールするんだ？

自社開発だろうが、人売りで売られた先だろうがオプソだろうがなんだろうが
ある程度以上の規模になったらプロジェクト全員が入っているMLなりIRCなり
Skypeなりのプロジェクト全員への共有連絡先位あるだろ。プロジェクトの
関係者以外にコミット権限を渡しているのなんて普通ないからそういう所に
一報を入れておけば事足りし。
865 ：デフォルトの名無しさん：2014/04/11(金) 08:36:31.74 ID:eJqQZ1pt.net: >>864
都合の悪いところを読み飛ばす癖直した方がいいぞ。

> 関係者全員とか迷惑なんですけど。
866 ：デフォルトの名無しさん：2014/04/11(金) 10:06:53.15 ID:Hu21eWhF.net: issue tracker ってそんなに普及してないのかな
867 ：デフォルトの名無しさん：2014/04/11(金) 10:15:31.46 ID:pXE62EYm.net: bug tracker ですら怪しいぞ。
とりあえず今までのやり方で回ってる大きな所はリスクとってやり方かえないし。
その気持ちもわからんでもないしなー。
868 ：デフォルトの名無しさん：2014/04/11(金) 11:10:30.81 ID:057GiJd2.net: githubでパッチを送る時ってぷるリクエストとフォークどっちのほうがいいのかおしえて
869 ：デフォルトの名無しさん：2014/04/11(金) 11:31:59.99 ID:pXE62EYm.net: fork しても結局 pull request になる。
勿論直接 pull request 書いてもいい。
870 ：デフォルトの名無しさん：2014/04/11(金) 12:37:49.14 ID:5a7Ytf0i.net: >>534
これ完全に騙されたわ。
専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。

おまけに本に書かれてる詳しい解説をネットにしているURLが間違ってるのか見れない。

この本買うつもりなら、一回本屋で立ち読みして欲しい。
間違ってもネットで注文はしない方がいい。
871 ：デフォルトの名無しさん：2014/04/11(金) 14:53:09.67 ID:H+z7YdpC.net: 茶色い本とgit-scm.comがあれば十分でしょ。
872 ：デフォルトの名無しさん：2014/04/11(金) 18:50:58.20 ID:dLUSGIri.net: >>865
メールに限定してないだろ。ちゃんと読め？

> 都合の悪いところを読み飛ばす癖直した方がいいぞ。

ブーメラン乙
873 ：デフォルトの名無しさん：2014/04/11(金) 19:05:04.23 ID:ZfLpKqnY.net: ロックしてれば後から編集しようとした人はその場で分かるからな
Gitなんかはソースコードを管理する為のツールだから、ロックせずとも後でパッチをマージすればいいって考えるのは妥当だけど、バイナリファイルを管理する場合、その考えは通じない
874 ：デフォルトの名無しさん：2014/04/11(金) 19:10:14.32 ID:im4bHUKa.net: >>872
全員に通知することを問題視してるんだが？
で、メールでなくてどうやるのさ。
掲示板にでも書いといて、編集の前にいちいち確認するのか？ (w
875 ：デフォルトの名無しさん：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
876 ：デフォルトの名無しさん：2014/04/11(金) 21:50:10.15 ID:mRoalEfA.net: >>875
接続先をgithub.com:22からssh.github.com:443に切り替えてトライ。
877 ：デフォルトの名無しさん：2014/04/11(金) 22:14:05.98 ID:TfGD3Njm.net: 接続先を変えるのは・・こまります・・・
878 ：デフォルトの名無しさん：2014/04/11(金) 22:26:00.91 ID:mRoalEfA.net: いいからやってみ。
879 ：デフォルトの名無しさん：2014/04/11(金) 22:35:44.27 ID:gZGZUewy.net: *Gitに*バイナリのロックが必要かどうかについて議論するんじゃなくて、
バージョン管理システム一般にロックが必要かどうかについて話してる奴はスレチなの認識してる？

誰もバージョン管理一般についてロックが不要だと強弁するつもりないし、一般的な話ならなぜここでやる必要があるのか説明してくれ。
880 ：デフォルトの名無しさん：2014/04/11(金) 22:37:52.84 ID:gZGZUewy.net: ロック疑問派「Gitみたいな分散管理システムとファイルのロックは相性が悪い、メールとかで連絡すべき」
ロック必要派「メールで連絡するとかありえない、ロックがあればそれで全て解決する」←はて分散管理との相性の悪さという根本的な問題はどこいった？

関係者全員とか迷惑を読み飛ばされたことに対して都合の悪いとこ読み飛ばすなとか批判するなら、まず相性が悪いものをどうやって実装するのかについて説明してからにしろよ

(忍法帖が消えてレスを分割せざるを得なかった、すまん)
881 ：デフォルトの名無しさん：2014/04/11(金) 22:53:57.78 ID:TfGD3Njm.net: どう変えるのかわかりません・・・
git@github.com:443:アカウント名.リポジトリ名.git
ってやりましたがだめです
ssh -t git@github.comをやっても接続されないしずっと接続を頑張っているのか何も表示されません
882 ：デフォルトの名無しさん：2014/04/11(金) 22:56:34.43 ID:bQVZn08t.net: >これ完全に騙されたわ。
>専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
>見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。

普通専門書ってそういうものだよ。

注釈とか用語解説はまとめて巻末とか当たり前、それとクロスリファレンスしながら読むって
やり方になれておいた方がいい。

普段固い本をまったく読んだことがないんだろうけど、こんなピント外れな批判されちゃう書籍
も可哀想だ。

「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。
883 ：デフォルトの名無しさん：2014/04/11(金) 23:40:30.41 ID:nUaUWR93.net: >>873
つまりソースコードのロックは百害あって一利なしでいいよね？
884 ：デフォルトの名無しさん：2014/04/11(金) 23:43:39.52 ID:nUaUWR93.net: >>882
> 「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。

そういう用途ならこれがいい。
なんかタイトルからクソ本みたいな印象を受けるかもしれないけど
読んでみるとふつうに良い。

アリスとボブのGit入門レッスン-川野辺-正博
http://www.amazon.co.jp/dp/4798035009/
885 ：デフォルトの名無しさん：2014/04/11(金) 23:48:43.96 ID:GvHlzSSy.net: サルでもわかるGit入門 ?バージョン管理を使いこなそう? | どこでもプロジェクト管理バックログ
http://www.backlog.jp/git-guide/

これじゃないの
886 ：デフォルトの名無しさん：2014/04/12(土) 00:33:16.71 ID:cB842cS/.net: >>884
開発の流れに沿ってシーンごとに必要なコマンドがわかるのがいいな
トレードオフで要点が複数ページに散らばっててぱっと読みにくいが
そこはネットかリファレンスを使うべきだし良書

>>885
本が至上という権威主義発言でしょ
難しい本を買うほど偉いという
887 ：デフォルトの名無しさん：2014/04/12(土) 00:53:51.35 ID:lUY660Yq.net: 875です
すいませんconfigでポート443したらいけました
Windowsでは指定しなくてもsshでclone出来るのに
Linuxでは指定しないと接続出来なくてタイムアウトするんですね
やっと接続できたので今から始発まで？仕事です
888 ：デフォルトの名無しさん：2014/04/12(土) 00:58:42.39 ID:+ggEbXVl.net: > 本が至上という権威主義発言でしょ
ん～？単にページ数の問題。
一般的に本のほうが情報量が多い。
889 ：デフォルトの名無しさん：2014/04/12(土) 00:59:15.38 ID:+ggEbXVl.net: 情報量じゃなくて、情報の密度に言い換えよう。
890 ：デフォルトの名無しさん：2014/04/12(土) 01:07:41.37 ID:cB842cS/.net: 背伸びしてる中学生感が痛々しいからやめて
891 ：デフォルトの名無しさん：2014/04/12(土) 01:22:43.30 ID:9dlKXrRX.net: ページ（画面）あたりでなくページ「数」の問題なら
本の方が密度が低いような

「こんなの本買うまでもなかったじゃん！」
って読後に思えるくらいの情報量・密度の方が
入門書としては成功な気がする

そして手元に残るのは入門書ではなく
黒魔術満載のチートシート……
892 ：デフォルトの名無しさん：2014/04/12(土) 03:03:51.85 ID:BW6c4MFF.net: >>874
＞全員に通知することを問題視してるんだが？

多人数でのプロジェクトをしたことないの？コンフリクトが頻繁に起きるような
共有ファイルの編集が必要な場面で通知がない方が問題だし、メールなんて
飛び交ってる状況なんだから適切なフィルタリングをしないと仕事にならんし。

＞掲示板にでも書いといて、編集の前にいちいち確認するのか？ (w

場所によっては普通にそういう運用をしてるところもあるな。
掲示板に編集します、編集終わりましたとか書いて、そういうのが目で見て
分かる状況になってないと、おちおちトイレにも行ってられんわ。
893 ：デフォルトの名無しさん：2014/04/12(土) 05:04:02.28 ID:U3ze+O2N.net: >>892
もっぽど無能な設計者とリーダーだったんだな。もしかして君が…。
894 ：デフォルトの名無しさん：2014/04/12(土) 05:33:31.04 ID:hrYZFkTS.net: 延々とスレチ続けてる時点でお前ら全員知障か気違い
895 ：デフォルトの名無しさん：2014/04/12(土) 07:29:31.34 ID:gbb+IGlp.net: 仮に、Gitに理想的なロック
(例えばあるファイルをロックしたら、
clone済みの全てのローカルリポジトリにおいてアトミックにロックされるようなロック)
が実装されたとしても、
人間様がロックの獲得と開放を制御する限り、
どこかで人間のレイヤへの割り込みは不可避なんだよね。

「御社の××さんがここ数日△△ファイルのロック取ってらっしゃるようですが、
編集中というステータスでよろしいでしょうか？
また、可能でしたら早めに解除していただけますか？」

とかね。もしそうなったとき、
開発体制公式の連絡手段が掲示板ならいちいち掲示板にかくしかない。
でもそんなの面倒でやってらんないよねって話でしょ。
ロックを強制解除する？
もし相手が本当に編集中で相手の作業が無駄になったらどうするの？
ロックって無駄な編集作業を避けるためのものじゃなかったの？
896 ：デフォルトの名無しさん：2014/04/12(土) 08:11:11.12 ID:12W5Y+Qh.net: 必要な人たちでロック機構ありのgitをフォークすればいいんじゃないかな。なんだか
凄腕の人達があつまってるみたいだし、すばらしいソフトが誕生すると思うよ。
わかったら早くやれ。
897 ：デフォルトの名無しさん：2014/04/12(土) 09:21:16.15 ID:ul/EWy73.net: バイナリの場合にロックが必要ということは
要するに、ソースコード（テキスト）に関しては
ロックは不要ってことでいいよね？
898 ：デフォルトの名無しさん：2014/04/12(土) 09:22:08.45 ID:zuiRAUii.net: 分散型はロックと相性悪いし、gitの開発陣がロックを必要としてるようには思えない
ロックが必要なプロジェクトはsvnを使えば良い
899 ：デフォルトの名無しさん：2014/04/12(土) 09:25:48.39 ID:ul/EWy73.net: ロックが必要な場合はあるかもしれないとして
それはバイナリに限るわけで
ソースコード（テキスト）にロックは不要。
もし必要だとしたら、それはソースコードの質が悪いから。

質が悪くて単一責任の原則（SRP）を満たしていないから
複数の人が一つの関数を修正することになる。
900 ：デフォルトの名無しさん：2014/04/12(土) 09:27:28.33 ID:s4x1CSLN.net: >>892
> 多人数でのプロジェクトをしたことないの？

今 50名規模のプロジェクトに放り込まれてますが何か？
この規模になるとメールでそんな連絡されてもマジで迷惑なだけ。
で、フィルタリングするとか意味不明なこと言ってるし。
そのフィルタリングどうやってやるのさ、書いてみな。

> 場所によっては普通にそういう運用をしてるところもあるな。

そうでないところは、どうしてるんだい。
901 ：デフォルトの名無しさん：2014/04/12(土) 09:32:41.33 ID:ul/EWy73.net: 多人数のプロジェクトがあるとして、
まずやるべきタスクがある（githubで言えばIssueに相当する）

そのタスクには担当者が書いてある。
だから同じタスクを複数の人がやることはない。

別々のことをやっているのだから、同じ関数をいじることは少ない。
もし別々の作業をやっていて同じ関数をいじることがあればマージすればいいだけである。
（ロックがあると別々の作業をやってるはずなのに、ロックされていて作業ができないという問題が発生する！）

マージできないバイナリだけが問題なので
ソースコード（テキスト）にロックが必要になることはない。
902 ：デフォルトの名無しさん：2014/04/12(土) 09:37:08.34 ID:s4x1CSLN.net: >>880
> 関係者全員とか迷惑を読み飛ばされたことに対して都合の悪いとこ読み飛ばすなとか批判するなら、まず相性が悪いものをどうやって実装するのかについて説明してからにしろよ

ホントに都合の悪いレスは読み飛ばすんだな...
折角 >>815 が調べたのにな (w

>>883
いいんじゃね？
てか、それに反対してる奴なんていたか？
903 ：デフォルトの名無しさん：2014/04/12(土) 09:38:47.48 ID:s4x1CSLN.net: >>895
頻度って知ってる？
904 ：デフォルトの名無しさん：2014/04/12(土) 10:02:01.28 ID:BW6c4MFF.net: >>900
＞そのフィルタリングどうやってやるのさ、書いてみな。

普通にsubjectに「[ファイルロック]」とでも入れるルールを作っておけば、
そのタイトルがあるメールを適当なフォルダに突っ込むなり、ラベルを
付けるなりすれば無視出来るだろ。それかロック専用のMLを作って
そこに投げるようにするとか。
50人もいるプロジェクトなら毎日のメール数なんて数十～数百通位に
なるなんて当たり前だろうから、そういうルール無しにやれるわけ無いと
思うのだが。
905 ：デフォルトの名無しさん：2014/04/12(土) 10:51:32.55 ID:2EpMpbWe.net: プロジェクトのメールも読まんで仕事する奴いるよ
まともな人間だけだと思うのは間違い
906 ：デフォルトの名無しさん：2014/04/12(土) 10:53:37.73 ID:gbb+IGlp.net: >>903
ロックなら人間が介入する必要の生じる頻度が
相対的に低いって言いたいんだろ？
その低い頻度で十分に面倒だって言ってるんだよ

無駄な編集開始を避けようと思ったら
(つまりロックしようと思ったら)
人間同士のコミュニケーションは避けられない
これが必須の要件の場合の現実的な方法の例は >>904 が示してる

ちなみに >>815 で紹介されてるツールについて議論するのは歓迎だよ。
フィットするユースケースや効果的な作業フローの考察を期待する。
ただし「やっぱロックさえあれば」って言うならボケがって思うわ。
907 ：デフォルトの名無しさん：2014/04/12(土) 11:04:03.85 ID:DOhnBRW9.net: >>901
> ソースコード（テキスト）にロックが必要になることはない。
それはマージが神の如く万能な時に限る
どうマージすればいいか担当者間で話し合わなきゃならないことがある
(それ以前に手元のソースがごちゃごちゃになって自分が面倒な事になる)

その手間を考えるとソースがロックされている間はいじらないようにしておこうと判断出来る
ロックがはずれた後変更内容を確認して自分で必要な変更をコミットできる

ただロックが必要なプロジェクトはgitよりもsvnを使うべきだろうね
908 ：デフォルトの名無しさん：2014/04/12(土) 11:11:06.10 ID:ul/EWy73.net: >>904
一般的な話をすると、必要ないメールは、減らす方がいい。
減らす努力をしないとダメだ。

メールがたくさんあると埋もれて重要なメールを見逃す。
たとえば、自分と関係ないファイルのロック情報のメールは
重要なメールを隠すゴミでしかない。
909 ：デフォルトの名無しさん：2014/04/12(土) 11:12:26.73 ID:ul/EWy73.net: 基本的な話として、コンフリクトが起きるのは
多人数のプロジェクトであっても少ないという
この前提があることを忘れないように。

つまりはロックをかける必要性は
少ないということである。
910 ：デフォルトの名無しさん：2014/04/12(土) 11:16:35.51 ID:ul/EWy73.net: >>907
> それはマージが神の如く万能な時に限る

95%うまくいく。

> どうマージすればいいか担当者間で話し合わなきゃならないことがある
ロックはファイル単位なので
「他の人が触っている時にそのファイルをいじれない」という大問題が、
プロジェクトの人数が増えれば増えるほど大きくなる。
つまり担当者間で調整する必要が増えるが

マージの95%はうまくいく、つまり
「他の人が触っている時にそのファイルを触っても問題ない」ので
担当者間での調整が殆ど発生しない。

「他の人が触っている時にそのファイルを触っても問題ない」のに
「他の人が触っている時にそのファイルをいじれない」ことが起きる原因がロック。
911 ：デフォルトの名無しさん：2014/04/12(土) 11:19:01.06 ID:zMh1JnO5.net: バイナリファイルであろうと、ロックなんてかけずに各々が編集して、編集後の状態を元に誰かが「マージ」すりゃいいんじゃねえのっていうのはだめなの？
912 ：デフォルトの名無しさん：2014/04/12(土) 11:19:55.82 ID:vy3cH3fd.net: >>863
＞解決方法は様々だが、会社で使うんなら「今からこのファイル編集
＞します」ってメールなりでコミュニケーションとれよと思う。

それで100%解決できるのなら、単にファイル共有でいいじゃんw

というか、だいたいはそれで機能するんだろうけど、万一の事故が起きないように、ソースが
クリーンであることを確実にしたいためにロック型の共有が必要になるんだよ。

なんか本当に仕事でチームで開発したことあるのか、と疑わしくなるような幼稚なレベルの
意見が多くて萎えるな、ここは。
913 ：デフォルトの名無しさん：2014/04/12(土) 11:20:45.20 ID:ul/EWy73.net: ロックをかけていれば、プログラムが壊れないかというとそうではない。

同時に作業をしている時、
Aさんがaというファイルを
Bさんがbというファイルを修正した時、

ロックをかけていても、ファイルが違うので
当然同時に作業できる。

a単体、b単体なら修正しても問題ないが、
aとbの両方が修正された時、プログラムが壊れることはある。

つまり、

> それはマージが神の如く万能な時に限る
> どうマージすればいいか担当者間で話し合わなきゃならないことがある

というのは、ロックをかけていても発生する問題。
ロックがあれば万能なんだということにはならない。
914 ：デフォルトの名無しさん：2014/04/12(土) 11:23:00.27 ID:ul/EWy73.net: >>912
> というか、だいたいはそれで機能するんだろうけど、万一の事故が起きないように、ソースが
> クリーンであることを確実にしたいためにロック型の共有が必要になるんだよ。

たしか、ソースコード（テキスト）のロックは百害あって一利なしって
コンセンサスを得られたと思ったんだけど？（笑）

ロックを使ったとしても確実にクリーンになることはない。
ただ他の人の作業を妨げるだけ。

本来同時に出来る作業（それが大部分）ができなくなる。というデメリットが発生するだけ。
915 ：デフォルトの名無しさん：2014/04/12(土) 11:24:57.83 ID:s4x1CSLN.net: >>904
で、編集し始めるときにメールをいちいち確認するのな (w
そもそもプロジェクト内のメール数百通とか、そんなに暇なんですか？
916 ：デフォルトの名無しさん：2014/04/12(土) 11:30:34.96 ID:Jis7Bk7Q.net: ロックなんて考えがあると、
誰かがこのファイル修正していたらどうなるんだろう？という
心配しなくていい心配をすることになる。

その発想を逆にして、コンフリクトが起きれば直せばいいという発想をすると、
ロックそのものが不要になる。

同時にファイルを修正しても問題ないことが殆どなので
ロックという発想そのものがだめということ。
svnを使ったロックもメールでロックしますって通知も同じ。
どちらであっても、ロックによって作業を妨げられる。
プロジェクトの参加人数が増えるたびに、他の人によって作業が妨げられる。
917 ：デフォルトの名無しさん：2014/04/12(土) 11:31:13.51 ID:s4x1CSLN.net: >>906
> ロックなら人間が介入する必要の生じる頻度が相対的に低いって言いたいんだろ？
> その低い頻度で十分に面倒だって言ってるんだよ

大抵のケースで介入の必要ないのに面倒ってどう言うこと？
918 ：デフォルトの名無しさん：2014/04/12(土) 11:31:24.03 ID:Vp3GiluJ.net: 接続先をgithub.com:22からssh.github.com:443にすることはセキュリティ的に良いことですか？
919 ：デフォルトの名無しさん：2014/04/12(土) 11:33:20.12 ID:s4x1CSLN.net: >>912
君の主張には同意するけど、なんで俺にアンカーしてんの？
920 ：デフォルトの名無しさん：2014/04/12(土) 11:37:39.89 ID:FjWpH3tq.net: ロックが面倒、ロックの調整が大変とか、そんな些細なことより
ロックによって開発作業が妨げられるということの方が問題。
開発作業をする時間のほうが長いんだよ。わかってるのかな？

なんかさ、作業しない人が、同時に同じファイルを修正したらどうしよう？
わからん？コンフリクトとか知らん（←馬鹿）
だからもうロックかけちゃえって思ってるんじゃないか？
ロックかければもう全部解決ーみたいな（全然そんなことない）

開発作業が妨げられることが一番の問題なのに、開発作業をしていないから、
どうでもいいロック（コンフリクトの解決）の話にばかり気にしている。

重要な事だからもう一度言うね。

ロックによって「長時間開発を妨げられる」ことが一番の問題
921 ：デフォルトの名無しさん：2014/04/12(土) 11:38:17.54 ID:s4x1CSLN.net: >>909
× つまりはロックをかける必要性は少ないということである。
○ つまりはロックが問題になる場合は少ないと言うことである。

君の主張は事故に遭う確率低いから保険に入る必要性は少ないと言ってるアホと変わらない。
922 ：デフォルトの名無しさん：2014/04/12(土) 11:39:01.79 ID:FjWpH3tq.net: >>921
それは保険の話。全く関係ないものに例えるな。
923 ：デフォルトの名無しさん：2014/04/12(土) 11:39:31.56 ID:U3ze+O2N.net: ロックしてても、解除された後に次のやつがマージするだけ。
924 ：デフォルトの名無しさん：2014/04/12(土) 11:39:41.59 ID:s4x1CSLN.net: >>911
それが現実的な時間と労力でできればね。
925 ：デフォルトの名無しさん：2014/04/12(土) 11:39:55.27 ID:FjWpH3tq.net: だから結局ロックしていても何も問題は解決しない。
926 ：デフォルトの名無しさん：2014/04/12(土) 11:42:03.74 ID:s4x1CSLN.net: >>922
> それは保険の話。全く関係ないものに例えるな。

ひょっとして、バカなの？
927 ：デフォルトの名無しさん：2014/04/12(土) 11:44:55.59 ID:FjWpH3tq.net: > 君の主張は事故に遭う確率低いから保険に入る必要性は少ないと

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

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

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

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

だからさー、コンフリクト起きても直すだけじゃん。
それ普通の開発作業なんだが？コストなんて超少ない。
ロックかけていてもコンフリクトが起きるってことは結局同じ場所を修正する必要があるってわけだろ？
どっちみち同じ作業をやるしかないんだが。
こんぐらいもわからんのかな？馬鹿じゃない？ｗ
928 ：デフォルトの名無しさん：2014/04/12(土) 11:45:35.66 ID:s4x1CSLN.net: >>925
ソースの話してるのか？
だったら、それでいいんじゃね？
だれも反対してないと思うし。
929 ：デフォルトの名無しさん：2014/04/12(土) 11:46:38.96 ID:ANARd0H4.net: >>926
ほら、ちゃんと説明してやったぞ？
反論できるかな？ｗ

所で君、明日太陽が登らないかもしれないんだぞ。
対策はちゃんとしているのかな？ｗ
930 ：デフォルトの名無しさん：2014/04/12(土) 11:49:21.39 ID:vy3cH3fd.net: テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。

大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
大事だから、やっぱGitは向いてないよ。

別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている（その
ために作られた）わけでさ。
931 ：デフォルトの名無しさん：2014/04/12(土) 11:50:50.05 ID:s4x1CSLN.net: >>929
> だからさー、コンフリクト起きても直すだけじゃん。

頑張って、としか言いようがない (w
932 ：デフォルトの名無しさん：2014/04/12(土) 11:53:24.86 ID:T5pqGmWJ.net: ソフトウェア開発において
バイナリよりもソースコードのほうが多いのです。
ならば、ソースコードをうまく管理できる方がいい。

gitがいいのはロックだけが理由ではない。
ローカルでソースコード管理できて履歴を直せることこそが重要

subversionでありがちな。
* ○機能完成
* ○のバグ修正
* ○のバグ修正2
* △機能完成
* ○機能バグってた
* △もバグってた
* ○の仕様が変わった

みたいな役に立たない履歴をなくせる
933 ：デフォルトの名無しさん：2014/04/12(土) 11:54:45.70 ID:T5pqGmWJ.net: >>931
あー、ほら、やっぱりそういうことだろ！

ロック必要とかいってるのは、コンフリクト怖い病なんだ。

コンフリクト怖い。直し方分からない。
起きたらどうしよう。頭爆発。

結局、こういう技術力不足が原因なんだろ！
934 ：デフォルトの名無しさん：2014/04/12(土) 11:55:31.68 ID:T5pqGmWJ.net: 「コンフリクト怖い病」という用語を普及させようぜ？ｗ
935 ：デフォルトの名無しさん：2014/04/12(土) 12:04:09.11 ID:MzN5Zxxd.net: 今から出かけるけど、返って来たら
コンフリクト怖い病患者の特徴をまとめてみようかな
次スレになりそうだから、まあテンプレにしよう。
936 ：デフォルトの名無しさん：2014/04/12(土) 12:07:34.60 ID:s4x1CSLN.net: >>933
だから、君はソースの話してるのか、バイナリの話してるのか、明確にしなよ。
指摘しづらいわ。
937 ：デフォルトの名無しさん：2014/04/12(土) 12:08:38.34 ID:MzN5Zxxd.net: バイナリのファイルは忘れろよ。
ソースコード管理ツールだろ。

例外であるバイナリの場合だけ
バイナリと明確に書くように。
938 ：デフォルトの名無しさん：2014/04/12(土) 12:08:41.20 ID:vy3cH3fd.net: 仕事と遊びとは違う
939 ：デフォルトの名無しさん：2014/04/12(土) 12:09:54.70 ID:gbb+IGlp.net: >>933
いや、お前および何人かは >>931 の主張の前提を共有できてない。

* マージ・コンフリクトの解決が難しい種類のファイルは現実的に存在する
* そういうファイルの編集を誤って開始してしまうのを防ぐためにロックが欲しい

と >>931 は言ってる。
>>931 はソースコードに関してはロック不要とも(暗に)言ってる。
なぜならお前がいうようにマージすればいいだけだからな。

これに対して「コンフリクトしてもマージすればいいだろ」と言っても
>>931 としても「頑張れ」としか言えんだろう。
940 ：デフォルトの名無しさん：2014/04/12(土) 12:10:15.79 ID:vy3cH3fd.net: ID: s4x1CSLN はGit脳かなんか知らんが発狂しすぎだろ。
適材適所、という言葉さえ知らないのか？

トンカチを持った奴はなんでも釘に見える、というけど、Gitを持つと、Git以外の管理方法が
目に入らなくなるらしい。
941 ：デフォルトの名無しさん：2014/04/12(土) 12:11:55.24 ID:MzN5Zxxd.net: > * マージ・コンフリクトの解決が難しい種類のファイルは現実的に存在する
だがそれはロックしても解決できない
942 ：デフォルトの名無しさん：2014/04/12(土) 12:13:01.95 ID:BW6c4MFF.net: >>930
＞大事だから、やっぱGitは向いてないよ。

gitに向いていないものをgitでやる必要は無いわけで。バージョン管理ツール自体は
ロックが出来るsvnなんかは無料で使えるんだからライセンス料の心配をする必要は無い。
バイナリファイル等のコンフリクトした際のマージ作業が面倒なファイルだけ
そういうツールで管理すればいいだけ。

gitというか分散管理ツールははオフラインで作業が捗るように作られている
わけだから、オンラインじゃなきゃ機能しないロック機構とは相性が悪い。
オフラインの人への通知をどうするのか考えたら別のツール使えよって
普通はなるよな。
943 ：デフォルトの名無しさん：2014/04/12(土) 12:15:34.46 ID:jnsRXNx1.net: まず、>>895の

＞仮に、Gitに理想的なロック
＞(例えばあるファイルをロックしたら、
＞clone済みの全てのローカルリポジトリにおいてアトミックにロックされるようなロック)
＞が実装されたとしても、

が分散型の仕組み上無理なことを誰も突っ込まないんだろうか…
だってそれできたら、もう分散型じゃないようなw
944 ：デフォルトの名無しさん：2014/04/12(土) 12:16:30.70 ID:MzN5Zxxd.net: ロックをすることでマージが簡単になるんじゃないことに注意な。

二人が同じファイルを修正する必要があったとして
ロックしたからといって、二人が同じファイルを修正できるようになるわけじゃない。

マージが難しい物は、どちらかを取るしかないわけだが、
どちらかを選択する行為はロックをかけなくできる。
マージする時にコンフリクトが起きたら、今あるやつを使うか
自分のやつを使うかを選択すればいいだけ。

ではロックで何が解決されるのか？
その答えが些細な事だって話。
945 ：デフォルトの名無しさん：2014/04/12(土) 12:17:24.13 ID:U3ze+O2N.net: バイナリをロックしても、解除された後に結局マージするんだろ。

テキストは自動マージがあるだけだが、マージされたからと言ってその結果が正しいとは言えないのだから、テストかレビューが必要。バイナリの手動マージと同じ。
946 ：デフォルトの名無しさん：2014/04/12(土) 12:21:57.16 ID:gbb+IGlp.net: >>917
> 大抵のケースで介入の必要ないのに面倒ってどう言うこと？

無駄な編集開始を避けようと思ったら
(つまりロックしようと思ったら)
人間同士のコミュニケーションは避けられない

ここまではいいよな？ Gitのような分散VCSに、

1. 同時編集を許容しない(ロック)機能を実装するかわりに、
それに付随するコミュニケーションが頻度の差はあれ必須になる

2. 同時編集を許容する代わりに、コミュニケーションは不要。
もし許容できないシチュエーションがあるなら
別のレイヤでコミュニケーションとるほうがいい

1は面倒なので2のほうがマシ、と言ってる。
947 ：デフォルトの名無しさん：2014/04/12(土) 12:25:31.35 ID:MzN5Zxxd.net: > 無駄な編集開始を避けようと思ったら
> (つまりロックしようと思ったら)
> 人間同士のコミュニケーションは避けられない

無駄な編集開始になぜロックが必要になるのか？

別な方法で、無駄な編集開始を避けられるのなら
ロックは必要ない。

君、作業分担にツールは何も使ってないの？
たとえばgithubのIssueとかさ
チケット管理システムとかさ
そういうのだよ。

普通一つのシステムを作る時に、それをいくつかのサブ機能に分けて
担当者を決めると思うけどさ、どうやってるの？
948 ：デフォルトの名無しさん：2014/04/12(土) 12:30:48.20 ID:MzN5Zxxd.net: 根本的な原因がわかってきたんじゃねーの？

バージョン管理以前の問題だって。
無駄な編集開始を避けるのに使うのはチケット管理システム。

作業を開始する前、作業中。
そのどちらであっても、ソースコード以外の
コミュニケーションツールが必要。

たとえば、仕様の確認とかバグ詳細の確認とかさ、
（まさかいちいちメールでやってるわけないよね？ｗ）

コミュニケーションツール出やるべきことを
ソースコード管理ツールでやろうとするのが根本的な間違い。

無駄な編集開始を避ける話しは、ここまでの話だよ。
949 ：デフォルトの名無しさん：2014/04/12(土) 12:32:07.50 ID:gbb+IGlp.net: >>947
> 無駄な編集開始になぜロックが必要になるのか？

ロックが必要だと言ってるのは >>936 だよ

>
> 別な方法で、無駄な編集開始を避けられるのなら
> ロックは必要ない。
>
> 君、作業分担にツールは何も使ってないの？
> たとえばgithubのIssueとかさ
> チケット管理システムとかさ
> そういうのだよ。

そうそう、無駄な編集開始を避けたいなら
そういうツールなりでコミュニケーションとれよって話。

「Gitにロックがあれば」なんて話にもっていくのはおかしい、
って俺は言っている。
950 ：デフォルトの名無しさん：2014/04/12(土) 12:44:54.37 ID:BW6c4MFF.net: >>948
＞（まさかいちいちメールでやってるわけないよね？ｗ）

お前がメールに親を殺されたか、恋人をNTRされたか分からんがメールへの
恨みだけは他の誰にも負けないことは分かったから黙ってろ。
951 ：デフォルトの名無しさん：2014/04/12(土) 12:47:55.69 ID:DvVB/wNe.net: >>950
次スレ建てろ
すぐやれ
952 ：デフォルトの名無しさん：2014/04/12(土) 12:48:02.86 ID:s4x1CSLN.net: とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
あと、分散では原理的に実現できないと言うのもいいよね。
これに反対する奴はいないと思うんだが、いいかな？
>>948 とかが不用意にソースコードとか書くから話がおかしくなってるので、確認させてくれ。
953 ：デフォルトの名無しさん：2014/04/12(土) 12:51:17.45 ID:gbb+IGlp.net: >>952
おｋ
954 ：デフォルトの名無しさん：2014/04/12(土) 12:51:58.82 ID:MzN5Zxxd.net: > とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。

ちょっと違うな。バイナリがマージできなかったとして、
自分の修正を取るか、相手の修正を取るかの二つしか選択できない。
それはgitであってもできること。

ロックで防げるのは、無駄な編集開始を避ける事ではあるが、
それはチケット管理ツールを使うべき話。

バイナリであったとしても、どちらかを取ればいいので
ロックを使う理由はない。
955 ：デフォルトの名無しさん：2014/04/12(土) 13:07:00.16 ID:BW6c4MFF.net: >>951
無理だった。

ＥＲＲＯＲ：Lvが足りなくてスレッド立て(ら)れません。

Git 9
名前：デフォルトの名無しさん
E-mail：
内容：
ソースコード管理を行う分散型バージョン管理システム、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 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
956 ：デフォルトの名無しさん：2014/04/12(土) 13:22:55.97 ID:B/06XIsq.net: >>902
>>880=>>815なんだが。
そのあとろくにgit-annexについて考察もしないのに「都合の悪いレスを読み飛ばすな」とか批判する資格ないだろ。
大体git-annexにだって問題点は沢山あるわけで。つーかgit-annexで解決してるならもういいだろ。
単にgitにロックがないということで無駄な論争を起こそうとしてるとしかおもえない。
957 ：デフォルトの名無しさん：2014/04/12(土) 13:23:23.64 ID:s4x1CSLN.net: >>955
立てといた

Git 9
http://toro.2ch.net/test/read.cgi/tech/1397276540/
958 ：デフォルトの名無しさん：2014/04/12(土) 13:31:12.71 ID:s4x1CSLN.net: >>954
> ロックで防げるのは、無駄な編集開始を避ける事ではあるが、

ここまでは同意。

> それはチケット管理ツールを使うべき話。

ロックの対象はファイルなので、SCM の方がより適切と思う。
あるファイルを編集する時にロックされてないかを確認するのにどのチケット見ればわかるの？
該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
959 ：デフォルトの名無しさん：2014/04/12(土) 13:36:24.72 ID:s4x1CSLN.net: >>956
本人なのか。
マジで何を言いたいのかよくわからんのだが。
960 ：デフォルトの名無しさん：2014/04/12(土) 13:41:55.23 ID:kSIcd9mI.net: 見てて結構面白いんだけどレッテル貼りだけは負け逃げみたいだからアカンよ。
961 ：デフォルトの名無しさん：2014/04/12(土) 13:49:00.36 ID:EipzA34R.net: >>958
ロックしなくて問題ない。

作業がかぶっていなければ、修正内容がかぶることはない。
かぶったらコンフリクトを解消すればいいだけ。コンフリクトを解消するのは、小さな作業。
（コンフリクトを解消した、つまり修正後のテスト等はロックがあっても結局やるべきことだから違いはない）

たとえロックしていたとしてもコンフリクトは発生する。
バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ
それはロックしなくてもできること。

> 該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。

複数のチケットで、たとえば画像を赤くしろ、青くしろなんてのがあったら
作業前にどちらのチケットをやるかを決めるべきこと。
ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。
だからこれはチケットで解決するべき問題。

複数のチケットから参照されてるなんて、具体的でないケースを言うからわからなくなる。
複数のチケットで、同じものに対する修正があるとき、それをどうするかはチケットで解決するべき問題だってわかるはずだ。
962 ：デフォルトの名無しさん：2014/04/12(土) 13:54:07.45 ID:EipzA34R.net: 考えれば考えるほど、ロックの意味がなくなってきたな。

AとBを同時に修正して、AをマージしてからBをマージするか
Aを修正してマージしてから、Bを修正してマージするかの違いしかないじゃないか。

この場合コンフリクトはどちらでも起こりうるし、
単に修正作業が直列化したに過ぎない。
（マージだけを見ればどちらも直列化している）
963 ：デフォルトの名無しさん：2014/04/12(土) 14:02:32.23 ID:s4x1CSLN.net: >>961
> バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ

はあ？
どっちかの編集の労力を捨てろって言ってるの？

> ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。

だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？
実際の運用考えてないのか？

> ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。

上半分と下半分の両方が修正されるというケースは思い付かないのか。
964 ：デフォルトの名無しさん：2014/04/12(土) 14:05:42.24 ID:EipzA34R.net: > どっちかの編集の労力を捨てろって言ってるの？

その為にチケット管理しろって言ってるの。

どのファイルを修正するかなんて
作業前にわかるだろ。
965 ：デフォルトの名無しさん：2014/04/12(土) 14:06:23.64 ID:s4x1CSLN.net: >>962
> 単に修正作業が直列化したに過ぎない。

当たり前だろ、直列化するための仕組みなんだから (w
普通にやるとそうならない場合があるから困ってるわけで...
966 ：デフォルトの名無しさん：2014/04/12(土) 14:09:32.79 ID:s4x1CSLN.net: >>964
お前が一人で修正するならな。
あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？についても、書いてね。
967 ：デフォルトの名無しさん：2014/04/12(土) 14:10:19.82 ID:kSIcd9mI.net: まあ平行作業しないで済むならそれに越したことはないよね
968 ：デフォルトの名無しさん：2014/04/12(土) 14:10:25.33 ID:EipzA34R.net: > だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？

要らない。

チケットベースで作業管理していて、作業内容が違うから、
内容はかぶらないのですんなりマージできる。
まれにマージできない場合だけコンフリクト解消するだけでOK

それよりも問題なのは、マージできない場合＝ロックする必要がある時に
本当にロックしてしまうと、並列で作業できるはずのことが
並列で作業できなくなってしまう。

それは開発の遅れを引き起こす。

ロックしないから並列で開発できる VS ロックするから並列で開発できない

こういいう話。

> 上半分と下半分の両方が修正されるというケースは思い付かないのか。
上半分を青くして、下半分を赤くする修正の二つが終わった時、
本当に、上半分を青くしてといった人の意図したとおりなっているかはわからない

やっぱり修正を始める前に、チケットで解決しておくべき問題だったな。
969 ：デフォルトの名無しさん：2014/04/12(土) 14:11:50.26 ID:EipzA34R.net: >>966
> あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？についても、書いてね。

書かなくていいというか、書いたらダメ。

書いたら並列で開発できなくなる。

"一人で開発しているから" 並列で開発することは出来ないからどうでもいいが、
"複数人で開発しているなら" 並列で開発できなくしてはいけない。

並列で開発できなくなったら待ちが発生する。
970 ：デフォルトの名無しさん：2014/04/12(土) 14:20:20.28 ID:gbb+IGlp.net: スレ立て乙
しばらく離れるのでまた次スレで。
971 ：デフォルトの名無しさん：2014/04/12(土) 14:24:48.81 ID:UapBJj1i.net: Git 9
http://toro.2ch.net/test/read.cgi/tech/1397276540/
972 ：デフォルトの名無しさん：2014/04/12(土) 15:05:13.12 ID:s4x1CSLN.net: >>968-969
マージできるファイルの話ならいちいちレスしなくてもいいよ。
誰もマージできるファイルにロックが必要とは言ってないから。
973 ：デフォルトの名無しさん：2014/04/12(土) 15:23:49.87 ID:qyNsAYgL.net: とりあえずだ。
gitにロックが必要か？という問題については、答え、必要ない。
バージョン管理にロックが必要か？については、答え、必要なこともある。
ってことでいいな。

つまり、ロック機能がほしいファイルを分散型のバージョン管理に突っ込むなということだ。
gitにロック機能必要といってるやつは、まず分散型の仕組みから復習しろ
974 ：デフォルトの名無しさん：2014/04/12(土) 15:39:46.69 ID:s4x1CSLN.net: >>973
> gitにロックが必要か？という問題については、答え、必要ない。

そうなんだろう、お前の中ではな。
975 ：デフォルトの名無しさん：2014/04/12(土) 15:45:39.17 ID:zMh1JnO5.net: 必要かどうかってより、gitのような分散型バージョン管理でロック実装はひどいことになるんじゃないの
976 ：デフォルトの名無しさん：2014/04/12(土) 15:54:45.04 ID:8wXT0UMc.net: 何でもできて重くもないツールにできるんだったら、
分散型でも集中型でも管理できてロック使用要否も選択できてissue管理もできて
ってすればいいよ

自分もExcelやWordを後からマージ作業はやりたくないからロックありで管理したいものがあるのはわかるけど
それをソースと同じくgitで管理したい、とは思わない
別のツールでいいじゃん
977 ：デフォルトの名無しさん：2014/04/12(土) 16:16:06.70 ID:iNxrw8O2.net: ume
978 ：デフォルトの名無しさん：2014/04/12(土) 16:19:24.13 ID:s4x1CSLN.net: >>975
分散だと原理的に無理だと思う
ただ、分散諦めても普段使い慣れた git を使うという選択肢があってもいいと思う
企業内だとそういう使い方は多いと思うしね

>>976
> それをソースと同じくgitで管理したい、とは思わない

仕様書を Word/Excel で管理していたり、リソースとかはソースと一緒に管理したい人もいるんよ
979 ：デフォルトの名無しさん：2014/04/12(土) 16:52:24.54 ID:U3ze+O2N.net: まだ一人でがんばってんのか。無駄に。
980 ：デフォルトの名無しさん：2014/04/12(土) 16:59:26.37 ID:zuiRAUii.net: officeドキュメントの管理は、本来ならSharePointを使った方が良い
ただ、ソースコードと一緒にドキュメントも管理したい場合もあるのは確か
svnでもgitでもhgでもドキュメントの管理にはあんまり向いてるとは思わないが、あえて言えばsvnが一番使いやすいと思う
ロックもそうだし、Windowsクライアントが優れてたり、日本語ファイル名とか、部分チェックアウトとか
981 ：デフォルトの名無しさん：2014/04/12(土) 17:04:58.66 ID:qyNsAYgL.net: >>978
そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。

リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、仕様書だけ、必要な人の方がおおい。

まぁ、まだ個人的にしかやったこと無いから、pj単位で運用したときはどうなるかわからんけど。。。

試してみるなら、リビジョンの不整合にはよう注意な。
ブランチ運用をちゃんとやらないと、svn側が大変なことになる。
982 ：デフォルトの名無しさん：2014/04/12(土) 17:11:43.01 ID:1eEiGLxS.net: なんでもエクセル使って書くバカと同じで
なんでもVCSで管理しようとするバカがいるのだろうか？

VCSはソースコードを管理するために作られたツールだ
ソースコード以外を入れようと考えるな。

そもそもバイナリを入れるという考えが間違いであることに気づけ。
983 ：デフォルトの名無しさん：2014/04/12(土) 17:22:34.14 ID:1G+VXwG6.net: >>982
間違ってはないと思うが。
984 ：デフォルトの名無しさん：2014/04/12(土) 17:28:45.84 ID:UuzLKOtw.net: レポジトリa,bがあり、bはaのサブモジュールになっています。
aのブランチを切り替えると、bの一部ファイルが消えるのですが、原因はわかりますか？

bでコミットをしたら、aでbについての「subproject commit ハッシュ」という変更もコミットする必要があるのでしょうか？
985 ：デフォルトの名無しさん：2014/04/12(土) 17:34:28.48 ID:1eEiGLxS.net: >>984
サブモジュールについての理解が甘いようだね。

サブモジュールはライブラリなど自分以外の
誰かが作っているリポジトリだと考えよう。
誰かが作っているということは、勝手にバージョンが上がるということだ。

そしてだ、君のそのコード。
それはサブモジュールのライブラリの
どのバージョンのコードで正しく動くのだ？

他人が作っているライブラリのバージョンが変わった時、
勝手に新しいバージョンを使ったら困るだろう？
986 ：デフォルトの名無しさん：2014/04/12(土) 17:36:55.18 ID:NV9wCwyl.net: >>981
> そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。

ごめん、それなんの意味があるのかさっぱりわからん。
管理だけなら git svn の方がいいと思うけど。

> リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、

なんで？
コミットは別かもしれないけど、一緒に管理してもいいと思うけど。

>>982
はいはい (w
987 ：デフォルトの名無しさん：2014/04/12(土) 17:38:50.24 ID:1eEiGLxS.net: 仕様書というのは膨大である。

仕様書はバージョンが有り
更新されると、一部だけが変わる。

その更新はどうやって知るか？
バイナリでは比較が困難なので
テキストで書くのが良い。

仕様書はテキストで書くべきというのが正解。
988 ：デフォルトの名無しさん：2014/04/12(土) 17:45:50.74 ID:kSIcd9mI.net: テキストだけより図とかも使った仕様書の方がわかりやすくて好きだなあ
989 ：デフォルトの名無しさん：2014/04/12(土) 18:09:05.83 ID:1rmX5tVh.net: >>987
> 仕様書はテキストで書くべきというのが正解。

自分だけで閉じる奴はそうしてる (ascildoc + graphviz)
990 ：デフォルトの名無しさん：2014/04/12(土) 18:18:17.28 ID:zMh1JnO5.net: リポジトリにバイナリ突っ込んでるけどなあ、複数人が同時に編集するようなもんほぼないけど
991 ：デフォルトの名無しさん：2014/04/12(土) 19:07:55.75 ID:U3ze+O2N.net: バイナリでも自分と相手のデータをアプリで開いてマージするだけだな。ロックがあろうとなかろうと。
作業が被るかどうかはプロジェクトマネジメントの領域で、同じ作業でも違うファイル名で新規に作ったりしたらロックしようがない。
992 ：984：2014/04/12(土) 21:32:17.16 ID:UuzLKOtw.net: >>985
そうだったんですね、勘違いしてました。

a,bともに自分のレポジトリで、
a,bわけて管理したいときはどうすればいいのでしょうか。
aのディレクトリにbが存在しています
993 ：デフォルトの名無しさん：2014/04/12(土) 21:36:24.94 ID:1eEiGLxS.net: >>992
別人になったつもりで作業すればいいだけ。
994 ：デフォルトの名無しさん：2014/04/12(土) 21:53:11.54 ID:gbb+IGlp.net: まだ埋まってなかったのか。
ロック必要だよ派はまだ居る？
(宗旨替えした結果いなくなったのなら、それはそれで良いけど)
995 ：デフォルトの名無しさん：2014/04/12(土) 22:21:13.23 ID:gbb+IGlp.net: 早ければ来週あたり 2.0-rc0 がでるっぽい。
これで新機能追加はほぼ終わり。

つっても 2.0 正式リリースまでまだ1ヶ月以上あるだろうけど。
996 ：デフォルトの名無しさん：2014/04/12(土) 22:27:45.81 ID:gbb+IGlp.net: つーか今朝の6時か7時ごろ 1.9.2 がリリースされてるな。
997 ：デフォルトの名無しさん：2014/04/12(土) 22:28:49.82 ID:gbb+IGlp.net: ちがった。2日くらい前か。
998 ：デフォルトの名無しさん：2014/04/12(土) 22:47:13.21 ID:qyNsAYgL.net: >>986
仕様書とソースじゃ工程が違うからコミットは当然別々になる。もし一緒にコミットしているならレビューのやり方がおかしい。

んで、バージョン管理されるファイルはコミットされたタイミングで全体の整合性が取れているべきなので、ソースと同じところに仕様書の類があるとどっちを信じていいかわからなくなるよ。

というわけで、僕は参照リポジトリの位置付けで、チェックアウトしたしたsvnとかのモジュールを取り込んでる。

ソースをコミットしたタイミングの仕様書も記録できるから。。。

変更するときは、大本だけどねー
999 ：デフォルトの名無しさん：2014/04/13(日) 01:01:16.17 ID:pwayVEBU.net: 梅
1000 ：デフォルトの名無しさん：2014/04/13(日) 01:04:55.07 ID:pwayVEBU.net: 1000なら日本国の少子化問題が解決する
1001 ：2ch.net投稿限界：Over 1000 Thread: 2ch.netからのレス数が1000に到達しました。

総レス数 1001
267 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★