Git 8

ソースコード管理を行う分散型バージョン管理システム、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/

>>1乙

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

◆前スレ
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/

◆関連書籍
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

>>1
乙

>>1乙だけど
http://progit.org/book/ja/
にアクセスできないなくない？

>>7
すまねえ、スマホからたてたので、リンクの確認サボっちまった。

http://progit-ja.github.io/ でいいのかな？

>>8
>>1が指してたページはたぶんこれでアクセスできるとこだな
http://git-scm.com/book/ja/
git-scm.comの中に統合されたってことかね？

というか http://progit-ja.github.io/ このページもいいね！
こっちは次スレでは >>4 の関連書籍に含めたらいいのでは

了解、よろしくね ⇒ >>950

よっしゃ

GitHubの質問する奴も多いしテンプレに誘導先としてリンク入れておいたほうがいかったんじゃないの

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

刈り込むとか何するのか全然わからねえよな

|....,,__
|＿::;; ~"'ヽ
|　//^''ヽ,,)
|　　i⌒"
| ∀｀）　＜ 誰もいない きのこるならいまのうち
|⊂
| ノ
　　　　　 _,,,......,,__
　　／_~　,,...:::＿::;; ~"'ヽ
　(,, '"ヾヽ　 i|i　//^''ヽ,,)
　 　^ :'⌒i　　　　i⌒"
　　　　　 |（　´∀｀）　＜ きのこ のこーのこ げんきのこ ♪
　　　　　 |（ﾉ　　 |つ
　　　　　 | 　　　 |
　　　　　⊂ ＿ ノ
　　　　　　　""U
　　　　　 _,,,......,,__
　　／_~　,,...:::＿::;; ~"'ヽ
　(,, '"ヾヽ　 i|i　//^''ヽ,,)
　 　^ :'⌒i　　　　i⌒"
　　　　 （´∀｀　）|　＜ エリンギ まいたけ ブナシメジ ♪
　　　　⊂|　　（ﾉ |
　　　　　 | 　　　 |
　　　　　 ヽ ＿ ⊃
　　　　　　.U""
|
| ミ
| ミ 　ｻｯ!
| ミ
|

Git 1.8.5.3 がリリースされたね
https://code.google.com/p/git-core/downloads/list

Gitをはじめて勉強するときってみんな何で覚えたん？
>>1にあるようなサイトか書籍？

俺はこの２つのサイトで覚えた

http://git-scm.com/book/ja/
http://www.backlog.jp/git-guide/

>>16
man git

今からおこなう作業にあらかじめタグをつけておくことは可能？

>>19
それはブランチだよ。

タグはコミットにつけるものだから

gitの場合はブランチもコミットに付くフラグなんだけどな

>>20
自動的にブランチ名をタグ名にしてタグを付けろってこと？

>>19
今から行う作業っていうのがどういう意味なのかわからない。
これから新しく作るひとつのコミットのことなのか？

これから新しく作っていく複数のコミットの履歴の最新につける名前なら、
それはブランチを作ればよいのでないか？

なんかさぁ、
もう、朝ごはんなのか昼ごはんなのか
わからないよ。

リベースというのは誰かと共有してるブランチではやってはまずいってことかな
masterからdevelopのラインで共同開発してる最中
臨時改修にmasterからfixで直してmasterへマージしたら
developをmasterからリベースしたら共同開発する全員が影響受けるから
masterかfixからdevelopにマージするってことをしないとダメってことか

朝ごはんを作るときに 朝ごはんブランチを作成したあとに
朝ごはんが完成したら そのまま朝ごはんというタグをつけたら
それは朝ごはんブランチの方につくんだよね？
メインにマージしてから朝ごはんというタグをつければいいの？

タグは１つのコミットに対してつけるものだから

Ｇｉｔの仕組みを理解すればタグやブランチやコミットがどういうものなのか分かるよ

Git - Book
http://git-scm.com/book/ja

>>29
それは読んで理解してるので大丈夫です！

理解してたらタグがどうのこうのなんて質問せんやろ・・

>>26
リベースは原則としてローカリポジトリでやるもの。
リモートにあってもそれが個人で専有しているならありだが。

>>27
gitにおいてブランチは消すもの。
メイン以外にタグを付けることはまず無い。

>>27
マージした後につけるべきかどうかはマージの方法に依存する

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

マージコミットが作られないマージの場合には、
マージするコミットがそのままマージ先のコミットになるので、
マージする前でもいい

>>32
ブランチは作業ごとに毎回消したほうがいいってことか
了解しました

git flowつかえばいいのに

git flowは無意味に複雑すぎ。

それに変わるものとして生まれた
github flowがいい。

毎回厳密にテストしてバグを最小限に抑えてリリースするならgit-flow
簡単なテストだけしてユーザーにバグ出しさせるならgithub-flow
どっちでもいい

小さな修正で不具合がでても被害を最小限にし
ユニットテストとCIによって毎日テストを行い
リリースを早めるのがgithub-flowだよ。

簡単なテストしかできないのは、単にお前の会社に
ユニットテストがないってだけの話。

GitHub Flow

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

ここ読めば納得できると思うけど、
github-flowに簡単なテストだけして
ユーザーにバグ出しさせるなんてことは一切書いてない。
逆に自動化されたモダンなテストを行っている。

なるほど
それぞれ確立されたフローだったのか
gitは最初GitHubから始めたからGitHubのヘルプページのそのGitHub Flowというのが標準のやり方かと思ってたけど
gitについて調べてくうちにそっちのgit Flowのほうの話題が多くてgit Flowのほうが普通なのかと改め直したばかりだったが
どっちでもよかったのか

>>39
＞小さなバグが入ることはあるだろうが、そういったものは素早く修正して再デプロイすることができる

複数バージョンを保守したりする必要があると、
github flow みたいに単純にはできないね
各個人のフューチャーブランチのマージ先として、
masterとは別のブランチが1本は欲しい

>>41
デプロイするものに小さなバグが混じることを容認してる
デプロイしたものはユーザに触れるわけでそのバグを見つけるのはユーザである可能性があるということ

突っ込み入った点は知ってたがflowを知らない人向けに超訳して書いた
なので特に反論はないです流してどうぞ

未来ブランチ?

テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。

>>45
featureブランチのことか？
futureじゃないぞ

>>46
普通最初にテストを失敗させてテスト自体のテストもすると思うけど

>>43
> デプロイするものに小さなバグが混じることを容認してる
> デプロイしたものはユーザに触れるわけでそのバグを見つけるのはユーザである可能性があるということ

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

バグがないソフトなんてあるのか？

>>46
> テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
> 開発形態

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

wikipediaみたいにだれでも書き換えるものが
存在すると思ってるんだよな？

小さなバグが入ることを許容する時点で馴染めないな・・・
全テスト通さないの？
そりゃ、テスト項目漏れは許すけども、許されるのはそこまでだろ

>>51
まさにそのテスト項目漏れのことを言ってんじゃん。

>>51
頭悪そう…

Linuxはガチガチの独裁型プロジェクトで、独裁者と奴隷しかいないからなんか楽しくない

>>51
誰が許容するなんて言ってるの？
許容するって言ってる奴は馬鹿だよ。

当たり前だけどgithubフローにバグを許容するなんて書いてない。
さあ、誰が言ってるのかな？
スレ検索すればわかるね。

「許容」でスレ検索したら、許容という
言葉を最初に使ってるのは、>>51でした。

なんだ自作自演かｗ

すぐ喧嘩するなお前ら
まあ俺もだけど

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　　　　 ＿
＿ 　　　　　　　＿ 　 　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、 ヽ| : i : : :,　　 　 ＿　　　　　　 ＿
＿ 　 　　　　 　 ＿ 　 ／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　 　　 　＿
＿　　　　　　 　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　 ＿　　　　　 　 ＿
　　　 　　　　　　 　 〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ¬ト､: :| : : ! : : : : :,
／　　　 　 　 　 ＼　　 /.: :/.: : : : /ｌ : |/Гト､　　 　 　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　 　 　 　 ＼
　／　 |　　|　　＼　 　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　 　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　 　 　 ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　 い、: :＼/ 　￣￣　　　　 　 　 　 　 　 　 ', : : i : : : : : : : : ,　　　　 _, -‐'　 　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣ フ 　 　 　 　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　 　 くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　 　 　 　 　 　 ／| : : :i : : : : :_, -‐'　 　 |　 ／
　 　ｒ―'　　　ヽ、 　 　 　 　 　 　 | : : : ＼　　　　　　　　 　 　 　 イ: : :| : : :i_,. -‐　　　　　　 |／
　 　 ｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　 　 .:〔: : :|: : :r┬'　 　 　 　 　 　 　 |

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　　　　 ＿
＿ 　 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┬'　 　 　 　 　 　 　 |

>>50-60 は全員 同レベルの存在

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 　　　　　　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　　　　 ＿
＿ 　　　　　　　＿ 　 　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、 ヽ| : i : : :,　　 　 ＿　　　　　　 ＿
＿ 　 　　　　 　 ＿ 　 ／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　 　　 　＿
＿　　　　　　 　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　 ＿　　　　　 　 ＿
　　　 　　　　　　 　 〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ¬ト､: :| : : ! : : : : :,
／　　　 　 　 　 ＼　　 /.: :/.: : : : /ｌ : |/Гト､　　 　 　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　 　 　 　 ＼
　／　 |　　|　　＼　 　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　 　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　 　 　 ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　 い、: :＼/ 　￣￣　　　　 　 　 　 　 　 　 ', : : i : : : : : : : : ,　　　　 _, -‐'　 　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣ フ 　 　 　 　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　 　 くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　 　 　 　 　 　 ／| : : :i : : : : :_, -‐'　 　 |　 ／
　 　ｒ―'　　　ヽ、 　 　 　 　 　 　 | : : : ＼　　　　　　　　 　 　 　 イ: : :| : : :i_,. -‐　　　　　　 |／
　 　 ｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　 　 .:〔: : :|: : :r┬'　 　 　 　 　 　 　 |

>>47
>>42 へのツッコミだろ。

>>62
見えてなかった。吊ってきやす

誰とは言わんがマルチしてるのばればれだからな

マルチ・・・？

ポスト

はわわ

>>61
これ何てキャラ？

自演とマルチの違いもわからない奴が許容だのなんだの偉そうに言ってたのか
恥ずかしい

※前スレから粘着してる頭の悪い荒らしがいるだけなので取り合わなくて結構です

※馬鹿のレスは馬鹿にしか見えません

addしてから編集すると、ちゃんとバレるんだな
かしこいじゃないか

先日のはこれの影響？

Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
http://www.atmarkit.co.jp/ait/articles/1401/21/news042.html

今読んだけどGithub-flowではリクエストをいったん取り込んで細かいとこ修正という流れができないから
オープンソース開発には向いてないんじゃないか

日本語ファイル名使うなら、非公式Unicode版使うしかないか。古いんだよね

msysGit でいけるよ

しまった
NGにレスしてしまった

あるブランチの内容をまるまるメインに取り込んで
コミットして用済みのブランチを削除
ってやり方は普通なの？

ブランチがどんどん溜まっていって邪魔
おまえんちゴミ屋敷

ありがとう
ブランチって削除できないのかぁ

タグに重要度みたいなのをつけられる？

重要なタグと重要じゃないタグをあとから区別したいんだけど
どうすらいいか

まるまるメインにコミットしたなら消してもいいだろ
試行錯誤して採用しなかった結果を個人的に残しておきたいときもあるんで、
リポジトリを別に作ってpushしておいたりもするが

>>80
ブランチ削除できるだろ

>>74
> 今読んだけどGithub-flowではリクエストをいったん取り込んで細かいとこ修正という流れができないから
> オープンソース開発には向いてないんじゃないか

なんで？

そのリクエストが動作に問題がないのであれば、取り込んで後から修正すればいいじゃん。
動作に問題があるのなら、github-flowでなくても取り込んじゃいけないし（ちゃんとテストしてから取り込む）
そういうのは、取り込まずに修正させればいいし、別ブランチで修正してから取り込んでもいい。

>>81
タグ名にルールをつけて、後でgrepすればいいんじゃない。

>>84
リクエストはマスターに来るだろうから即デプロイ可能な品質のコード以外は一度破棄することになる
マスタに入れる前に信用できるメンバーがテストをしないといけないが修正とテストをするためには相手か自分でブランチを切らないといけない
git-flowならデベロップにガンガン突っ込んで自分で直していけるのにリクエスト1個1個にブランチ切るのは効率悪すぎるしコンフリクトの温床になるだろ
ならメンバーはホットフィクスその他はデベロップでgit-flow流用したほうがいいんじゃないの

git-flow打つの面倒だから略語くれ

>>86
それのどこがgithubフローと関係あるの？

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

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

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

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

> コンフリクトの温床になるだろ
それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
開発者が一人しかしないというのなら話は別だが？

> 即デプロイ可能な品質のコード以外を一度破棄するのは
> どのフローでも同じじゃん。
OSS開発で集まる技術レベルのまばらな人間に十分な品質のコードを求めるのは非現実的
修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い

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

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

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

> それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
順次修正するならそうだが複数のリクエストをまとめて取り込んで修正する方法の選びやすさが違う
温床は書きすぎたのでもとになる程度にしとく

コンフリクトの量じゃなくて解消しやすさだな

git-flowやgithub-flowに替わる新しいflowを誰か考えてくれや

>>89
> バグフィクスのリクエスト100個のために100個のブランチがある状態にしたいか？

それgitでは普通だけど？

言っておくけど、gitではブランチは消すものなので、
バグがフィクスされれば、ブランチはなくなる。

>>89
> デベロップに入れるなら動かなくてもかまわないがgithubはマスタしかないのでそれができない

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

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

> マージしないで手で拾っていくのはGitの効率性を捨ててるし協力してくれる人もいなくなる
完成してから、ブランチをマージすればいいだけ。
Gitの効率性＝分散開発 なのだから別リポジトリで作業すれば良い。

>>89
> 修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い

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

つか、なんでマージしてからじゃないと修正できないと思うんだよ？

なんでケンカ腰なの？戦闘民族なの？

　　 ' ,　＼､ 、|　 　 　 　ヽ 　　l / ／　　　 ヽ, 　 ／　/　 /
　 ｀`ヽ　　ヽヽ!　, 　 lj　 　ヽ 　i／ ,　' 　u　　!／　／　　/
　　、　ヽ＼ ｀ l_/ /｀ヽ､　　 ヽ/ ／ ,. ' ´ヽ l ,'／'´　 　／__
　 ､ ヽ、　,へ､/ ,ﾍ｀`ヽ､ヽ. ｀　/ ／,. -‐,´ _!,-､ ／ ／'´／
　ヽ＼｀` l l^ヽ,',　 ',　　oヽ`､} ﾚ／o 　 ,'　 〉"^l/／'´／
　　 ＼､　l l r'　',　 ー―‐",｀ｰ´`ｰ―‐'　 //_',/_,. -;ｧ
　　　 ,.ゝ-＼ｰ､ ','"""""　　ﾉ_　゛゛゛゛｀　/'_j /　 ／
　　　　｀`,ゝ-ゝ､_',u 　 　 r====ｮ　　　 /-／_／
　　　　　´￣｀`ｰ,ﾍ　　　 `====''　 　 /=''"´
　　　　　　　 　 ,'､ ｀ヽ、,:'　-‐-　　,　'｀`>、
　　　　　　　　 ﾉ`::ｰ-､_＼＿＿,／_,. ::'´:::::冫二ニ７7ｰ-
　　,...-､‐ニ二{{:::::::::::::::::::::::::::::::::::::::::::::::::::::/ニニﾆ〃::::::::
　　:::::::::ヽニ二ヽ:::::::::::::::::::::::::::::::::::::::::::::::/二二ﾆ〃:::::::::::

こんな感じでもめるから *-flow が出来るわけなんだよな

何か実装するときにはみんなdevelopブランチから新しいブランチ作って始めるんだから、
developブランチに動かないものマージするなんて言語道断

すぐ喧嘩するなお前ら。まあ俺もだけど。

メジャーなリポジトリの使用例見てきた

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

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

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

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

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

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

夜更かししすぎた

>>85
ありがとう
それしか方法がないのか
意外とかゆいところに手が届かないね

ふつうのひとは
そんなところ
かゆくならない

世の中便利ツールが増えすぎて人間が不精になってきてるのな
grep程度を手間とか

>>103
grepが手間とかじゃあないんだよんべ
タグ名にそういう意味も持たせる ってのがちょっと嫌なだけ
みんな大好きなハンガリアン記法でしょ

つgit notes

jpegやbmpみたいなバイナリファイル、ワードやエクセルのファイルを
管理するにはどうすればいいの？
企業内開発では避けては通れないんだけど、チェックイン＆チェックアウト
みたいな管理はできるの？

あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う

あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う

開発用と社内アーカイブ用で分けるとか？

>>108
1度言えばわかる

>>110
すまぬ
タイムアウトして、リロードせずに再度投稿しちゃったもんだから…

あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う

gitってどの辺がperlに依存してんの？
今一分からん

>106
SVG

>>101
Excelとか何でもかんでも詰め込んだアプリでも使っとけ。
俺は今のgitでも詰め込みすぎててちょっと不安。キープシンプル。

あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う

>>106
シェアポイント

あるタグから後ろのコミットのメッセージの一覧
ってどうやって取得できるんだっけか

後ろって？

>>118
git log tag..
でカレントブランチのtag以降のコミットを見れる。

git log tag..branch
で任意のブランチのtag以降のコミットを見れる。

後ろって言えば、そりゃ、右を90度回転させたところよ。

>>121
おかしいな、前にみえる。

どんな規模のプロジェクトだろうと一番の問題はコミュニケーション齟齬、あいまいな言葉を使うなどで生じやすい

>>120
おっ サンキュウ

右手の親指と人差し指を90度に開いてL字にして
親指を垂直上方向に向けて人差し指を正面に向けた時に
人差し指を反転した方向が後ろ

右京区は地図の上では左

ITpro
伝わる文章：5日目「曖昧な曖抽象的表現の多い文章」はダメである 2014年01月31日
http://www.nikkeibp.co.jp/article/news/20140131/382014/

　相手に伝えやすくする方法の一つに「曖昧に書かない、抽象的表現を使わない」ということがあります。
曖昧な表現や抽象的な表現は、読み手の理解を妨げます。「かなりよい」、「とても大変」、
「我々には考えつかない程の大きな考慮点が必要」などの表現は、
相手に正しく理解してもらえないダメ文章に繋がります。

Gitを使い始めてから俺の生産性が500%上がった

>>127
フェルミ推定をディスってるな。

フェルミ推定は曖昧な情報で
相手を納得させる技術だからな。

フェルミ推定 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A
> 手掛かりを元に論理的に推論し、短時間で概算することを指す

「曖昧」や「抽象」とは異なる
フェルミ推定を誤解してると言わざるを得ない

〜すると、大変なことになります。[EOF]

という文章を見ると殺意がこみ上げてくる

禿丸ω

〜すると幸せになれる

ブログなんかの解説でこれ見たらファビョりそうになる

でお前らはどこにリポジトリをぶん投げてるの？
GitHub？

githubでしか使ってない
会社はsvn

>>134
GitLab

最近色々な同様のサービスのサイトが出来てきて迷うよな
GitLabはGitLab cloud?

GitLabはサービスじゃないよ。
GitHubのEnterprise相当の機能をもった
オープンソースのウェブアプリ

>>134
どこってVPSとかそういうことか?

リモートはSourceForge.JPの作業部屋っていう個人リポジトリとGitHubの個人リポジトリ使ってる
GitLab cloudやbibucketも最近気になってる

Dropboxにベアリポジトリ置くの超便利

自動同期はあまり好きじゃない

azure

そこらにある普通の無料レンタルホームページサービスじゃ
gitのベアリポジトリの公開は無理そうだな
OSSのホスティングサービス使うしかないのか

なんでGitLab cloudがあるのに
レンタルサーバーなんか使わんといかんのだ？

サーバーに対する信用性の問題じゃね
そこらのレンタルサーバーのほうが信用性がおけるならレンサバのほうでGitLabなりを構築する
レンサバよりもGitLab cloudなどの非公開リポジトリ可のサービスのほうが信用たるならそっち使う
という感じだろ

あとレンサバ使う理由としては独自ドメインを使いたいとかもあるんじゃないかな

あとは費用の問題とか
GitLab cloudなどのサービスだとgitサーバー以外の出来ることが限られるけど
サーバーマシンそのものを借りるレンサバなら色々好きに構築できるし

おいおい、前提として
「そこらにある普通の無料レンタルホームページサービス」
だろ？

専用サーバーとかVPSの話はするなよ。

>>149
勝手に前提つけるなよ

「そこらにある普通の無料レンタルホームページサービス」

これは自動挿入される広告とかで収入上げてんだろ？
gitみたいなダウンロードだけのことは規約違反だろＪＫ

>>150

>>144にかいてあるじゃないか
> そこらにある普通の無料レンタルホームページサービスじゃ

>>152
もともとの>>134の話題にレスしてる人もいるんだからってことだよ。

現在のブランチから分岐している(=fast-forwardの関係にない)ブランチを簡単に
リストアップする方法ってありますか？

現在のブランチのHEADから分岐してる別のブランチは、fast-forwardの関係にあるだろ？

>>154をどう読んだら「HEADから」と思うんだ？

git branch --no-merged
とかじゃだめ？

>>156
「現在のブランチから分岐している(=fast-forwardの関係にない)」

>>158
それのどこにHEADの要素が？

それのどこにHEADを除外すると書いてあるんだ？

　 ┌──────────　　←　fast-forwardでないブランチ
┬┴─────┬────　　←　現在のブランチ
└─┬────┘　　　　　　　　←　マージされたブランチ
　　　└─────────　　←　fast-forwardなブランチ

こんな感じ？

　　　　　　┌─■──■──■─────　　←　fast-forwardでないブランチ
┬─■─┴─■─■───┬────　　←　現在のブランチ
└─■─┬───────┘　　　　　　　　←　マージされたブランチ
　　　　　　└──■──■─────　　←　fast-forwardなブランチ

こんな感じ？

fast-forwardになってない

　 　 ┌■─■─■─■─■──　　←　fast-forwardでないブランチ
┬■┴■─■─■─■┬───　　←　現在のブランチ
│　　　　　　　　 │　 　　└■─■─　←　fast-forwardなブランチ
└■┬■─■─┘　
　　　└■─■─■─■─■──　　←　fast-forwardでないブランチ

こんな感じ？

fast-forwardは重要な概念だからちゃんと理解しとけよ
>>161-162は落第

fast-forwardの解説おながいしまうｓ

一番下のブランチは派生元のブランチがマージされてるから現在のブランチの分岐扱いになるのかな

>>166
fast-forwardとは
HEADが指すコミットを最新のコミットを指すようにするだけで済むマージ

fast-forwardでないとは
マージコミットが発生する

ブランチ切った後にそれぞれにコミットが発生すると初めて分岐が発生して
fast-forward じゃなくなる、でOKじゃないのかね

　 　 ┌■─■─■─■─■──　　←　ノーマルエンド
┬■┴■─■─■─■┬───　　←　ハッピーエンド
│　　　　　　　　 │　 　　└■─■─　←　真のエンディング
└■┬■─■─┘　
　　　└■─■─■─■─■──　　←　バッドエンド

>>169
それぞれ、だけと片方だけでもよさそうだからダメだな。
それぞれに異なるコミットが、にすればいい。

あと、さっきからHEADをsvnみたいな意味で使ってるやつがいるのか？

>>168
よくある説明だけど、わかっている人にはわかって
わからない人には全然わからない答えだよな。

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

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

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

またfast-forwardはclone元から単純に遅れている時にしか使えない。
clone元には無い修正を加えてしまうとfast-forwardできない。

こんな感じ？

http://ideone.com/hvgkDV

全然違う

以下のようにコミットの履歴が番号順に育っていて、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マージ」と「マージコミットを作成することによるマージ」
のどちらかを任意に選択可能。

リスト構造の概念が分かってればgitも似たようなもんだから理解は難しくないと思われ

全然違うよ

>>174,177
なにがだ。

　 　┌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まで来てしまったら鬱エンドは回避不可能。

現在Fにいるとして、ここからG、H、にはfast-forwardではいけない。
だが無理やりFにG、Hをマージすることが出来る。
そうすると、ハッピーエンドを見た後で、真のエンディングを見ることが可能になる。
単純にG、Hにくるだけでは真のエンディングしか見れない。
また逆にHにいるときにFをマージすることで、真のエンディング＋ハッピーエンドになる。

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

さすがに同じ選択肢で違う答えを選んでルートが別れたので単純にはマージできない。
これがコンフリクトである。もしコンフリクトが解消できたのなら
真のエンディングと鬱エンドを合わせた別のストーリーができるかもしれない。

おまえも人生巻き戻すべきだな

>>157
まさにこれでした。ありがとうございました。

これよかったよ。
http://www.slideshare.net/kotas/git-15276118
fast-forward な関係理解できた。

git でファイルモードの変更を無視するには
なにを設定すればいいんだっけか

ググればいいだろ。
http://tetsuwo.tumblr.com/post/36066698390/git-chmod-git-config

一つのディレクトリ、リポジトリを複数のサービスに上げることって出来る？
例えばgithubやgitlab cloudに

リモートリポジトリを複数持てるかってことなら当たり前のようにやれる
普通にgithub使うだけでも本家とforkした自分ので2つ使う参照するし

push 先選べばいいだけの話

git remote addでリモートリポジトリを追加登録すれば楽だな
しなくてもいいけど

GitHubはEclipseと連携出来るようだけど、GitLab、GitLab Cloudとかは出来る？

sshの公開鍵認証でリモートリポジトリとして使うだけなら、
Githubだろうがなんだろうが全部一緒だろ

なるほど
じゃぁEGit使ってGitLab Cloud試してみます

gitのpushを2回行った場合ってリポジトリに何か変更起こる？
git push -u origin hoge
ここでうっかり２回目のpush
git push -u origin hoge
変更というか書き換え？

試してみればいいよ

アレ？
俺根本的にgitのこと勘違いしてたのかな？
commitって言葉だけから、Subversionと同じ仕組みかと思ってたんだけど、
ファイルのバージョン管理は出来ないの？
あるリビジョンに復旧させたり、diffしたり...
SVNと昔から比較されてたからそういう事も出来るのかと思ってたんだけど

Git - Book
http://git-scm.com/book/ja

2のgitの基本を読むといいよ

Branch master set up to track remote branch master from origin.
Everything up-to-date
適当に作って2回pushしたら表示された
これってリポジトリでは何らかの変更が行われてるの？
それともヘッダのハッシュが同じだから弾かれてる？

英語ちゃんと読めよ

GitはSubversionとは用語の意味や使い方違うから
感覚で使わずちゃんと導入のための読み物があるのだからそれ読んでから使え

Git - Book
http://git-scm.com/book/ja

pushの -u オプションは毎回つける必要なくね？

大した分量でもないから基本的な部分の話だけなら２〜３時間くらいあれば読めるだろう

subversion と同じ感覚で使うと間違いなく事故る

>>197
送信の通信量をチェックするか
リモートブランチを自前サーバーにでも作ってチェックするか
Gitのソースコードでpushで何やってるかを直に見るか
すればいい

無駄に通信コストのかかる設計にしてるとはとても思えないがな

ところがどっこい

プロトコル次第なんだな、面白い
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

Gitのソースコード見てたが案外やっつけだな

くそぅ、うんこがしたいのに３日我慢してんだぜ...

味噌を食うと良い

EGitからpushする際、毎回URIの入力をしないといけないんだけど、これ何とかならない？
GitLab Cloudに送りたいんだけど 、毎回URIを確認しにファイルだかサイトだかにアクセスしないといけないんだけど

>>210
Eclipseスレで聞いたら？EGitの話題も多いよ

分かった
ありがと

git status
で見ると、変更があることになってるんだけど
git diff
で見ると、変更がない（属性も同じ）

これってなにが原因なの？

>>213
git add 済みとかじゃないの？

よくわからん
CRLFかな

普通はstatusの方が正しいかな
diffの方は差分をいろいろ無視するオプションがある

gitでdiffを見るときに
@@ -133,20 +128,17 @@
みたいな行の後ろが改行されないんだけど
これってなにが原因だと思う？

LFとCRLF改行の混在じゃね？

cvswebのdiff表示もそんな状態になってたな。
行番号の後にさらにその差分の部分がどこのCの関数内であるかを
付けられるとかなんとかそういうフォーマットもあるらしい。

CR/LFを多数決で判断するようなエディタなんか捨てちまえ。

改行コードくらいプロジェクトで統一しろよ・・・

>>218
CRLFの混在が原因ではなさそう
LFのみのプロジェクトでも @@ の後ろに改行がつかない

SourceTree使ってる人いる？

1ファイル内で混在みたいなアホなことになってるとか

>>224
仮にCRLFの混在があったとしても、
diffコマンドの出力にLFがつかない理由にはならないと思う

commitはしたけどpushはまだしていない分について
git status コマンドで状況見たいんだけど
どうしたらいいかな

remote との差が知りたいってこと？

>>222
>>219も言ってるけど、@@の直後に改行無しで表示される部分は、差分が属するクラスなんかの定義のことじゃないの？
差分を見やすくするためにdiffがソースを解析してくっつけてくれる。

>>226
ブランチがリモート追跡ブランチになってれば、
pushしてないコミットがあるときにgit statusに表示されるだろ
こんな感じに
# Your branch is ahead of 'origin/master' by 4 commits.

おれはgit logに(HEAD, master)とか(origin/master)が表示されるようにして
差があるかどうかを判断してる
こっちはremote追跡ブランチになってる必要は無いな

>>228
なるほど
その定義表示部分が空文字列になってて
改行表示されなくなってる可能性があるのか

いや定義表示部分が空文字列になってるとかじゃなくて、
@@ に続いて改行無しで定義部分が表示される。

こんな風に表示されることを言ってるんだろ？
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クラスの定義内に含まれてますよって意味だ

あああーなるほどー
そういうことか・・・
恥ずかしい発言だった・・・

cvswebの方はガチで1つ下にあるべき行がそこに入っていたけど、
そんなものを今も使ってるところが見つからないからもういいやｗ

http://code.google.com/p/git-core/downloads/list
１．８．５．４

空のフォルダに.gitkeepを追加しようと思ってます。
しかしフォルダ数が多いため時間がかかります。

自動で追加してくれるフリーソフトかなにかありませんか？

find . -type d -empty -not -path './.git*' -exec touch {}\/.gitignore \;

>>236
.gitignoreではないです。

>>237
横レスだが、ignoreでも問題ないし、以前はignoreだった。
気に入らないならkeepに変えればいいだけだろう。ちゃんとお礼言えよ。

空のディレクトリを見つけてそこに.gitkeepという空ファイルを配置する
スクリプトで簡単に書けそうな気もするけど

シェルスクリプトとか find だの test だの組み合わせるのがない世代なんだろ
もしくは Windows だとか

WindowsならWSHがあるじゃん

WindowsってGitBashがインストールされるじゃん

>>241
もう wsh は死んだのだよ
今は powershell だ

GitBashにfindもgrepもtouchも入ってるよね

要するに無能

何故唐突にgrep?

.gitignoreはバージョン管理しないファイルを指定するgitで決められたファイル
.gitkeepは空ディレクトリも作らせるための慣例的なファイル

という違いはさておき、 >>237 はその程度読み替えてほしいもんだ。

しれっといつのまにか vundle のメンテナ化するのかな

Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
システムだよな。
大手SIerで使わないのはそこにも原因があるんだろうね。
上ででていた、誰がどこを直すのかしっかり決まっている組織や開発体制では、その
作業のミスをふせぐMSSみたいなファイルのロック・アンロックのような
バージョン管理システムの方が向いている。
ExcelやJpegと行った、差分を取ってもしょうがないバイナリファイルの編集も必要だし。

GitHub-Flowだと独裁者が決めるって感じでは無いようだけど

またおまえか
ファイルロックで担当ミスを防ぐとか
いい加減勘違いに気付け

だからMSSて何だよ

WSSのましがい

google先生に質問した結果を最大限に好意的に解釈しても
　MSS=Maximum Segment
　WSS=Windows SharePoint Services
だな。

×MSS=Maximum Segment
◯MSS=Maximum Segment Size

>>249
VSSでチェックアウトするとデフォルトでロックするのが不便なのは周知の事実で、
TFSではデフォルトではロックしないようになった。
ロックを使わずにワークフローで重複作業を防ぐのが今のベストプラクティス。
新しいものに拒絶反応を示すのはやめて勉強した方がいいよ。

会社でベストプラクティスとかいう単語を使う奴は信用しない。

じゃあワーストプラクティス

お前は信頼はできないが信用は出来そうだな

信用は金で買えるからな

信用金庫でお取扱しております。

「情報共有」、「コミュニケーション力」、「本音ベース」

>>250
github flowに限らずgit flowとかも、いわゆる中央リポジトリーのようなものを
作ってそこからpull、pushしてという感じになる。pushに関してもただ単に権限の
問題だからやろうと思えば好きなモノをpush出来る。ただそれだと色々問題が
起きるかも知れないからっていうのでレビュアーを置いてチェックするルールで
運用しているだけ。 svnなんかもライブラリ管理者やゲートキーパーなんて
呼ばれている人がいたわけで、ある意味独裁者だったでしょ？

独裁って言葉に過剰飯能する奴いるけど、Linusの独裁モデルに都合の良い仕様だから当然でいちいち反論しなくてよろしい

ジョブズでもなんでも、良い製品は民主的体制じゃなくて独裁から生まれる

＞Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、ってシステムだよな。
まずはここが間違ってるよね。GitではPull-Request方式しかできないと思ってる？

Gitでもマージしてpushの手順で各個人が中央リポジトリに各々修正を追加していくことができる。
SVNと別に変わらんよ。

>>249
　「Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
　　システムだよな。」
そんなことはまったくない。
別にlinux kernelの開発スタイルでなくてもgitは使えるよ。

このスレで独裁者モデルの話をするのはやめたらどうかね。
OSSの開発モデルの一つでしかなく、gitとは直接関係のない話だ。

天才がいれば独裁が一番なのは当たり前
でも天才自体少ない上に、万人に都合の良い天才なんてそうそういないから困るんだよね
すると多数決的な体制にならざろうえない

きちんとした独裁者モデルを構築したいんだけど
gitだとちょっと難しいんだよね

UNIX板で遊ぶのに飽きてこっちに来たのか

> 天才がいれば独裁が一番なのは当たり前

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

独裁が一番なのは、小さなプロジェクトにおいての話。

>>270
なんで独裁者が一人でコード書くの？
コードを書かせないと独裁にならないでしょ。
ちょっと認識がずれてるみたいだけど大丈夫？

船頭多くして船山に登るっていうことわざがあるくらい昔から意思決定の
人間は少ないほうがいいって事が言われてるのに。

>>271
誰も一人で書くとは言ってないよ。
こなせないといったの。
レビューをこなせないと言ったんだよ。

でもどうやら君はコードを書かせれば、
それでやれると思ってるみたいねｗ

>>273
Linusの独裁モデルがどんなものか
ちょっと勉強してきたほうがいいよ？

>>274
調べてきた結果、俺の言ってることに
何も問題ないことがわかったよ。

Linusはもちろんコードを全部書いてるわけでもないし、
全部のレビューをLinus一人でやってるわけでもない
しかし独裁と言われている。

>>275
ちゃんと理解してたら>>270みたいなことは言わないでしょう。
だめね。やりなおし。

>>277
いや、理解して言ってるよ。
違うっていうのなら、
ちゃんと君が説明したら？

>>278
>>276に書いたとおり、独裁モデルっていうのは独裁者が全部レビューしなくても成り立つの。

そもそもLinusのやり方は独裁じゃないから
論点がずれてる。

今は独裁の話をしている。

この「独裁」の話をしている。

249 名前：デフォルトの名無しさん[sage] 投稿日：2014/02/11(火) 05:11:32.98
Gitってみんなが勝手にいろんな所を直す→独裁者がどこを採用するか決める、って
システムだよな。

前提が違うｗアホか逃げるなｗ
Gitの独裁モデルと言えば普通Linux kernelの独裁モデルだろｗ

一体誰がLinuxの独裁モデルの話を始めたんだ？
どう見てもあとから言い出しただろ。

>>263
結局まともな運用しようとしたら、集中型でってことなのか...
ローカルコミットさえサポートしてくれれば svn で充分だな。

svnがgitと同じになれば、svnで十分だな。

ローカルコミットがあったらそれは分散型だろ

>>283
gitに限らず、普通に独裁モデルと言えば
Linusがやってるモデルを指すのが一般的よ

>>286
なにそれこわい
cvsも分散モデルになれるってこと

あほか

>>284
いや、リリース用のプロダクトは一つに収斂されるから中央のようなものが
あると都合がいいってだけ。 コミュニケーションパスが太ければ、次のは
○○さんの所に集めてそれを使いましょうってことも出来る。

まあ、少なくともsvnのあのマージの苦行に戻るくらいなら多少難有りでも
gitを使いますよ。

gitのシステムに文句を言うのではなく
git導入を決意した上司などに文句を言うべき

(優しい)独裁者モデルというのは、適切なリーダーシップが無ければプロジェクトは成功しないという意味だぞ
toolで制限をかける方法は、平等で民主的に見えるが、いずれ破綻する

>>292
逆だろ
toolで制限かけないといずれ破綻する

toolで制限かけるしかコントロールできないなら、何やっても無駄

>>249
そうだよ
Gitみたいな分散型をSubversionの上位概念みたいに言ってる、はてなの連中とかウザいって前から思ってた

まだいたのかキチガイ

だからgitに文句言うのでなくgitを採用決定した上司に文句言え

OSS開発には向いてると思うなのGi

gitの分散型なんてどうでもいいわ。実際の所、分散開発なんてしねえし。
gitが重要なのは分散型ではなく小さいコミットの積み重ねで開発が可能というところ。

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

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

gitはソースコード管理ツールじゃねぇ。
開発とリリースのためのツールだ。

お前がそう思うんならそうなんだろう（ry

反論がないのならそうなんだろうな。

GitやMercurialのような分散管理が向く場合もあれば、Subversionのような中央管理が向く場合もある

いや、管理だけでなく開発のことも考えろよ。
Subversionでどうやって間違ったコミットの修正とか
大きな開発を小さなコミットに分割とかするんだよ。

ソースコードを中央に上げる前の
手元の開発作業の話だよ。

馬鹿には無理

ソーシャルゲーム，ボードゲーム，ファミコンまで!?　Global Game Jam 2014参加レポート：レポート｜gihyo.jp … 技術評論社
http://gihyo.jp/news/report/2014/02/0601?page=3&ard=1392151422
> 今回，メンバーのプログラマ全員がGitを使ってソースコードを管理していたのですが

git人気すぎだんろ

Windowsでgitも日本語ファイル名使えるようになったみたいだけど
GUIはどれがお勧め？

CUIと同じくらい軽いGUIクライアントってないの？

SourceTreeでいいだろ

そのSourceTreeが重いんだよ
なんかしらんが過去データか何かに
アクセスしすぎ

>>307
そんな軽いツールキット自体がないだろ。gitに限らず。PCの性能によっては無視できるだろうけど、それはあなたが鈍感である必要がある。

>>299
cvsやsvnの時代から、リポジトリを持ち出せるようにする追加のソフトあったろ。そういう需要があったと言う事。

>>308
いいよね、SourceTree。
ちなみにbitbucketも最高。

gitはmercurialと比べても履歴を修正出来過ぎて、余計な混乱を招く
高機能が常に低機能に勝るわけじゃない

> 履歴を修正出来過ぎて
え？ 出来・・・すぎ・・・？

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

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

一体どの程度の履歴修正機能がほしいんだ？
なんの履歴修正機能が欲しくて、どの修正機能は
つけたらダメだというのだ？それを具体的にいいなよ。
でないと、無知が叫んでるだけだって思っちゃうよ？

>>312
うちはポリシーで対応してるが、できないって方がゴネたり誤魔化すやついなくて良いかもな。
リポジトリの設定で変えられるくらいなら、高性能もいいな。

普通、共有リポジトリはdenyNonFastforwardsとdenyDeletesを設定して
履歴の巻き戻し禁止にするから
混乱なんてしない

だから”ソースコードの管理”ではなく
ローカルで一人でやってる開発作業が
やりやすくなるんだよ。

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

ソースコードの管理なんて考えているから
gitを理解できないんだよ。

>>314
ゴネたり誤魔化す奴のために機能を削れってか？
糞だな。
確かにそういう環境ならgit使わなくていいよ

>>317
リーダーとかマネージャーやるようになったら、そういう苦労もわかるようになるよ

そこまで考えてクソだと思うなら使わなきゃいいだけなのに
いったいどうしたいんだろう

馬鹿には無理

>>318
まずは、誤魔化したりゴネたりする部下の態度を改める努力はしたのか？
それが面倒くらいだけなんだろ？
その面倒を避けるためにgitという他に余りあるメリットを切り捨てるという愚策。
つまり本質的なところでお前はマネージャーとしての苦労を放棄してるんだよ。

リーダーとかマネージャ側の都合でGit使えないとか情けなさすぎて涙が出る

折衷案としては
「履歴書換申請書」（専門部署による決裁）
かなｗ

>>321
いや、想像だから。うちはポリシーで対応してるって書いてる。
まあ、誤魔化しとかチェックしないとわからないけど。

共有リポジトリの改変許可は>>323のレベルの非常事態対応だけでいい
好き勝手やっていいのはローカルリポジトリだけだ
共有リポジトリとローカルリポジトリに明確な線引きをして
ローカルリポジトリ側で好き勝手やれるのがGitのメリット

>>324
共有リポジトリへの直接ログインを制限してさらに>>315の設定してあれば、
誤魔化すとかできないだろ？

>>326
それは俺が>>314で言ってること。
高機能と低機能の比較の話で、gitがって話ではない。

あ、話をまとめるとだな。
「subversion」 = 「gitのリモートリポジトリ」
こういうことだよ。

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

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

「gitのローカルリポジトリ」　これはsubversionには無い。
subversionではローカルで作業している間は昔ながらの
ファイルコピーでバックアップ（笑）をしていなきゃならないし
作業中の特定の地点のコードに戻すのは大変だが、
gitではリモートリポジトリに加えて、ローカルにも
個人専用のリポジトリがあるので開発作業が格段に楽になる。

robocopy使えよ捗るぞ
好きなタイミングで突っ込めるし何よりわかりやすい

robocopyじゃ捗りません。
どれだけ低機能で満足してるんだよｗ

結局アレだ、subversionをファイル倉庫として
バックアップ機能としてしか見ていないから
コミットをマージして開発する流れが理解できんのだ。

むしろそういう旧態然の人が居てくれるお陰で
ご飯を食べるチャンスが増える

robocopyみたいなツールじゃ特定地点に戻したりとかしかできないもんな。

Gitなら特定地点から現在までのコードの差分を機能別に分類。
分類した差分を任意の組み合わせで適用して試すとか出来るからなあ。
そして必要な差分だけを一つのコミットとして共有リポジトリにpush。
残りの差分はまたローカルにいじくり回す作業を続ける。
こんなのを手作業でやるのは気が遠くなるけどGitなら簡単にできる。

git でリモートブランチとのアクセスが生じるのって push と pull 以外にあるかしら？

ローカルとリモートのリポジトリ間で情報をやりとりするのはpushとfetchだな
pullはfetch+mergeでしかない
後はcloneで丸ごとリモートリポジトリをローカルにコピーとか
ls-remoteでリモートリポジトリを参照するとか

>>335
ありがとう。
ls-remote を知らなかったよ。peek-remote とか色々あるんだな・・・

repoA　　　repoB
リモート　　ローカル
俺が指摘したのはこの間をrobocopy使えつー話なのに
robocopyでバックアップ管理だとしかおもえなかったんだね

やはり馬鹿には無理だね(笑)

そう。無理無理。わかったよ天才だ君は。

>>337
なにそれ？ローカルが一つなの？

svn使ってるなら、git-svnでかなりの事が出来るのに。
まあ、オレの周りでも禁止してるわけじゃないのに頑なに使わずにコミットミスや
コミット漏れを続けてるのがいるけどね。

commitしてpushまでしちゃったら
もう取り返しはつかないよね？

つくかもしれないけど
下手にごちゃごちゃやるよりは
忘れてもっかいcommitすべきだよね

それは使わないんじゃなくて、使えないんだろ。

git-cvs は便利だね

>>337
馬鹿には無理wwwwwwwwｗｗｗｗ

robocopyは便利だな
というかrsyncのコマンド体系が分かりづらすぎる

>>337
それで何がしたいの？

アンチって何でわざわざ自分から嫌いなものに関わろうとするんだろうね、よく分からない

rebase するときって一つ前のコミット ID を指定するけど、
一つ前のコミットが存在しない初回のコミットって内容の修正は出来ないのかな。

rebaseの引数にコミットIDなんか書いたこと無いなぁｗ

rebase -iを使うときは書き換え始める位置のひとつ前のコミットIDを指定するかな

質問の意味がよく分からない
図で説明してくれ

え？ 一つ前ならHEAD^じゃん？

イニシャルコミットの一つ前のコミットが存在しないから
イニシャルコミットは書き換え出来ないってことだろ

git init直後の最初のコミットは空にするようにしてる

空のコミットってどうやるん？

git commit --allow-empty

お、さんきゅー

>>348
最初のコミットの書き換えはメンドクサイことすればできるよ
最初のコミットからブランチを作ってそれをcommit --amendで書き換え
(この時点で起点を共有しないブランチがリポジトリに存在することになる)
その後もとのブランチに戻って、書き換えた最初のコミットのブランチへrebaseする

はぁ？ git rebase -i -root これだけじゃん。
何が面倒くさいのか。

>>359
うちのgitにはそんなオプションないな
バージョンいくつよ？

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>.

1.7.xだとgit rebase -i --rootもダメだ

ああ、1.7.12から使えるようになったらしい

gitは最新版を使った方がいい。

rebase: learn to rebase root commit ・ 190f532 ・ git/git ・ GitHub
https://github.com/git/git/commit/190f53232d1e92a57843df90e889bcfea39620d3
> Teach git-rebase a new option --root

debian squeezeだとbackportsでも1.7.10が最新なんだよなあ
そろそろ新しくするか

debianとかねーわ

コンパイルして入れればいいのに。
gitは仕組み的に、ファイルにアクセスして
ネットワーク通信するだけだから簡単にコンパイルできるよ。

>>365
そのへんのバージョンだと-i --rootじゃダメで、--ontoを指定しないと叱られる

>>368
> ファイルにアクセスしてネットワーク通信するだけ

そんな言い方したらほとんどのソフトが当てはまるわけだが (w

数百を超えるソフト使ってるのに、いちいち手動で入れてられんわ

必要な物だけ手動で入れればいいのでは？

お、新しいバージョンだと最初のコミットもいじれるのか

squeezeなんてもうすぐeolだぞ

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する必要がある？

>>372
じゃあgitは不要だ。

最新安定バージョンのwheezyでも1.7.10なんだけどな

無駄に用心深いdebianじゃどうしようもない、捨てろ

backportsに1.8.5.3あるじゃん

>>377
フリーズしてから1年以上立つんじゃないか。
安定版は機能追加しないぞ?

tortoiseGit1.8.7使っているんだけど、一度コードを変更してから前の状態に戻したら大抵は
変更無しとみなしてくれるんだけど、ちょくちょく変更ありのままになってどうしようもなくなる。
これってどうやったら巻き戻せるの？checkoutしてもresetしてもrevertしても戻せない。
結局面倒になって全部消してcloneしなおす感じになっているんだけどなんか納得いかないんだよな。
Subversionだとrevertするか一度消して取りなおせばokだったけどどうも思う様にいかん・・・。

馬鹿には無理

デスマおつかれさまです。
さっさと寝たら？

git config core.filemode false
git config core.symlinks false

ローカルでの変更全破棄
git checkout -- *
面倒なことが起きてる場合
git reset --hard origin/upstream_worktree

>>384
ダメだった・・・

コミットの打ち消し ってなにをするんだろう
どうなるのか実験するの怖い

revertは、過去のコミットで追加した部分を削除する、新しいコミットを作るだけだよ
あまり高度なことをやってるわけじゃないから
revertしようとするコミットで追加した部分が既に変更されてたりするとコンフリクトする
その場合は手作業でコンフリクト解消しないといけない

git って差分じゃないのによくマージとかできるなと思う。

gitは圧縮されたスナップショットだがsvnと違ってブランチ切りで大量のコピーは生み出さない

メインのブランチがある。
そのブランチからの派生が二つあって
それぞれブランチAとブランチB

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

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

なんでみんなそんなほいほいマージできるんだ？

2つのファイルから差分情報を作るのと、
1つのファイルと差分情報からもう1つのファイルを再現するのと、
難度に違いがあるの？

>>390
そのためにレグレッションテストを用意しておくんじゃね？
ほいほいマージっていうけどなんの検証も保証も無しにほいほいやってる人はよっぽどの自信家なんだろう。

プルリクエストをマージする権限のある人がちゃんと検証するもんじゃないの？

プルリクエストって・・なんで github 前提なんだよ

複数人で開発してる場合にはどちみちマージしなけりゃいけないんだから
それを手作業でやるかツールでやるかの違いにしか過ぎない

マージかよ

>>389
svnもコピーを作ってるわけじゃないぞ。ブランチ切っても変更したやつだけが
格納される。 ただローカルに落とすときに実体としてのファイルが必要になる。
svn copyとか処理自体はgitのブランチと同じですぐに終わる。

gitのブランチ切りはすぐ終わるという謳い文句は一体何だったのか

Gitのブランチ切りは管理してるファイルとか一切変更しないからマジはやいよ

>>398
ブランチ切りは速いよ。切り替えは遅いこともある

簡単に切れちゃうからこんどは使い終わったブランチを消すべし消さないべし論争が

昔みたいに安定版と開発版みたいな2本のラインで無理なく開発出来るくらいの
開発スピードだったらsvnでも良かったんだけど、今だと無駄に並行開発して、
リリースもまちまちだったりするからsvnだと取り回しがしんどいって部分も
結構あるからなぁ。

　　↓　　↓　　↓　　↓　　↓　　↓
http://kohada.2ch.net/test/read.cgi/prog/1190866177/816

>>401
保守するなら残す。しないなら、する必要ないなら削除する。
それがgitのブランチ運用じゃん？
マージ済みとかで開発の終わったブランチを残す理由って何だろ。

>>404
テンポラ

>>404
マージの仕方にもよると思うけど試行錯誤の跡が見えた方が履歴を追う時に
良いというのは考えられるけど・・・大抵は古い作業データなんぞ見ても意味ないし
殆ど理由は無いと思われ。なかなか物を捨てられずに整理できない人と同じじゃない？

隠し状態に出来れば一番いいんだけどな
そういう痒いところにはなかなか手が届かないな

どこかに適当なリポジトリ作っといてpushすればいい
それで手元からは消す

人間は消してもいい、という判断が適切にできるもんじゃないという思想が
根底にあるんじゃないのGitって。とにかくとにかく過去にやったことは極力
追えるようにしておきたい、というのがデフォ。

自分一人でやってることならそれでいいんだろうけどさ、多人数でやる以上
絶対はない、必ずさかのぼれるようにしておきたいという思想があるんだと思う。

git svn cloneで、svnの同一階層のディレクトリから
一部のディレクトリについてだけcloneすることってできませんか?
たとえばsvn側が以下のようなディレクトリ構成だとして
DirAとDirBについての履歴だけいっしょにcloneしたい状況です。

　Dir
　 |-DirA
　 |-DirB
　 `-DirC

git svn clone Dirしてしまうと
不要なDirC含めてすべての履歴がクローンされますけど
DirCの差分は不要な場合、どうしたらいいでしょう?

マージコミットの粒度がすごく荒いとブランチ消したくなくなる

>>409
うーんどうだろ
gitの場合は過去を改ざんする手段が割と豊富にあるし
その気になったらなんでもさせる気構えなのがイヤだよ

>>409
それはVCSの存在意義みたいなものだし…

むしろgitは性善説に則って人間側の自由を重んじている感があるけどなあ
VCSの中でもgitは何でも出来ちゃう部類だと思う

マージするとき XX な時以外は fast-forward するな！とかみたいな
運用フローをプログラムレベルで保証するようなラッパーとかあったらいいのかもね。

github のプルリクエストみたいなのはうまくいってる例じゃないかなあ。

>>406
バグ修正してる時に、なんでその変更したか読み取るのに必要。BTSと連携してるので特に。

>>415
それあるね
消されるとわからなくなる
消せないフラグがあるといいのかね

>>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のみ履歴から消すことができる

>>410
sparse checkout

1.9がキター

ほんまや

>>312
元々、mercurial使ってからgit使い始めたけど、ほんまこれ
gitを理解してる上で、これやろうならいいけど
あんま理解してない状態で、あれやりたい！とりあえずググろう、みたいなスタンスで使って泥沼に嵌ってる人をたまにみかける

理解さえしてしまえば、かなり大胆にいろいろ自由にやっても破綻しない
そして、構造自体は比較的簡単なので理解するのはそれほど難しくない

GithubってGithub自身のソースは公開してないのかよ！

おまえのものはおれのもの
おれのものはおれのもの

\\hoge\fuga\bar\.git というサーバーをwindowsでcloneするにはどうすればいいのでしょうか？

httpsやhttpでアクセスできないと思うのですが・・・

フォルダごとコピー

>>425
cloneの展開先はローカル限定だけど、展開元はリモートでもローカルでもどっちでもいいぞ
hogeサーバのフォルダをローカルで参照できるんだろ？
ならばローカルからローカルへのcloneで何も問題無いんじゃ？

ローカルなリポジトリの参照方法を聞いてるのかね

試してみたけど、Cygwinなら普通にこんな感じでできるな
git clone //hoge/fuga/bar/.git bar
最後のbarは何でもいい

ありがとうございました。
できました。

>>426
.gitごと含めてまんまフォルダをコピー
そのあとoriginをコピー先に変更


これとgit cloneって違いはありますか？
こんな方法で使用継続しちゃってもいいのでしょうか・・・

>>431
違いはある。が実用上問題ない。

コピー元のOSが違ったら改行コード問題が起きね？

件の件はローカルのコピーだろうから問題なさそうな気もするけど
確かに config で設定してる色々なフィルタ処理を考えると clone した方がよさそう

core.autocrlf=trueの設定に依存してる人はワーキングコピーに変換が反映されてなくて問題になるかもね
まあ俺はWin環境でもソースファイルの改行は原則LFにしてるから問題にならんが

ああ、でもｗ逆に俺のcore.autocrlf=falseの環境では、
core.autocrlf=trueのワーキングコピーをそのままコピーしてきて、
改行コードCRLFのままファイルを編集コミットpushして、
顰蹙を買う可能性があるのかｗ

分散バージョン管理システム「Git 1.9」が公開 | SourceForge.JP Magazine
http://sourceforge.jp/magazine/14/02/17/153000

git pushでエラーが出るの治った？

>>438
それはあんたが勉強して
正しい使い方を学ばないとだめだよ。

バグなんよ

http://orangeclover.hatenablog.com/entry/2014/01/15/215758
https://github.com/msysgit/msysgit/issues/153

close されてんじゃん

なんかさ、一生懸命チェックしてこれでよしと思っても
pushした瞬間にキャンセルしたくなるよな

今pushしたのだけ大至急キャンセルするにはどうしたらいいかな

どういうflowか知らんがpushを戻したくなる状況ってよく分からんな

revert して、push すればいいじゃん

コメントの書式微妙に間違ってた！なんてとき差し戻したくなるよな
ローカルリポジトリならそういうのやりたい放題なんだが

ドジっ子が多いんやな

説明文の英語ミスったりとかな・・
git push -f でなかったことにして修正してるんですけどね

ネイティブすら気にしない英文のミスを日本人は気にし過ぎる

立つ鳥後を濁さず的な精神強すぎるんよ
過去を消したりしてまでやる価値あるんか？

そうはいっても amend みたいなのでちゃちゃっと直す癖ついちゃってるしなぁ

コメントだけなら、サーバにリモートログインして rebase -i で変更したらいいんじゃね

その潔癖がクレーマーを生み出す原因なんだけどね

飛躍しすぎだ

おまえらって↓これをチェックしてたりすんの？

github/gitignore ・ GitHub
https://github.com/github/gitignore

マルチうぜー
http://toro.2ch.net/test/read.cgi/tech/1354608228/859

>>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に対する変更のみのコミットが空コミットとして入っているので、
　　それらを削除

fetch面倒くさい

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版）

具体的なバージョンは忘れたけど
fedora12環境(つまり結構ふるい)では
ふつうにgit svn cloneできてたよ。

※svnのサーバ側もlinux。バージョン等はよく知らない。

と思ったけど、やっぱ忘れて。
tagsのことは知らない。。。。

昨日新宿西口のドトールで隣りの席の奴がGitポケットブックよみながらMacBook
いじってたので横からずっと覗いてた。
かなりなヘボプログラマだった。

>>461
いいなあ。そんな暇俺も欲しいわ。

みんな初めはヘボなんだよ

知らない人が隣から覗き込んでくるって怖いね

tigって使ってる？

>>461
ボウリングだと隣の香具師が下手でも何も思わんが
プログラマだと隣が下手だと気になるよね不思議だぬ
http://www.nicovideo.jp/watch/sm8562641
http://www.nicovideo.jp/watch/sm8642352

結局は争いは同じレベルの以下略と同じだろ。
プログラマという同じ土台に乗ってるという
土台のレベルが同じだったとｗ

あなたがそうなのですねわかりますω

わざわざレスを付けに出てくる時点で
見下してるはずのレベルの奴とレベルが同じになると
気づかなかったのだろうか？ｗ

よくできてるな
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

githubはもう古い
時代はgitlab

EUCで保存されてるリポジトリを
ShiftJISに変換してチェックアウトしたいんだけど
やり方を教えれ

>>472
ワーキングツリーだけ文字コードを変更する方法などない気がするが。

フックかけて文字コード変更するとかかねえ

>>472
他の人はEUC-JPのコードで実行。お前はShiftJISで実行
HTMLはEUC-JPなのでShiftJISで実行したお前は文字化け

コンパイルしたら、バイナリにはEUC-JPで格納。
そのソフトをWindowsで動かすときにはEUC-JPをShiftJISに変換して出力するコードが含まれている。
お前はShiftJISでバイナリに格納され、ShiftJISをEUCｰJPだと思ってShiftJISに変換。もちろん文字化け。

>>472
cleanとsmudgeフィルタを使えばできそうな気がするが実際にやってみたことは無い。
http://git-scm.com/book/ja/ の「7.2 Git のカスタマイズ - Git の属性」の「キーワード展開」のとこに説明がある。
checkout時とcommit時にそれぞれフィルタをかける方法。

>>476を参考にして下のような感じで>>472が解決できました
どうもありがとうございました

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

git --globalでフィルタプロパティを編集
[filter "txtconv"]
smudge = nkf -s
clean = nkf -e

.gitattributeじゃない.gitattributesだった

>>477
git diffとかも問題無く使える？

リポジトリと作業フォルダの文字コードが変わっても、
その文字コードの差異に関してはdiffは反応しなかったです
テキスト内容を編集した分に関してはdiffが反応します
自分が試した感じでは期待通りの動作でした

もしや、ascii文字だけでそれを試して、わざわざここに書いたのではあるまいな

>>481
リポジトリと作業コピーの改行コードが違ってても同じtextとして認識してるだろ？
それはgit内部でフィルタを使ってるからなのよ
上で行ってるのはユーザーがその機能を追加してるだけ
お前は知らないなら自分で試せよ

http://git-scm.com/book/ja/の7章は役に立つノウハウ満載だな
そんな長くもないし一度読んでおくべき

ローカルで何もしてないのにコンフリクトが起こる糞vcs
CONFLICT (content): Merge conflict in ...
Automatic merge failed; fix conflicts and then commit the result.

>>484
git mergeとかしない限りコンフリクトなんか起きねーよｗ
なにもしてないのにコンフリクトが起きるわけがない。

起きたらgit statusとかgit logみれば原因ぐらいわかるだろ。

IT土方屋のこびと

おじいさんがデスマで疲れ果てて寝ていると
小さな妖精さんがコードを朝までに仕上げてくれました
なお git rebase master はおろか
大量の機能を一本糞コミットにまとめたあげく
コンフリクト解消の途中でばっくれた模様

途中でバックレてもpushしてなければローカルだけの話だろうし、pushされてても
そんなのはrevertで打ち消しちゃえばいいだけの話だろ？

>>484はいつもの人なんで真面目に構ってもムダ

おじいさんはwizardだったので、
git reset --hard HEAD@{6.hour.ago}
して何を逃れましたとさ。

現実提示して批判したら>>485や>>488だからなあ
どんだけ馬鹿だらけなんだろうね(笑)

ageるやつはキチガイ、はっきりわかんだね

「何もしてないのに壊れた」とか素人かよ

>>492
そりゃ素人だよ

素人が質問してはいけない空気

いやあ、素人が質問はいいけど
素人がわけもわからず見当はずれのdisはいかんでしょ

そもそも質問じゃない件

>>484\n君は他のを使った方がいいかもね（ニッコリ

>>497
特定のプロジェクト限定で*仕方なく*使ってるんだよ
わかるかな?

ついでに言えば489の件はとうの昔にバッチに組み込んである

ほんとなんでキチガイってageるんだろう。

イミフ

たぶん489をバッチに書いて
出社時
昼休憩後
帰宅時
に毎回実行してるんでしょ

そんな馬鹿なことする馬鹿は501くらいだ

ネタにマジレス…

質問です。
今日変更した分の差分を見たいですが、どうすればいいでしょうか？

git diff HEAD

もう既にコミット済みなんで何も表示されないです…
とりあえず git log して昨日の最後のコミット番号をコピって
git diff xxxxxxxxxxxx として確認は出来たんですが、
もう少し簡単に見れればと

git diff -1

git diff $(git rev-list -n1 --before="1 day ago" master)

>>506
git diff master@{one.day.ago}
git diff master@{12.hour.ago}
etc

>>508
遅くなりましたが、まさにこれでした。ありがとうございました。

>>509
見逃してました…こんなシンプルな書き方があるんですね。勉強になります。
みなさん、ありがとうございました。

git-flowとgithub-flow以外にメジャーなgitのflowってある？

カレントブランチであれば
git diff @{yesterday}
とも書けた。これが最短かな。

512
ggrks

>>513
これって過去のカレントブランチになるの？
過去のHEADになるの？

revisionのデフォルト指定を考慮すると
git diff @{1}
でよかった。しつこくてごめんなさい…

>>515
gitに詳しくないから今一質問の意味するところが分かりません…

>>516
24時間前にはdevelopブランチをチェックアウトしていたとして、
現在はmasterブランチをチェックアウトしているとすると、
git diff @{yesterday}
は24時間前のdevelopブランチをさすのか、
それとも24時間前のmasterブランチをさすのかどっちだろってことでした。

>>517
http://evadeflow.com/2011/04/git-diff-yesterday/
を見るに、
git diff @{yesterday}
git diff HEAD@{yesterday}
は等価みたいなのでdevelopブランチをさすみたいですね

>>517
gitは24時間前にどのブランチをチェックアウトしてたかなんて管理してないと思う。

>>519
git reflog show HEADしてみるとわかるよ。

git diff @{tomorrow} が実装されるのはまだ？
これがあれば開発がずいぶんと楽になると思うんだけど。

$ git merge @{tomorrow}
Already up-to-date.

$ git merge @{tomorrow} --allow-empty

>>522
バグってますね。
空なワケがない

git diff @{tomorrow}が実装された瞬間に時間(歴史)の矛盾が生じるので世界が崩壊します…

涙の数だけ強くなれるよ

$ git merge @{tomorrow}
Already up-to-date.
↑
今日という日に勝るものはない (ゲーテ)
今日を大切にｲ�`とgitは教えてくれている

現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/

>>523
こういう結果になるがよろしいか
http://p.twpl.jp/show/orig/VJ6m2

どうしてgitにはリモートのタグ一覧を見る機能が無いんだろう

>>529
gitはとってきてから何かするってイメージがある。

>>529
ls-remote --tags

>>529
どうしてそう思ったの？

まだ公式サイトにも Google code にもないけど 2.0.0 がリリースされたみたい
Git 2.0.0 released
http://sdt.bz/content/article.aspx?ArticleID=68912&page=1

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

いよいよ入門書の決定版が出そうだな。

ステマ？

GitとGithubの違いがわからない人か
それほど厚い本でもないし、Git自体の解説にはあまりページを割けないだろ

git init
ls
fileA
git add fileA
ls
gzip filreA.gz

これしたらfileAが残ったまんまになった
touch fileAしてgit addしてコミットしたら直ったけど

>>537
indexにfileAが残ったまんまになるのは当たり前だろう。
indexが何かがわかってないのかな？

>>537
3行目のfileAは2行目のlsの結果なのだろうか？
とうことは5行目のlsの結果は？ファイルが存在しないってこと？
6行目のgzip filreA.gzってなんだ？仮にfileAを圧縮するならgzip fileAだよね？
fileAが残ったままになったというのはlsするとfileAだけ存在するってこと？

リポジトリの状態はgit statusで確認しろ

git init
ls
fileA
git add fileA
gzip fileA
ls
gzip fileA.gz


こうだった
バージョン管理ソフトってあんまり使い始めたからよくわからない
OSSにプッシュして保存する感じで使ってる

入力と出力はそれとわかるように % とかのプロンプト付けるとか > で出力っぽくするかしてくれ

>>540
それも間違ってると思うぞ。

>>540
7行目は何なんだ？

$git init
$ls
fileA
$git add fileA
$gzip fileA
$ls
fileA.gz

こうでした

>>544
で、何が君にとって予想外だったの？

予想は何もしてなかったけどキャッシュを削除すればいいと今わかった
それだけでしたｗ

$git add fileA

これをした理由がよくわからんね

>>540
質問する時は何がしたいのかも書いて欲しい。
いったんfileAをgitの管理下に置いたけど、それを取り消してfileA.gzをgitで管理したいってこと？

まず、fileA.gzをgitで管理する理由は？ 普通はfileAを管理すればいい筈だけど。
次に、git addだけしてgit commitしてないのは何故？ 単にgitが分かってないだけかな。
あとは何がしたいのかにもよるけど、git addを取り消したいの？
それとも、git commitまでしたものを取り消すまたは削除したいの？
多分、根本的にバージョン管理とは何かを学ぶ必要があるね。

まあここにいる人の大半は知っていると思うけど。

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

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

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

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

計画は思ったとおりに行かない。だから後から修正ができるようになっている。

git addっていうのは、「ファイルが完成したので追加します」ではなく
「一つの修正」に含まれる内容にaddするという意味だからね。
「一つの修正」を登録して完了するのがgit commit

>>550
そこにrmが含まれてない理由はよ

ステージング

>>551
そこにrmが含まれるとか考えた理由を知りたい

>>547,548
質問者はステージングされたファイルを削除しても
インデックスに残り続ける事を不思議に思った、と言いたいんでしょ
コミットとか操作の意図とかはどうでもいい話だと思うよ

ワークとステージが別と理解すべし

>>554
実験してるだけってことね

ワーキングステージックス？

>>551
git rm --cachedしたいの？

>>551
rmとはgit rmのことなのか普通のrmなのか。

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

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

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

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

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

俺はgit add -uで変更されたファイル（削除含む）を全て登録することが多いんだが。

>>549の手順を具体的に教えてほしい
ブランチ切ればいいの？

>>560
いろんなやり方があるんじゃないの？
ワークツリー上の変更の一部だけをコミットしたいなら add -p 使えばいいし
stash saveでワークツリー上の変更を一旦退避してから、別の修正をコミットして、
その後stash popで退避した変更をワークツリーに戻して元の作業に戻るとか

コミットしてしまう前か、してしまった後かによって違うね。
コミットしておらず、ファイルの一部分のみをコミットしたいのなら
git add -pだろう。

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

ブランチは作ってもいいけど、小さいなら作る必要はない。
大きな修正がある場合は、過去の何処かでブランチ切って
そっちにマージやcherry-pickしていったほうが早いかもしれない。

またGitの解説本だ

http://www.amazon.co.jp/dp/4863541465
開発効率をUPする Git逆引き入門

何冊も解説本が必要な時点で終わっとる

何冊も解説本が販売されると、
なんで終わることになるんですか？
多分C言語なんか、一番解説本が多いと思ういますけど？

まあそれだけ多くの人が使い始めてるわけだ

ちょっとある仮説を思いついたから、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)

ちなみに、仮説っていうのは、本の発行年から、どのように世の中が
移り変わっているかがわかるんじゃないかってこと

Pro Gitでだいたい事足りると思うんだけどなあ

入門書
リファレンス
オライリー

本格的に使うならこれは買ってもおかしくない

>>569
入門書ってどれだよ・・・

>>567のだとGitポケットリファレンス以外は全部入門書でいいんじゃないの

http://1topi.jp/curator/fushimik/1303/04/103271
gitでDropBoxみたいな事できるそうなんですが
Rubyのスクリプトみたいです

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

やりかたわからないけど

素直にDropboxを使うか、Dropboxクローンが
ほしいならownCoudとかを使ったほうがいいよ。

>>572
これ見てガンバレ
https://github.com/kitak/ohajiki/blob/master/README.md

>>572
・タイムスタンプが同期されない
・バイナリ差分転送できない
・テキストであっても、かなり低速

バージョン管理するテキストデータだけ専用のフォルダに分けて共有フォルダと別管理するべき

gitでpullとかcloneするときにタイムスタンプも戻したいんだけど
どのオプションだっけか

パソコンの日付を変える。

>>577
Gitはファイルのタイムスタンプを保存していない
コミットした時間は保存してる
シェルスクリプトとか使えば、ファイルのタイムスタンプをコミットした時間に変更できる

Git神
Subversionはじだいおくれ糞

gitはなんで空ディレクトリが扱えないんだよ
偏屈すぎるだろ
それとも実装できない理由でもあるのか？

ファイルじゃなくて内容を管理しているから、かなあ(てきとう)

内容を管理しているならさ、もう少しマシなdiffをだせないものかな？
どうせ外部diffを呼んでるだけなんだろうけどさ、
たとえば長い関数の一部を取り出してを他のファイルに移動した時とか、
ちゃんとそれがわかるようなdiffを出して欲しいんだけど。

>>583がもっとましなdiff作ってるってさ

>>583
期待してるよ

>>584-585

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

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

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

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

これが今のdiffの欠点で、将来はどういう目的で変更したかまで把握できるdiffができる。

空のディレクトリを共有しようとする方がよっぽど偏屈に見える。それって必要？

>>586
だからその「目的」を解釈してくれるエンジンを>>583が作るんでしょ？

>>588
単に今のdiffの欠点と、将来はどうあるべきかを言っているだけだけど？
なに？　問題点をいっちゃダメなの？

意味を理解するdiffっていうのは
優れたアイデアなんだけど
それぐらい、わからないのかな？

言い出しっぺやるの法則を知らない国の人か

>>583
git diff -C 試した？

>>590
そういうことしたいなら、どう考えてもそのリファクタリングを行ったツールと連動した方が確実で簡単だと思う。

>>590
意味を理解するdiffとか、Git自体にそんなもの組み込む必要はないよ
おなじみの http://git-scm.com/book/ja/ の7章読んできてくれ
「7.1 Git のカスタマイズ - Git の属性」の「外部のマージツールおよび Diff ツール」

あー、お馬鹿なお前らに名乗るの忘れていた。

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

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

ここで>>586と同じことを英語で書いてるから、
俺の言ったことが理解できない、馬鹿なことを言ってると思うのなら
英語を読むといいよｗ
あと無知はぐぐれ。

>>595
いやだから最初から期待してるって言ってるじゃん。
はやく完成するといいね。

>>595
Martin Fowlerさん降臨記念カキコ

結局何が言いたいんだろう

diff、取ってみようか。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?SemanticDiff

>>587
普通に必要だろ。git使いだけど不満に思っているよ。
もう少し想像力を働かせて欲しいものだな。

>>600
empty_dir/.gitignoreに
!.gitignore
って書くんじゃだめなんすか

>>601
いや、それはちょっとダサいでしょ。
仕方なく、そうやっているんだけどさ...

おっと
*
が抜けた
どちらにしろ空のディレクトリを空のまま使うことなんて有り得ないんだから
.gitignoreは必要になるんじゃないのかなあ。
まあgit_root/.gitignoreにまとめて書きたいという需要もあるのか。

>>603
開発スタイルによるけど、たいていの場合はディレクトリ構成って設計段階から決まるから、先に作っておきたい。
仕方なく.gitkeepとか.deletemeとか使っているが、コレジャナイ感がある。
ちなみに、.gitignoreは意味が違うような気がしていて使ってないです。

>>600
gitでファイルのパスが管理されてるのに、パスの情報しか持たないディレクトリを管理したいだなんて、
ファイルシステムへの理解不足かプロジェクトのマヌケさを疑うね。

コードがなにかファイルをそのディレクトリに放り込む手筈になってるのなら
ディレクトリの作成も一緒にやってしまえばいい。

>>604
そういうのはせめてREADME入れといてよ…

svnから取得したプロジェクトをgitに登録しようとしてるんだけど
trunkフォルダにあるデータをそのままルートにコピーして、trunkフォルダ削除しちゃった

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

これを↓

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

こんな感じ

こうするとgit-svnで引っ張ってきた過去の履歴と比較できなくなるって言われたんだけど
今から治す方法ない？

最初っからtrunk込みのパスをgit-svnに渡しとけ
折角svnはサブディレクトリ単位でもリポジトリ扱いできるんだから

或いはgit svn -sか。

>>606
この文脈でREADMEって、何を書く想定なんだ？

>>610
なんでこの空ディレクトリがコミットされているのかと、どういうモノをここにコミットしていく予定なのか。
ディレクトリがイントロスペクティブなら、後で気が変わってツリーの見直しが発生してもドキュメントと作業ディレクトリの二重管理を防げる。

>>586
そんな使えないツール作ってないで、コメントつけろよ。

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）

>>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を使えばその警告を無視してブランチを消せる

>>613
　HEAD(、temp)
　↓
┌C3
↓
C1←C2
　　↑
　　master
Q1
Q1でのC3のようにブランチなどから参照されていないコミットをdetachedという
この状態でHEADをC2などに動かすと どこからも参照されていないC3は失われてしまう(もちろんreflogはできる)ので変更を残したいならブランチなどを作ってね、ということ

Q2
ここではtempはC3を指すように作られる
tempを作った直後は編集していないけど、上図の通りC3がマージされていない

小保方さんも論文のバージョン管理はGitでやれば良かったのに

gitでもコピペは防げません

>>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)

コミット番号についての単純で重要な事を一つ言っておくよ。

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

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



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

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

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

ただし、マージした時に必ずマージコミットができるかといったら、そうではなく
（処理結果の過去が同じになるので）マージコミット作らなくていいんじゃね？ と
gitが判断したらマージコミットを作らない。マージコミットを作らない＝fast forward（早送り）
これはオプションで制御できる。

AブランチからBブランチへのマージ・・・Bブランチに含まれていないAブランチのコミットを全てマージする
チェリーピック・・・特定のコミットのみ加える。

detachedはなんとなく異常な状態に思ってしまうかもしれないけれど、実は便利な道具なのです。

detachedの使い方 その1

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

detachedの使い方 その2

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


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

reglogはある程度大きくなって30日だっけ？立てば自動的に消えるけど
消えなければコミット番号からコミット（とその歴史）は完全な状態で復活できる。

>>621
その1はわかるがその2は
git branch ブランチ名 コミット番号
でいきなり名前付けちゃうなあ。checkout -bでもいいし

タグでバージョン管理してんだけど
git tag
でタグ一覧表示してるときに
hoge-1.2.9 のつぎに hoge-1.2.10 が来るようにしたいんだけど
どうしたらいいかな

コミットの日付ごとにソート？

自分の好みの順番に並べ替えるフィルタを書けばいいだろ

>>623
|sort -n

>>605 ファイルシステムへの理解不足かプロジェクトのマヌケさを疑うね。
お前何言ってんの

空のディレクトリを管理しないのは、
gitがソースコード管理システムだからだろ。
プロジェクト管理システムじゃない。

diffが全てだと言ってもいいと思う。
diffに意味がなければSCMを使う意味がない。

> gitがソースコード管理システムだからだろ。
> プロジェクト管理システムじゃない。

これは

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

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

ディレクトリが必要なのは、デプロイつまり動作するときであって
動作させるにはディレクトリ作成以外にもパーミッション設定とか
サーバーごとの設定とか色々あるわけで、
こういうのはデプロイとしてやるべきことだと思う。

考えてみたら、スクリプト言語のせいなんかな？

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

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

チェックアウトしたソースコードのそのままの位置で
動かそうとするスクリプト言語だから空のディレクトリが
必要だと思っちゃう。

意味がわからん
スクリプト言語でも今どきは DB 初期化だのなんだので make 的なのを掛けるのが一般的だが

>>631
”今どきは” でしょう？

つまり今どきじゃないやり方では
ソースコードをチェックアウトして
make的なことをせずに、そのまま動かすことに
心当たり、あるでしょう？

あ、なるほど。合点がいった。
rootにmakeファイルがあってREADMEにtestにsrcに…ってのが出発点なのに
いきなりindex.htmlとか放り込んでる連中が空ディレクトリ置けないって嘆いてるのか。

なんかExcel方眼紙思い出した。

>>633
makeファイル前提の考え方って、どんだけ限定的な開発しかしてないんだよ。。。

>>628
前レス気になってみこっちも見たんだけど、ひどいな。
この解釈はお子様だ。

うわぁ

diffで出てこないものは管理しないってのは合点がいくけど
じゃあ

失礼途中送信です
じゃあなんで git commit --allow-empty を許可しちゃうんだろ？

今日秋葉のヨドバシの中の有隣堂書店行ったら、コンピュータ関係書籍の売り上げ
一位がこの本だった。

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

やっぱ売れているんだな。

立ち読みしたけどごく初歩的なことしか書いてないのですでに使ってる人間にはいらない
GitHubのファンブック程度のものでしかない

つまり、使ってない人間には〜？

金の無駄
SNSの手引書ごときに何千円も出す価値なんてない
その金でGitの入門書買ってGitHubの使い方は触って覚えろ

2580円しかしないと思うけど？

時々さ、パソコン系の雑誌の値段（1500円ぐらい）を
高いっていう人がいるんだけど、君も同じ種類の人間？

お前が100円のガムを1000円で買いたがるバカなのはわかった

売れてるんだから世の中は貴方より馬鹿な人で満ち満ちてるってことなんだよ。
こんなとこでそんな連中を馬鹿にするよりこの本みたいなの執筆して金にする方でも考えたらいいんじゃない？
100円のガムを1000円で売れる錬金術だぞ？

>>644
ん？ この程度の本なんだから価格も安くて2580円でしょ？

>>645
本業以外四方八方に手を出して回るほど多芸でも暇でもない

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


ではおやすみ

売り上げ１位ということは注目されているってことで喜ぶべきことだと思うけど。
単に事実を報告しただけなのに、なんでやたらケチ付けないと気が済まない奴がいるんだろう？
心が貧しいのかな？

その本なあ、正直それ買うくらいならWebDBPressをPDFにまとめたやつ買ったほうが…
そこでやってた記事のリメイクみたいなもんだし

>>647
いやいや、俺は本をさほど評価してないんだよ？
GitHubの紹介程度だから価格も安いと言ってる。

技術書を買い慣れてないんじゃないの？
雑誌1500円、入門書3000円。
（初心者向け以外の）オライリー本4000〜5000円
マイナー本6000円、高い本8000円〜
これぐらいが普通の感覚でしょう？

>>638
man git-commitのオプションの項目見た？
空コミット許してる他のVCSとの絡みで存在するとある。
git rebase -iすると空コミットはデフォでコメントアウトされるよ。

2500円程度の技術書がAmazonで1位になるといくら入るのか教えてくれ

×100円のガムを1000円で
○0円のガムを1000円で

適当にぐぐった感じでは技術書の印税率は7〜8%ぐらいだとか
一冊あたり \2,500 * 7.5% ≒ \188
出版社や電子出版とかの出版形態、著者の知名度とかでも変わるらしいが。

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

これにプラス原稿料か。2万部もそれなりに時間かかっての話だし、
夢の印税生活ってわけにはいかないねえ。

Windowsで開発しています
WindowsやLinux,Macといった複数の環境でリポジトリを共有するときの改行コードについて悩んでます。
リポジトリにはLFで記録されていないとパッチのときに困ることになる事がググってわかりました。
Visual StudioでC#を書いているので、このコードの改行コードはIDEで自動的にCRLFになります。
他のRubyなどの言語ではLFで統一して書いてます。
なのでソースコードによって改行が異なるのですが、こういう場合はautocrlfの設定をどうしたらいいのか教えてください。
C#のソースコードの改行を全部LFできれば問題ないんですがプロジェクトがたくさんありすぎて、CRLFからLFに変換することで予期しないバグを生みそうで怖いのでできません。

>>651
知りませんでしたなるほど
空の内容を許可できないとディレクトリだけ追加したコミットがインポートできませんね

>>654
なるほど、どうも
技術書は小遣い稼ぎと執筆実績が目当てなんだろうね

>>655
MSは互換性を崩すことで囲い込みをする戦略だから基本的に混ぜるな危険。

ブログをはしごするより本にまとまってると利用しやすいってのはあるけどね。

環境とか前提条件を明示してないクソぶろぐはほろぶがいい

>>655
設定変えればいいだけじゃんか、LFに

>>658
くだらない悪口言ってないで
ちゃんとした答えを言えよ。

>>655
VSの設定で改行コードをLFに変更する。
autocrlfは弄るな危険。
どうしてもやりたければsafecrlfとセットで。
共同開発者にニワカが紛れ込んでる場合は、リポジトリに、コードの全行がCRLFだった場合にrejectするhookを置く。

自動変換は、ヒアドキュメントなんかで異なる改行コードが行末に必要になると破綻する。

MS-DOS 1.1のソースコードに変更履歴がコメントで残してあってほっこりした

技術書の執筆なんて手間ばかり掛かってぜんぜん金にはならないよ。
本を紹介するとやっかみで批判する奴いるけど、むしろボランティアなんだから
感謝しこそすれ、儲けやがってと批判するのは完全にお門違い。

まともな本書いてるひとには申し訳ないけど
一見してまともじゃない本の方が
内容が糞な割に儲けてる感じがするのも事実
そういうのが多いとやっかみで文句ばかり言う人が
増えるのもやむを得ないと感じる

そりゃそうだろ？
どんなものでも圧倒的に素人の方が多い。
そして素人の方が本を必要とする。

表面なめただけの粗悪な本でも見当のつかない分野のアウトラインを知るために
藁をもつかむ思いで買うことはあるがそんなときでもなければ買わない
今回買ったのはデザイナーか営業か人事か役員あたりじゃないか
設計やコーディングする人間にはググれば済む程度の内容だし

なんかやたらと買わないアピールが続いてるけどいったいどうしたんだ

最初にこの本の話題が出たときから、このスレに常駐してるような人には必要ない本だろうって感じだった

発売前から紹介されてたのに買ってアピールする人が出てこないのはみんな立ち読みしたけど棚に戻したということでしょ
なのにしつこくプッシュされたら反論したくもなる

つまらない反論なんてしなくて無視しとけばいいのに。プッシュしてる書き込み
なんてほとんどなくて、反論の書き込みの方が多くて邪魔だよな。

http://www.amazon.co.jp/dp/477416366X
どんだけ２ちゃんねるの評判に頼ってるんだよｗ

こんな所に頼るぐらいなら
amazonの方がまだまし。

俺はそんなこととっくに知ってるから不要

っていうのは、その本を批判していることにはならない。

淡々と本のメリットを紹介するなら反論も出ないだろうけど、
本を買わない奴は糞、という論調だから買わないアピールが出るんだよ。

えっ
買うやつは糞って論調じゃないの？

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の取り方も紹介してんのな

>>676
catdocってツールの存在を知れて有用だったわ

>>676
WindowsならWinMergeのままでいいかな
xdocも読めるし外部だけどExcelにも対応してるし

>>677
猫か犬かはっきりしろg

>>677
いつの間にかドキュメントのバージョン上がってたんだな。
たしか前までstringsコマンドが紹介されてて日本語使えねぇと思ったんだけど。

Git使ってる人がいつの間にかバージョン上がってたとか曖昧なこと言ってるのは嘆かわしい
https://github.com/progit-ja/progit/commit/120cd6b88bb7bfd54e934d6240a343b42903b399
7ヶ月前だ

>>679
はっきりしてんだろg

>>681
『いつの間にか』日本語の文法もバージョン上がったのか。sha1くれよ。

>>669
>このスレに常駐してるような人には必要ない

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

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

本なんて安いもの、という発想が出来ないうちはいつまでたっても底辺のままだよ。

いやいやごみはごみだよ

初めからこのスレの住人をコンテキストに書かれてるのも読み取れないで本や仕様書が読めるのかね？

コンテキストってな〜に？

それ以前に日本語がおかしいぞ

わずか一行の文章でここまでわけのわからないことを書けるのも一種の才能

くんこくさいし

誤爆、しかも誤字

>>616-617
gitで複数のリポジトリからpullしたのを合体なんて出来た？

>>692
fetch
fetch
merge

1.9系のメンテナンスリリース「Git 1.9.1」がリリース
http://sourceforge.jp/magazine/14/03/25/150000
> バグ修正が中心のメンテナンスリリースで、ユーザーにアップデートを呼びかけている。

　3月18日、Git 1.9系の最新版となる「Git 1.9.1」がリリースされた。
^^^^^^^^^^^^

↓を参考に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がないのが原因ではないかと推測したのですが
何か考えられる対処方法はありませんか？

>>695
1.9.1ってどうやったら入手できるん？

自己解決、見つけた

Release v1.9.1: Git 1.9.1 ・ git/git ・ GitHub
https://github.com/git/git/releases/tag/v1.9.1

git使ってるはずなのに
gitのソースコードを
gitで取ってこないのってなんで？

Windows使いだから

msysgitがまだ1.9.1に上がってないだけだった

Windowsだとgitつかえないのー？
Windows版あるのになんでー？

gitのソースコードなんかWindowsに持ってきてどうするんだよ

>>703
最新版使いたいって話なんだから
コンパイルするに決まってるじゃん？
何だと思ったのさｗ

> 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に持ってきてどうするんだよ

http://git-scm.com/
↑でDownloadのところが1.9.1になってるのにダウンロードしようとすると1.9.0になるから
おかしいなと思っただけだよ

つまり>>698は1.9.1の存在を確認したってだけのレスだよ

ソースコードならgitで取ってくればいいだろって
いっただけだよ。

ソースコードじゃなくビルドされたmsysgitの1.9.1が欲しかったんだよ

ソースコードあるんだから存在確認なんかするできるじゃない。

ソースコードあるんだからビルドすればいいじゃない。

gitは1.9.1に上がったけどmsysgitソースコードはまだ1.9.0のままだからmsysgitの1.9.1はビルドできないよ

最後にコミットした内容を全文取得する方法を教えてください

>>712
git show のこと？
全文ってなんぞや

改行のない1行のファイルでコンフリクトした場合と
改行のあい1行のファイルでコンフリクトした場合で
コンフリクトしたときに生成される内容がどっちも同じで、最後に改行があるかどうかわからないんですが
こういうものですか？

Gitの前に日本語を勉強したほうがいい

>>713
全てのコミットログ

履歴から特定のキーワードを検索する方法を教えてください

git log --grep

>>716
最後のコミットってのと全部ってのはどうも噛み合ってない気がするが、
git log -p でいままでの全てのコミットごとのdiffをみれるよ

翻訳案:
このスレに書かれているもののコンテキストも読み取れないレベルで、本や仕様書が読めるのかね？

通常人の知能があれば読める文章をわざわざ翻訳してあげなくていいよ

本や仕様書を読んで理解するより
ここの不思議ちゃんの質問の真意を汲み取るほうがはるかに難しいよ

> Gitの前に日本語を勉強したほうがいい
Gitスレで日本語の勉強を指南する人は言うことが違いますね
おわり

gitってwindowsじゃ使えないの？
何で使うの？

使えるよ

>>715は普段他人に言われているんだろ
かわいそうだからあんまり>>715をいじめんなよ
ガチな奴を煽ると社会で何するかわからないからな

>>726
じゃあ、お前はいじめて良さそうだなｗ

>>726
指摘されて悔しい

まで読んだ

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

この機能使えばロック代わりになるんじゃないの？

>>729
なるほど、pre-commitフックでどのファイルがlockされているかを調べ、
コミットがそのファイルへの変更を含む場合弾く
ってバカみたいなフック書けばコミットは防げるな

そんなに馬鹿な方法でもないよ。
ロックというのは要するにアクセス権限の制御と同じ。
一時的に特定のユーザーにだけ
読み書きの権限を与えるのがロックの本質。

ロックという言い方のせいでファイルやデータベースの
ロックと勘違いされやすいけど、
本当はアクセス制限なんだよ。

>>731
んなもんをわざわざフックでゴリゴリ書くのがバカみたいだって言ってるんだが

>>732
なんで？

>>733
メダカにアームスーツ着せてる感じだな

ほらね。ちゃんと説明できないんだよな。

比喩がわるかったか。
本来そなわっていない、そぐわない機能を無理矢理に御仕着せてるのがバカらしいって話。

こう言う奴って標準でロックサポートしてたらなんも考えずに使うんだろうな (w

あっても使わないだろ

いや、別にサポートされてたら使ったって問題ないだろそりゃ
もしわざわざサポートしたんだとしたら使うべきフローが見出されたってことなんだろうし

事前の根回しとか、ロックしっぱなしの奴とか面倒くさくて使ってられない。

なぜ人はコンフリクトにびびるのか

LinuxパッケージのGitがバージョン1.7.10なんだけど
ソースコードをコンパイルしてでも1.9を使ったほうがいいですか？

>>736
だから本来そなわっていない、そぐわない機能であるという
理由を言えって。

>>739
git の仕様決めてる奴は常に正しいと言うわけか
宗教じみてるな

俺は便所の落書きより天才独裁者を信じるよ

>>743
ああ、それすら理解できないアホなのか。
一生CVS使っててください。

Windowsでいままで作り上げてきたリポジトリを
LinuxからWindowsにアクセスしてコミットしたら壊れますか？

>>746
俺が理解しているかどうかではなくて
お前がちゃんと理由を言えるかって問題なんだが？
なに？ 何も考えてなかったの？

>>748
ロックでもアクセス管理でもいいんだけど、分散レポジトリ環境全体でそれを実現するには
全レポジトリが相互に管理情報のやりとりをする必要があるのは理解できてる？

ロック不要なのは、ロック解除後に前のバージョンに戻す馬鹿がいるからだよ。

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

結局、運用ルール必須。

あるファイルの5番目に編集したハッシュタグを知る方法を教えてください
HEAD@{4}だとマージしたとか関係ないとこに当たるからだめでした

5番目ってどっからどう数えるの？
普通にログを目で追うんじゃだめなん？

https://github.com/progit/progit/commits/master/README.md
こゆの？

こういう感じです
対象:Aファイル
最後に編集した3番目の例えると・・・

(古い)
git init
Bファイルを編集&コミット
Aファイルを編集& コミット　←５　ここのハッシュタグが知りたい
ブランチ切り替え
Bファイルを編集 & コミット
Aファイルを編集 & コミット ←４
ブランチ切り替え
マージ
Aファイルを編集 & コミット ←３
Aファイルを編集 & コミット ←２
Aファイルを編集 & コミット ←１　ここからカウント
Bファイルを編集 & コミット
git push
(新しい)

x 最後に編集した3番目の例えると・・・
o 最後に編集した5番目の例えると・・・

こう？
git log --oneline -- Aファイル

>>749
>>729 のリンク先も見てないのか

>>729で説明してるのは単純な中央リポジトリに対するアクセス制御を実現する方法

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

本格的にやるならリポジトリが相互にアクセス制御情報を交換するような実装が必要になるけど
複雑な仕組みになるからやらないだろうな

っていうか、subversionだって
ローカルでファイルを修正すれば同じことだろ？

ロックがかかった状態と言っても、
ローカルで作業している分にはネットワーク切れてるわけで、
当然ローカルにあるものは読み書き可能。

LinuxでおすすめのGUIってなんですか？
SourceTreeがインストールできないので残念です

>>758
> 複雑な仕組みになるからやらないだろうな

難しいかどうか以前に、本質的に無理でしょ。
同時にロックされたときの排他制御が必要だから、なんらかの中央集権は必要。
ただちょっとした開発でもその手のサーバーは持ってると思うけど。

>>759
subversionとかのロックはファイルを編集する前にかけるの
ローカルに編集する前に中央のサーバに問い合わせて、自分がファイルを編集できるかどうかを確認する

>>762
いや、ファイルの読み取り専用属性を解除すれば
ロックかかっていても修正できるから。

subversionでロックをかけるには中央サーバとの接続が必要で、
お互いがロックをかけてから編集するというルールを守っている限りコンフリクトを抑止できる
ここまではいいかな？

gitで同じような効果を得るには中央サーバが必要になる
しかしgitの場合には>>758で示したように、中央サーバに該当するものが存在しないとか、
中央サーバーが直接ローカルからアクセスできない環境で運用される場合がある
それらに対応できない以上gitにおいては中途半端な実装と言うしかない

そもそも
コンフリクトを抑止して「効率的に開発する」という目的に対しては
ロック機能自体が中途半端な存在ってことでしょ

できる/できない の話と やる/やらない の話が
ごっちゃになってる感じ

お前ら親切だなあ。

ローカルではgitを使い、本家へのコミットにはsvnを使う
というのがプロのやり方だよね

>>763
ツールが想定する運用と違う使い方してダメだしとか、頭おかしいのか？

>>764 もそうだけと、いかなる構成に対応できるって言ってるわけじゃないだろ。
ロック使いたいならこんなやり方でできますよって言ってるだけなんだから、必要ないならスルーすればいいだけのこと。

だからロックを使いたいやつをgitに呼びこむのがそもそもの間違いだろ

何を使うかは上が決める
トップダウン

gitでもロックできるみたいだからロック使った運用しろなんて馬鹿な上が言ってくるかもしれないからな
分散管理に対する不自由と引き換えになる不完全なやり方だってことを書き込んでおかないとね
それを承知で使うなら別に構わないんじゃないか？

ロックって聞くとすぐ発狂するよなGit信者って
自由の戦士のつもりかなんかなのか？

>>772
だからCVSを死ぬまで使ってろよ、あれだって自由ソフトウェアだぞ

>>772
ROCKってのは心揺さぶるもんだろう、お前も一緒にシャウトしようぜ

…と言うのは流石に冗談として、lockが無いと発狂してる人に、落ち着けと言ってるだけにしか読めないんだがなあ
何にしても元々オプソ用だったgitにlockなんて百害あって一利も無いだろうし、どうにも必要なら素直に別の使えば良い

lockのあるツールでlockかけたまま会社を休んだのがいて仕事にならなかったのを
経験するとlockのあるツールを積極的に使おうという気はなくなるけどな。

>>775
ロックと言ってもただの読み取り専用属性なので
解除すれば編集できるよ。

>>774
> 何にしても元々オプソ用だったgitにlockなんて百害あって一利も無いだろうし

意味わからん
OSS がどう関係するかもわからんし、一利ないと言うのはいいとして、百害ってなんだ？
なんか lock を凄いガチガチの機能だと思ってねーか？

まず、ロックを使うという前提だとする。
つまり、ファイルを編集する前には必ずロックをかけるということ。

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

ここまではいいね？


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

これに答えて欲しい。

ロックを外せば（無視すれば）運用できるじゃねーか。という意見が正しいなら、
最初からロックはなくていいのではないか？という答えになる。

と言うか前提が分からんなあ
ローカルコミット出来ないようにロックするのか、プッシュ出来ないようにロックするのか…

まあコミットするのにいちいち書類提出しなくちゃいけないようなルールの運用もあるっていう噂だし、
ロックが必要だっていう社内論理も同様にあり得るんじゃないの。

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

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

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

ロックが必要、って言ってる人はVCSにロックが必要だと思ってるのか、Gitにロックが必要だと思ってるのかどっちなの？

書類提出とか言うのは、そもそも権限の話だから全く違う問題。

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

本来コミットしていいはずの人が、コミット禁止される。
なぜ？って話。

>>778
前提が滅茶苦茶だな。

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

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

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

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

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

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

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

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

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

意味わからん。
お前さんが考えてるロックの利点ってなんだ？

>>780
> ロックが必要、って言ってる人はVCSにロックが必要だと思ってるのか、Gitにロックが必要だと思ってるのかどっちなの？

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

>>781
マージできないからだろ。

>>781
ちょっと追記

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

ロック禁止はロックのことだと仮定して、本来ロックはコミットを禁止させる行為じゃないよ。
編集を開始させないようにするためのもの。
マージできないからその編集は無駄になる可能性が高いからね。

そのうちDBの排他ロックすら許せなくなっちゃうんだろな

ロックがゲシュタルト崩壊

>>785
RDBMSにはマージという概念がないだろう。

確かにGitってテキスト主体のオープンソースの分散開発ならいいけど、
社内とかの仕事で使うにはあまり意味ないよね。

各人勝手にソースいじることないし、最終的にどこを取り入れるか判断する
人の負担が大きいし。

>>788
意味ないとまでは思わないが、効果が薄いと言わざるを得んな。

文書は全部Officeでマージできない、開発メンバはSubversionのこ
とをちょっと面倒な共有ファイルサーバくらいに思ってる、といっ
た環境だと、苦労してGitに変える必要もないかなって思う

>>783
多分、ロックがあった方が美味しいってことが多いシチュエーションでは、Gitなんか使わない方が皆幸せだってことをロックを嫌がる人は思ってるんじゃないのかな？
リソース画像ファイルとかですらGitのリポジトリには含めるべきではないっていう原理主義の人多いし。
自分は原理主義もわかるけど、自分の利用ではリソース画像ファイルとかは必須なので、なんとかうまいことする方法があればいいのにな(他VCS含め)と思っている。

Gitにロックがあればいい、というあなたの立場は理解した上で、どういう実装があり得ると思う？自分は上手い、と思う方法が見つからないよ。

ファイルの中にパスワードを書いたままGitHubにプッシュしたんですけど
これはまずいと思ってパスワードを削除したファイルをプッシュしたんです。
でも過去の履歴って閲覧できますよね。
どうやって闇に葬り去ることができますか？
バレたら首になるので誰かヘルプ！

github側リポジトリを消す
自分のローカルリポジトリはパスワード追加前のコミット前の状態revert
githubにプッシュし直す

github の HEAD を他の誰かが取り込んだら終わりだからな
とりあえず迷ってる暇はない
今すぐ github のアカウントごと消せ

凍結してfilter-branchの練習かな

>>791
最初にやるべきことはそのパスワードそのものを無効にすることだよ
もちろんそのパスワードを外部にさらしてしまったことを回りにちゃんと説明しろ

みなさんありがとうございます
入社して7日目で首だけは避けたいのでアドバイスを参考に動いてみます

>>790
> 原理主義の人多いし。

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

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

排他が必要だから俺も中央サーバーたてる以外の方策は思い付かない。

入社して7日目に2chに書き込んでいるとか

>>797
>たかがツールなんだから便利に使えればいいと思うんだけどね。

こういうのって自分だけはメタ視点、なつもりで高所から見ているつもりだろうけど、
誰でも分かってる当たり前のこと言ってるだけだよな。
当面の議論には参加する能力がないけど、偉そうな態度だけは取りたいという。

>>797
> たかがツールなんだから便利に使えればいいと思うんだけどね。
いや、原理主義は大事だと思うよ。本当に無理やり目的を達成したほうがいいのかをそもそも論で考えるのは大事だと思うから。
ただ、原理主義に固執するあまりに状況も把握せずに全否定、ってのは良くないと思うけど。

「便利に」使えればいいというのはその通りなんだけど、ツールの設計思想や構造を無視して「こういう機能があると便利なんだけど」って言ってもしょうがないとも思う。
乗用車にトイレがあったら便利だと思うけど、トイレを実装するには様々な困難があるし、乗用車の存在目的を考えたら外部化したほうがいいでしょ？
そういうところを無視して「便利だと思うからつけたっていいじゃん」ってのもまた、同意できない。

gitは単なるツールでそれを運用するシステムは別でしょ
そのシステムがgitを前提としてなかった場合、システムがgitに合わせることになる

>>799
いきなりどうした？
なんか悔しかったのか？ (w

>>800
まあそこは色々な考え方あってしかるべきだし、使い方は人によって違うしね。
車の例えなら、キャンプ大好きで自家用車をキャンピングカーにしてるような人なら、トイレもあった方がいいと思うかもしれないよね。
設計者には悪いけど個人的に使うなら設計思想関係なく便利に使えばいいと思うよ。

>>801
システムって具体的にどんなのを言ってるの？

Gitはあくまでもソースコードの分散バージョン管理ツールであって
そのために必須ではない機能を何でもかんでも突っ込むのはUNIX的なやり方じゃないね

バイナリファイルとかの管理のために分散環境ではうまく機能しないロックが必要だっていうなら、
そういう仕組みをGitとは別に新しく作ればいい
もちろんそれを実現するのにGitを利用するのは構わないけど、
Git本体を肥大化させるのはダメだ

>>803
会社みたいに複数人で開発する場合、集中管理できるようなツール入れることになるでしょ
そこで、どのツールを使うとか、そのツールで管理してる各リポジトリに対して、誰にどれだけの権限を与えるとか
gitをバージョン管理ツールとして導入して運用するのに必要な管理ツールやルール的なものという意味でのシステム

そんなに便利な機能なら拡張作れば大人気だろう

>>805
いわゆる運用系の話しかな
なら、ツールにうまく合わせるのは当たり前やね

>>806
便利だとは思うが、本質的に分散システムでは実現が難しいから、かなりの部分を運用でカバーする必要があると思う

分散システムの本質ってなんだろうな

>>800
原理主義っていうことの意味自体が排他的なネガティブなものなので、原理主義が
大事ってのは普通の感覚だとありえないんだけどね。保守的よりさらに変化を
認めないってのが原理主義だから。

>>802
いや、お前自分ではドヤ顔だけど、つまんねえだけだよ、と誰か教えてやった方がいいと思ったからさ。

GitってVSSみたいにファイルのチェックイン、チェックアウトを厳密に
アトミックにロックするやり方の管理もできるの？

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。

WindowsでGitをインストールすると.gitconfigの[core]の項目が存在しますが
Linuxでソースコードから入れると、入れたばかりだと.gitconfigは存在しません。
名前とメールアドレスを登録したら自動的に.gitconfigが作られますけど
Linuxでは[core]の部分は設定しなくてもいいのでしょうか？
例えばautoCRLFとか

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

>>802
もちろんそれぞれの解があっていいと思うけど、トイレと車での移動を両立しようと思ったら、なにか諦めなくちゃいけないじゃない。
汚物を自分で処理するということなのか、上水下水を駐車時に勝手に流してくれるようなステーションにしか行けないような車を作るのか、諦め方は色々あると思うけど。

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

>>809
すまん、それは言葉が悪かった。本来あるべき正当な立場に立ってものを考えてみることもときには重要だ、くらいの意味だけど。
ツールを開発してる本人たちは原理主義であるほうが軸がブレブレのツールとかにならなくていいかも、って思って原理主義って言葉が出てきたのかもしれない。

ちっ、ID変わる前に書き込んだほうがわかりやすいと思ってギリギリに書き込んだのにちょっと遅れてID変わってしまった。

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

けどやっぱり>>804の言うように、バイナリの管理って小さいものだったらまあなんとかロックさえあればいいのかもしれないけど、ムービーくらいのでかいものを管理しようと思ったら
いきなりリポジトリのサイズがどんどんでかくなってまともに使えなくなるわけで、Git本体を考えなしに肥大化させちゃうような進化の方向はよろしくないと思うな。
結局、便利に使うためには「どういう理由で何を実現したくて、今後何が起きるか」ってことをちゃんと考えなければ便利には使えないわけで。

>>808
離れた相手の作業に邪魔されないこと

ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。

>>817
ウォーターフォール型のプロジェクトで、
ソースファイルの同じ位置を複数の人で編集しまくることとかあるの？
コンフリクトが簡単に解決できないようなファイルの編集が複数の人の間で頻繁に発生するとか、
有り得ないと思うんだけど

>>817
頻繁にコンフリクトが起きるようなプロジェクトならsvnだろうが他のだろう関係なく
起きるよ。 コンフリクト以前にsvnのマージ作業なんて、作った奴死ねって思う
くらいひどいし。そういうマージやらコンフリクトの解消のコストがgitは他のに
比べて圧倒的に低いからgitは使う価値があると思う。 svn使ってるならローカルで
git svn使う方がはるかに楽だし。

自分だけしか使ってないリポジトリで
今までコミットしてきた時の名前を変更したいんですが
どうやるのか教えてください
適当に名前をつけてたのですが、今後他の人もコミッターに加わるので名前を変えたいんです

何でコンフリクトが起きる事を問題視してる人がいるのかよくわからん。
gitというツールを運用する環境をどう構築するかを考えた方がいいんじゃないの
そもそも、svnで問題なかったのならsvnでいいでしょ
svnもgitもツールなんだし、適材適所

>>819
簡単に解決できないようなコンフリクトって例えばどんな場合におこるの？
けっこう複雑な関数を同じ人がいじりまくるとかするの？

.gitconfigで名前を変えとけば過去の名前も変わると思ったんですがダメでした

正直同じ関数に対する修正みたいなのは被らないようにチケット割り振りしたいわな
オープンソースみたいにいつ誰がどんな修正してるかわからんようなのはともかく
チームでやってる時は少なくともわかってる範囲内では影響範囲かぶらないようにしてる

>>823
git filter-branch

オープンソースならメールなり掲示板なりircなりでやりとりしてるのが普通だよ

>>821
コンフリクトというのはいわばバグですよ。
バグは起きてはいけない
コンフリクトも起きてはいけない。





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

>>826
開発が活発なOSSについてはそうだろうけど
開発者が実質１人だとかメンテナ不在ってのが
OSSの「普通」（圧倒的多数）だと思うけどね

作業が無駄になろうがマージがめんどくさかろうが
コンフリクトが顕在化するのはまだ幸運な方だよね

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

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

>>829
その為にテストを自動化するんでしょ？

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

>>729の燃料投下から100レス目か

>>830
gitだろうとロック機能のあるツールだろうと
顕在化するコンフリクトなんて可愛いもんで
熱く議論するほどのことじゃないよねって言いたかった

ロックでなんとかなると思ってるのは、コード書いてない証拠。
書き始めたら結局マージするはめになる。

ま、適切に機能分割されてて、関数やファイルで構造化されていれば、酷いコンフリクトなんかそうそう起きないわな

実質１人だとかメンテナ不在ならそもそも
いつ誰がどんな修正してるかわからん
みたいな♪心肺ないからね

>>810
つまんないなら、スルーしとけよ (w

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

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

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

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

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

>>824
同じファイルならまだしも、同じ関数を複数の人が同時に触るとかなんかの間違いでもない限り 100% あり得ないよね。
コンフリクト心配してる人はどんな管理してるんだろう？

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

上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

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

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

ハサミでネジが締められないからハサミはクソと喚いてるわけだな

立派な大企業様なら、クソみたいなOSSを使わないで、自分達で作るなり買うなりすれば
いいのにねー。2chでアレがデキない、コレがデキナイと喚いているだけなら、無職に
も劣る。

どこを直すかの管理をバージョン管理ツールに頼るとかありえないんだけど

ユーザーとタスク管理までさせられるVCSは大変ですね

開発効率をUPする Git逆引き入門 [単行本（ソフトカバー）]
http://www.amazon.co.jp/dp/4863541465/

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

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

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

難癖つけるやつの方が声がでかいだけの話しだから気にすんな

すばらしい技術書を親切心で紹介します！異論を唱えるのはキチガイだけ！
この本が手に入るのにたかが数千円のはした金も出さないのはまともな技術者じゃありません！
いますぐ買ってまともな技術者になりましょう！

あほか

フォークして修正を送る時ってブランチの名前はなんてつけていいのか教えてください
例えばさtestってブランチで送った場合、他の人もtestで送ってたらダブっちゃいますよね
ダブった場合もコンフリクトしちゃうんですか？

>>843
まあこのスレじゃないけどステマっぽいのはあったし、実際あなたの書き込みがステマかどうか判断しようがないからね。
そんな風に言われるのが嫌ならこの手の掲示板は避けた方がいいと思うよ。

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

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

>>843
知らなかったので本の紹介には感謝する
ただ、余分な書き込みは必要なかったかな
何にでも文句を言う人はどこにでもいるから
それをスルーできない人は書き込まない方が精神衛生上いいのかも

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

>>843
ステマ言われるのそんなにないやろ
こないだGitHubの本でステマ言われてたやつはあったけどアレは本当にいろんなところでみたからな…

そろそろ誰か寸評とか星付きのGit本リスト作ってテンプレに入れてよ。

>>839
う〜ん、ハサミに例えると、たまに 3cm とかの幅で切りたいから、目盛りみたいのがついてたら便利じゃね？ って感じかな。
そんなことしない人には不要なんだけど、使わなきゃ邪魔になるわけでもないしね。

GitHub実践入門はGit本体についての説明はゴミみたいなもんだし、
あれを入門書の決定版とか紹介したら叩かれて当たり前だな

逆引き入門の方は、ちょっと立ち読みしてきたけど、
これから始める人にもある程度使ってる人にもいいと思うよ

>>851
うーん、その例えも何か違う気がするなあ
Gitに付けるのは変だと思う、でもGithubに付けるならアリだと思うんよね
ハサミで言うなら、ハサミの歯のパーツを作ってるトコが目盛り付けちゃう感じがする

たまに話題になるくらいならいいが新刊出るたびにレビューするのは尼でやってくれ

>>853
ああなるほど、そうかも。
別にツールでやろうが、システムでやろうが、できればいいじゃんというスタンスなので。

846おねがいします

目的とか自分のid的なものとか組み合わせたり

Gitは〜には向かないのでは？　という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。

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

まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね？
と思う。

自分は違うんだぞ、って言う自意識過剰なレス乙

>>858
小馬鹿にするっていうか、「〜には向かないのでは？」って書いてる奴が馬鹿過ぎるんだものｗ

>>846
上流が何か命名規則を指定してるならそれに従う
してないならなんでもいいが、ブランチの意図を端的に表した名前にするのがお勧め
技術的にはマージするときのブランチ名は単にコミットを指すポインタなのでコンフリクトは起こらない
GitHub上の詳細は知らんがユーザなり何なりで別の名前空間に分離されてるはず。
プルリクが活発なリポジトリの画面眺めてみろ

ロック必要だよ派は

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

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

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

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

いちいちそんなコミュニケーション取ってらんねーよとおもった？
分散作業の世界へようこそ。

>>862
> コミュニケーションとれよと思う。

ロックはそのための仕組みなんだが...
そもそも、誰が編集するかわからないのに誰にメールするんだ？
関係者全員とか迷惑なんですけど。

>>863
＞そもそも、誰が編集するかわからないのに誰にメールするんだ？

自社開発だろうが、人売りで売られた先だろうがオプソだろうがなんだろうが
ある程度以上の規模になったらプロジェクト全員が入っているMLなりIRCなり
Skypeなりのプロジェクト全員への共有連絡先位あるだろ。 プロジェクトの
関係者以外にコミット権限を渡しているのなんて普通ないからそういう所に
一報を入れておけば事足りし。

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

> 関係者全員とか迷惑なんですけど。

issue tracker ってそんなに普及してないのかな

bug tracker ですら怪しいぞ。
とりあえず今までのやり方で回ってる大きな所はリスクとってやり方かえないし。
その気持ちもわからんでもないしなー。

githubでパッチを送る時ってぷるリクエストとフォークどっちのほうがいいのかおしえて

fork しても結局 pull request になる。
勿論直接 pull request 書いてもいい。

>>534
これ完全に騙されたわ。
専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。

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

この本買うつもりなら、一回本屋で立ち読みして欲しい。
間違ってもネットで注文はしない方がいい。

茶色い本とgit-scm.comがあれば十分でしょ。

>>865
メールに限定してないだろ。ちゃんと読め？

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

ブーメラン乙

ロックしてれば後から編集しようとした人はその場で分かるからな
Gitなんかはソースコードを管理する為のツールだから、ロックせずとも後でパッチをマージすればいいって考えるのは妥当だけど、バイナリファイルを管理する場合、その考えは通じない

>>872
全員に通知することを問題視してるんだが？
で、メールでなくてどうやるのさ。
掲示板にでも書いといて、編集の前にいちいち確認するのか？ (w

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

>>875
接続先をgithub.com:22からssh.github.com:443に切り替えてトライ。

接続先を変えるのは・・こまります・・・

いいからやってみ。

*Gitに*バイナリのロックが必要かどうかについて議論するんじゃなくて、
バージョン管理システム一般にロックが必要かどうかについて話してる奴はスレチなの認識してる？

誰もバージョン管理一般についてロックが不要だと強弁するつもりないし、一般的な話ならなぜここでやる必要があるのか説明してくれ。

ロック疑問派「Gitみたいな分散管理システムとファイルのロックは相性が悪い、メールとかで連絡すべき」
ロック必要派「メールで連絡するとかありえない、ロックがあればそれで全て解決する」←はて分散管理との相性の悪さという根本的な問題はどこいった？

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

(忍法帖が消えてレスを分割せざるを得なかった、すまん)

どう変えるのかわかりません・・・
[email protected]:443:アカウント名.リポジトリ名.git
ってやりましたがだめです
ssh -t [email protected]をやっても接続されないしずっと接続を頑張っているのか何も表示されません

>これ完全に騙されたわ。
>専門用語が沢山出てくるけど解説は別のページに書いてるからいちいち見に行くんだけど、わかりにくい。
>見に行った先にも専門用語が出てきて、その解説も別のページにいくから、先になかなか進まない。

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

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

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

「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。

>>873
つまりソースコードのロックは百害あって一利なしでいいよね？

>>882
> 「サルでも分かるGit」みたいな本でもあれば推薦してあげたいが、Git関連はそういうのはないねえ。

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

アリスとボブのGit入門レッスン-川野辺-正博
http://www.amazon.co.jp/dp/4798035009/

サルでもわかるGit入門 ?バージョン管理を使いこなそう? | どこでもプロジェクト管理バックログ
http://www.backlog.jp/git-guide/

これじゃないの

>>884
開発の流れに沿ってシーンごとに必要なコマンドがわかるのがいいな
トレードオフで要点が複数ページに散らばっててぱっと読みにくいが
そこはネットかリファレンスを使うべきだし良書

>>885
本が至上という権威主義発言でしょ
難しい本を買うほど偉いという

875です
すいませんconfigでポート443したらいけました
Windowsでは指定しなくてもsshでclone出来るのに
Linuxでは指定しないと接続出来なくてタイムアウトするんですね
やっと接続できたので今から始発まで？仕事です

> 本が至上という権威主義発言でしょ
ん〜？ 単にページ数の問題。
一般的に本のほうが情報量が多い。

情報量じゃなくて、情報の密度に言い換えよう。

背伸びしてる中学生感が痛々しいからやめて

ページ（画面）あたりでなくページ「数」の問題なら
本の方が密度が低いような

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

そして手元に残るのは入門書ではなく
黒魔術満載のチートシート……

>>874
＞全員に通知することを問題視してるんだが？

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

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

場所によっては普通にそういう運用をしてるところもあるな。
掲示板に編集します、編集終わりましたとか書いて、そういうのが目で見て
分かる状況になってないと、おちおちトイレにも行ってられんわ。

>>892
もっぽど無能な設計者とリーダーだったんだな。もしかして君が…。

延々とスレチ続けてる時点でお前ら全員知障か気違い

仮に、Gitに理想的なロック
(例えばあるファイルをロックしたら、
clone済みの全てのローカルリポジトリにおいてアトミックにロックされるようなロック)
が実装されたとしても、
人間様がロックの獲得と開放を制御する限り、
どこかで人間のレイヤへの割り込みは不可避なんだよね。

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

とかね。もしそうなったとき、
開発体制公式の連絡手段が掲示板ならいちいち掲示板にかくしかない。
でもそんなの面倒でやってらんないよねって話でしょ。
ロックを強制解除する？
もし相手が本当に編集中で相手の作業が無駄になったらどうするの？
ロックって無駄な編集作業を避けるためのものじゃなかったの？

必要な人たちでロック機構ありのgitをフォークすればいいんじゃないかな。なんだか
凄腕の人達があつまってるみたいだし、すばらしいソフトが誕生すると思うよ。
わかったら早くやれ。

バイナリの場合にロックが必要ということは
要するに、ソースコード（テキスト）に関しては
ロックは不要ってことでいいよね？

分散型はロックと相性悪いし、gitの開発陣がロックを必要としてるようには思えない
ロックが必要なプロジェクトはsvnを使えば良い

ロックが必要な場合はあるかもしれないとして
それはバイナリに限るわけで
ソースコード（テキスト）にロックは不要。
もし必要だとしたら、それはソースコードの質が悪いから。

質が悪くて単一責任の原則（SRP）を満たしていないから
複数の人が一つの関数を修正することになる。

>>892
> 多人数でのプロジェクトをしたことないの？

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

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

そうでないところは、どうしてるんだい。

多人数のプロジェクトがあるとして、
まずやるべきタスクがある（githubで言えばIssueに相当する）

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

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

マージできないバイナリだけが問題なので
ソースコード（テキスト）にロックが必要になることはない。

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

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

>>883
いいんじゃね？
てか、それに反対してる奴なんていたか？

>>895
頻度って知ってる？

>>900
＞そのフィルタリングどうやってやるのさ、書いてみな。

普通にsubjectに「[ファイルロック]」とでも入れるルールを作っておけば、
そのタイトルがあるメールを適当なフォルダに突っ込むなり、ラベルを
付けるなりすれば無視出来るだろ。それかロック専用のMLを作って
そこに投げるようにするとか。
50人もいるプロジェクトなら毎日のメール数なんて数十〜数百通位に
なるなんて当たり前だろうから、そういうルール無しにやれるわけ無いと
思うのだが。

プロジェクトのメールも読まんで仕事する奴いるよ
まともな人間だけだと思うのは間違い

>>903
ロックなら人間が介入する必要の生じる頻度が
相対的に低いって言いたいんだろ？
その低い頻度で十分に面倒だって言ってるんだよ

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

ちなみに >>815 で紹介されてるツールについて議論するのは歓迎だよ。
フィットするユースケースや効果的な作業フローの考察を期待する。
ただし「やっぱロックさえあれば」って言うならボケがって思うわ。

>>901
> ソースコード（テキスト）にロックが必要になることはない。
それはマージが神の如く万能な時に限る
どうマージすればいいか担当者間で話し合わなきゃならないことがある
(それ以前に手元のソースがごちゃごちゃになって自分が面倒な事になる)

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

ただロックが必要なプロジェクトはgitよりもsvnを使うべきだろうね

>>904
一般的な話をすると、必要ないメールは、減らす方がいい。
減らす努力をしないとダメだ。

メールがたくさんあると埋もれて重要なメールを見逃す。
たとえば、自分と関係ないファイルのロック情報のメールは
重要なメールを隠すゴミでしかない。

基本的な話として、コンフリクトが起きるのは
多人数のプロジェクトであっても少ないという
この前提があることを忘れないように。

つまりはロックをかける必要性は
少ないということである。

>>907
> それはマージが神の如く万能な時に限る

95%うまくいく。

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

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

「他の人が触っている時にそのファイルを触っても問題ない」のに
「他の人が触っている時にそのファイルをいじれない」ことが起きる原因がロック。

バイナリファイルであろうと、ロックなんてかけずに各々が編集して、編集後の状態を元に誰かが「マージ」すりゃいいんじゃねえのっていうのはだめなの？

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

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

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

なんか本当に仕事でチームで開発したことあるのか、と疑わしくなるような幼稚なレベルの
意見が多くて萎えるな、ここは。

ロックをかけていれば、プログラムが壊れないかというとそうではない。

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

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

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

つまり、

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

というのは、ロックをかけていても発生する問題。
ロックがあれば万能なんだということにはならない。

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

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

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

本来同時に出来る作業（それが大部分）ができなくなる。というデメリットが発生するだけ。

>>904
で、編集し始めるときにメールをいちいち確認するのな (w
そもそもプロジェクト内のメール数百通とか、そんなに暇なんですか？

ロックなんて考えがあると、
誰かがこのファイル修正していたらどうなるんだろう？という
心配しなくていい心配をすることになる。

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

同時にファイルを修正しても問題ないことが殆どなので
ロックという発想そのものがだめということ。
svnを使ったロックもメールでロックしますって通知も同じ。
どちらであっても、ロックによって作業を妨げられる。
プロジェクトの参加人数が増えるたびに、他の人によって作業が妨げられる。

>>906
> ロックなら人間が介入する必要の生じる頻度が相対的に低いって言いたいんだろ？
> その低い頻度で十分に面倒だって言ってるんだよ

大抵のケースで介入の必要ないのに面倒ってどう言うこと？

接続先をgithub.com:22からssh.github.com:443にすることはセキュリティ的に良いことですか？

>>912
君の主張には同意するけど、なんで俺にアンカーしてんの？

ロックが面倒、ロックの調整が大変とか、そんな些細なことより
ロックによって開発作業が妨げられるということの方が問題。
開発作業をする時間のほうが長いんだよ。わかってるのかな？

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


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

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

ロックによって「長時間開発を妨げられる」ことが一番の問題

>>909
× つまりはロックをかける必要性は少ないということである。
○ つまりはロックが問題になる場合は少ないと言うことである。

君の主張は事故に遭う確率低いから保険に入る必要性は少ないと言ってるアホと変わらない。

>>921
それは保険の話。全く関係ないものに例えるな。

ロックしてても、解除された後に次のやつがマージするだけ。

>>911
それが現実的な時間と労力でできればね。

だから結局ロックしていても何も問題は解決しない。

>>922
> それは保険の話。全く関係ないものに例えるな。

ひょっとして、バカなの？

> 君の主張は事故に遭う確率低いから保険に入る必要性は少ないと

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

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

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

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



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

>>925
ソースの話してるのか？
だったら、それでいいんじゃね？
だれも反対してないと思うし。

>>926
ほら、ちゃんと説明してやったぞ？
反論できるかな？ｗ

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

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。

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

別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている（その
ために作られた）わけでさ。

>>929
> だからさー、コンフリクト起きても直すだけじゃん。

頑張って、としか言いようがない (w

ソフトウェア開発において
バイナリよりもソースコードのほうが多いのです。
ならば、ソースコードをうまく管理できる方がいい。

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

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

みたいな役に立たない履歴をなくせる

>>931
あー、ほら、やっぱりそういうことだろ！

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

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

結局、こういう技術力不足が原因なんだろ！

「コンフリクト怖い病」という用語を普及させようぜ？ｗ

今から出かけるけど、返って来たら
コンフリクト怖い病患者の特徴をまとめてみようかな
次スレになりそうだから、まあテンプレにしよう。

>>933
だから、君はソースの話してるのか、バイナリの話してるのか、明確にしなよ。
指摘しづらいわ。

バイナリのファイルは忘れろよ。
ソースコード管理ツールだろ。

例外であるバイナリの場合だけ
バイナリと明確に書くように。

仕事と遊びとは違う

>>933
いや、お前および何人かは >>931 の主張の前提を共有できてない。

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

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

これに対して「コンフリクトしてもマージすればいいだろ」と言っても
>>931 としても「頑張れ」としか言えんだろう。

ID: s4x1CSLN はGit脳かなんか知らんが発狂しすぎだろ。
適材適所、という言葉さえ知らないのか？

トンカチを持った奴はなんでも釘に見える、というけど、Gitを持つと、Git以外の管理方法が
目に入らなくなるらしい。

> * マージ・コンフリクトの解決が難しい種類のファイルは現実的に存在する
だがそれはロックしても解決できない

>>930
＞大事だから、やっぱGitは向いてないよ。

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

gitというか分散管理ツールははオフラインで作業が捗るように作られている
わけだから、オンラインじゃなきゃ機能しないロック機構とは相性が悪い。
オフラインの人への通知をどうするのか考えたら別のツール使えよって
普通はなるよな。

まず、>>895の

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

が分散型の仕組み上無理なことを誰も突っ込まないんだろうか…
だってそれできたら、もう分散型じゃないようなw

ロックをすることでマージが簡単になるんじゃないことに注意な。

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

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

ではロックで何が解決されるのか？
その答えが些細な事だって話。

バイナリをロックしても、解除された後に結局マージするんだろ。

テキストは自動マージがあるだけだが、マージされたからと言ってその結果が正しいとは言えないのだから、テストかレビューが必要。バイナリの手動マージと同じ。

>>917
> 大抵のケースで介入の必要ないのに面倒ってどう言うこと？

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

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

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

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

1は面倒なので2のほうがマシ、と言ってる。

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

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

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

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

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

根本的な原因がわかってきたんじゃねーの？

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

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

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

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

無駄な編集開始を避ける話しは、ここまでの話だよ。

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

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

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

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

「Gitにロックがあれば」なんて話にもっていくのはおかしい、
って俺は言っている。

>>948
＞（まさかいちいちメールでやってるわけないよね？ｗ）

お前がメールに親を殺されたか、恋人をNTRされたか分からんがメールへの
恨みだけは他の誰にも負けないことは分かったから黙ってろ。

>>950
次スレ建てろ
すぐやれ

とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
あと、分散では原理的に実現できないと言うのもいいよね。
これに反対する奴はいないと思うんだが、いいかな？
>>948 とかが不用意にソースコードとか書くから話がおかしくなってるので、確認させてくれ。

>>952
おｋ

> とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。

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

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

バイナリであったとしても、どちらかを取ればいいので
ロックを使う理由はない。

>>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/