トップページ⇒tech
1001コメント345KB

Git 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なんで？

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

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

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

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

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

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

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

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

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

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

それgitでは普通だけど？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://ideone.com/hvgkDV
0174デフォルトの名無しさん2014/02/03(月) 01:43:15.60
全然違う
0175デフォルトの名無しさん2014/02/03(月) 01:57:26.57
以下のようにコミットの履歴が番号順に育っていて、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マージ」と「マージコミットを作成することによるマージ」
のどちらかを任意に選択可能。
0176デフォルトの名無しさん2014/02/03(月) 02:04:08.14
リスト構造の概念が分かってればgitも似たようなもんだから理解は難しくないと思われ
0177デフォルトの名無しさん2014/02/03(月) 02:11:48.62
全然違うよ
0178デフォルトの名無しさん2014/02/03(月) 02:12:10.74
>>174,177
なにがだ。
0179デフォルトの名無しさん2014/02/03(月) 04:47:05.44
　 　┌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まで来てしまったら鬱エンドは回避不可能。
0180デフォルトの名無しさん2014/02/03(月) 05:02:40.54
現在Fにいるとして、ここからG、H、にはfast-forwardではいけない。
だが無理やりFにG、Hをマージすることが出来る。
そうすると、ハッピーエンドを見た後で、真のエンディングを見ることが可能になる。
単純にG、Hにくるだけでは真のエンディングしか見れない。
また逆にHにいるときにFをマージすることで、真のエンディング＋ハッピーエンドになる。

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

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

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

Git - Book
http://git-scm.com/book/ja
0200デフォルトの名無しさん2014/02/04(火) 00:33:09.00
pushの -u オプションは毎回つける必要なくね？
0201デフォルトの名無しさん2014/02/04(火) 00:33:09.30
大した分量でもないから基本的な部分の話だけなら２～３時間くらいあれば読めるだろう
0202デフォルトの名無しさん2014/02/04(火) 00:34:02.30
subversion と同じ感覚で使うと間違いなく事故る
0203デフォルトの名無しさん2014/02/04(火) 00:38:32.46
>>197
送信の通信量をチェックするか
リモートブランチを自前サーバーにでも作ってチェックするか
Gitのソースコードでpushで何やってるかを直に見るか
すればいい
0204デフォルトの名無しさん2014/02/04(火) 00:42:13.92
無駄に通信コストのかかる設計にしてるとはとても思えないがな
0205デフォルトの名無しさん2014/02/04(火) 00:43:28.75
ところがどっこい
0206デフォルトの名無しさん2014/02/04(火) 00:51:57.24
プロトコル次第なんだな、面白い
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
0207デフォルトの名無しさん2014/02/04(火) 01:07:07.82
Gitのソースコード見てたが案外やっつけだな
0208デフォルトの名無しさん2014/02/04(火) 03:26:03.37
くそぅ、うんこがしたいのに３日我慢してんだぜ...
0209デフォルトの名無しさん2014/02/04(火) 11:07:45.50
味噌を食うと良い
0210デフォルトの名無しさん2014/02/04(火) 14:19:52.08
EGitからpushする際、毎回URIの入力をしないといけないんだけど、これ何とかならない？
GitLab Cloudに送りたいんだけど 、毎回URIを確認しにファイルだかサイトだかにアクセスしないといけないんだけど
0211デフォルトの名無しさん2014/02/04(火) 14:45:41.55
>>210
Eclipseスレで聞いたら？EGitの話題も多いよ
0212デフォルトの名無しさん2014/02/04(火) 15:13:50.09
分かった
ありがと
0213デフォルトの名無しさん2014/02/04(火) 19:50:17.43
git status
で見ると、変更があることになってるんだけど
git diff
で見ると、変更がない（属性も同じ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つくかもしれないけど
下手にごちゃごちゃやるよりは
忘れてもっかいcommitすべきだよね
0342デフォルトの名無しさん2014/02/12(水) 22:35:31.22
それは使わないんじゃなくて、使えないんだろ。
0343デフォルトの名無しさん2014/02/12(水) 22:41:16.96
git-cvs は便利だね
0344デフォルトの名無しさん2014/02/12(水) 22:58:42.71
>>337
馬鹿には無理wwwwwwwwｗｗｗｗ
0345デフォルトの名無しさん2014/02/12(水) 23:27:27.46
robocopyは便利だな
というかrsyncのコマンド体系が分かりづらすぎる
0346デフォルトの名無しさん2014/02/13(木) 00:08:11.05
>>337
それで何がしたいの？
0347デフォルトの名無しさん2014/02/13(木) 00:09:58.47
アンチって何でわざわざ自分から嫌いなものに関わろうとするんだろうね、よく分からない
0348デフォルトの名無しさん2014/02/13(木) 00:46:03.94
rebase するときって一つ前のコミット ID を指定するけど、
一つ前のコミットが存在しない初回のコミットって内容の修正は出来ないのかな。
0349デフォルトの名無しさん2014/02/13(木) 00:53:59.26
rebaseの引数にコミットIDなんか書いたこと無いなぁｗ
0350デフォルトの名無しさん2014/02/13(木) 00:59:46.37
rebase -iを使うときは書き換え始める位置のひとつ前のコミットIDを指定するかな
0351デフォルトの名無しさん2014/02/13(木) 01:02:21.03
質問の意味がよく分からない
図で説明してくれ
0352デフォルトの名無しさん2014/02/13(木) 01:05:00.67
え？ 一つ前ならHEAD^じゃん？
0353デフォルトの名無しさん2014/02/13(木) 01:11:03.20
イニシャルコミットの一つ前のコミットが存在しないから
イニシャルコミットは書き換え出来ないってことだろ
0354デフォルトの名無しさん2014/02/13(木) 01:13:24.26
git init直後の最初のコミットは空にするようにしてる
0355デフォルトの名無しさん2014/02/13(木) 01:19:58.57
空のコミットってどうやるん？
0356デフォルトの名無しさん2014/02/13(木) 01:23:04.70
git commit --allow-empty
0357デフォルトの名無しさん2014/02/13(木) 02:01:03.09
お、さんきゅー
0358デフォルトの名無しさん2014/02/13(木) 02:02:02.05
>>348
最初のコミットの書き換えはメンドクサイことすればできるよ
最初のコミットからブランチを作ってそれをcommit --amendで書き換え
(この時点で起点を共有しないブランチがリポジトリに存在することになる)
その後もとのブランチに戻って、書き換えた最初のコミットのブランチへrebaseする
0359デフォルトの名無しさん2014/02/13(木) 02:22:14.50
はぁ？ git rebase -i -root これだけじゃん。
何が面倒くさいのか。
0360デフォルトの名無しさん2014/02/13(木) 02:47:35.96
>>359
うちのgitにはそんなオプションないな
バージョンいくつよ？
0361デフォルトの名無しさん2014/02/13(木) 02:52:49.96
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>.
0362デフォルトの名無しさん2014/02/13(木) 02:54:45.78
1.7.xだとgit rebase -i --rootもダメだ
0363デフォルトの名無しさん2014/02/13(木) 02:55:26.77
ああ、1.7.12から使えるようになったらしい
0364デフォルトの名無しさん2014/02/13(木) 02:55:44.94
gitは最新版を使った方がいい。
0365デフォルトの名無しさん2014/02/13(木) 03:03:25.78
rebase: learn to rebase root commit ・ 190f532 ・ git/git ・ GitHub
https://github.com/git/git/commit/190f53232d1e92a57843df90e889bcfea39620d3
> Teach git-rebase a new option --root
0366デフォルトの名無しさん2014/02/13(木) 03:06:14.41
debian squeezeだとbackportsでも1.7.10が最新なんだよなあ
そろそろ新しくするか
0367デフォルトの名無しさん2014/02/13(木) 03:14:09.08
debianとかねーわ
0368デフォルトの名無しさん2014/02/13(木) 03:14:32.42
コンパイルして入れればいいのに。
gitは仕組み的に、ファイルにアクセスして
ネットワーク通信するだけだから簡単にコンパイルできるよ。
0369デフォルトの名無しさん2014/02/13(木) 03:14:32.86
>>365
そのへんのバージョンだと-i --rootじゃダメで、--ontoを指定しないと叱られる
0370デフォルトの名無しさん2014/02/13(木) 08:00:01.28
>>368
> ファイルにアクセスしてネットワーク通信するだけ

そんな言い方したらほとんどのソフトが当てはまるわけだが (w
0371デフォルトの名無しさん2014/02/13(木) 08:39:06.72
数百を超えるソフト使ってるのに、いちいち手動で入れてられんわ
0372デフォルトの名無しさん2014/02/13(木) 08:47:43.84
必要な物だけ手動で入れればいいのでは？
0373デフォルトの名無しさん2014/02/13(木) 09:00:12.35
お、新しいバージョンだと最初のコミットもいじれるのか
0374デフォルトの名無しさん2014/02/13(木) 14:21:01.59
squeezeなんてもうすぐeolだぞ
0375デフォルトの名無しさん2014/02/13(木) 17:31:20.08
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する必要がある？
0376デフォルトの名無しさん2014/02/13(木) 18:02:11.12
>>372
じゃあgitは不要だ。
0377デフォルトの名無しさん2014/02/13(木) 23:47:25.44
最新安定バージョンのwheezyでも1.7.10なんだけどな
0378デフォルトの名無しさん2014/02/13(木) 23:49:44.46
無駄に用心深いdebianじゃどうしようもない、捨てろ
0379デフォルトの名無しさん2014/02/14(金) 00:06:06.24
backportsに1.8.5.3あるじゃん
0380デフォルトの名無しさん2014/02/14(金) 00:16:15.53
>>377
フリーズしてから1年以上立つんじゃないか。
安定版は機能追加しないぞ?
0381デフォルトの名無しさん2014/02/14(金) 05:41:16.11
tortoiseGit1.8.7使っているんだけど、一度コードを変更してから前の状態に戻したら大抵は
変更無しとみなしてくれるんだけど、ちょくちょく変更ありのままになってどうしようもなくなる。
これってどうやったら巻き戻せるの？checkoutしてもresetしてもrevertしても戻せない。
結局面倒になって全部消してcloneしなおす感じになっているんだけどなんか納得いかないんだよな。
Subversionだとrevertするか一度消して取りなおせばokだったけどどうも思う様にいかん・・・。
0382デフォルトの名無しさん2014/02/14(金) 06:09:27.03
馬鹿には無理
0383デフォルトの名無しさん2014/02/14(金) 06:20:22.73
デスマおつかれさまです。
さっさと寝たら？
0384デフォルトの名無しさん2014/02/14(金) 11:06:14.85
git config core.filemode false
git config core.symlinks false

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

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

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

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

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

　Dir
　 |-DirA
　 |-DirB
　 `-DirC

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

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

github のプルリクエストみたいなのはうまくいってる例じゃないかなあ。
0415デフォルトの名無しさん2014/02/16(日) 13:06:56.02
>>406
バグ修正してる時に、なんでその変更したか読み取るのに必要。BTSと連携してるので特に。
0416デフォルトの名無しさん2014/02/16(日) 19:28:42.49
>>415
それあるね
消されるとわからなくなる
消せないフラグがあるといいのかね
0417デフォルトの名無しさん2014/02/17(月) 00:01:18.89
>>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のみ履歴から消すことができる
0418デフォルトの名無しさん2014/02/17(月) 01:48:19.18
>>410
sparse checkout
0419デフォルトの名無しさん2014/02/19(水) 01:20:06.23
1.9がキター
0420デフォルトの名無しさん2014/02/19(水) 01:22:37.97
ほんまや
0421デフォルトの名無しさん2014/02/19(水) 11:06:52.13
>>312
元々、mercurial使ってからgit使い始めたけど、ほんまこれ
gitを理解してる上で、これやろうならいいけど
あんま理解してない状態で、あれやりたい！とりあえずググろう、みたいなスタンスで使って泥沼に嵌ってる人をたまにみかける
0422デフォルトの名無しさん2014/02/19(水) 14:32:01.28
理解さえしてしまえば、かなり大胆にいろいろ自由にやっても破綻しない
そして、構造自体は比較的簡単なので理解するのはそれほど難しくない
0423デフォルトの名無しさん2014/02/19(水) 16:30:52.77
GithubってGithub自身のソースは公開してないのかよ！
0424デフォルトの名無しさん2014/02/19(水) 19:02:13.55
おまえのものはおれのもの
おれのものはおれのもの
0425デフォルトの名無しさん2014/02/20(木) 20:02:00.54
\\hoge\fuga\bar\.git というサーバーをwindowsでcloneするにはどうすればいいのでしょうか？

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


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

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

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

github/gitignore ・ GitHub
https://github.com/github/gitignore
0455デフォルトの名無しさん2014/02/23(日) 08:33:09.72
マルチうぜー
http://toro.2ch.net/test/read.cgi/tech/1354608228/859
0456デフォルトの名無しさん2014/02/23(日) 18:06:07.80
>>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に対する変更のみのコミットが空コミットとして入っているので、
　　それらを削除
0457デフォルトの名無しさん2014/02/24(月) 10:40:25.19
fetch面倒くさい
0458デフォルトの名無しさん2014/02/25(火) 00:00:06.34
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版）
0459デフォルトの名無しさん2014/02/25(火) 05:59:38.49
具体的なバージョンは忘れたけど
fedora12環境(つまり結構ふるい)では
ふつうにgit svn cloneできてたよ。

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.amazon.co.jp/dp/4863541465
開発効率をUPする Git逆引き入門
0564デフォルトの名無しさん2014/03/16(日) 17:13:12.82ID:EOaK1FG8
何冊も解説本が必要な時点で終わっとる
0565デフォルトの名無しさん2014/03/16(日) 17:17:40.87ID:rHQmp5Mm
何冊も解説本が販売されると、
なんで終わることになるんですか？
多分C言語なんか、一番解説本が多いと思ういますけど？
0566デフォルトの名無しさん2014/03/16(日) 17:21:37.93ID:YKmk2JvD
まあそれだけ多くの人が使い始めてるわけだ
0567デフォルトの名無しさん2014/03/16(日) 17:27:48.29ID:rHQmp5Mm
ちょっとある仮説を思いついたから、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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これを↓

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

こんな感じ

こうするとgit-svnで引っ張ってきた過去の履歴と比較できなくなるって言われたんだけど
今から治す方法ない？
0608デフォルトの名無しさん2014/03/24(月) 07:39:05.71ID:coYvviPW
最初っからtrunk込みのパスをgit-svnに渡しとけ
折角svnはサブディレクトリ単位でもリポジトリ扱いできるんだから
0609デフォルトの名無しさん2014/03/24(月) 07:40:05.59ID:coYvviPW
或いはgit svn -sか。
0610デフォルトの名無しさん2014/03/24(月) 09:59:32.00ID:l/qxp3d1
>>606
この文脈でREADMEって、何を書く想定なんだ？
0611デフォルトの名無しさん2014/03/24(月) 12:26:30.45ID:k2bvJYlJ
>>610
なんでこの空ディレクトリがコミットされているのかと、どういうモノをここにコミットしていく予定なのか。
ディレクトリがイントロスペクティブなら、後で気が変わってツリーの見直しが発生してもドキュメントと作業ディレクトリの二重管理を防げる。
0612デフォルトの名無しさん2014/03/24(月) 12:33:59.02ID:rzCer1bD
>>586
そんな使えないツール作ってないで、コメントつけろよ。
0613デフォルトの名無しさん2014/03/24(月) 14:56:36.98ID:x252QyU1
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）
0614デフォルトの名無しさん2014/03/24(月) 16:26:56.74ID:7xUxQev3
>>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を使えばその警告を無視してブランチを消せる
0615デフォルトの名無しさん2014/03/24(月) 18:45:49.12ID:15T1FlGn
>>613
　HEAD(、temp)
　↓
┌C3
↓
C1←C2
　　↑
　　master
Q1
Q1でのC3のようにブランチなどから参照されていないコミットをdetachedという
この状態でHEADをC2などに動かすと どこからも参照されていないC3は失われてしまう(もちろんreflogはできる)ので変更を残したいならブランチなどを作ってね、ということ

Q2
ここではtempはC3を指すように作られる
tempを作った直後は編集していないけど、上図の通りC3がマージされていない
0616デフォルトの名無しさん2014/03/25(火) 00:33:52.38ID:56htplUz
小保方さんも論文のバージョン管理はGitでやれば良かったのに
0617デフォルトの名無しさん2014/03/25(火) 01:53:12.00ID:T9JHOn1b
gitでもコピペは防げません
0618デフォルトの名無しさん2014/03/25(火) 02:16:02.05ID:6ItjGCiG
>>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)
0619デフォルトの名無しさん2014/03/25(火) 03:33:44.11ID:FBko2gtk
コミット番号についての単純で重要な事を一つ言っておくよ。

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

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



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

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

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

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

detachedの使い方 その1

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

detachedの使い方 その2

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


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

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

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

これは

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

本なんて安いもの、という発想が出来ないうちはいつまでたっても底辺のままだよ。
0685デフォルトの名無しさん2014/03/30(日) 14:58:24.37ID:KMVNCqdy
いやいやごみはごみだよ
0686デフォルトの名無しさん2014/03/30(日) 15:58:28.39ID:/CfyfstJ
初めからこのスレの住人をコンテキストに書かれてるのも読み取れないで本や仕様書が読めるのかね？
0687デフォルトの名無しさん2014/03/30(日) 16:00:11.26ID:J3oHNw57
コンテキストってな～に？
0688デフォルトの名無しさん2014/03/30(日) 16:03:06.58ID:Ym7n0+3V
それ以前に日本語がおかしいぞ
0689デフォルトの名無しさん2014/03/30(日) 16:13:00.70ID:lTbLNvca
わずか一行の文章でここまでわけのわからないことを書けるのも一種の才能
0690デフォルトの名無しさん2014/03/30(日) 20:06:17.85ID:AmZWDzue
くんこくさいし
0691デフォルトの名無しさん2014/03/30(日) 20:07:17.57ID:AmZWDzue
誤爆、しかも誤字
0692デフォルトの名無しさん2014/03/31(月) 06:09:15.40ID:Dx9xREGz
>>616-617
gitで複数のリポジトリからpullしたのを合体なんて出来た？
0693デフォルトの名無しさん2014/03/31(月) 10:33:24.64ID:Jzg3YQa1
>>692
fetch
fetch
merge
0694デフォルトの名無しさん2014/04/01(火) 01:36:09.78ID:HTAg2n1d
1.9系のメンテナンスリリース「Git 1.9.1」がリリース
http://sourceforge.jp/magazine/14/03/25/150000
> バグ修正が中心のメンテナンスリリースで、ユーザーにアップデートを呼びかけている。
0695デフォルトの名無しさん2014/04/01(火) 11:30:36.52ID:L86dyqvA
　3月18日、Git 1.9系の最新版となる「Git 1.9.1」がリリースされた。
^^^^^^^^^^^^
0696デフォルトの名無しさん2014/04/01(火) 15:28:53.38ID:zd2Xq/O2
↓を参考に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がないのが原因ではないかと推測したのですが
何か考えられる対処方法はありませんか？
0697デフォルトの名無しさん2014/04/01(火) 21:58:10.85ID:HTAg2n1d
>>695
1.9.1ってどうやったら入手できるん？
0698デフォルトの名無しさん2014/04/01(火) 21:59:49.76ID:HTAg2n1d
自己解決、見つけた

Release v1.9.1: Git 1.9.1 ・ git/git ・ GitHub
https://github.com/git/git/releases/tag/v1.9.1
0699デフォルトの名無しさん2014/04/01(火) 22:03:48.11ID:L86dyqvA
git使ってるはずなのに
gitのソースコードを
gitで取ってこないのってなんで？
0700デフォルトの名無しさん2014/04/01(火) 22:08:00.54ID:HTAg2n1d
Windows使いだから
0701デフォルトの名無しさん2014/04/01(火) 22:09:45.98ID:HTAg2n1d
msysgitがまだ1.9.1に上がってないだけだった
0702デフォルトの名無しさん2014/04/01(火) 22:11:25.10ID:L86dyqvA
Windowsだとgitつかえないのー？
Windows版あるのになんでー？
0703デフォルトの名無しさん2014/04/01(火) 22:17:14.30ID:HTAg2n1d
gitのソースコードなんかWindowsに持ってきてどうするんだよ
0704デフォルトの名無しさん2014/04/01(火) 22:58:03.14ID:GxYZELvy
>>703
最新版使いたいって話なんだから
コンパイルするに決まってるじゃん？
何だと思ったのさｗ
0705デフォルトの名無しさん2014/04/01(火) 22:58:55.23ID:GxYZELvy
> 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に持ってきてどうするんだよ
0706デフォルトの名無しさん2014/04/01(火) 23:15:16.31ID:HTAg2n1d
http://git-scm.com/
↑でDownloadのところが1.9.1になってるのにダウンロードしようとすると1.9.0になるから
おかしいなと思っただけだよ
0707デフォルトの名無しさん2014/04/01(火) 23:18:39.59ID:HTAg2n1d
つまり>>698は1.9.1の存在を確認したってだけのレスだよ
0708デフォルトの名無しさん2014/04/01(火) 23:18:51.75ID:GxYZELvy
ソースコードならgitで取ってくればいいだろって
いっただけだよ。
0709デフォルトの名無しさん2014/04/01(火) 23:26:20.82ID:HTAg2n1d
ソースコードじゃなくビルドされたmsysgitの1.9.1が欲しかったんだよ
0710デフォルトの名無しさん2014/04/01(火) 23:30:34.74ID:GxYZELvy
ソースコードあるんだから存在確認なんかするできるじゃない。

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

まで読んだ
0729デフォルトの名無しさん2014/04/07(月) 05:47:52.87ID:K/kPFgfw
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここまではいいね？


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

これに答えて欲しい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。
0812デフォルトの名無しさん2014/04/09(水) 23:20:46.34ID:Il0l8m2A
WindowsでGitをインストールすると.gitconfigの[core]の項目が存在しますが
Linuxでソースコードから入れると、入れたばかりだと.gitconfigは存在しません。
名前とメールアドレスを登録したら自動的に.gitconfigが作られますけど
Linuxでは[core]の部分は設定しなくてもいいのでしょうか？
例えばautoCRLFとか
0813デフォルトの名無しさん2014/04/09(水) 23:41:10.33ID:hkLzWOQG
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
0814デフォルトの名無しさん2014/04/10(木) 00:00:04.05ID:ZuhRq4by
>>802
もちろんそれぞれの解があっていいと思うけど、トイレと車での移動を両立しようと思ったら、なにか諦めなくちゃいけないじゃない。
汚物を自分で処理するということなのか、上水下水を駐車時に勝手に流してくれるようなステーションにしか行けないような車を作るのか、諦め方は色々あると思うけど。

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

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

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

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





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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

95%うまくいく。

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

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

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

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

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

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

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

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

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

つまり、

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バイナリであったとしても、どちらかを取ればいいので
ロックを使う理由はない。
0955デフォルトの名無しさん2014/04/12(土) 13:07:00.16ID:BW6c4MFF
>>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/
0956デフォルトの名無しさん2014/04/12(土) 13:22:55.97ID:B/06XIsq
>>902
>>880=>>815なんだが。
そのあとろくにgit-annexについて考察もしないのに「都合の悪いレスを読み飛ばすな」とか批判する資格ないだろ。
大体git-annexにだって問題点は沢山あるわけで。つーかgit-annexで解決してるならもういいだろ。
単にgitにロックがないということで無駄な論争を起こそうとしてるとしかおもえない。
0957デフォルトの名無しさん2014/04/12(土) 13:23:23.64ID:s4x1CSLN
>>955
立てといた

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

ここまでは同意。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要らない。

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

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

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

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

こういいう話。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

変更するときは、大本だけどねー
0999デフォルトの名無しさん2014/04/13(日) 01:01:16.17ID:pwayVEBU
梅
1000デフォルトの名無しさん2014/04/13(日) 01:04:55.07ID:pwayVEBU
1000なら日本国の少子化問題が解決する
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。