Git 9
1 ：デフォルトの名無しさん：
ソースコード管理を行う分散型バージョン管理システム、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/
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/
|
|
|
2 ：デフォルトの名無しさん：2014/04/12(土) 13:36:51.60 ID:UapBJj1i
ここは Git のスレ
github の話題はこちらで
↓
OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
github の話題はこちらで
↓
OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
3 ：デフォルトの名無しさん：2014/04/12(土) 15:13:56.03 ID:hrYZFkTS
頭悪すぎで話にならないID:s4x1CSLNはng推奨
4 ：デフォルトの名無しさん：2014/04/12(土) 15:28:59.89 ID:4Ld644Zh
5 ：デフォルトの名無しさん：2014/04/12(土) 15:32:53.63 ID:4Ld644Zh
◆関連スレ
バージョン管理システムについて語るスレ10
http://toro.2ch.net/test/read.cgi/tech/1393147031/
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/
OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
◆関連スレ 別板
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
バージョン管理システムについて語るスレ10
http://toro.2ch.net/test/read.cgi/tech/1393147031/
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/
OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
◆関連スレ 別板
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
6 ：デフォルトの名無しさん：2014/04/12(土) 15:38:56.65 ID:4Ld644Zh
◆関連書籍
開発効率をUPする Git逆引き入門 2014/04
http://www.c-r.com/book/detail/970
Git ポケットリファレンス 2012/07
http://gihyo.jp/book/2012/978-4-7741-5184-7
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
開発効率をUPする Git逆引き入門 2014/04
http://www.c-r.com/book/detail/970
Git ポケットリファレンス 2012/07
http://gihyo.jp/book/2012/978-4-7741-5184-7
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
7 ：デフォルトの名無しさん：2014/04/12(土) 16:02:59.22 ID:s4x1CSLN
>>4
すまん。
すまん。
8 ：デフォルトの名無しさん：2014/04/13(日) 01:34:47.62 ID:f3OGXPtA
サルでもわかるGit入門 ?バージョン管理を使いこなそう? | どこでもプロジェクト管理バックログ
http://www.backlog.jp/git-guide/
http://www.backlog.jp/git-guide/
9 ：デフォルトの名無しさん：2014/04/13(日) 19:17:52.20 ID:XMFLaUST
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
大塚 弘記
http://www.amazon.co.jp/gp/product/477416366X/
大塚 弘記
http://www.amazon.co.jp/gp/product/477416366X/
10 ：デフォルトの名無しさん：2014/04/13(日) 22:25:00.03 ID:preDdKCE
>>9
ここGitのスレだからGitHubメインでGitのことがほとんど書かれてない本はお門違いじゃないの
ここGitのスレだからGitHubメインでGitのことがほとんど書かれてない本はお門違いじゃないの
11 ：デフォルトの名無しさん：2014/04/13(日) 22:41:15.55 ID:wSq/pgWA
>>10
git 繋がりでいいんじゃね？
git 繋がりでいいんじゃね？
12 ：デフォルトの名無しさん：2014/04/13(日) 22:49:27.59 ID:preDdKCE
>>11
GitHubスレいけができなくなるがよろしいか
GitHubスレいけができなくなるがよろしいか
13 ：デフォルトの名無しさん：2014/04/13(日) 22:58:41.51 ID:qxdLUwd6
format-patchで、
本線だけのパッチって作れないんでしょうか？
マージコミット部分ではマージされた区間をsquashしたようなパッチが生成されて欲しいのですがムリでしょうか？
本線だけのパッチって作れないんでしょうか？
マージコミット部分ではマージされた区間をsquashしたようなパッチが生成されて欲しいのですがムリでしょうか？
14 ：デフォルトの名無しさん：2014/04/13(日) 23:11:35.99 ID:qL3uhhaK
>>13
詳しく調べてないので外してたらすまんが、マージコミットをパッチにはできなかったはず。
ベースになるコミットから現在のHEADまでマージコミットについてはmerge --squash しながら再構成、
新しいHEADとオリジナルのHEADをdiffして漏れがないのを確認後、format-patchするとかでどうかな。
詳しく調べてないので外してたらすまんが、マージコミットをパッチにはできなかったはず。
ベースになるコミットから現在のHEADまでマージコミットについてはmerge --squash しながら再構成、
新しいHEADとオリジナルのHEADをdiffして漏れがないのを確認後、format-patchするとかでどうかな。
15 ：デフォルトの名無しさん：2014/04/13(日) 23:33:00.29 ID:wSq/pgWA
16 ：デフォルトの名無しさん：2014/04/14(月) 00:01:32.52 ID:7zmL9s1f
>>15
Gitに関係ないGitHubの話や質問をここですることを受け入れるかということです
Gitに関係ないGitHubの話や質問をここですることを受け入れるかということです
17 ：デフォルトの名無しさん：2014/04/14(月) 06:07:54.65 ID:eZQPfKWX
18 ：デフォルトの名無しさん：2014/04/14(月) 06:12:49.91 ID:1BzKypQe
GitHubはGit関係なので
話題にしてOK
話題にしてOK
19 ：デフォルトの名無しさん：2014/04/14(月) 06:23:10.46 ID:7zmL9s1f
祝・GitHub解禁
20 ：デフォルトの名無しさん：2014/04/14(月) 06:33:02.10 ID:1BzKypQe
gitやるなら、gitコマンドだけじゃなくて
gitを使った開発手法も対象内だし、
gitサーバーやgitワークフローもgitの話題の一つ。
GitHubはそのサーバーとワークフローのためのツールなんだから
このスレで全然問題ない。
gitを使った開発手法も対象内だし、
gitサーバーやgitワークフローもgitの話題の一つ。
GitHubはそのサーバーとワークフローのためのツールなんだから
このスレで全然問題ない。
21 ：デフォルトの名無しさん：2014/04/14(月) 06:54:18.95 ID:r6Wx+cLS
OpenSSLにすごいバグがあるらしいけど、OpenSSHは大丈夫なのかな。SSHでgitサーバに接続してます。
22 ：デフォルトの名無しさん：2014/04/14(月) 07:13:46.54 ID:7zmL9s1f
23 ：デフォルトの名無しさん：2014/04/14(月) 08:56:01.10 ID:AmAJMm0T
>>9
ステマすんなゴミ
ステマすんなゴミ
24 ：デフォルトの名無しさん：2014/04/14(月) 09:08:38.81 ID:1BzKypQe
25 ：デフォルトの名無しさん：2014/04/14(月) 09:48:57.46 ID:6tPspeJq
http://yamaha-webmusic.github.io/
http://yamaha-webmusic.github.io/nsx1-apps/manual/
こういうアカウントってフォローするのどうやるの？
http://yamaha-webmusic.github.io/nsx1-apps/manual/
こういうアカウントってフォローするのどうやるの？
26 ：デフォルトの名無しさん：2014/04/14(月) 09:52:00.42 ID:toZF1Crt
git 単体で ITS なしの運用って辛いな・・・
なんでメールのみでのやりとりなんだ・・・
なんでメールのみでのやりとりなんだ・・・
27 ：デフォルトの名無しさん：2014/04/14(月) 13:45:30.96 ID:gAJOCe3S
ITSって何だ？
28 ：デフォルトの名無しさん：2014/04/14(月) 14:04:20.03 ID:toZF1Crt
29 ：デフォルトの名無しさん：2014/04/14(月) 14:48:38.62 ID:pS18deUR
発行追跡システマ
30 ：デフォルトの名無しさん：2014/04/14(月) 16:08:45.44 ID:gAJOCe3S
31 ：デフォルトの名無しさん：2014/04/14(月) 21:07:55.30 ID:Uax92dk0
関東ITはなかなか良いぞ
32 ：デフォルトの名無しさん：2014/04/14(月) 22:59:31.00 ID:XW768nZt
33 ：デフォルトの名無しさん：2014/04/15(火) 20:21:29.46 ID:LX0BNsfx
Gitって色々あるけどどう違うのかわからない。
GitHubのアカウントをとってみたり、>>8のリンク先を見たりしたが
色々種類があってわからない。
やりたい事は「プログラムのバージョン管理をしたい(Gitはそう言う用途だからあたりまえだかけど)」と言う事と
何より重要なのが「ソースコードを誰にも見られたくない」と言う事くらいかな。
後は、「どこにいてもソースが落とせる」ってのもある。
GitHubはTwitterみたいなUIだから「どこにいてもソースが落とせる」って事はできそうだけど色んな人から見られそう。
>>8のはローカルで管理する感じなのかな？
良ければ初心者に簡単なGitを教えて下さい。
GitHubのアカウントをとってみたり、>>8のリンク先を見たりしたが
色々種類があってわからない。
やりたい事は「プログラムのバージョン管理をしたい(Gitはそう言う用途だからあたりまえだかけど)」と言う事と
何より重要なのが「ソースコードを誰にも見られたくない」と言う事くらいかな。
後は、「どこにいてもソースが落とせる」ってのもある。
GitHubはTwitterみたいなUIだから「どこにいてもソースが落とせる」って事はできそうだけど色んな人から見られそう。
>>8のはローカルで管理する感じなのかな？
良ければ初心者に簡単なGitを教えて下さい。
34 ：デフォルトの名無しさん：2014/04/15(火) 20:33:20.49 ID:D1Ol4DiB
「ソースコードを誰にも見られたくない」ならローカルで完結させるしかないね
35 ：デフォルトの名無しさん：2014/04/15(火) 20:34:19.07 ID:CXoafp6W
たくさんあるってどういうこっちゃ。クライアントプログラムは色々あるかもしれんが git は一種類しかないぞ。
github は git を使ったホスティングサービスであって git の一種ってわけじゃない。
ホスティングサービスどれがいい？って質問なら↓の方が回答もらえるんでないかな。
・OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
他人にソースを見られたくない場合は
・自分で git のサーバを建てる
・ローカルで使う
・プライベートリポジトリをサポートしてるホスティングサービスを使う(大抵は有料)
github もプライベートリポジトリサポートしてるけど有料だね。パブリックだと無料だけど。
自分でサーバを建てる場合も自由になるサーバ持ってないならどっかから借りなきゃいけないから有料になる。
github は git を使ったホスティングサービスであって git の一種ってわけじゃない。
ホスティングサービスどれがいい？って質問なら↓の方が回答もらえるんでないかな。
・OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/
他人にソースを見られたくない場合は
・自分で git のサーバを建てる
・ローカルで使う
・プライベートリポジトリをサポートしてるホスティングサービスを使う(大抵は有料)
github もプライベートリポジトリサポートしてるけど有料だね。パブリックだと無料だけど。
自分でサーバを建てる場合も自由になるサーバ持ってないならどっかから借りなきゃいけないから有料になる。
36 ：デフォルトの名無しさん：2014/04/15(火) 21:13:10.96 ID:Td9RmRcX
初心者ですが、
Gitの説明でよくブランチの分岐が書いてあってそれでrebaseだcherry-pickだ等々
説明が書いてあるけど、
このブランチの構造自体は皆さんgitのログとかから頭の中でイメージしたり
できるんですか? 自分にはまずそこが問題w
Gitの説明でよくブランチの分岐が書いてあってそれでrebaseだcherry-pickだ等々
説明が書いてあるけど、
このブランチの構造自体は皆さんgitのログとかから頭の中でイメージしたり
できるんですか? 自分にはまずそこが問題w
37 ：デフォルトの名無しさん：2014/04/15(火) 21:44:05.28 ID:z6touH+D
VPSを自分専用のgit鯖にしてる。
って、ssh開けるだけだから、鯖という言い方もおかしいか。
自宅鯖が安心最安だろうけど、1k円/月くらいあれば安いVPSあるんじゃないか。
って、ssh開けるだけだから、鯖という言い方もおかしいか。
自宅鯖が安心最安だろうけど、1k円/月くらいあれば安いVPSあるんじゃないか。
38 ：デフォルトの名無しさん：2014/04/15(火) 21:45:31.32 ID:z6touH+D
>>36
git graphっていう、よく出回ってるalias見て理解してる。つもり。
git graphっていう、よく出回ってるalias見て理解してる。つもり。
39 ：デフォルトの名無しさん：2014/04/15(火) 21:58:59.82 ID:OKvn8yBf
git log --gragh --all
でツリー出てくるよ。
コミットログの書式短いのにした方が見やすいけど。
でツリー出てくるよ。
コミットログの書式短いのにした方が見やすいけど。
40 ：デフォルトの名無しさん：2014/04/15(火) 22:10:15.34 ID:JExjPciB
とりあえずならこんな感じか
git log --graph --all --decorate --oneline
自分はこれだとちょっと表示が気に食わないので、
--decorate --onelineの代わりに--pretty=formatで表示を加工してる
git log --graph --all --decorate --oneline
自分はこれだとちょっと表示が気に食わないので、
--decorate --onelineの代わりに--pretty=formatで表示を加工してる
41 ：デフォルトの名無しさん：2014/04/15(火) 23:55:03.38 ID:4LopPBVb
俺はDropboxにbareリポジトリ置いてるだけだ。
壊れるのが怖いから時々zipに固めてるけど。
壊れるのが怖いから時々zipに固めてるけど。
42 ：デフォルトの名無しさん：2014/04/16(水) 00:09:16.13 ID:7KV1DqqH
>>34-35
ありがとうございます。
>>8を見ながらインストールしてみました。
取り合えずローカルで使う予定なのでコミットまで一通りやってみました。
ローカルで使うならリポジトリの共有以降は不要ですよね(Gitとしての恩赦も薄そうだけど)
皆さんはリモート使って他の人と共同で何かを作ってるんでしょうか？
仕事で使う以外はローカルでも不便しなさそうですが、勉強のため開発と平行して使い方を勉強していこうかな。
ありがとうございます。
>>8を見ながらインストールしてみました。
取り合えずローカルで使う予定なのでコミットまで一通りやってみました。
ローカルで使うならリポジトリの共有以降は不要ですよね(Gitとしての恩赦も薄そうだけど)
皆さんはリモート使って他の人と共同で何かを作ってるんでしょうか？
仕事で使う以外はローカルでも不便しなさそうですが、勉強のため開発と平行して使い方を勉強していこうかな。
43 ：デフォルトの名無しさん：2014/04/16(水) 00:27:33.04 ID:23qQxnbb
リモートリポジトリを使った共同作業が git の本領発揮するとこだから読んでおいたほうがいいと思うけどな
一人で使ってるんだとしても、作業用のローカルリポジトリとリモートの(別にリモートじゃなくてもいいが)マスターリポジトリが分かれてると
push/pull のタイミングでコミット纏めたりとか出来て都合がよかったりするし
自分は githubでプログラム書いたり設定ファイル載せたりしてる
基本的に自分ひとりで書いてるけど誰かが勝手にバグ直してパッチ送ってきてくれたりして楽しいよ
逆に公開されてるソフトなんかで気になる部分を修正してパッチ送ったりとかね
とりあえずアカウントでもとって練習用として色々遊んでみたらいいんじゃない
一人で使ってるんだとしても、作業用のローカルリポジトリとリモートの(別にリモートじゃなくてもいいが)マスターリポジトリが分かれてると
push/pull のタイミングでコミット纏めたりとか出来て都合がよかったりするし
自分は githubでプログラム書いたり設定ファイル載せたりしてる
基本的に自分ひとりで書いてるけど誰かが勝手にバグ直してパッチ送ってきてくれたりして楽しいよ
逆に公開されてるソフトなんかで気になる部分を修正してパッチ送ったりとかね
とりあえずアカウントでもとって練習用として色々遊んでみたらいいんじゃない
44 ：デフォルトの名無しさん：2014/04/16(水) 00:37:04.13 ID:FwnwH35E
>>36
githubフローに近いやり方で開発している。
自分が開発しているブランチがどこから分岐したかとかは一応把握してる。
それでも忘れるけど忘れたらgit log --decorateで確認するだけ。
自分が作業中のブランチはそんなに多数に平行して
開発するわけじゃないので、数個にしかならない。
他人のブランチの状態や過去のブランチは何も考えていない。
知りたくなったら調べるけど、基本的に無監視。
気にしてるのは、masterが更新されたかどうか。
基本的に自分のブランチは「masterの最新からの開発」という形にしたいから
誰かがマージしてmasterが更新されたら、git rebase masterして
masterの最新からの開発に配置し直す。・・・ってのを定期的に行う。
あとは単純にmasterにリベースしづらい時とか、一時的に他の人のコミットを取りたいとか
なんかミスってコミットを整理し直したいとかイレギュラーな作業でcherry-pickを使う程度。
まあ分岐しまくってそれを把握しなきゃってことはまずないよ。過去は忘れて、自分の現在の作業分だけ。
githubフローに近いやり方で開発している。
自分が開発しているブランチがどこから分岐したかとかは一応把握してる。
それでも忘れるけど忘れたらgit log --decorateで確認するだけ。
自分が作業中のブランチはそんなに多数に平行して
開発するわけじゃないので、数個にしかならない。
他人のブランチの状態や過去のブランチは何も考えていない。
知りたくなったら調べるけど、基本的に無監視。
気にしてるのは、masterが更新されたかどうか。
基本的に自分のブランチは「masterの最新からの開発」という形にしたいから
誰かがマージしてmasterが更新されたら、git rebase masterして
masterの最新からの開発に配置し直す。・・・ってのを定期的に行う。
あとは単純にmasterにリベースしづらい時とか、一時的に他の人のコミットを取りたいとか
なんかミスってコミットを整理し直したいとかイレギュラーな作業でcherry-pickを使う程度。
まあ分岐しまくってそれを把握しなきゃってことはまずないよ。過去は忘れて、自分の現在の作業分だけ。
45 ：片山博文MZバグロボ ◆T6xkBnTXz7B0 ：2014/04/16(水) 01:17:21.34 ID:9W1Fzx+3
VS2013でgit使ってるか？
どうやるの？
どうやるの？
46 ：デフォルトの名無しさん：2014/04/16(水) 01:21:41.21 ID:xXOno5ZN
Use Visual Studio with Git
http://msdn.microsoft.com/en-us/library/hh850437.aspx
http://msdn.microsoft.com/en-us/library/hh850437.aspx
47 ：デフォルトの名無しさん：2014/04/16(水) 01:35:45.97 ID:vWpEG2+U
>>36
初心者はgitk --allでビジュアルに状態を確認しながら
雰囲気をつかむと良いと思う。
あと、「開発・バグフィックスはすべてトピックブランチを作って作業する。」
「トピックは原則としてmasterから分岐する」などのルールを設けて、
確認しないといけないこと(分岐元がどこか、とか)を減らす。
統合ブランチは master またはmasterの先端に作った使い捨てブランチだけにして、
マージ状況は log --oneline --first-parentで俯瞰するなど
ワークフローを工夫すれば、正確なコミットグラフをイメージしなくても
だいたいの状況を把握できるようになる。
初心者はgitk --allでビジュアルに状態を確認しながら
雰囲気をつかむと良いと思う。
あと、「開発・バグフィックスはすべてトピックブランチを作って作業する。」
「トピックは原則としてmasterから分岐する」などのルールを設けて、
確認しないといけないこと(分岐元がどこか、とか)を減らす。
統合ブランチは master またはmasterの先端に作った使い捨てブランチだけにして、
マージ状況は log --oneline --first-parentで俯瞰するなど
ワークフローを工夫すれば、正確なコミットグラフをイメージしなくても
だいたいの状況を把握できるようになる。
48 ：デフォルトの名無しさん：2014/04/16(水) 03:11:28.56 ID:EGmRT2AB
たまーに他人のコミットとコンフリクトしまくったりマージのミスでバグが混入したりするから、そういうときにコミットツリーをよく確認したいときは、
SourceTreeとかGitHub/BitBucketとかのサービスで詳細に把握しようと思うことはあるかな。大抵はそこまで把握しなくてもトラブらないけど。
SourceTreeとかGitHub/BitBucketとかのサービスで詳細に把握しようと思うことはあるかな。大抵はそこまで把握しなくてもトラブらないけど。
49 ：デフォルトの名無しさん：2014/04/16(水) 03:16:00.58 ID:FwnwH35E
それってツリー見てなにかわかるん？
50 ：デフォルトの名無しさん：2014/04/16(水) 03:22:23.47 ID:LjaPwUAW
というよりbisectだよね
51 ：デフォルトの名無しさん：2014/04/16(水) 03:24:09.57 ID:O1uBrWmJ
自動ビルドテストしようず
GitHubでプルリクエストすればマージ前でも自動テストしてくれるみたいだからリモート環境だけでテストできるんじゃないの
やったことないしどうせ自動化のテストはローカルでしなきゃならんけど
GitHubでプルリクエストすればマージ前でも自動テストしてくれるみたいだからリモート環境だけでテストできるんじゃないの
やったことないしどうせ自動化のテストはローカルでしなきゃならんけど
52 ：デフォルトの名無しさん：2014/04/16(水) 03:40:07.18 ID:FwnwH35E
そういやbisectで思い出したけど、
テストコードをしっかり書いているとする。
バグが何処かで混入されたとして、
それを見逃したということはテストコードがなかったということになる。
そこで新たにテストコードを追加する。
さて、このテストコードを使って、どこでバグが混入されたかを
bisectで調べるにはどうしたらいいだろう？
git bisectをするたびにコミットが変わるのはいいんだが、
そのコミットには当然追加されたテストコードは含まれていない。
やばい、酒ははいってて、何を書いているのかわからないｗｗｗｗ
テストコードをしっかり書いているとする。
バグが何処かで混入されたとして、
それを見逃したということはテストコードがなかったということになる。
そこで新たにテストコードを追加する。
さて、このテストコードを使って、どこでバグが混入されたかを
bisectで調べるにはどうしたらいいだろう？
git bisectをするたびにコミットが変わるのはいいんだが、
そのコミットには当然追加されたテストコードは含まれていない。
やばい、酒ははいってて、何を書いているのかわからないｗｗｗｗ
53 ：デフォルトの名無しさん：2014/04/16(水) 03:40:53.57 ID:FwnwH35E
おーい、ちゃんと文章なりたってるかー？ｗ
54 ：デフォルトの名無しさん：2014/04/16(水) 03:49:55.54 ID:EGmRT2AB
>>49
上手いこと説明できないが、ツリーがないよりあったほうがマージのやり直しはしやすい気がする。たぶん自分が関わってるプロジェクトの特性上のものだと思う。
まあ、ツリーだけってよりは1個1個コミットを見ていってそのローカルブランチではなにをするつもりだったのかとかを解釈していくという方が重要なのだろうけど。
>>51
インタラクティブなアプリだと自動でのビルドテストがかなり難しいんだよね。
OpenGLとかメディア系ライブラリと各種センサを使ったアプリとかだと、描画が想定通り行われてるかとか、ムービーが正しく再生されてるかとか、
センサの値が正しく反映されてるかとか、そういうものをテストコード書くのが難しすぎる、というか結局人間が解釈しないとOKかNGか判断できないものが
多すぎてTDDしづらいんだよね。ゲームとか典型例なんじゃないかな？
上手いこと説明できないが、ツリーがないよりあったほうがマージのやり直しはしやすい気がする。たぶん自分が関わってるプロジェクトの特性上のものだと思う。
まあ、ツリーだけってよりは1個1個コミットを見ていってそのローカルブランチではなにをするつもりだったのかとかを解釈していくという方が重要なのだろうけど。
>>51
インタラクティブなアプリだと自動でのビルドテストがかなり難しいんだよね。
OpenGLとかメディア系ライブラリと各種センサを使ったアプリとかだと、描画が想定通り行われてるかとか、ムービーが正しく再生されてるかとか、
センサの値が正しく反映されてるかとか、そういうものをテストコード書くのが難しすぎる、というか結局人間が解釈しないとOKかNGか判断できないものが
多すぎてTDDしづらいんだよね。ゲームとか典型例なんじゃないかな？
55 ：デフォルトの名無しさん：2014/04/16(水) 04:03:18.65 ID:O1uBrWmJ
56 ：デフォルトの名無しさん：2014/04/16(水) 12:51:47.35 ID:LjaPwUAW
57 ：デフォルトの名無しさん：2014/04/16(水) 14:21:34.93 ID:zACk8w4U
漏れはソースを他人に見せたくて仕方がない
露出狂鴨試練
露出狂鴨試練
58 ：デフォルトの名無しさん：2014/04/16(水) 21:49:07.29 ID:SSurM9Qy
git statusをgit sだったりgsにエイリアスを設定して短くするやり方ありますよね
これgitの開発人たちに公認公式のエイリアスの設定方法って公開してませんかね？
これgitの開発人たちに公認公式のエイリアスの設定方法って公開してませんかね？
59 ：デフォルトの名無しさん：2014/04/16(水) 21:52:45.78 ID:23qQxnbb
alias の設定の「仕方」なら公認公式もへったくれもなく今やってる方法が公式だろうと思うが
大抵の人が設定してるであろう、一般的な alias の一覧みたいなのないかってことかね
大抵の人が設定してるであろう、一般的な alias の一覧みたいなのないかってことかね
60 ：デフォルトの名無しさん：2014/04/16(水) 22:13:23.97 ID:QCJjs0GG
git config alias.変更表示 diff
こんなのがあったところで使うかよｗ
そんなの自分の自由
こんなのがあったところで使うかよｗ
そんなの自分の自由
61 ：デフォルトの名無しさん：2014/04/16(水) 22:59:29.71 ID:HsjrRpyw
shellのalias使えば良いだけじゃね？
62 ：デフォルトの名無しさん：2014/04/16(水) 23:18:22.32 ID:YDFUIFCV
git sとか一意に出来るところまであれば自動で補完して実行する機能をオンオフ出来れば良さそう
63 ：デフォルトの名無しさん：2014/04/17(木) 03:15:07.74 ID:KNGPRiph
64 ：デフォルトの名無しさん：2014/04/17(木) 03:18:41.09 ID:KNGPRiph
65 ：デフォルトの名無しさん：2014/04/17(木) 13:12:49.12 ID:ns8t/lZO
設定してあるエイリアス晒してみる
st = status
ci = commit
co = checkout
br = branch
dif = diff
difc = diff --cached
lo = log --oneline
lf = log --first-parent
lof = log --oneline --first-parent
st = status
ci = commit
co = checkout
br = branch
dif = diff
difc = diff --cached
lo = log --oneline
lf = log --first-parent
lof = log --oneline --first-parent
66 ：デフォルトの名無しさん：2014/04/17(木) 13:45:04.02 ID:aPfzsLri
statusはsだろうが
commitはcだろうが
きめえよ
commitはcだろうが
きめえよ
67 ：デフォルトの名無しさん：2014/04/17(木) 14:05:07.53 ID:vWEx34Yo
一番良く使うstatusとかlogはシェル関数で置き換えちゃってるな
gst = git status -s -b
glo = git log --graph --branches --remotes --pretty=format:'%C(black white)%h%Creset%C(blue bold)%d%Creset %s'
gst = git status -s -b
glo = git log --graph --branches --remotes --pretty=format:'%C(black white)%h%Creset%C(blue bold)%d%Creset %s'
68 ：デフォルトの名無しさん：2014/04/17(木) 16:24:56.84 ID:xYf1zYlh
>br = branch
わかる
>dif = diff
まぁ、わかる
>ci = commit
どういうことなの
せめてcmでしょ
わかる
>dif = diff
まぁ、わかる
>ci = commit
どういうことなの
せめてcmでしょ
69 ：デフォルトの名無しさん：2014/04/17(木) 16:47:58.48 ID:ns8t/lZO
>>68
俺はかつてCVSユーザだったんだが、
CVSのcommitはciというエイリアスを持ってたんだよ。
SVNもciはcommitのエイリアスになってるだろ？
といってもそもそも何でCVSのcommitがciなんだよ？って話だよな。
CVSは当初、その前に流行した単一ファイルバージョン管理用RCSにかぶせてつかう
ディレクトリツリー管理拡張のためのラッパースクリプトとして登場した。
RCSのコミットに相当する操作はcheck inと呼ばれ、コマンドはciだった。
CVS, SVNはそれを継承してるというわけだ。
現在でも主要なディストロはだいたいRCSのパッケージを持ってて、
インストールすればciコマンドを使えるぞ。
ちなみにRCSのcheckoutは当然coだから使い方はmanを見てくれ。
俺はかつてCVSユーザだったんだが、
CVSのcommitはciというエイリアスを持ってたんだよ。
SVNもciはcommitのエイリアスになってるだろ？
といってもそもそも何でCVSのcommitがciなんだよ？って話だよな。
CVSは当初、その前に流行した単一ファイルバージョン管理用RCSにかぶせてつかう
ディレクトリツリー管理拡張のためのラッパースクリプトとして登場した。
RCSのコミットに相当する操作はcheck inと呼ばれ、コマンドはciだった。
CVS, SVNはそれを継承してるというわけだ。
現在でも主要なディストロはだいたいRCSのパッケージを持ってて、
インストールすればciコマンドを使えるぞ。
ちなみにRCSのcheckoutは当然coだから使い方はmanを見てくれ。
70 ：デフォルトの名無しさん：2014/04/17(木) 17:02:55.46 ID:x5+myCPx
ci co は結構多いと思うぞ。
過去の VC の流れで。
過去の VC の流れで。
71 ：デフォルトの名無しさん：2014/04/17(木) 17:04:57.52 ID:7VV2HzZ+
checkinの略だったよね？
72 ：デフォルトの名無しさん：2014/04/17(木) 17:32:10.40 ID:x5+myCPx
github で gitconfig alias で検索すると結構色々でてきて面白いな
https://github.com/search?l=ini&q=gitconfig+alias&ref=searchresults&type=Code
わりとみんな同じ感じなんだねえ
https://github.com/search?l=ini&q=gitconfig+alias&ref=searchresults&type=Code
わりとみんな同じ感じなんだねえ
73 ：デフォルトの名無しさん：2014/04/17(木) 17:33:57.98 ID:xYf1zYlh
そうなんか、知らんかった
調べたらmercurialもciなんだな
調べたらmercurialもciなんだな
74 ：デフォルトの名無しさん：2014/04/17(木) 17:38:39.61 ID:Fx1ijgIa
branchはbだろうが
diffはdだ！
diffはdだ！
75 ：デフォルトの名無しさん：2014/04/17(木) 17:44:29.46 ID:x5+myCPx
一文字だと不安(?)なのか二文字が多いなgithubだと
76 ：デフォルトの名無しさん：2014/04/17(木) 18:39:15.48 ID:ns8t/lZO
2文字派か1文字派か。主要コマンドは比較的統一してる人多いね
77 ：デフォルトの名無しさん：2014/04/17(木) 18:50:05.36 ID:gzIoS/KQ
ｃがかぶりやすいからだなｗ
78 ：デフォルトの名無しさん：2014/04/17(木) 18:52:52.00 ID:zmGYf3iT
おれはねエイリアスでgit revertをecho ""に設定している
危ないコマンドや初心者が過去を隠すために使うようなコマンドをあえて禁止している
危ないコマンドや初心者が過去を隠すために使うようなコマンドをあえて禁止している
79 ：デフォルトの名無しさん：2014/04/17(木) 18:56:43.52 ID:vWEx34Yo
git revertは危なくもないし過去を隠すコマンドでもないだろ
80 ：デフォルトの名無しさん：2014/04/17(木) 20:34:51.97 ID:ns8t/lZO
むしろイケてない過去のコミットを無かったことにできるのがgitの利点かと思うが
81 ：デフォルトの名無しさん：2014/04/17(木) 21:44:17.51 ID:XZy5mn+7
revertを禁止にするならresetも禁止にするべき
前進あるのみ
前進あるのみ
82 ：デフォルトの名無しさん：2014/04/17(木) 21:47:12.93 ID:KNGPRiph
え？ エイリアスの話？
俺は、
bisect bad に bisect-fixed を
bisect good に bisect-unfixed を
割り当ててる。
便利だよ。
俺は、
bisect bad に bisect-fixed を
bisect good に bisect-unfixed を
割り当ててる。
便利だよ。
83 ：デフォルトの名無しさん：2014/04/17(木) 22:05:50.07 ID:i6eMI8h0
晒してみる。省略形は多用するとクセになるから避けてるなぁ
[alias]
serve = daemon --reuseaddr --base-path=. --export-all --verbose
stat = status --short --branch
exec = "!exec "
[alias]
serve = daemon --reuseaddr --base-path=. --export-all --verbose
stat = status --short --branch
exec = "!exec "
84 ：デフォルトの名無しさん：2014/04/17(木) 22:10:52.86 ID:u3XqYAfL
>>36ですが皆さん（>>38-40 >>44 >>47 >>48）アドバイスをどうもありがとうございます。
いやーgitをよく知らないままgitで大勢でメンテしているプロジェクトに送り込まれて
しまいまして。
とりあえずgitkとかで表示してみました... うわっ、平行な線が沢山走っている部分が!
なんか宇宙戦艦ヤマトのワープの図を複雑にしたような（たとえが古いか）
線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
いやーgitをよく知らないままgitで大勢でメンテしているプロジェクトに送り込まれて
しまいまして。
とりあえずgitkとかで表示してみました... うわっ、平行な線が沢山走っている部分が!
なんか宇宙戦艦ヤマトのワープの図を複雑にしたような（たとえが古いか）
線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
85 ：デフォルトの名無しさん：2014/04/17(木) 22:23:16.22 ID:KNGPRiph
開発する人数やワークフローにもよるけど、平行な線は
沢山あるべきじゃないよ。マージしづらくなるからね。
沢山あるべきじゃないよ。マージしづらくなるからね。
86 ：デフォルトの名無しさん：2014/04/18(金) 02:04:45.06 ID:G95hrNw/
87 ：デフォルトの名無しさん：2014/04/18(金) 10:26:06.59 ID:TiuM1iK+
初心者ですけどリポジトリを作ったフォルダの中が管理対象になるんですよね？
でそのリポジトリを削除するとソースファイルまで削除されるんですが
もちろんブックマークだけ（sourcetreeで)の削除はできるのですが
間違ってハードディスク上のリポジトリを削除してしまったら大変です。
何か対策はあるのでしょうか？それともこういうものなのでしょうか
でそのリポジトリを削除するとソースファイルまで削除されるんですが
もちろんブックマークだけ（sourcetreeで)の削除はできるのですが
間違ってハードディスク上のリポジトリを削除してしまったら大変です。
何か対策はあるのでしょうか？それともこういうものなのでしょうか
88 ：デフォルトの名無しさん：2014/04/18(金) 10:28:30.25 ID:V7HQhmWQ
そりゃそうだろう
リモートにあろうがローカルにしかなかろうがリポジトリ物理的に消したらなくなるわな
大事ならバックアップとっといたらいい
リモートにあろうがローカルにしかなかろうがリポジトリ物理的に消したらなくなるわな
大事ならバックアップとっといたらいい
89 ：デフォルトの名無しさん：2014/04/18(金) 10:30:51.17 ID:l4m/ooPn
bitbucketあたりにアカウントとってそっちにプッシュしておくとか
90 ：デフォルトの名無しさん：2014/04/18(金) 10:51:55.78 ID:TiuM1iK+
ローカルのみで使おうと思ってたのですがリモートにも上げた方がよさそうですね
91 ：デフォルトの名無しさん：2014/04/18(金) 11:00:45.77 ID:KSddQ8SJ
Dropboxにリポジトリを作るやり方はここの先輩方はやってますか？
92 ：デフォルトの名無しさん：2014/04/18(金) 11:01:59.07 ID:V7HQhmWQ
>>41にそういう奴がいるな
93 ：デフォルトの名無しさん：2014/04/19(土) 12:55:58.24 ID:7PgX0mPg
>>84
gitkはgit log(というかgit rev-list)と同じ範囲指定が可能だから、
--allで表示が多すぎるなら表示範囲を適切に限定してやればよい。
特定のtopic(ここではmasterから分岐したとする)とmasterにだけ注目すればいいんなら
gitk master..topic (masterから分岐後のtopicのコミットのみ表示)
gitk master...topic (masterから分岐後のtopicのコミットとmasterにマージされたブランチを表示)
とか。範囲指定は複数回可能なので関係する範囲を好きなだけ指定すればよい。
gitkはgit log(というかgit rev-list)と同じ範囲指定が可能だから、
--allで表示が多すぎるなら表示範囲を適切に限定してやればよい。
特定のtopic(ここではmasterから分岐したとする)とmasterにだけ注目すればいいんなら
gitk master..topic (masterから分岐後のtopicのコミットのみ表示)
gitk master...topic (masterから分岐後のtopicのコミットとmasterにマージされたブランチを表示)
とか。範囲指定は複数回可能なので関係する範囲を好きなだけ指定すればよい。
94 ：デフォルトの名無しさん：2014/04/20(日) 20:26:37.01 ID:mILxVbg/
>>91
.zshrcとか.vimrcとかをつっこんだリポジトリはDropboxにbareで載せてる。
.zshrcとか.vimrcとかをつっこんだリポジトリはDropboxにbareで載せてる。
95 ：デフォルトの名無しさん：2014/04/21(月) 13:00:54.05 ID:ZKyIOHr8
gitignoreで
/*
/.*
このふたつを指定しているのをたまに見かけますが
はじめに/*ですべてのファイルを除外しているので/.*を書く意味は無いと思うんですが何故書くのですか？
/*
/.*
このふたつを指定しているのをたまに見かけますが
はじめに/*ですべてのファイルを除外しているので/.*を書く意味は無いと思うんですが何故書くのですか？
96 ：デフォルトの名無しさん：2014/04/21(月) 14:22:29.42 ID:dtgq5rdV
ドットで始まるファイルは * のワイルドカードにひっかからない仕様になってる。
シェル由来だね。
シェル由来だね。
97 ：デフォルトの名無しさん：2014/04/21(月) 16:06:02.61 ID:mYIG7FH4
なにそれバグだろ
クソだなgitって
クソだなgitって
98 ：デフォルトの名無しさん：2014/04/21(月) 20:57:12.01 ID:1sDt+ic8
無知発見
99 ：デフォルトの名無しさん：2014/04/21(月) 21:13:29.40 ID:fKV6ATCG
餌を与えないでください
100 ：デフォルトの名無しさん：2014/04/21(月) 21:48:05.88 ID:yaM3rCK5
gitは糞だからsubversionを使え
101 ：デフォルトの名無しさん：2014/04/21(月) 22:43:41.18 ID:KhXBvEFh
やだGitじゃないと
VSS、これ最悪でした。
チェックアウトされたままコンパイル通らない状態で担当者休み。どーすんの？
でもMSじゃないと駄目、OSSなんか信用できないとかで泣く泣く使う現場多数。
それに比べるとSubVersionかなりマシだけどオフラインな状態でコミットできない。
ちょっと痛い。
VSS、これ最悪でした。
チェックアウトされたままコンパイル通らない状態で担当者休み。どーすんの？
でもMSじゃないと駄目、OSSなんか信用できないとかで泣く泣く使う現場多数。
それに比べるとSubVersionかなりマシだけどオフラインな状態でコミットできない。
ちょっと痛い。
102 ：デフォルトの名無しさん：2014/04/21(月) 23:08:04.07 ID:/9iyZBJ2
バージョン管理はgitしか使ったことがない
SVNは何がなんやらサッパリわからないから使えない
SVNは何がなんやらサッパリわからないから使えない
103 ：デフォルトの名無しさん：2014/04/21(月) 23:28:39.44 ID:wk0llTNx
104 ：デフォルトの名無しさん：2014/04/21(月) 23:37:15.06 ID:vVBjDa2G
オフラインの状態でコミットできないとか言ってるけど
コミットしたところでローカルにあるだけだからオンラインで他の奴がお前のリポジトリに
アクセスできなきゃ何もかわらんだろアホか
コミットしたところでローカルにあるだけだからオンラインで他の奴がお前のリポジトリに
アクセスできなきゃ何もかわらんだろアホか
105 ：デフォルトの名無しさん：2014/04/21(月) 23:51:33.94 ID:KhXBvEFh
例えばあなたが飛行機で移動中に１０項目ぐらいの作業して
帰社してコミットする時にコメントに１０項目だらだら書くの？
やーだー
帰社してコミットする時にコメントに１０項目だらだら書くの？
やーだー
106 ：デフォルトの名無しさん：2014/04/22(火) 00:01:10.97 ID:4JSOLbvH
移動中に仕事するようなワーカホリックになりたくないわ正直
107 ：デフォルトの名無しさん：2014/04/22(火) 00:05:36.52 ID:DheOpfOv
一例として挙げただけなのに。想像力無いなあ。
108 ：デフォルトの名無しさん：2014/04/22(火) 00:32:53.01 ID:ysn+k/fU
セキュリティ的なこと考えるとオフラインでソースにアクセスってあんまりないんだよね
109 ：デフォルトの名無しさん：2014/04/22(火) 00:48:34.17 ID:9W1A4/eN
>>97
いわゆるシェルは.(ドット)で始まるファイルは隠しファイルとしている
隠しファイルは ls *.conf とかで表示されない (.hoge.conf とか)
そんな時に rm *.conf して普段表示されてないファイルが消えるのは困る
だから * だけでは隠しファイルにマッチしないようになっている
ちなみに git が内部でどう処理してんのかは知らん
いわゆるシェルは.(ドット)で始まるファイルは隠しファイルとしている
隠しファイルは ls *.conf とかで表示されない (.hoge.conf とか)
そんな時に rm *.conf して普段表示されてないファイルが消えるのは困る
だから * だけでは隠しファイルにマッチしないようになっている
ちなみに git が内部でどう処理してんのかは知らん
110 ：デフォルトの名無しさん：2014/04/22(火) 13:52:48.51 ID:+yEK9mtt
ふつーにfnmatchでは
111 ：デフォルトの名無しさん：2014/04/23(水) 05:15:19.40 ID:7ZWtOh9Z
commit A
commit B
commit C
commit D
commit E
commit F
と順番に作業して
あとから B から D をまとめて
commit A
commit b(B-D)
commit E
commit F
としたいときはどうすれば・・・
commit B
commit C
commit D
commit E
commit F
と順番に作業して
あとから B から D をまとめて
commit A
commit b(B-D)
commit E
commit F
としたいときはどうすれば・・・
112 ：デフォルトの名無しさん：2014/04/23(水) 05:24:18.61 ID:kDpoyMyg
よう知らんけど
↓のsquashというやつで出来るんじゃないの？
Git - 歴史の書き換え
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88#コミットのまとめ
> # s, squash = use commit, but meld into previous commit
↓のsquashというやつで出来るんじゃないの？
Git - 歴史の書き換え
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88#コミットのまとめ
> # s, squash = use commit, but meld into previous commit
113 ：デフォルトの名無しさん：2014/04/23(水) 07:20:48.07 ID:fIp3qZsI
>>111
rebase -i
rebase -i
114 ：デフォルトの名無しさん：2014/04/23(水) 09:40:59.20 ID:T4x0zu0j
２．０って来月でる？
115 ：デフォルトの名無しさん：2014/04/23(水) 20:35:59.48 ID:7vo5B08Z
116 ：デフォルトの名無しさん：2014/04/23(水) 22:04:37.40 ID:59LgjvrD
rebase -i はいろいろ便利だよな
ただ慣れないと指定にちょっと戸惑う
>>111みたいにB以下をいじりたい場合だと rebase -i A ってしなくちゃいけないんだよな
それと、まとめたり順番入れ替えるだけなら操作は簡単だけど、バラす場合はちょっと操作がややこしい
ただ慣れないと指定にちょっと戸惑う
>>111みたいにB以下をいじりたい場合だと rebase -i A ってしなくちゃいけないんだよな
それと、まとめたり順番入れ替えるだけなら操作は簡単だけど、バラす場合はちょっと操作がややこしい
117 ：デフォルトの名無しさん：2014/04/24(木) 00:12:45.07 ID:6IEmJN8m
git rebase -i のコミットの表示順とgit logの表示順が逆なのは何故なんだぜ？
逆に表示するオプションあるけどグラフ表示とは併用できませんし。
逆に表示するオプションあるけどグラフ表示とは併用できませんし。
118 ：デフォルトの名無しさん：2014/04/24(木) 01:22:42.87 ID:cdLHxk0K
logは新しい順に表示しないと不便だと思うし(見たいのは最新の辺のことが多いよね)
rebase -iの指示書は、前のコミットにまとめるとかの指定することを考えると古い順に並んでたほうがわかり易い気がする
まあ、自分は慣れてしまったからかもしれないが
rebase -iの指示書は、前のコミットにまとめるとかの指定することを考えると古い順に並んでたほうがわかり易い気がする
まあ、自分は慣れてしまったからかもしれないが
119 ：デフォルトの名無しさん：2014/04/24(木) 01:29:19.68 ID:SDYiDObT
>>116
rebase -i B^
rebase -i B^
120 ：デフォルトの名無しさん：2014/04/24(木) 05:27:42.49 ID:6xlhO1bi
rebase -i ^_^b
121 ：デフォルトの名無しさん：2014/04/24(木) 13:18:49.88 ID:QakcezKL
最新のコミットだけプッシュする方法と
最新のタグをつけたコミットだけプッシュする方法
２つおしえてください
最新のタグをつけたコミットだけプッシュする方法
２つおしえてください
122 ：デフォルトの名無しさん：2014/04/24(木) 13:19:34.50 ID:QakcezKL
なぜかというとコミットログからニートがバレるのでコミットログを全部プッシュしたくないからです
123 ：デフォルトの名無しさん：2014/04/24(木) 13:22:26.51 ID:V8z90YIW
>>121
sqush
sqush
124 ：デフォルトの名無しさん：2014/04/24(木) 13:47:51.32 ID:JOpp0cve
githubのコミットログからニートを検索するツールはよ
125 ：デフォルトの名無しさん：2014/04/24(木) 19:02:31.15 ID:yOTIc0ZO
その前に日本人を探すツールが必要だ
126 ：デフォルトの名無しさん：2014/04/24(木) 21:18:41.68 ID:hPYav21o
>>122
git filter-branch --env-filter 'GIT_COMMITTER_DATE="Thu, 01 Jan 1970 09:00:00 +0900
"; GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE' --all
git filter-branch --env-filter 'GIT_COMMITTER_DATE="Thu, 01 Jan 1970 09:00:00 +0900
"; GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE' --all
127 ：デフォルトの名無しさん：2014/04/24(木) 22:02:19.45 ID:6xlhO1bi
コミットログに日時変えればいいだけじゃん。
128 ：デフォルトの名無しさん：2014/04/24(木) 22:18:20.71 ID:0H30XzcZ
git init
git checkout -b test
>Switched to a new branch 'test'
git branch
>何も表示されない
git checkout test
>error: pathspec 'test' did not match any file(s) known to git.
なんもコミットされてないとこうなるんですがどうしてこうなるんですか？
git checkout -b test
>Switched to a new branch 'test'
git branch
>何も表示されない
git checkout test
>error: pathspec 'test' did not match any file(s) known to git.
なんもコミットされてないとこうなるんですがどうしてこうなるんですか？
129 ：デフォルトの名無しさん：2014/04/24(木) 22:21:42.53 ID:hPYav21o
>>128
その状態だと、HEADはrefs/heads/test向けのsymbolic-refになっているが、
そもそも指すべきコミットがないのでrefs/heads/testは存在しない。
よってbranchも何も表示しないし、checkoutもできない。
その状態だと、HEADはrefs/heads/test向けのsymbolic-refになっているが、
そもそも指すべきコミットがないのでrefs/heads/testは存在しない。
よってbranchも何も表示しないし、checkoutもできない。
130 ：デフォルトの名無しさん：2014/04/24(木) 22:23:42.17 ID:0H30XzcZ
仕様なんですか
一番最初のコミットが汚れるのがいやですね
一番最初のコミットが汚れるのがいやですね
131 ：デフォルトの名無しさん：2014/04/24(木) 22:25:13.61 ID:6xlhO1bi
rebaseすればいいじゃんｗ
俺は、とりあえず空コミットを作る。
かもしれないし、作らないかもしれない。
俺は、とりあえず空コミットを作る。
かもしれないし、作らないかもしれない。
132 ：デフォルトの名無しさん：2014/04/24(木) 22:26:57.87 ID:hPYav21o
>>130
つまりコミット無し状態でブランチを複数作りたいということ？
つまりコミット無し状態でブランチを複数作りたいということ？
133 ：デフォルトの名無しさん：2014/04/24(木) 22:31:15.84 ID:0H30XzcZ
漢がrebaseなんて許せないタチなんですよ
コミットなし状態からブランチを分けて開発したいんです
基本的にmasterは汚したくないのです
コミットなし状態からブランチを分けて開発したいんです
基本的にmasterは汚したくないのです
134 ：デフォルトの名無しさん：2014/04/24(木) 22:33:01.48 ID:6xlhO1bi
subversionがだめな理由が
rebaseできないからなんだけど？
それぐらい、というかそれ以上に
よく使う機能だぞ。
汚くしないためにrebaseがある。
rebaseできないからなんだけど？
それぐらい、というかそれ以上に
よく使う機能だぞ。
汚くしないためにrebaseがある。
135 ：デフォルトの名無しさん：2014/04/24(木) 22:37:44.72 ID:hPYav21o
>>133
129で言ったようにHEADが存在しないrefを参照していればgit initした状態と同じなのだから、
二個目のブランチを作るときにgit checkout -bではなく
git symbolic-ref HEAD refs/heads/branch_name してから開発を進めればいいじゃない
129で言ったようにHEADが存在しないrefを参照していればgit initした状態と同じなのだから、
二個目のブランチを作るときにgit checkout -bではなく
git symbolic-ref HEAD refs/heads/branch_name してから開発を進めればいいじゃない
136 ：デフォルトの名無しさん：2014/04/24(木) 23:47:09.80 ID:T/Y/fuz3
>>133
そこまで潔癖ならマージもしないだろうからブランチじゃなくてリポジトリを分けたら？
そこまで潔癖ならマージもしないだろうからブランチじゃなくてリポジトリを分けたら？
137 ：デフォルトの名無しさん：2014/04/25(金) 00:27:14.58 ID:kupFdBxu
master汚したくないっていうのが出来たとして、
1つ目のcommitがあって、それがtestブランチだとする。
が、masterはこのcommitから辿れる親コミットも指してないし、どれも指していない。
fast forward mergeできない状態だけどいいの？
どうせmasterはなにかしらコミットした段階で一番汚されてなくたってそのコミットを指してしまうのだから、コミットしてからチェックアウトしてもいいじゃん。
1つ目のcommitがあって、それがtestブランチだとする。
が、masterはこのcommitから辿れる親コミットも指してないし、どれも指していない。
fast forward mergeできない状態だけどいいの？
どうせmasterはなにかしらコミットした段階で一番汚されてなくたってそのコミットを指してしまうのだから、コミットしてからチェックアウトしてもいいじゃん。
138 ：デフォルトの名無しさん：2014/04/25(金) 03:08:01.24 ID:XQM8U6nM
mergeする予定無いのにブランチ切りたいとか意味不明すぎる
139 ：デフォルトの名無しさん：2014/04/25(金) 04:07:01.58 ID:zu0sgmwa
空コミットじゃあかんのか？
つか空の.gitignoreくらい作ってからでも汚れとは思わんぞ
つか空の.gitignoreくらい作ってからでも汚れとは思わんぞ
140 ：デフォルトの名無しさん：2014/04/25(金) 04:20:32.33 ID:jzYptMLV
気に入らない部分があってもgitを使わざるをえない人は大変だね
個人の趣味でやってるならVCSは好きなのを使えるのにね
個人の趣味でやってるならVCSは好きなのを使えるのにね
141 ：デフォルトの名無しさん：2014/04/25(金) 04:23:50.66 ID:4klH39dY
気に入らない部分が、git以外には多すぎる。
142 ：デフォルトの名無しさん：2014/04/25(金) 05:28:33.42 ID:cdj1D6xv
だねー
俺はローカル全部svnだわ
俺はローカル全部svnだわ
143 ：デフォルトの名無しさん：2014/04/25(金) 08:52:14.28 ID:xiFjVo8G
３つ前のコミットに戻ってブランチを分岐したい場合ってどうすればいいのでしょうか
３つ前に巻き戻してからブランチするのでしょうか
最後の２つのコミットも念のために残したいのでブランチにしたいのです
具体的には
最後の２つのコミットの変更が破棄になったけど
念のために残したい
という状況です
３つ前に巻き戻してからブランチするのでしょうか
最後の２つのコミットも念のために残したいのでブランチにしたいのです
具体的には
最後の２つのコミットの変更が破棄になったけど
念のために残したい
という状況です
144 ：デフォルトの名無しさん：2014/04/25(金) 11:14:49.10 ID:4klH39dY
三つ前のコミットIDから
ブランチ作ればいいじゃん。
ブランチ作ればいいじゃん。
145 ：デフォルトの名無しさん：2014/04/26(土) 02:05:43.27 ID:pkQNyj+N
146 ：デフォルトの名無しさん：2014/04/26(土) 02:08:06.72 ID:/GEUo84h
なんでブランチ取り込む時にontoなんだ？
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。
147 ：デフォルトの名無しさん：2014/04/26(土) 02:26:05.50 ID:pkQNyj+N
やり方がわるいんかな？
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。
148 ：デフォルトの名無しさん：2014/04/26(土) 02:39:25.28 ID:7YL+swb1
>>147
だからなんでFFにするんだよ
だからなんでFFにするんだよ
149 ：デフォルトの名無しさん：2014/04/26(土) 02:41:39.49 ID:/GEUo84h
onto使ったら必ずほぼ確実にFFできないだろ？
なんか無駄に複雑なことしている気がするな。
なんか無駄に複雑なことしている気がするな。
150 ：デフォルトの名無しさん：2014/04/26(土) 13:53:59.32 ID:Vv5x70uz
ホームディレクトリ以下の設定ファイルだとか、個人で使ってる自作ツールはSubversionで管理してる
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい
151 ：デフォルトの名無しさん：2014/04/26(土) 13:58:18.76 ID:/GEUo84h
152 ：デフォルトの名無しさん：2014/04/26(土) 14:05:48.63 ID:Z8XCebgD
?
153 ：デフォルトの名無しさん：2014/04/26(土) 14:20:33.69 ID:dMJ+hsKf
>>151
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。
154 ：デフォルトの名無しさん：2014/04/26(土) 14:56:15.48 ID:1yS20LQ1
リポジトリを1つだけだとさ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ
155 ：デフォルトの名無しさん：2014/04/26(土) 15:03:43.34 ID:/GEUo84h
なぜリポジトリを一つにまとめるのか？
リポジトリを作るのが面倒であるということである。
リポジトリを作るのが面倒であるということである。
156 ：デフォルトの名無しさん：2014/04/26(土) 18:03:12.98 ID:Vv5x70uz
リポジトリをたくさん作るとその数だけcheckoutしてpull/updateしてcommitしないといけない
自分一人で使うだけでそんな面倒なことしない
自分一人で使うだけでそんな面倒なことしない
157 ：デフォルトの名無しさん：2014/04/26(土) 18:26:46.44 ID:ztOmzoR+
subversionだと、このようにpullやupdateや
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。
gitだと気軽なのにね。
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。
gitだと気軽なのにね。
158 ：デフォルトの名無しさん：2014/04/26(土) 18:27:44.99 ID:bHDNIx6I
cvs使ってた10年以上前は、私もひとつのリポジトリでやってたことがありました。(*ﾉωﾉ)
159 ：デフォルトの名無しさん：2014/04/26(土) 18:30:43.24 ID:Vv5x70uz
一人でしか使わないんだからコンフリクトなんかしない
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰
160 ：デフォルトの名無しさん：2014/04/26(土) 18:39:48.80 ID:ztOmzoR+
>>159
コンフリクトかどうかは
重要じゃないよ。
gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。
追加漏れのファイルを追加
スペルミスの修正
こんなマヌケなコミットを残さないで済む。
コンフリクトかどうかは
重要じゃないよ。
gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。
追加漏れのファイルを追加
スペルミスの修正
こんなマヌケなコミットを残さないで済む。
161 ：デフォルトの名無しさん：2014/04/26(土) 18:42:46.95 ID:ztOmzoR+
subversionが残すのは"作業"履歴なんだろうね。
gitが残すとのは"修正"履歴
だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。
gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。
subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。
gitが残すとのは"修正"履歴
だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。
gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。
subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。
162 ：デフォルトの名無しさん：2014/04/26(土) 18:47:04.31 ID:ztOmzoR+
subversionだと作業履歴が残っちゃうから
ちょっと気軽にコミットしようということができない。
gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが
subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。
ちょっと気軽にコミットしようということができない。
gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが
subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。
163 ：デフォルトの名無しさん：2014/04/26(土) 18:56:37.43 ID:Vv5x70uz
.bashrcや.inputrcが数千行になったらgitの導入を考える
164 ：デフォルトの名無しさん：2014/04/26(土) 18:57:44.05 ID:ztOmzoR+
HAHAHAHA、基準がおかしい奴がいる。
こういう奴がgitに反対しているわけさ。
こういう奴がgitに反対しているわけさ。
165 ：デフォルトの名無しさん：2014/04/26(土) 19:04:14.03 ID:a+LUSt4b
bareめんどくない?
166 ：デフォルトの名無しさん：2014/04/26(土) 19:10:57.12 ID:Vv5x70uz
だいたい.screenrcに対する特定のコミットを取り消すとか、そんな必要性感じたこと一度もない
167 ：デフォルトの名無しさん：2014/04/26(土) 19:12:42.80 ID:ztOmzoR+
面倒くさいなら作らなくていいよ。
bareは必須ではない。
gitを始めるのに必要なのはディレクトリで
git initするだけ。
これでもうすぐにブランチ切り替えも
タグの作成もできる。
某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。
bareは必須ではない。
gitを始めるのに必要なのはディレクトリで
git initするだけ。
これでもうすぐにブランチ切り替えも
タグの作成もできる。
某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。
168 ：デフォルトの名無しさん：2014/04/26(土) 19:13:48.14 ID:ztOmzoR+
169 ：デフォルトの名無しさん：2014/04/26(土) 19:17:57.35 ID:Vv5x70uz
いや、何の事かわからないが、subversionでもgitでもどういうブランチ構成にするかはその人次第だから
170 ：デフォルトの名無しさん：2014/04/26(土) 19:22:53.05 ID:ztOmzoR+
subversionにおけるブランチの作り方
※ブランチ作るたびに、この長いURLをいちいち入力する必要があります。
svn cp https://www.example.com/svn/trunk \
https://www.example.com/svn/branches/v1p2p3
gitだとこれだけです。
git branch v1p2p3
さてブランチに切り替えてみましょう。
svn sw https://www.example.com/svn/branches/v1p2p3
ぷぷぷぷｗ
なんでsvnはそんな長いURLが必要なんですか？ｗｗｗｗ
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる＝コピー場所を指定しなければいけないんですね。
これを毎回毎回入力して切り替えるんですね。大変ですねぇｗｗｗｗ
git checkout v1p2p3
みじかい！
※ブランチ作るたびに、この長いURLをいちいち入力する必要があります。
svn cp https://www.example.com/svn/trunk \
https://www.example.com/svn/branches/v1p2p3
gitだとこれだけです。
git branch v1p2p3
さてブランチに切り替えてみましょう。
svn sw https://www.example.com/svn/branches/v1p2p3
ぷぷぷぷｗ
なんでsvnはそんな長いURLが必要なんですか？ｗｗｗｗ
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる＝コピー場所を指定しなければいけないんですね。
これを毎回毎回入力して切り替えるんですね。大変ですねぇｗｗｗｗ
git checkout v1p2p3
みじかい！
171 ：デフォルトの名無しさん：2014/04/26(土) 19:24:43.18 ID:ztOmzoR+
>>169
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。
だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。
こんなの、き・そ・！ です。
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。
だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。
こんなの、き・そ・！ です。
172 ：デフォルトの名無しさん：2014/04/26(土) 19:30:14.03 ID:y+As8odQ
おっ、そうだな
173 ：デフォルトの名無しさん：2014/04/26(土) 19:30:26.82 ID:Vv5x70uz
いや、初めからブランチ作らないって言ってるし、.my.cnfでも.pgsqlでもなんでもいいが、ブランチ切って修正を分ける必要性を全く感じない
174 ：デフォルトの名無しさん：2014/04/26(土) 19:32:08.93 ID:ztOmzoR+
※>>173 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうｗｗｗ
175 ：デフォルトの名無しさん：2014/04/26(土) 19:33:56.04 ID:Z8XCebgD
なんでこの人こんなに発狂してるの・・・
別に git はゴミ！とか貶してるわけじゃないのに
別に git はゴミ！とか貶してるわけじゃないのに
176 ：デフォルトの名無しさん：2014/04/26(土) 19:34:13.93 ID:Vv5x70uz
世の中には.ssh/configをテストファーストで日々更新してる人もいるのかもしれない、そういう人にはリリースと開発でブランチを分けてるのかもしれない
俺はそんなことしてないけど
俺はそんなことしてないけど
177 ：デフォルトの名無しさん：2014/04/26(土) 19:35:28.56 ID:ztOmzoR+
subversion使っている人は、みんな
ブランチ作らないって言ってるんでしょうかね
みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。
実はブランチ作れないの間違いでしょうかねｗ
面白いですねｗｗｗ
ブランチ作らないって言ってるんでしょうかね
みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。
実はブランチ作れないの間違いでしょうかねｗ
面白いですねｗｗｗ
178 ：デフォルトの名無しさん：2014/04/26(土) 19:36:05.09 ID:ztOmzoR+
subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
179 ：デフォルトの名無しさん：2014/04/26(土) 19:39:59.70 ID:iVzDEppp
>>173
お前がブランチ作らないとかどうでもいいわ。
バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。
それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
お前がブランチ作らないとかどうでもいいわ。
バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。
それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
180 ：デフォルトの名無しさん：2014/04/26(土) 19:44:23.08 ID:Vv5x70uz
いや、ホームディレクトリ以下の設定ファイルという前提なんだけど
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
181 ：デフォルトの名無しさん：2014/04/26(土) 19:46:55.41 ID:koYBfWi3
ホームディレクトリ以下をgitで管理しようと思うのならば、
git initするだけでもう使えるよ。
subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
git initするだけでもう使えるよ。
subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
182 ：デフォルトの名無しさん：2014/04/26(土) 19:51:45.97 ID:Z8XCebgD
なんか話を一般化して叩いてるけどホームディレクトリ内のファイルの管理ぐらい好きにやらせたれや・・・
183 ：デフォルトの名無しさん：2014/04/26(土) 19:54:06.41 ID:HaseiyYq
自由にやっていいよ。面倒な方法だって言っているだけだから
別に面倒な方法だってわかってやってるなら問題ない。
面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。
gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
別に面倒な方法だってわかってやってるなら問題ない。
面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。
gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
184 ：デフォルトの名無しさん：2014/04/26(土) 19:54:51.87 ID:Vv5x70uz
185 ：デフォルトの名無しさん：2014/04/26(土) 19:56:09.41 ID:Z8XCebgD
まあそこら辺は git スレでわざわざ頑張る内容ではないだろな
186 ：デフォルトの名無しさん：2014/04/26(土) 19:56:42.73 ID:HaseiyYq
>>184
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。
gitでも当然のようにリポジトリを別の場所におけるわｗ
だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。
少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。
gitでも当然のようにリポジトリを別の場所におけるわｗ
だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。
少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
187 ：デフォルトの名無しさん：2014/04/26(土) 19:59:08.48 ID:Z8XCebgD
>そういう使い方するとGitよりSubversionが使いやすい
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
188 ：デフォルトの名無しさん：2014/04/26(土) 20:01:00.30 ID:HaseiyYq
189 ：デフォルトの名無しさん：2014/04/26(土) 20:14:52.93 ID:7bCdF05U
まとめ
（俺にとっては）Subversionの方が簡単
俺にとってはって、君、Subversionを何に使ってるの？
設定ファイルの管理だけど？
ブランチは使わない！
でもブランチやタグを使うと面倒だよね？
だから、俺はブランチは使わない！
ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。
gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！
いや、同等って、それ簡単ということになってないじゃん。
（俺にとっては）Subversionの方が簡単
俺にとってはって、君、Subversionを何に使ってるの？
設定ファイルの管理だけど？
ブランチは使わない！
でもブランチやタグを使うと面倒だよね？
だから、俺はブランチは使わない！
ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。
gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！
いや、同等って、それ簡単ということになってないじゃん。
190 ：デフォルトの名無しさん：2014/04/26(土) 20:38:24.09 ID:knmAOh4a
ブランチ使わないって前提の話で、subversionはブランチ作るのが面倒とか的外れな反論しておかしくなった
ドットファイルをブランチに分ける事は基本ないわな
ドットファイルをブランチに分ける事は基本ないわな
191 ：デフォルトの名無しさん：2014/04/26(土) 20:42:18.34 ID:7YL+swb1
192 ：デフォルトの名無しさん：2014/04/26(土) 22:24:36.07 ID:jBTvJ1OX
Unix系のツールの設定ファイルとか複数の環境で使いまわすことが普通だし
最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合
最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合
193 ：デフォルトの名無しさん：2014/04/26(土) 23:35:52.72 ID:pkQNyj+N
>>148,149
たとえば
$ git log --color=never --all --graph --pretty="[%h] %d %s"
* [6a1c481] (HEAD, master) 2
* [523984e] (branch2) branch2-2
* [6554768] branch2-1
| * [05c389f] (branch1) branch1-2
| * [6b85c6d] branch1-1
|/
* [9d47912] 1
ここから、 branch1をFFなるように取り込もうとしたら
$ git rebase --onto master 3829497 branch1 として 分岐なくしてからマージしない？
それとも履歴にはこだわらず、 rebaseで1世代だけにしてからcherry-pickするのが普通？
たとえば
$ git log --color=never --all --graph --pretty="[%h] %d %s"
* [6a1c481] (HEAD, master) 2
* [523984e] (branch2) branch2-2
* [6554768] branch2-1
| * [05c389f] (branch1) branch1-2
| * [6b85c6d] branch1-1
|/
* [9d47912] 1
ここから、 branch1をFFなるように取り込もうとしたら
$ git rebase --onto master 3829497 branch1 として 分岐なくしてからマージしない？
それとも履歴にはこだわらず、 rebaseで1世代だけにしてからcherry-pickするのが普通？
194 ：デフォルトの名無しさん：2014/04/26(土) 23:37:58.13 ID:pkQNyj+N
195 ：デフォルトの名無しさん：2014/04/26(土) 23:46:42.24 ID:7YL+swb1
だからなんでFFに拘るんだよ
196 ：デフォルトの名無しさん：2014/04/26(土) 23:47:26.43 ID:7YL+swb1
197 ：デフォルトの名無しさん：2014/04/26(土) 23:49:50.02 ID:DhTsVAJ/
FFはCoolだかｒ
198 ：デフォルトの名無しさん：2014/04/27(日) 01:10:15.13 ID:TcUJdg0l
199 ：デフォルトの名無しさん：2014/04/27(日) 05:35:56.46 ID:/n7QikUK
svnでわざわざtrunk、branches、tagsディレクトリを作ってコミットなんて面倒なこと
ただの一度もしたことねえわ
ただの一度もしたことねえわ
200 ：デフォルトの名無しさん：2014/04/27(日) 06:08:30.59 ID:TcUJdg0l
まあ、そういう変な人もいる。
201 ：デフォルトの名無しさん：2014/04/27(日) 10:01:09.95 ID:YIeV8hDm
202 ：デフォルトの名無しさん：2014/04/27(日) 10:13:05.46 ID:+jGSbN4U
俺は、FFT派
203 ：デフォルトの名無しさん：2014/04/27(日) 14:15:59.24 ID:ijMC55vL
git覚えたての子が暴れてて凄いなこのスレ
204 ：デフォルトの名無しさん：2014/04/27(日) 16:48:41.84 ID:/n7QikUK
git派は自分のやり方以外は認められない原理主義者が多いんだろ
205 ：デフォルトの名無しさん：2014/04/27(日) 16:52:16.11 ID:s0HPULD5
206 ：デフォルトの名無しさん：2014/04/27(日) 20:05:48.91 ID:0q81XbwG
>>205
それでもFFにならないわけはない。
それでもFFにならないわけはない。
207 ：デフォルトの名無しさん：2014/04/27(日) 20:42:56.75 ID:RalmXzvw
>>9
>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚 弘記
>http://www.amazon.co.jp/gp/product/477416366X/
この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。
>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚 弘記
>http://www.amazon.co.jp/gp/product/477416366X/
この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。
208 ：デフォルトの名無しさん：2014/04/27(日) 20:56:58.74 ID:37jfUrsD
Gitについてはさわり中のさわりしか書いてないからまともにGit使おうと思ったら別の入門書買い足すことになるってだけだよ
209 ：デフォルトの名無しさん：2014/04/27(日) 21:34:00.25 ID:FuM1UcuM
>>207
> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。
> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。
210 ：デフォルトの名無しさん：2014/04/27(日) 21:39:02.03 ID:FuM1UcuM
>>201
> FFこだわるのは、FF縛りがあるから。
何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。
> FFこだわるのは、FF縛りがあるから。
何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。
211 ：デフォルトの名無しさん：2014/04/27(日) 21:46:21.84 ID:0q81XbwG
まっさきに思いついたのは無能なPMに強制されてるという理由だったが
212 ：デフォルトの名無しさん：2014/04/27(日) 22:46:45.69 ID:y1TCx0zf
もうそろそろ2.0リリースされそうだけど使ってる？
213 ：デフォルトの名無しさん：2014/04/28(月) 01:24:17.91 ID:r745xiPh
2.0は5月の第三週あたり
214 ：デフォルトの名無しさん：2014/04/28(月) 05:49:30.90 ID:G/O2/oE+
プロジェクトいくつも首突っ込んでればリポジトリなんてすぐ数十にはなるわけで
手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ
手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ
215 ：デフォルトの名無しさん：2014/04/28(月) 06:17:16.50 ID:SIdeIE1K
Gitはリポジトリ数十になってもpullとか手作業でいいと思うが？
216 ：デフォルトの名無しさん：2014/04/28(月) 09:59:35.16 ID:ES7XWIWl
どのプロジェクトが何の言語で書いたのかわかんない
githubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便
githubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便
217 ：デフォルトの名無しさん：2014/04/28(月) 12:04:38.80 ID:UImZVLxS
どの言語かなんて気にする必要ないだろ。
言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。
言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。
218 ：デフォルトの名無しさん：2014/04/28(月) 12:26:41.94 ID:ES7XWIWl
Git 2.0になって.gitconfigも変わる？誰か調べてる人いる？
219 ：デフォルトの名無しさん：2014/04/28(月) 12:27:37.63 ID:ES7XWIWl
Gitインストールするときにタグ指定し忘れて開発版の最新2.0をインストールしたんだけど特に不具合ないんだよね
220 ：デフォルトの名無しさん：2014/04/28(月) 13:13:07.74 ID:DVYrPedv
リリースノート読む限り大きな変更はgit pushのデフォルトがsimpleになることくらい？
自分の場合は既にsimpleに設定してたし
git addでパス省略ってやらないし影響なさげ
でも暫くは移行しない
自分の場合は既にsimpleに設定してたし
git addでパス省略ってやらないし影響なさげ
でも暫くは移行しない
221 ：デフォルトの名無しさん：2014/04/29(火) 03:34:15.62 ID:yOn60HCq
222 ：デフォルトの名無しさん：2014/04/29(火) 04:05:17.29 ID:5g+Rsf3h
223 ：デフォルトの名無しさん：2014/04/29(火) 04:10:14.41 ID:jiz/CQ6q
224 ：デフォルトの名無しさん：2014/04/29(火) 09:19:49.77 ID:wf66nSBF
修正履歴を残したいのに履歴をいじるのはおかしい
rebaseなんてGOTOと同じくらいいらない
rebaseなんてGOTOと同じくらいいらない
225 ：デフォルトの名無しさん：2014/04/29(火) 10:11:12.30 ID:gWfSfq0v
はぁ？
226 ：デフォルトの名無しさん：2014/04/29(火) 10:21:10.13 ID:fjfML7VO
わざわざログを壊してまで見やすくしようっていうのがいらねえんだよ
コミッターが何をしたのか把握できないだろう
コミッターが何をしたのか把握できないだろう
227 ：デフォルトの名無しさん：2014/04/29(火) 10:22:25.29 ID:fjfML7VO
そういうのはタグで管理するべき
rebaseを使うのは下手くそが使うコマンド
rebaseを使うのは下手くそが使うコマンド
228 ：デフォルトの名無しさん：2014/04/29(火) 10:41:22.64 ID:jiz/CQ6q
議論が変な方向に行くのがイヤなんで一応ハッキリさせときたいんだけど、
俺が気にしてるのは rebase && FF マージね。
master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
FF merge するってやり方のこと。これをやりたくなる意味がわからない。
他の目的のrebase自体は問題ないと思ってる。
俺が気にしてるのは rebase && FF マージね。
master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
FF merge するってやり方のこと。これをやりたくなる意味がわからない。
他の目的のrebase自体は問題ないと思ってる。
229 ：デフォルトの名無しさん：2014/04/29(火) 10:50:31.16 ID:2NEMUWta
masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
意味がないならrebaseしてからのほうがログが読みやすい
意味がないならrebaseしてからのほうがログが読みやすい
230 ：デフォルトの名無しさん：2014/04/29(火) 10:58:37.39 ID:fjfML7VO
どこで作業を行ったかの記録も重要である
余計なことはするな
余計なことはするな
231 ：デフォルトの名無しさん：2014/04/29(火) 11:14:43.54 ID:jiz/CQ6q
>>229
> masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
どういう場合にベースを意味がある(または意味がない)くわしくたのむ
俺にとって重要なのはブランチの目的とその目的に向かってコミットがどう積み重ねられたのかであって、
ベースがどこかは明示的にはあんまり気にしないんだが。
FFマージじゃなければ統合ブランチの履歴を log --first-parent で要約できるのと、
マージコミットのログなどに表示される親コミット2つ使って
git log deadbeaf..cafebabe
のようにトピックのログだけ簡単に取り出せるのが便利なのに。
後者は内部で merge-base 使ってるのでベースに意味があるのは確かだが、
だとすれば常に(俺にとっては)意味があると言える。
> masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
どういう場合にベースを意味がある(または意味がない)くわしくたのむ
俺にとって重要なのはブランチの目的とその目的に向かってコミットがどう積み重ねられたのかであって、
ベースがどこかは明示的にはあんまり気にしないんだが。
FFマージじゃなければ統合ブランチの履歴を log --first-parent で要約できるのと、
マージコミットのログなどに表示される親コミット2つ使って
git log deadbeaf..cafebabe
のようにトピックのログだけ簡単に取り出せるのが便利なのに。
後者は内部で merge-base 使ってるのでベースに意味があるのは確かだが、
だとすれば常に(俺にとっては)意味があると言える。
232 ：デフォルトの名無しさん：2014/04/29(火) 11:21:26.26 ID:LqsKRBzG
コミッターが行った作業をありのままに記録するべき
はたして捏造された記録に意味があるのか
はたして捏造された記録に意味があるのか
233 ：デフォルトの名無しさん：2014/04/29(火) 11:33:05.72 ID:EYu9TTok
>>224
コミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。
コミットして1分後に気づいたタイポの修正なんか
修正の履歴として残す価値はないはない。
レビューを誰かに依頼して見つかったバグの修正なんか
修正の履歴として残す必要はない。
このコミットで何を修正するのかを明確に記録するには
rebaseは必須の機能。rebaseの機能なしで同じことを
やろうとしたら大変すぎて断念するレベル。
反論できる？
コミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。
コミットして1分後に気づいたタイポの修正なんか
修正の履歴として残す価値はないはない。
レビューを誰かに依頼して見つかったバグの修正なんか
修正の履歴として残す必要はない。
このコミットで何を修正するのかを明確に記録するには
rebaseは必須の機能。rebaseの機能なしで同じことを
やろうとしたら大変すぎて断念するレベル。
反論できる？
234 ：デフォルトの名無しさん：2014/04/29(火) 11:38:42.10 ID:LqsKRBzG
その修正の裏に気づかずに別の箇所を修正しているかもしれない
不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね
不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね
235 ：デフォルトの名無しさん：2014/04/29(火) 11:40:07.95 ID:LqsKRBzG
>>233
だからそういうのはタグで管理しろ
だからそういうのはタグで管理しろ
236 ：デフォルトの名無しさん：2014/04/29(火) 11:49:24.38 ID:EYu9TTok
>>228
> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。
rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
masterへのmergeで起きたコンフリクトをその場で修正すると
バグを入れる可能性が高くなる。
コンフリクトが起きなければ問題ないが、いざマージしようと思った時に
コンフリクトが起きたら、修正する必要がある。
masterへの追尾が遅れれば遅れるほど、コンフリクトが起きる可能性も高くなるし、
コンフリクトが起きた時の修正も大変になる。だからこまめにmasterへrebaseしておく。
その一環として、最後にrebaseしておくだけのこと。
そうすればレビューアーも安心してレビューを行える。
もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。
rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
masterへのmergeで起きたコンフリクトをその場で修正すると
バグを入れる可能性が高くなる。
コンフリクトが起きなければ問題ないが、いざマージしようと思った時に
コンフリクトが起きたら、修正する必要がある。
masterへの追尾が遅れれば遅れるほど、コンフリクトが起きる可能性も高くなるし、
コンフリクトが起きた時の修正も大変になる。だからこまめにmasterへrebaseしておく。
その一環として、最後にrebaseしておくだけのこと。
そうすればレビューアーも安心してレビューを行える。
もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
237 ：デフォルトの名無しさん：2014/04/29(火) 11:51:08.54 ID:EYu9TTok
238 ：デフォルトの名無しさん：2014/04/29(火) 11:54:15.32 ID:EYu9TTok
>>234
gitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。
gitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。
239 ：デフォルトの名無しさん：2014/04/29(火) 11:57:18.99 ID:jiz/CQ6q
俺としては歴史修正ツールとしてのrebaseの使用には賛成なんだが、
やはりそっちの議論にいってしまうか。
いや、本当に全てのrebaseが有害と言ってるヤツもいるのかもしれんけども。
・rebase && FFマージの話
・歴史修正ツールとしてのrebaseの良し悪し
これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。
やはりそっちの議論にいってしまうか。
いや、本当に全てのrebaseが有害と言ってるヤツもいるのかもしれんけども。
・rebase && FFマージの話
・歴史修正ツールとしてのrebaseの良し悪し
これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。
240 ：デフォルトの名無しさん：2014/04/29(火) 11:59:42.78 ID:EYu9TTok
>>239
じゃあピンポイントで聞くわ。
開発者と、masterへマージ（レビュー）する人が別々の人だとする。
masterへマージする時にコンフリクトが起きました。
この時どうしますか？
1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。
じゃあピンポイントで聞くわ。
開発者と、masterへマージ（レビュー）する人が別々の人だとする。
masterへマージする時にコンフリクトが起きました。
この時どうしますか？
1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。
241 ：デフォルトの名無しさん：2014/04/29(火) 12:25:05.93 ID:jiz/CQ6q
>>236
おぉ、そういう主張か。 >>239 はとりあえず忘れてくれ。
> rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
> masterへのmergeで起きたコンフリクトをその場で修正すると
> バグを入れる可能性が高くなる。
主題から少しはなれるがここはおかしい。
masterにマージする人間とtopicを作ってる人間が別人ならその場で修正なんかせず、topic 作ってるやつに一旦 merge か rebase させるべき。
topic 側から master をマージした直後なら、その topic を master にマージするときはコンフリクトは起きない。このときは master 側からは no-ff でマージすべきだが、topic作ってくれたやつがmergeした方向による。
もちろん topic 作ってる人間は rebase してもいい。たぶん君が取ってる戦略はこっちなんだろう。
ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
もう一度言うが、俺が気にしてるのは rebase && FFマージだからね？
rebase後にno-ffでマージしてるなら大きな疑問はないよ。(topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
> レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
やっぱ他人なんだよな。mergeする場合はコンフリクトの解消はmerge/rebaseで書いたやつにさせるように運用するのがお勧めだよ。
おぉ、そういう主張か。 >>239 はとりあえず忘れてくれ。
> rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
> masterへのmergeで起きたコンフリクトをその場で修正すると
> バグを入れる可能性が高くなる。
主題から少しはなれるがここはおかしい。
masterにマージする人間とtopicを作ってる人間が別人ならその場で修正なんかせず、topic 作ってるやつに一旦 merge か rebase させるべき。
topic 側から master をマージした直後なら、その topic を master にマージするときはコンフリクトは起きない。このときは master 側からは no-ff でマージすべきだが、topic作ってくれたやつがmergeした方向による。
もちろん topic 作ってる人間は rebase してもいい。たぶん君が取ってる戦略はこっちなんだろう。
ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
もう一度言うが、俺が気にしてるのは rebase && FFマージだからね？
rebase後にno-ffでマージしてるなら大きな疑問はないよ。(topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
> レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
やっぱ他人なんだよな。mergeする場合はコンフリクトの解消はmerge/rebaseで書いたやつにさせるように運用するのがお勧めだよ。
242 ：デフォルトの名無しさん：2014/04/29(火) 12:27:35.28 ID:jiz/CQ6q
>>240
> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。
どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。
> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。
どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。
243 ：デフォルトの名無しさん：2014/04/29(火) 12:30:47.09 ID:EYu9TTok
> ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
gitlabでmasterにマージするときは、
ウェブの管理画面からボタンを押すだけ
その時勝手にno-ffされる。
というか、ウェブの管理画面からはno-ffでしかマージできない。
> (topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
コンフリクト起きないならrebaseもすぐに終わる。1コマンド入力してあとは自動処理。
コンフリクトするなら、結局どこかで作業するのだから大差ない。
コンフリクトするのかな～？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。
gitlabでmasterにマージするときは、
ウェブの管理画面からボタンを押すだけ
その時勝手にno-ffされる。
というか、ウェブの管理画面からはno-ffでしかマージできない。
> (topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
コンフリクト起きないならrebaseもすぐに終わる。1コマンド入力してあとは自動処理。
コンフリクトするなら、結局どこかで作業するのだから大差ない。
コンフリクトするのかな～？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。
244 ：デフォルトの名無しさん：2014/04/29(火) 12:35:19.57 ID:jiz/CQ6q
245 ：デフォルトの名無しさん：2014/04/29(火) 12:38:23.48 ID:EYu9TTok
rebase派だけど、FF派じゃねーよ？
rebaseのあとはどっちでもいい派。
rebaseすることに異議を唱えてるんじゃないの？
rebaseのあとはどっちでもいい派。
rebaseすることに異議を唱えてるんじゃないの？
246 ：デフォルトの名無しさん：2014/04/29(火) 13:06:53.85 ID:jiz/CQ6q
>>245
ちがうよ、rebaseはなくてはならない重要なツール。
俺が疑問に思ってるのは rebase && FF だよ。
理由はrebase && FF してしまうと
1 log --first-parent で要約をとれなくなる
2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
から。詳しくは上の方を見てくれ。
ちがうよ、rebaseはなくてはならない重要なツール。
俺が疑問に思ってるのは rebase && FF だよ。
理由はrebase && FF してしまうと
1 log --first-parent で要約をとれなくなる
2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
から。詳しくは上の方を見てくれ。
247 ：デフォルトの名無しさん：2014/04/29(火) 13:21:06.01 ID:GKmjQvWP
別にどっちでもいいというか
プロジェクトの性質に合わせて運用するべきで
他人がどうこう言うもんじゃないと思うが
FF派にとっては1と2は大して重要じゃないんでしょ
どうせログなんて参考にしかならんのだから
コードを追うならFFの方が都合がいい場合もあろう
プロジェクトの性質に合わせて運用するべきで
他人がどうこう言うもんじゃないと思うが
FF派にとっては1と2は大して重要じゃないんでしょ
どうせログなんて参考にしかならんのだから
コードを追うならFFの方が都合がいい場合もあろう
248 ：デフォルトの名無しさん：2014/04/29(火) 13:47:07.80 ID:+oyspTjV
プロジェクトの性質にもよるし、そのブランチで音一連の変更がどの程度の変更量かだったり、変更の意味にもよるし、mergeやrebaseをする人の技量にもよるよな。
merge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
http://blog.layer8.sh/ja/2013/04/08/best-git-commands-for-the-lonely-programmer/ (ちょっと違う例だけど)
こういうのって、ケースバイケースでしかないのに、mergeは悪！rebaseは正義！みたいに思っていそうで、
しかもこういうのを読んでmergeやrebaseの利点欠点について理解してない人たちがまたmergeは悪！rebaseは正義！と思い込んでしまって、害しかないと思うんだよな。
pullしてマージが発生したら「これでは自分が持っていたコミットの方が正統としているようなものです。origin へ push したのは a と b の方が先なのに…。」とか意味不明もいいとこ。
merge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
http://blog.layer8.sh/ja/2013/04/08/best-git-commands-for-the-lonely-programmer/ (ちょっと違う例だけど)
こういうのって、ケースバイケースでしかないのに、mergeは悪！rebaseは正義！みたいに思っていそうで、
しかもこういうのを読んでmergeやrebaseの利点欠点について理解してない人たちがまたmergeは悪！rebaseは正義！と思い込んでしまって、害しかないと思うんだよな。
pullしてマージが発生したら「これでは自分が持っていたコミットの方が正統としているようなものです。origin へ push したのは a と b の方が先なのに…。」とか意味不明もいいとこ。
249 ：デフォルトの名無しさん：2014/04/29(火) 14:26:17.37 ID:jiz/CQ6q
>>247
> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？
> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？
一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。
「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。
ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？
> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？
一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。
「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。
ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
250 ：デフォルトの名無しさん：2014/04/29(火) 14:28:32.84 ID:jobIXRFq
どうでもいい
251 ：デフォルトの名無しさん：2014/04/29(火) 14:30:18.99 ID:GcKmP5Zr
このスレの先輩方の議論のまとめとか入門とかをwikiにまとめませんか？
252 ：デフォルトの名無しさん：2014/04/29(火) 14:58:20.39 ID:jiz/CQ6q
俺も他人が管理してるプロジェクトであれば「うちではrebase && FFでやるから」って言われても
「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。
だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識
もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。
だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識
もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
253 ：デフォルトの名無しさん：2014/04/29(火) 15:08:09.46 ID:jiz/CQ6q
名指しして悪いんだけど例えばこれ
http://powerful-code.com/blog/2012/11/merge-or-rebase/
mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。
rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
http://powerful-code.com/blog/2012/11/merge-or-rebase/
mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。
rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
254 ：デフォルトの名無しさん：2014/04/29(火) 15:16:46.84 ID:jiz/CQ6q
巨大なプロジェクトでも--first-parentで見れば直線的だし、
かなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。
例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。
これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
かなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。
例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。
これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
255 ：デフォルトの名無しさん：2014/04/29(火) 15:25:33.99 ID:GKmjQvWP
イマイチ何を問題としているのかが分からん
> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが
>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの
考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが
>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの
考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
256 ：デフォルトの名無しさん：2014/04/29(火) 15:48:55.09 ID:+oyspTjV
>>252
rebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
rebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
257 ：デフォルトの名無しさん：2014/04/29(火) 15:56:19.89 ID:jiz/CQ6q
>>255
そういうことなの？
トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。
rebase && FFはトピックブランチ使わないってことなのかね。
そういうことなの？
トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。
rebase && FFはトピックブランチ使わないってことなのかね。
258 ：デフォルトの名無しさん：2014/04/29(火) 16:01:07.06 ID:jiz/CQ6q
>>256
なるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、
って感じかな。
感謝感謝。
なるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、
って感じかな。
感謝感謝。
259 ：デフォルトの名無しさん：2014/04/29(火) 16:15:23.14 ID:GKmjQvWP
なぜトピックブランチ使わないって結論に至るの？
FFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの
まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
FFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの
まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
260 ：デフォルトの名無しさん：2014/04/29(火) 16:17:02.13 ID:EYu9TTok
さっきからrebase && FFが問題であるかのように言ってるが、
問題なのは「FF only の masterマージ」だろう？
rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。
さらに言えば、masterへのマージ以外には
当てはまらないだろう？
問題なのは「FF only の masterマージ」だろう？
rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。
さらに言えば、masterへのマージ以外には
当てはまらないだろう？
261 ：デフォルトの名無しさん：2014/04/29(火) 16:19:03.64 ID:EYu9TTok
そしてFF only で masterマージ している（かのようなログをした）
有名なライブラリ例を上げておく。
https://github.com/lodash/lodash/commits/master
有名なライブラリ例を上げておく。
https://github.com/lodash/lodash/commits/master
262 ：デフォルトの名無しさん：2014/04/29(火) 16:21:51.52 ID:EYu9TTok
>>258
> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
263 ：デフォルトの名無しさん：2014/04/29(火) 16:26:11.71 ID:jiz/CQ6q
>>259
いや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
いや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
264 ：デフォルトの名無しさん：2014/04/29(火) 16:29:31.48 ID:jiz/CQ6q
>>260
> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
265 ：デフォルトの名無しさん：2014/04/29(火) 16:30:46.56 ID:+oyspTjV
266 ：デフォルトの名無しさん：2014/04/29(火) 16:30:55.69 ID:jiz/CQ6q
>>261
> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> https://github.com/lodash/lodash/commits/master
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> https://github.com/lodash/lodash/commits/master
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
267 ：デフォルトの名無しさん：2014/04/29(火) 16:31:51.96 ID:EYu9TTok
>>252
> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
268 ：デフォルトの名無しさん：2014/04/29(火) 16:40:59.32 ID:jiz/CQ6q
>>267
> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
269 ：デフォルトの名無しさん：2014/04/29(火) 16:43:19.24 ID:EYu9TTok
>>266
> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
270 ：デフォルトの名無しさん：2014/04/29(火) 16:51:05.11 ID:jiz/CQ6q
>>269
> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
271 ：デフォルトの名無しさん：2014/04/29(火) 16:53:09.53 ID:EYu9TTok
272 ：デフォルトの名無しさん：2014/04/29(火) 16:59:55.32 ID:EYu9TTok
>>270
> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
273 ：デフォルトの名無しさん：2014/04/29(火) 17:07:40.73 ID:EYu9TTok
ちなみに俺が反論している所を明確にしておくと、
「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
274 ：デフォルトの名無しさん：2014/04/29(火) 17:14:28.12 ID:jobIXRFq
トピックブランチのコミットが2個以上なら
マージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
マージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
275 ：デフォルトの名無しさん：2014/04/29(火) 17:18:53.63 ID:EYu9TTok
連投するが、俺がいいたいのは
・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
276 ：デフォルトの名無しさん：2014/04/29(火) 18:11:38.86 ID:jiz/CQ6q
>>273
コミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
A-B-C
/ \
X-------M-M
\ /
D--E--F
こういう変更は DEF をrebaseして
A-B-C
/ \
X-------M---------M
\ /
D'-E'-F'
こうすべき、ってことでいいかい？
俺的にはどちらもfirst-parentで
\
X-M-M
/
に要約可能だからどっちでもいいよ。
# ただ自分でやる場合はコンフリクトしない限り前者のほうがrebaseしなくていいから楽だけと思うけどね。
# もちろんDEFのマージ時にコンフリクトしたらrebaseすることもある。DEF開発者によるmergeも可。
コミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
A-B-C
/ \
X-------M-M
\ /
D--E--F
こういう変更は DEF をrebaseして
A-B-C
/ \
X-------M---------M
\ /
D'-E'-F'
こうすべき、ってことでいいかい？
俺的にはどちらもfirst-parentで
\
X-M-M
/
に要約可能だからどっちでもいいよ。
# ただ自分でやる場合はコンフリクトしない限り前者のほうがrebaseしなくていいから楽だけと思うけどね。
# もちろんDEFのマージ時にコンフリクトしたらrebaseすることもある。DEF開発者によるmergeも可。
277 ：デフォルトの名無しさん：2014/04/29(火) 18:12:17.95 ID:jiz/CQ6q
疑問視してるのは
X-A-B-C-D'-E'-F'
にすべきという主張だ。
これはA-B-CとD-E-Fが本来別の目的を目指して重ねたコミットだという情報が失われてしまうから
たとえ一直線でもわかりにくいと俺は主張しているんだよ。
トピックが2個程度ならどっちでも良さそうだが、トピックが数十の場合を想像してくれ
X-M-M-M-.....M-M
という数十個の要約を見る(必要に応じてトピック内のABC等を確認する)のと
X-A-B-C......(区切りもなく、めちゃくちゃたくさんのコミット)....x-y-z
を見るのと、どっちがわかりやすいの？ってこと。
X-A-B-C-D'-E'-F'
にすべきという主張だ。
これはA-B-CとD-E-Fが本来別の目的を目指して重ねたコミットだという情報が失われてしまうから
たとえ一直線でもわかりにくいと俺は主張しているんだよ。
トピックが2個程度ならどっちでも良さそうだが、トピックが数十の場合を想像してくれ
X-M-M-M-.....M-M
という数十個の要約を見る(必要に応じてトピック内のABC等を確認する)のと
X-A-B-C......(区切りもなく、めちゃくちゃたくさんのコミット)....x-y-z
を見るのと、どっちがわかりやすいの？ってこと。
278 ：デフォルトの名無しさん：2014/04/29(火) 18:15:08.80 ID:jiz/CQ6q
ブラウザによっては結構ずれるな。わかんなきゃ無視してくれ。
279 ：デフォルトの名無しさん：2014/04/29(火) 18:24:55.80 ID:VGBInRA4
2.0からデフォルトでFF onlyになるのは知ってるよね君たち
どうしてこうなったのかもちろん議論されてるのも知ってるよね
どうしてこうなったのかもちろん議論されてるのも知ってるよね
280 ：デフォルトの名無しさん：2014/04/29(火) 18:25:46.52 ID:ABe1tyQZ
これもうわかんねえな(バグったときの修正範囲が)
281 ：デフォルトの名無しさん：2014/04/29(火) 18:30:04.67 ID:qq5sN0hH
>履歴は一直線になっていたほうがわかりやすい。これは事実。
一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
282 ：デフォルトの名無しさん：2014/04/29(火) 18:44:21.18 ID:jiz/CQ6q
>>279
pull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
pull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
283 ：デフォルトの名無しさん：2014/04/29(火) 18:45:53.07 ID:jiz/CQ6q
284 ：デフォルトの名無しさん：2014/04/29(火) 19:02:08.02 ID:ABe1tyQZ
ベースブランチの状態が多いイコール検証箇所も多くなって面倒だからそうならないようコミットも最小限にしたほうがいいんじゃないの
285 ：デフォルトの名無しさん：2014/04/29(火) 19:47:52.24 ID:6KBRCzBr
>>223
というわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
というわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
286 ：デフォルトの名無しさん：2014/04/29(火) 19:56:50.37 ID:EYu9TTok
> ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
ね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
ね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
287 ：デフォルトの名無しさん：2014/04/29(火) 19:58:40.00 ID:jiz/CQ6q
>>285
報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
288 ：デフォルトの名無しさん：2014/04/29(火) 20:21:45.22 ID:jobIXRFq
一直線バカは救いようのないバカだな
289 ：デフォルトの名無しさん：2014/04/29(火) 23:30:04.09 ID:+oyspTjV
「履歴が一直線になってわかりやすい！」かどうかって、もはやコミットの順序というものにどういう意味があるかどうかという意味論なのだから、
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
290 ：デフォルトの名無しさん：2014/04/30(水) 00:35:08.42 ID:UGHSixxv
一直線が良いケースが挙げられてないけどな
291 ：デフォルトの名無しさん：2014/04/30(水) 01:11:54.22 ID:pWom3qZR
一直線： 見えを貼りたいだけのバカ。俺はまっすぐ順調に開発をしてきたというアピールがしたい
292 ：デフォルトの名無しさん：2014/04/30(水) 01:29:11.37 ID:Gbwo+6jG
東大一直線
293 ：デフォルトの名無しさん：2014/04/30(水) 05:04:21.07 ID:mdKtpEfX
意味不明なエラーでpush不可能になった
remote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
remote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
294 ：デフォルトの名無しさん：2014/04/30(水) 08:30:44.87 ID:1vNQkGgC
hook declined
ってかいてあんじゃん
ってかいてあんじゃん
295 ：デフォルトの名無しさん：2014/04/30(水) 11:02:23.25 ID:4gXDKzV2
書き込み時刻を見ろ 察してやれ
296 ：デフォルトの名無しさん：2014/04/30(水) 14:42:09.85 ID:mdKtpEfX
dis発言に対してはただ叩くだけ
それも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
それも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
297 ：デフォルトの名無しさん：2014/04/30(水) 14:48:31.80 ID:mdKtpEfX
別リポジトリで他人による大量の更新があって
半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
298 ：デフォルトの名無しさん：2014/04/30(水) 14:55:49.07 ID:nKoANYQ+
またいつものコンフリクト恐怖症の人か
299 ：デフォルトの名無しさん：2014/04/30(水) 18:26:55.40 ID:mdKtpEfX
コンフリクト解消で済めばいいんだが腐ってるから済まないんだよね
300 ：デフォルトの名無しさん：2014/04/30(水) 18:51:13.84 ID:h9gMUOtr
なるほど、コンフリクトの解消の仕方が分からないから
コンフリクト恐怖症になってしまったのか
コンフリクト恐怖症になってしまったのか
301 ：デフォルトの名無しさん：2014/04/30(水) 18:51:51.42 ID:rHgIYikH
Aリポジトリでもらったpull requestを
Bリポジトリに反映する方法を教えてください
Bリポジトリに反映する方法を教えてください
302 ：デフォルトの名無しさん：2014/04/30(水) 18:59:19.90 ID:1L5gAVQy
ところで、大声でジットと呼ぶ人がいて困ってるんだ
ディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
ディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
303 ：デフォルトの名無しさん：2014/04/30(水) 19:12:36.93 ID:ZY5HChQC
じっと我慢汁
304 ：デフォルトの名無しさん：2014/04/30(水) 19:50:56.80 ID:fWhizGrM
レーダーデスクカラオケ
305 ：デフォルトの名無しさん：2014/04/30(水) 19:56:34.41 ID:EonfyA0Y
ギットギトにしてやんよ
306 ：デフォルトの名無しさん：2014/04/30(水) 20:25:07.89 ID:WuyiDL68
>>297
> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
307 ：デフォルトの名無しさん：2014/04/30(水) 21:19:26.86 ID:livyiFPX
>>297
> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
308 ：デフォルトの名無しさん：2014/04/30(水) 21:28:01.99 ID:upmIhAH5
309 ：デフォルトの名無しさん：2014/04/30(水) 21:58:49.74 ID:Y0BKcERE
>>308
悪いことは言わないから足を洗え。
悪いことは言わないから足を洗え。
310 ：デフォルトの名無しさん：2014/04/30(水) 22:12:33.53 ID:livyiFPX
そういやgithubってプロジェクトで使用している言語がわかるようになったよね。
gitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
gitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
311 ：デフォルトの名無しさん：2014/04/30(水) 22:41:41.21 ID:rUdHCEgh
githubだけの視野で語られても
312 ：デフォルトの名無しさん：2014/04/30(水) 22:42:55.54 ID:livyiFPX
github以外のプロジェクトでも
複数言語でアプリ作るのは一般的だけど？ｗ
複数言語でアプリ作るのは一般的だけど？ｗ
313 ：デフォルトの名無しさん：2014/04/30(水) 23:26:12.17 ID:mdKtpEfX
307は本当に馬鹿なんだなぁ
管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
314 ：デフォルトの名無しさん：2014/04/30(水) 23:51:07.78 ID:1vNQkGgC
結局gitのおかげで無事でした
めでたしめでたし
めでたしめでたし
315 ：デフォルトの名無しさん：2014/05/01(木) 00:28:44.24 ID:WukXr8jq
＞＞３１２
プロジェクトを1つのディレクトリに詰め込むタイプですか？
プロジェクトを1つのディレクトリに詰め込むタイプですか？
316 ：デフォルトの名無しさん：2014/05/01(木) 09:28:45.91 ID:PzUwUPDQ
317 ：デフォルトの名無しさん：2014/05/01(木) 11:07:25.45 ID:PVO7jj2i
>>315
なんでそんな発想が出てくるんだ？ (w
なんでそんな発想が出てくるんだ？ (w
318 ：デフォルトの名無しさん：2014/05/01(木) 11:24:48.42 ID:/DVUm5po
おれはさ
php/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
php/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
319 ：デフォルトの名無しさん：2014/05/01(木) 17:12:30.25 ID:PzUwUPDQ
>>318
それとGitと何の関係があるんだ？
それとGitと何の関係があるんだ？
320 ：デフォルトの名無しさん：2014/05/01(木) 17:20:29.51 ID:U31MyfYF
Gitはソースコードを管理するわけだからプロジェクトと関係あるだろ
C:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
C:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
321 ：デフォルトの名無しさん：2014/05/01(木) 17:24:28.79 ID:n23f7Uie
名前付けのポリシーとか別に好きにすればいいと思う。
322 ：デフォルトの名無しさん：2014/05/01(木) 17:44:02.84 ID:PzUwUPDQ
>>320
そんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
そんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
323 ：デフォルトの名無しさん：2014/05/01(木) 17:52:02.03 ID:U31MyfYF
>>310
複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
324 ：デフォルトの名無しさん：2014/05/01(木) 18:01:12.45 ID:n23f7Uie
もう自由にタグ付けできる自分用プロジェクト管理ツール使っちゃえよ。
325 ：デフォルトの名無しさん：2014/05/01(木) 18:13:02.15 ID:ZgnY/tZG
326 ：デフォルトの名無しさん：2014/05/01(木) 19:05:29.45 ID:PzUwUPDQ
>>323
githubがリポジトリを「https://github.com/ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
githubがリポジトリを「https://github.com/ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
327 ：デフォルトの名無しさん：2014/05/01(木) 19:26:56.62 ID:3NSQaEE2
だからさGitHubだけで語るな
328 ：デフォルトの名無しさん：2014/05/01(木) 22:47:07.56 ID:dcOXu/fE
確かにSubversion使ってたときは一つのリポジトリに色々入れてたけど(そしてSubversionを適当に使う限りではそれで事足りてた)、
Gitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
Gitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
329 ：デフォルトの名無しさん：2014/05/02(金) 03:41:26.83 ID:ZGvM0amq
>>316 pullするだけでその状態になることすらわからないとかお前本当に馬鹿だな
330 ：デフォルトの名無しさん：2014/05/02(金) 03:48:34.89 ID:PU3lP69m
331 ：デフォルトの名無しさん：2014/05/02(金) 06:22:29.35 ID:KJDTZacL
自分の管理下にあるリポジトリなら好きに名前付けりゃいいじゃん
332 ：デフォルトの名無しさん：2014/05/02(金) 06:35:41.08 ID:Ujs4NpLL
333 ：デフォルトの名無しさん：2014/05/02(金) 06:37:10.90 ID:Ujs4NpLL
334 ：デフォルトの名無しさん：2014/05/02(金) 08:09:07.29 ID:ZGvM0amq
わざわざvcsの勉強なくて無価値なことはしたくもないね
335 ：デフォルトの名無しさん：2014/05/02(金) 08:29:32.57 ID:Ujs4NpLL
Gitに関しては勉強する価値があった
正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
336 ：デフォルトの名無しさん：2014/05/02(金) 11:30:23.12 ID:W9jDDFpi
パスワードを含んだファイルがあるんですけど
このファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
このファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
337 ：デフォルトの名無しさん：2014/05/02(金) 13:03:04.92 ID:pbdRog+k
>>336
$ touch password.txt; git add password.txt; git commit
$ git update-index --skip-worktree password.txt
$ echo -n 'himitsu' > password.txt; git status
On branch master
nothing to commit, working directory clean
とか？
$ touch password.txt; git add password.txt; git commit
$ git update-index --skip-worktree password.txt
$ echo -n 'himitsu' > password.txt; git status
On branch master
nothing to commit, working directory clean
とか？
338 ：デフォルトの名無しさん：2014/05/02(金) 13:06:17.10 ID:Pfd+HO5D
>>332
> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
339 ：デフォルトの名無しさん：2014/05/02(金) 13:17:21.62 ID:Oia8PEO/
340 ：デフォルトの名無しさん：2014/05/02(金) 14:47:13.55 ID:Ujs4NpLL
341 ：デフォルトの名無しさん：2014/05/02(金) 15:06:33.45 ID:WqSAbr7K
User/repository.gitが
User/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
User/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
342 ：デフォルトの名無しさん：2014/05/02(金) 17:26:31.17 ID:BNaPh7J8
% git clone http://.../User/php-oreore.git php/oreore.git
すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
343 ：デフォルトの名無しさん：2014/05/02(金) 17:34:19.17 ID:XSE+HkNu
C:￥testからD:￥testに移動したいんですけど
ファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
ファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
344 ：デフォルトの名無しさん：2014/05/02(金) 17:44:12.24 ID:BNaPh7J8
345 ：デフォルトの名無しさん：2014/05/02(金) 17:53:43.03 ID:XSE+HkNu
C:￥testでgit initして適当にファイルを作ってコミットして
C:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
C:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
346 ：デフォルトの名無しさん：2014/05/02(金) 18:06:55.59 ID:+HIQMOvh
全く再現しねえな
347 ：デフォルトの名無しさん：2014/05/02(金) 18:07:33.93 ID:XSE+HkNu
eeeeeeeeeeee
348 ：デフォルトの名無しさん：2014/05/02(金) 18:14:47.14 ID:+HIQMOvh
GitBushから
cd /c/temp
mkdir git
cd git
mkdir test1
cd test1
git init
vim README
git add .
git commit -m "initial commit"
エクスプローラで
Cドライブ(C:\Temp\Git\Test1)を右クリックメニューでコピー
Dドライブ(D:\Temp\Git)にて右クリックメニューから貼り付け
GitBushから
cd /d/temp/git/test1
(ちゃんとmasterって表示になった)
git log
(ちゃんとinitial commitのコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
cd /c/temp
mkdir git
cd git
mkdir test1
cd test1
git init
vim README
git add .
git commit -m "initial commit"
エクスプローラで
Cドライブ(C:\Temp\Git\Test1)を右クリックメニューでコピー
Dドライブ(D:\Temp\Git)にて右クリックメニューから貼り付け
GitBushから
cd /d/temp/git/test1
(ちゃんとmasterって表示になった)
git log
(ちゃんとinitial commitのコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
349 ：デフォルトの名無しさん：2014/05/02(金) 18:23:12.12 ID:3JApfdBs
おかしいな・・・またあとできます
350 ：デフォルトの名無しさん：2014/05/02(金) 20:15:24.71 ID:dlumt8FZ
Gitのこともほとんど具体的な操作方とか知らないままなんだけど、GitHub実践入門を買った
ので、Git操作のお勉強と同時にGithubも使いだした。
ので、Git操作のお勉強と同時にGithubも使いだした。
351 ：デフォルトの名無しさん：2014/05/02(金) 20:18:51.30 ID:6MkiwdiC
rmした後に全く関係ないファイルをaddするとrmしたファイルのrename扱いになるんですが
単に新規ステージングしたファイル扱いにできますか？
直後にrmしたファイルではなく、始めにrmしたファイルのrenameになっていたり
動作がわけわららんです
単に新規ステージングしたファイル扱いにできますか？
直後にrmしたファイルではなく、始めにrmしたファイルのrenameになっていたり
動作がわけわららんです
352 ：デフォルトの名無しさん：2014/05/02(金) 20:48:37.15 ID:YmhbMTXU
>>337 横レス
設定ファイルとか便利そうだな。覚えておこう。
設定ファイルとか便利そうだな。覚えておこう。
353 ：デフォルトの名無しさん：2014/05/02(金) 20:49:12.42 ID:6MkiwdiC
どうやら中身が同じファイルは勝手にrename扱いにしてくれるようですね
空ファイルでトレーニングしていたので混乱してしまいました
空ファイルでトレーニングしていたので混乱してしまいました
354 ：デフォルトの名無しさん：2014/05/02(金) 20:59:01.62 ID:6ajnVdK2
355 ：デフォルトの名無しさん：2014/05/02(金) 21:02:26.52 ID:6MkiwdiC
356 ：デフォルトの名無しさん：2014/05/02(金) 21:42:27.82 ID:x3xYwsX7
gitはファイルではなくコンテンツを管理していると言われる所以だね。
357 ：デフォルトの名無しさん：2014/05/02(金) 22:17:35.97 ID:Xf1Tcq77
gitでhookファイルを変更した場合
これをGitHubにプッシュした阿戸に
ローカルのファイルとリポジトリを削除してからクローンしたらhookファイルの内容がないんですが何故ですか？
これをGitHubにプッシュした阿戸に
ローカルのファイルとリポジトリを削除してからクローンしたらhookファイルの内容がないんですが何故ですか？
358 ：デフォルトの名無しさん：2014/05/02(金) 23:58:46.02 ID:ojQzvTVb
こんなGit入門の本を買った。
http://2ch-dc.net/v4/src/1399042353761.jpg
http://2ch-dc.net/v4/src/1399042353761.jpg
359 ：デフォルトの名無しさん：2014/05/03(土) 00:29:50.84 ID:9lt90aGA
喜ぶべきか悼むべきか・・・
360 ：デフォルトの名無しさん：2014/05/03(土) 01:42:57.16 ID:fa3rSR83
>>358
それってどう？
それってどう？
361 ：デフォルトの名無しさん：2014/05/03(土) 02:05:49.12 ID:Z2xjVVlJ
>>357
フックは版管理されてないから。configも同様。
フックをシェアしたいならワーキングディレクトリにフックを置いて、Makefileなりsetupスクリプトからインストールできるようにする。
クローンしただけで勝手にスクリプトに走られたら困る。
フックは版管理されてないから。configも同様。
フックをシェアしたいならワーキングディレクトリにフックを置いて、Makefileなりsetupスクリプトからインストールできるようにする。
クローンしただけで勝手にスクリプトに走られたら困る。
362 ：デフォルトの名無しさん：2014/05/03(土) 02:07:15.00 ID:vyhhlfA3
>>360
文章読むだけならGithubで公開されてる
文章読むだけならGithubで公開されてる
363 ：デフォルトの名無しさん：2014/05/03(土) 02:11:26.95 ID:Z2xjVVlJ
364 ：デフォルトの名無しさん：2014/05/03(土) 07:45:11.01 ID:n1PIULKZ
365 ：デフォルトの名無しさん：2014/05/03(土) 13:12:50.33 ID:EAqxmtFF
リモートにtagをpushした後、リモートに存在するtagを確認するにはどうすればよいのでしょうか
ローカルリポジトリのtagなら git tag, リモートのブランチなら git branch -r ですが、
リモートのtagを表示するコマンドが見つかりません
ローカルリポジトリのtagなら git tag, リモートのブランチなら git branch -r ですが、
リモートのtagを表示するコマンドが見つかりません
366 ：デフォルトの名無しさん：2014/05/03(土) 14:26:01.92 ID:H1NY/7i6
git ls-remote リモート名
367 ：デフォルトの名無しさん：2014/05/03(土) 14:26:42.30 ID:oP8j+OVm
368 ：デフォルトの名無しさん：2014/05/03(土) 14:47:09.37 ID:EAqxmtFF
>>366-367
感謝です！ありがとうございました！
感謝です！ありがとうございました！
369 ：デフォルトの名無しさん：2014/05/04(日) 11:33:46.82 ID:bQKl4dNQ
リモートリポジトリからPullした直後で一切変更を加えていないにも関わらず
git statusでいくつかのファイルで差分が検出されてしまう現象にが起きています
差分が検出されているファイルのdiffを見るとソースコード全体が入れ替えられたような表示になります
しかし、該当ファイルをgit addしてから再度git diffすると変更点なしと表示されます
現象が起きるファイルは.cpp、.cs等複数の拡張子で
その拡張子のファイルすべてで起きる訳ではなく、頻繁に更新されるファイルで起きているように見えました
この現象についてWeb検索したのですが、該当しそうな情報は得られませんでした
githubのクライアントとVisualStudio2013のgit機能を併用していることに
原因がありそうな気がしているのでそのあたり調査する予定ですが
見直すべき設定等、何かヒントを頂けたら嬉しいです
git statusでいくつかのファイルで差分が検出されてしまう現象にが起きています
差分が検出されているファイルのdiffを見るとソースコード全体が入れ替えられたような表示になります
しかし、該当ファイルをgit addしてから再度git diffすると変更点なしと表示されます
現象が起きるファイルは.cpp、.cs等複数の拡張子で
その拡張子のファイルすべてで起きる訳ではなく、頻繁に更新されるファイルで起きているように見えました
この現象についてWeb検索したのですが、該当しそうな情報は得られませんでした
githubのクライアントとVisualStudio2013のgit機能を併用していることに
原因がありそうな気がしているのでそのあたり調査する予定ですが
見直すべき設定等、何かヒントを頂けたら嬉しいです
370 ：デフォルトの名無しさん：2014/05/04(日) 11:50:13.22 ID:IxrX60Uq
>>369
改行コードだな
改行コードだな
371 ：デフォルトの名無しさん：2014/05/04(日) 18:11:29.06 ID:Efc5dGc7
git config core.filemode false
git config core.symlinks false
git config core.symlinks false
372 ：デフォルトの名無しさん：2014/05/05(月) 12:36:20.36 ID:qzGHizbC
pullは1箇所から取得してpushは複数にする方法を教えてください
AitHubのみpullして
pushはAitHub,BitHub,CitHubの3箇所に送信してバックアップがしたいんです
AitHubのみpullして
pushはAitHub,BitHub,CitHubの3箇所に送信してバックアップがしたいんです
373 ：デフォルトの名無しさん：2014/05/05(月) 13:48:29.73 ID:bcw2AmGJ
>>372
git remote add知ってる?
git remote add知ってる?
374 ：デフォルトの名無しさん：2014/05/05(月) 13:50:28.20 ID:HNW3XBXV
それ知ってますけど1つのとこしかpushできませんよね
375 ：デフォルトの名無しさん：2014/05/05(月) 14:07:54.45 ID:NnoKU6B2
一つの所ってなんですか？ originですか？
なんでいちいち名前を指定すると思いますか？
一つだけなら名前は必要ないはずですよね？
なんでいちいち名前を指定すると思いますか？
一つだけなら名前は必要ないはずですよね？
376 ：デフォルトの名無しさん：2014/05/05(月) 14:08:40.84 ID:NnoKU6B2
なんでremote addだと思いますか？
一つだけならremote setでいいはずですよね？
あとは自分で考えてください。
一つだけならremote setでいいはずですよね？
あとは自分で考えてください。
377 ：デフォルトの名無しさん：2014/05/05(月) 18:39:57.72 ID:G1VleuAd
git push {A,B,C}itHub branch
378 ：デフォルトの名無しさん：2014/05/06(火) 11:11:21.75 ID:wWugdkdR
>>369
autocrlfくさい
autocrlfくさい
>>370,371,378
ありがとうございます。
いただいた助言を参考に試行錯誤して、とりあえず以下の操作をしたら
現象が落ち着きました。
・core.autocrlfをtrueからfalseに(Windowsでしか開発しないので)
・core.whitespaceを明示(space-before-tab,trailing-space)
・該当ファイルをVisualStudioの「ドキュメントのフォーマット」を使用して整形
もしかしたらwhitespace周りが原因だったのかもしれません。
どうもありがとうございました。
ありがとうございます。
いただいた助言を参考に試行錯誤して、とりあえず以下の操作をしたら
現象が落ち着きました。
・core.autocrlfをtrueからfalseに(Windowsでしか開発しないので)
・core.whitespaceを明示(space-before-tab,trailing-space)
・該当ファイルをVisualStudioの「ドキュメントのフォーマット」を使用して整形
もしかしたらwhitespace周りが原因だったのかもしれません。
どうもありがとうございました。
380 ：デフォルトの名無しさん：2014/05/06(火) 16:27:04.50 ID:dFD2Q7zD
masterブランチの内容をtestブランチに移動して
masterブランチ内のファイルの内容を空の状態にする方法を教えてください
masterブランチ内のファイルの内容を空の状態にする方法を教えてください
381 ：デフォルトの名無しさん：2014/05/06(火) 18:22:58.02 ID:ms/T2S5F
ファイルの内容を空の状態にする？ファイルのサイズを0バイトにするってこと？
382 ：デフォルトの名無しさん：2014/05/06(火) 18:53:05.44 ID:2kojW0Cn
あるブランチでコミットした内容をmasterに反映させる時rebaseを使えっていうのをここで習ったんですが
具体的にどうやるのか教えてください
git init
touch a
git add a
git commit -m "INITIAL COMMIT"
git checkout -b kaihatu1"
echo "1" > a
git add a
git commit -m "1を追加"
echo "1" > a
git add a
git commit -m "数字を2に変更" ←いまここ
この後から何をしたらいいのか教えてください
具体的にどうやるのか教えてください
git init
touch a
git add a
git commit -m "INITIAL COMMIT"
git checkout -b kaihatu1"
echo "1" > a
git add a
git commit -m "1を追加"
echo "1" > a
git add a
git commit -m "数字を2に変更" ←いまここ
この後から何をしたらいいのか教えてください
383 ：デフォルトの名無しさん：2014/05/06(火) 18:59:41.16 ID:WvF/ZXc8
絵に描いたような教えてクン
384 ：デフォルトの名無しさん：2014/05/06(火) 19:03:35.48 ID:Fr+PW76D
あるブランチでコミットした内容をmasterに反映させる時に使うのはmerge
ブランチには複数のコミットが含まれている。という前提とする。
masterにマージする時のやり方
1. squashして一つのコミットにしてマージ
2. squashせず、マージコミットを作ってマージ（no fast foward）
3. squashせず、マージコミットもつくらずマージ（fast forward）
ブランチは作業履歴とか入っていてコミットが汚いことがあるので
mergeする前にブランチを綺麗にしておくと良い。
ただし1ならコミットは一つになるからrebaseする必要はない。
2. もしくは 3の時、マージされたコミットを綺麗にしておきたいならrebaseする。
小さなバグ修正とか、タイポの修正とかそんなのが残ってても気にしないならrebase不要。
ただし、rebaseせずにfast fowardでmasterにマージすると
revertしづらくて死ぬだろう。コミットが綺麗なら3でも良いが、
2にしておくと、ブランチ単位でrevertできるから楽。
ブランチには複数のコミットが含まれている。という前提とする。
masterにマージする時のやり方
1. squashして一つのコミットにしてマージ
2. squashせず、マージコミットを作ってマージ（no fast foward）
3. squashせず、マージコミットもつくらずマージ（fast forward）
ブランチは作業履歴とか入っていてコミットが汚いことがあるので
mergeする前にブランチを綺麗にしておくと良い。
ただし1ならコミットは一つになるからrebaseする必要はない。
2. もしくは 3の時、マージされたコミットを綺麗にしておきたいならrebaseする。
小さなバグ修正とか、タイポの修正とかそんなのが残ってても気にしないならrebase不要。
ただし、rebaseせずにfast fowardでmasterにマージすると
revertしづらくて死ぬだろう。コミットが綺麗なら3でも良いが、
2にしておくと、ブランチ単位でrevertできるから楽。
385 ：デフォルトの名無しさん：2014/05/11(日) 13:29:58.96 ID:DrfDcIuJ
1.9.3 がリリースされたね
386 ：デフォルトの名無しさん：2014/05/11(日) 16:13:44.39 ID:8Qasa1hM
>>385
それが・・・どうかしたの？
それが・・・どうかしたの？
387 ：デフォルトの名無しさん：2014/05/11(日) 16:14:30.91 ID:M5uHChWE
今回のはつまらんリリースだ
388 ：デフォルトの名無しさん：2014/05/11(日) 17:39:48.22 ID:qkdWQCFA
まだ１．９つかってるの？もうこっちは２．０使ってるよ
389 ：デフォルトの名無しさん：2014/05/11(日) 19:24:38.83 ID:04FzsR6r
俺のはいまだに1.7ですが
390 ：デフォルトの名無しさん：2014/05/11(日) 21:21:49.14 ID:wZvRNfhO
カレントを追いかけているから俺も常に最新・・・
アップデートきてたから1.9.3に今した
アップデートきてたから1.9.3に今した
391 ：デフォルトの名無しさん：2014/05/11(日) 21:23:17.01 ID:pXskIuQ6
1.8 位から、処理速度が速くなったと思う
392 ：デフォルトの名無しさん：2014/05/12(月) 00:23:32.35 ID:fWwUyCwI
俺初めて使ったとき、まずルートでinitしていつまでも延々待ちになってしまって
壊れているかと思った。
壊れているかと思った。
393 ：デフォルトの名無しさん：2014/05/12(月) 12:14:12.48 ID:bllVZHXA
>>390
カレントってなに？gitからクローンすると2.0になるけど？
カレントってなに？gitからクローンすると2.0になるけど？
394 ：デフォルトの名無しさん：2014/05/12(月) 13:44:49.20 ID:1rzT8Re4
>>393
>カレントってなに？gitからクローンすると2.0になるけど？
「現時点で GitHub から Git のリポジトリのクローンを取得してビルドしてインストールすると 2.0 になる」という意味？
現時点で 2.0 は正式版ではなくて RC 版だよ。
https://github.com/git/git/releases
現時点の最新の 2.0 は 2日前にリリースされた v2.0.0-rc3。
現時点の最新の正式版は 2 日前にリリースされた v1.9.3。
>カレントってなに？gitからクローンすると2.0になるけど？
「現時点で GitHub から Git のリポジトリのクローンを取得してビルドしてインストールすると 2.0 になる」という意味？
現時点で 2.0 は正式版ではなくて RC 版だよ。
https://github.com/git/git/releases
現時点の最新の 2.0 は 2日前にリリースされた v2.0.0-rc3。
現時点の最新の正式版は 2 日前にリリースされた v1.9.3。
395 ：デフォルトの名無しさん：2014/05/12(月) 16:08:54.91 ID:VMOJUad9
バグ修正が中心のリリースとなる「Git 1.9.3」が公開される
http://sourceforge.jp/magazine/14/05/12/152000
http://sourceforge.jp/magazine/14/05/12/152000
396 ：デフォルトの名無しさん：2014/05/13(火) 00:02:25.45 ID:cgdWIPbr
397 ：デフォルトの名無しさん：2014/05/13(火) 00:23:30.33 ID:Kbu/OO7P
カレントって普通は安定板stableの最新版じゃないの
テスト要素のあるrcやβは含まないんじゃないの
テスト要素のあるrcやβは含まないんじゃないの
398 ：デフォルトの名無しさん：2014/05/13(火) 00:36:15.98 ID:A9K77IIM
普通は安定版だよ
399 ：デフォルトの名無しさん：2014/05/13(火) 00:47:21.79 ID:V9w/ceW7
currentというとバージョン管理システムから持ってきた
開発版のソースを指すケースもあるな
*BSD方面とか
開発版のソースを指すケースもあるな
*BSD方面とか
400 ：デフォルトの名無しさん：2014/05/13(火) 01:02:23.02 ID:TNqok+m1
2.0を使ってるひとは、2.0がrc版だって認識して使ってるの？
401 ：デフォルトの名無しさん：2014/05/13(火) 01:09:14.75 ID:8hwDbhT0
RCというのはリリース候補。ベータ版よりも
完成度が高い、リリース版レベルのもののことだよ
完成度が高い、リリース版レベルのもののことだよ
402 ：デフォルトの名無しさん：2014/05/13(火) 01:09:32.07 ID:Kbu/OO7P
そりゃそうだろ
ソースからビルドするならタグから引っ張ってくるだろうし
ソースからビルドするならタグから引っ張ってくるだろうし
403 ：デフォルトの名無しさん：2014/05/13(火) 01:11:36.76 ID:Kbu/OO7P
>>401
v2.0.0はrcが1、2、3と出てるんですがそれは
v2.0.0はrcが1、2、3と出てるんですがそれは
404 ：デフォルトの名無しさん：2014/05/13(火) 01:19:56.17 ID:aq/kP6dx
405 ：デフォルトの名無しさん：2014/05/13(火) 01:21:40.67 ID:TNqok+m1
2.0で付加される新機能を早く使いたいとかGitのバグ取りに協力したいっていうなら理解できるんだけど、それ以外に2.0rcをあえて使う理由ってあるの？
406 ：デフォルトの名無しさん：2014/05/13(火) 05:43:56.92 ID:Tx8Pcw2g
自分が何かgitに関連するモノを作って自分以外の人に提供してるなら
最低でもRCの段階で問題無い事を確認しておきたいな
最低でもRCの段階で問題無い事を確認しておきたいな
407 ：デフォルトの名無しさん：2014/05/13(火) 12:15:49.81 ID:KvmMEOaQ
>>406
それは理解できる
でもこのスレの >>388 とか >>393 ってそういう感じじゃないんだよね
GitHubからクローン取得してビルドしたら2.0で、2.0がrcであることも知らないで使っている、そして2.0未満のバージョンのユーザを馬鹿にしている
こんな風に思えてしまう
それは理解できる
でもこのスレの >>388 とか >>393 ってそういう感じじゃないんだよね
GitHubからクローン取得してビルドしたら2.0で、2.0がrcであることも知らないで使っている、そして2.0未満のバージョンのユーザを馬鹿にしている
こんな風に思えてしまう
408 ：デフォルトの名無しさん：2014/05/13(火) 12:57:27.93 ID:0j07nOJV
データを蓄積するツールとして使ってるから安定版。俺はまだ1.7使ってるし。
409 ：デフォルトの名無しさん：2014/05/13(火) 13:06:38.35 ID:vRP8IXzs
410 ：デフォルトの名無しさん：2014/05/13(火) 13:14:13.76 ID:+cSIqVHp
gitでバージョン番号管理って、みんなどうやってる？
411 ：デフォルトの名無しさん：2014/05/13(火) 18:24:36.93 ID:A9K77IIM
vistaでgui使ってコミットするファイルの選択してたら固まりまくったんだけどなんなん
1.8.4で起きて1.9.2に更新しても再発した
もろもろ込みの15mくらいのexe
Git-1.8.4-preview20130916 → Git-1.9.2-preview20140411
1.8.4で起きて1.9.2に更新しても再発した
もろもろ込みの15mくらいのexe
Git-1.8.4-preview20130916 → Git-1.9.2-preview20140411
412 ：デフォルトの名無しさん：2014/05/13(火) 18:42:33.12 ID:KvmMEOaQ
>>409
了解
了解
413 ：デフォルトの名無しさん：2014/05/13(火) 20:58:37.93 ID:Xzl/NzK/
Gitのmasterはrcとはいえpuやnextに比べれば安定してんじゃねーの
あとGitはrcをリリース4 5週間前から毎週出すポリシーみたいだから、
rcの数が多いか少ないかで安定度は測れない。
一応今週末に正式リリース予定ぽいんで、
今週出なければなんかまずいバグが残ってるのかもね。
あとGitはrcをリリース4 5週間前から毎週出すポリシーみたいだから、
rcの数が多いか少ないかで安定度は測れない。
一応今週末に正式リリース予定ぽいんで、
今週出なければなんかまずいバグが残ってるのかもね。
414 ：デフォルトの名無しさん：2014/05/13(火) 21:43:52.50 ID:HfUZuSMx
gitをコンパイルして入れるときってユーザーはrootでやってますか？
415 ：デフォルトの名無しさん：2014/05/13(火) 21:58:13.25 ID:8hwDbhT0
416 ：デフォルトの名無しさん：2014/05/13(火) 22:42:01.92 ID:HfUZuSMx
debianです
ソースコードから入れる時って/usr/local/srcにいれてるんですが
ここ一般ユーザーだと書込できないんですよね
おまけにrootにsshの設定をしてないのでgit cloneできないし
rootにsshの設定をするべきではないらしいのでどうするのがいいのかわかりません
ソースコードから入れる時って/usr/local/srcにいれてるんですが
ここ一般ユーザーだと書込できないんですよね
おまけにrootにsshの設定をしてないのでgit cloneできないし
rootにsshの設定をするべきではないらしいのでどうするのがいいのかわかりません
417 ：デフォルトの名無しさん：2014/05/13(火) 22:48:27.73 ID:8hwDbhT0
debianなら /usr/local 以下は staff グループになってるでしょ？
なら自分をstaffグループに追加すればいいだけ。
まあ、俺は自分のhome以下でコンパイルするけど。
なんかさ、よくコマンド実行できなかった時、
グループに追加すればいいのに、すぐsudo使う人いるよね。
なら自分をstaffグループに追加すればいいだけ。
まあ、俺は自分のhome以下でコンパイルするけど。
なんかさ、よくコマンド実行できなかった時、
グループに追加すればいいのに、すぐsudo使う人いるよね。
418 ：デフォルトの名無しさん：2014/05/13(火) 22:49:46.52 ID:tJgFTBc/
ソースなんてどこに入れてもいいし、バイナリやライブラリもパス通ってるならどこでもいい
419 ：デフォルトの名無しさん：2014/05/13(火) 22:49:59.25 ID:tmdhIwHM
なんか呼ばれたような気がしたので
420 ：デフォルトの名無しさん：2014/05/13(火) 23:30:22.27 ID:HfUZuSMx
なんかエラーで全然ここに書込ができません
ありがとうございます
あとはlinxuできいてきます
ありがとうございます
あとはlinxuできいてきます
421 ：デフォルトの名無しさん：2014/05/14(水) 00:59:32.71 ID:N43CNidq
Git の公式の文書ではソースからのインストールの例として sudo を使ってるけどね。
http://git-scm.com/book/en/Getting-Started-Installing-Git
http://git-scm.com/book/en/Getting-Started-Installing-Git
422 ：デフォルトの名無しさん：2014/05/14(水) 01:46:24.51 ID:ToGrq+HN
>>410
リリース番号とかなら、CIツールのビルド番号とかでいいんじゃね
リリース番号とかなら、CIツールのビルド番号とかでいいんじゃね
423 ：デフォルトの名無しさん：2014/05/14(水) 02:13:25.97 ID:+eGAQ9pX
そもそも自分しか使わない PC で、いちいちグループに追加とかしてると、むなしくなってくるわ
sudo で十分だよ
sudo で十分だよ
424 ：デフォルトの名無しさん：2014/05/14(水) 02:48:09.56 ID:LFlUnuUg
sudo & パスワード打つのが面倒だろ？
楽な方を提案してるんだよ。
楽な方を提案してるんだよ。
425 ：デフォルトの名無しさん：2014/05/14(水) 02:49:32.86 ID:TJ8LcHmI
もうrootになっちゃえよ。
426 ：デフォルトの名無しさん：2014/05/14(水) 02:51:54.81 ID:EH48jFeA
侵入されたら即乗っ取られそうなインターネッツですね
427 ：デフォルトの名無しさん：2014/05/14(水) 03:03:17.35 ID:LFlUnuUg
>>425
それはだめ。
root使うなって流れでsudoなんだろうけど、
なんでもsudo使ってたら意味ないって。
そのうち普通のコマンドまでsudo使う癖がつくとかな。
sudoつかってホームディレクトリ以下にファイルやディレクトリを
作るもんだから、自分のファイルを編集できないとかアホなことにｗ
それはだめ。
root使うなって流れでsudoなんだろうけど、
なんでもsudo使ってたら意味ないって。
そのうち普通のコマンドまでsudo使う癖がつくとかな。
sudoつかってホームディレクトリ以下にファイルやディレクトリを
作るもんだから、自分のファイルを編集できないとかアホなことにｗ
428 ：デフォルトの名無しさん：2014/05/14(水) 04:42:12.31 ID:8Tw5p8Hi
一般ユーザの権限増やしちゃうほうが余程ダメだろ
確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
…でも、そこでそのファイルの所有者を自分に戻す方法や
どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
「一般ユーザの権限を増やしちゃえ」
ってやるのは思考停止だと思うよ、root常用と発想が変わらない
確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
…でも、そこでそのファイルの所有者を自分に戻す方法や
どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
「一般ユーザの権限を増やしちゃえ」
ってやるのは思考停止だと思うよ、root常用と発想が変わらない
429 ：デフォルトの名無しさん：2014/05/14(水) 05:13:22.04 ID:TJ8LcHmI
普通にrootでapt-getしてstaffなユーザでgit使ったらいいんじゃないの。
staffグループに入れるのすら嫌うのにsudoersに入ってるってどゆことよ。
staffグループに入れるのすら嫌うのにsudoersに入ってるってどゆことよ。
430 ：デフォルトの名無しさん：2014/05/14(水) 07:50:49.18 ID:gY3lBZ4/
GUI があって sudoers 弄ってる認識ないとか。
431 ：デフォルトの名無しさん：2014/05/14(水) 07:51:39.21 ID:HVjR+QBF
432 ：デフォルトの名無しさん：2014/05/14(水) 08:16:46.96 ID:1MSvyiHJ
脱線はそのくらいで
433 ：デフォルトの名無しさん：2014/05/14(水) 10:07:15.20 ID:LFlUnuUg
434 ：デフォルトの名無しさん：2014/05/14(水) 10:21:07.79 ID:U/CskQfB
そもそもlinux公式のパッケージなんて古いのに誰が使うんだよ
俺が使ってるのディストリのは1.7だぞ
OpenSSLの件もあるのに今1.9.1以下を使ってる奴は世界の地雷
俺が使ってるのディストリのは1.7だぞ
OpenSSLの件もあるのに今1.9.1以下を使ってる奴は世界の地雷
435 ：デフォルトの名無しさん：2014/05/14(水) 10:50:10.78 ID:tkkbE9ax
権限設定が大雑把すぎる
rootにならないと何もできない
rootにならないと何もできない
436 ：デフォルトの名無しさん：2014/05/14(水) 11:53:53.82 ID:HVjR+QBF
437 ：デフォルトの名無しさん：2014/05/14(水) 13:19:05.91 ID:LFlUnuUg
438 ：デフォルトの名無しさん：2014/05/14(水) 14:37:13.29 ID:RXztcnfz
439 ：デフォルトの名無しさん：2014/05/14(水) 15:57:03.71 ID:z8cZm/fT
スクリプトの中でsudo書いたら負け
440 ：デフォルトの名無しさん：2014/05/14(水) 18:43:36.40 ID:HVjR+QBF
>>437
ひょっとして皮肉って、わからなかったのか？ (w
ひょっとして皮肉って、わからなかったのか？ (w
441 ：デフォルトの名無しさん：2014/05/14(水) 19:12:13.53 ID:56gZpWss
どうでもいい
442 ：デフォルトの名無しさん：2014/05/14(水) 19:45:20.61 ID:LYwl2FB3
相談させてください。
開発ブランチをmasterへマージしたいのですが、
masterブランチがかなり進んでしまい、開発ブランチとの共通コミットがかなり前の物となってしまいました・・・
このままマージすると履歴が見づらいので、masterでリベースをしたいのですが、
開発ブランチにも、沢山のマージコミットがあり、そのままリベースするとマージコミットが吹き飛んで困ります。
マージコミットを残したままで、masterとリベースする方法というのはあるでしょうか？
もし、そのような方法がない場合・・・
どのようにすれば、少しでも見やすい履歴として残してマージする事ができるのでしょうか・・・
よろしくお願いします
開発ブランチをmasterへマージしたいのですが、
masterブランチがかなり進んでしまい、開発ブランチとの共通コミットがかなり前の物となってしまいました・・・
このままマージすると履歴が見づらいので、masterでリベースをしたいのですが、
開発ブランチにも、沢山のマージコミットがあり、そのままリベースするとマージコミットが吹き飛んで困ります。
マージコミットを残したままで、masterとリベースする方法というのはあるでしょうか？
もし、そのような方法がない場合・・・
どのようにすれば、少しでも見やすい履歴として残してマージする事ができるのでしょうか・・・
よろしくお願いします
443 ：デフォルトの名無しさん：2014/05/14(水) 20:19:17.04 ID:NgeMMujl
マージじゃあかんのか？
444 ：デフォルトの名無しさん：2014/05/14(水) 20:37:04.99 ID:W0xDTkwU
--preserve-merges で ggrks
445 ：デフォルトの名無しさん：2014/05/14(水) 20:38:55.41 ID:W0xDTkwU
だけど俺もマージをおすすめする
446 ：デフォルトの名無しさん：2014/05/14(水) 20:59:04.67 ID:LYwl2FB3
>>443-445
お答えありがとうございます
まさしく、--preserve-merges この機能を求めていました！
本当に助かりました
普通にマージでも、運用はまったく問題ありません。
しかし、あまりに前のコミットからブランチが切れている物なので、
グラフ上でその他のマージしたコミットなどを、またぎまくりで見るのた大変な状態でした・・・
本当に感謝です
お答えありがとうございます
まさしく、--preserve-merges この機能を求めていました！
本当に助かりました
普通にマージでも、運用はまったく問題ありません。
しかし、あまりに前のコミットからブランチが切れている物なので、
グラフ上でその他のマージしたコミットなどを、またぎまくりで見るのた大変な状態でした・・・
本当に感謝です
447 ：デフォルトの名無しさん：2014/05/14(水) 21:21:30.74 ID:Tc6rr+/g
男なら履歴をいじってんじゃねえよ！
448 ：デフォルトの名無しさん：2014/05/14(水) 22:35:14.87 ID:XlAO72qf
http://git-scm.com/download/gui/win
ここにTortoiseGitないのは何で？
ここにTortoiseGitないのは何で？
449 ：デフォルトの名無しさん：2014/05/14(水) 23:23:23.76 ID:LFlUnuUg
>>428
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
意味不明。
今の話はsudo権限で書き込める人に対して
sudo使うな一般ユーザー権限でコマンド使えるようにしろって話だから。
誰もsudo権限ない人に権限与えろなんて言ってねーよｗ
> …でも、そこでそのファイルの所有者を自分に戻す方法や
> どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
> 「一般ユーザの権限を増やしちゃえ」
> ってやるのは思考停止だと思うよ、root常用と発想が変わらない
そんな話してないけどねｗ
sudo使って権限を変える行為のがroot常用と同じだから
sudoも使わずに一般ユーザーでやれるようにしろと。
ユーザに必要な権限を与えるのは、必要で許されるならば何の問題もなく、
権限を与えなければ、sudo使うしか無いわけでそれがroot使ってるのと変わらない。
っていうか、sudo常用＝root常用ってわかってる？
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
意味不明。
今の話はsudo権限で書き込める人に対して
sudo使うな一般ユーザー権限でコマンド使えるようにしろって話だから。
誰もsudo権限ない人に権限与えろなんて言ってねーよｗ
> …でも、そこでそのファイルの所有者を自分に戻す方法や
> どうすれば一般ユーザのファイルとして作れるのかを考えず調べずに
> 「一般ユーザの権限を増やしちゃえ」
> ってやるのは思考停止だと思うよ、root常用と発想が変わらない
そんな話してないけどねｗ
sudo使って権限を変える行為のがroot常用と同じだから
sudoも使わずに一般ユーザーでやれるようにしろと。
ユーザに必要な権限を与えるのは、必要で許されるならば何の問題もなく、
権限を与えなければ、sudo使うしか無いわけでそれがroot使ってるのと変わらない。
っていうか、sudo常用＝root常用ってわかってる？
450 ：デフォルトの名無しさん：2014/05/14(水) 23:36:27.18 ID:ExP2CQtU
a.phpを修正(50行)した後にb.php(500行)を修正しました
このときgit add a.php; git commit -m "a.phpを修正"したあとにgit checkout -fしたらどうなりますか？
このときgit add a.php; git commit -m "a.phpを修正"したあとにgit checkout -fしたらどうなりますか？
451 ：デフォルトの名無しさん：2014/05/14(水) 23:36:39.56 ID:EH48jFeA
クソニートの戯言はチラシの裏にでも書いてくださいね
452 ：デフォルトの名無しさん：2014/05/14(水) 23:38:18.31 ID:EH48jFeA
>>449宛て
453 ：デフォルトの名無しさん：2014/05/14(水) 23:45:05.68 ID:LFlUnuUg
煽って何がしたいの？ｗ
454 ：デフォルトの名無しさん：2014/05/14(水) 23:48:28.71 ID:PSOih+2g
今週の中学生日記はここですか
455 ：デフォルトの名無しさん：2014/05/15(木) 00:44:28.26 ID:YRo5/B9y
456 ：デフォルトの名無しさん：2014/05/15(木) 01:08:22.07 ID:p6ZJAeXV
>>449
> っていうか、sudo常用＝root常用ってわかってる？
こういう奴って /etc/sudoers の ALL = (ALL) ALL をおまじないだと思ってるんだろうな...
能力のないものには、いい道具与えても無駄なのがよくわかるな (w
> っていうか、sudo常用＝root常用ってわかってる？
こういう奴って /etc/sudoers の ALL = (ALL) ALL をおまじないだと思ってるんだろうな...
能力のないものには、いい道具与えても無駄なのがよくわかるな (w
457 ：デフォルトの名無しさん：2014/05/15(木) 01:23:15.29 ID:FUoGOy6E
>>456
本当にsudo常用がroot常用と変わらないの分からないの？
sudo touch a ってやったら、root:rootでファイル作られるよね？
sudoはなるべくrootにならずに、root権限（ユーザー未指定の場合）で
実行するものであって、結局のところrootで実行しているのと同じ。
sudoを常用したら意味がないんだけど。
なんでもかんでもsudo使って"root権限で実行"するのではなく
適切な権限を指定しなさいと言ってる。
本当にsudo常用がroot常用と変わらないの分からないの？
sudo touch a ってやったら、root:rootでファイル作られるよね？
sudoはなるべくrootにならずに、root権限（ユーザー未指定の場合）で
実行するものであって、結局のところrootで実行しているのと同じ。
sudoを常用したら意味がないんだけど。
なんでもかんでもsudo使って"root権限で実行"するのではなく
適切な権限を指定しなさいと言ってる。
458 ：デフォルトの名無しさん：2014/05/15(木) 01:45:41.47 ID:p6ZJAeXV
>>457
> sudo touch a ってやったら、root:rootでファイル作られるよね？
お前俺のレスの意味わかってないだろ (w
touch でファイル作られるのが嫌なら禁止すればいいだけ
ALL = (ALL) ALL って書いといて、root 常用と同じとか、バカすぎ
> sudo touch a ってやったら、root:rootでファイル作られるよね？
お前俺のレスの意味わかってないだろ (w
touch でファイル作られるのが嫌なら禁止すればいいだけ
ALL = (ALL) ALL って書いといて、root 常用と同じとか、バカすぎ
459 ：デフォルトの名無しさん：2014/05/15(木) 02:11:34.74 ID:t+uv2X5h
「俺のレス」
くさかべ先生が怒りそう
くさかべ先生が怒りそう
460 ：デフォルトの名無しさん：2014/05/15(木) 02:39:04.28 ID:mVM4WfmV
そういうことにしたいのでつね
461 ：デフォルトの名無しさん：2014/05/15(木) 03:28:24.48 ID:FUoGOy6E
>>458
お前根本的に間違ってるじゃんか。
/usr/local/srcへの書き込みだぞ。
実行コマンドを制限してどうする。
こういう時はグループで書き込み権限を与えるんだよ。
sudo使うにしても結局グループ使うんだから、
sudoの前にまずグループだろうが。
お前根本的に間違ってるじゃんか。
/usr/local/srcへの書き込みだぞ。
実行コマンドを制限してどうする。
こういう時はグループで書き込み権限を与えるんだよ。
sudo使うにしても結局グループ使うんだから、
sudoの前にまずグループだろうが。
462 ：デフォルトの名無しさん：2014/05/15(木) 07:07:31.46 ID:p6ZJAeXV
>>461
> /usr/local/srcへの書き込みだぞ。
俺はそんな話してない。
俺は、
> っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
ちなみに sudo はグループでもユーザーでも指定して制御できるから
> sudo使うにしても結局グループ使うんだから、
は、根本的に間違ってる。
なので、
> お前根本的に間違ってるじゃんか。
これはお返ししておくよ (w
> /usr/local/srcへの書き込みだぞ。
俺はそんな話してない。
俺は、
> っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
ちなみに sudo はグループでもユーザーでも指定して制御できるから
> sudo使うにしても結局グループ使うんだから、
は、根本的に間違ってる。
なので、
> お前根本的に間違ってるじゃんか。
これはお返ししておくよ (w
463 ：デフォルトの名無しさん：2014/05/15(木) 07:10:12.05 ID:ARfjiSB0
ブランチ名に日本語使ったりする？
464 ：デフォルトの名無しさん：2014/05/15(木) 09:03:46.47 ID:FUoGOy6E
>>462
> 俺はそんな話してない。
そもそもそれが間違ってるじゃないか。
話の流れを読め。
最初の >>416 は ファイルを書き込む権限の話。
> ソースコードから入れる時って/usr/local/srcにいれてるんですが
> ここ一般ユーザーだと書込できないんですよね
>>428 でもファイルを書き込む権限の話。
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
> 確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
最初っから、ファイルの権限の話なんだよ。
> 俺はそんな話してない。
そもそもそれが間違ってるじゃないか。
話の流れを読め。
最初の >>416 は ファイルを書き込む権限の話。
> ソースコードから入れる時って/usr/local/srcにいれてるんですが
> ここ一般ユーザーだと書込できないんですよね
>>428 でもファイルを書き込む権限の話。
> 一般ユーザの権限増やしちゃうほうが余程ダメだろ
> 確かに初心者の頃には自分に弄れないファイル作ったりするもんさ
最初っから、ファイルの権限の話なんだよ。
465 ：デフォルトの名無しさん：2014/05/15(木) 09:14:11.31 ID:8qQimVf0
sudoをroot権限を与えること以外で使うなら
setuidで十分な事が多くね？
setuidで十分な事が多くね？
466 ：デフォルトの名無しさん：2014/05/15(木) 10:08:52.62 ID:uV6K9eLe
/usr/local/srcを一般ユーザーに権限与えるのってLinuxの意に反してないの？
rootしか書き込みできないのは意味があってそうなってるんじゃないの？
rootしか書き込みできないのは意味があってそうなってるんじゃないの？
467 ：デフォルトの名無しさん：2014/05/15(木) 10:20:43.45 ID:yW4QL04N
468 ：デフォルトの名無しさん：2014/05/15(木) 11:05:33.69 ID:l/v1SCMb
>>463
使わないなあ
使わないなあ
469 ：デフォルトの名無しさん：2014/05/15(木) 11:22:14.76 ID:uV6K9eLe
sqliteのデーターベースファイルに日々データを追加しているんですが
これもリポジトリで管理したほうがいいですか？
GitHubでこのファイルをみたことがないのでどうしたらいいのかわかりません
バックアップが目的なのでデータベースファイルを使ってるプロジェクトだけはzipで固めるべきか
これもリポジトリで管理したほうがいいですか？
GitHubでこのファイルをみたことがないのでどうしたらいいのかわかりません
バックアップが目的なのでデータベースファイルを使ってるプロジェクトだけはzipで固めるべきか
470 ：デフォルトの名無しさん：2014/05/15(木) 11:46:35.53 ID:8MS98tJI
>>464
> 話の流れを読め。
そんな話には興味がない。
俺は単に、
> > っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
まあ、誤魔化そうと必死なのは伝わったよ (w
> 話の流れを読め。
そんな話には興味がない。
俺は単に、
> > っていうか、sudo常用＝root常用ってわかってる？
がおかしいって言ってるだけ。
まあ、誤魔化そうと必死なのは伝わったよ (w
471 ：デフォルトの名無しさん：2014/05/15(木) 11:55:39.44 ID:WbHEhbR4
472 ：デフォルトの名無しさん：2014/05/15(木) 14:32:57.85 ID:R166abH9
473 ：デフォルトの名無しさん：2014/05/15(木) 18:07:08.81 ID:Q6tngT9B
testブランチからmasterブランチにマージすると
testブランチのコミットログがmasterブランチのコミットログと合体しますよね
だからここのスレの先輩方はrebaseしろって書かれているのでrebaseしようとおもうんですが
rebaseしたらtestブランチのいままでのコミットログはgit logで見れなくなりますよね
testブランチのコミットログがmasterブランチのコミットログと合体しますよね
だからここのスレの先輩方はrebaseしろって書かれているのでrebaseしようとおもうんですが
rebaseしたらtestブランチのいままでのコミットログはgit logで見れなくなりますよね
474 ：デフォルトの名無しさん：2014/05/15(木) 19:20:39.33 ID:dmANjRi5
475 ：デフォルトの名無しさん：2014/05/15(木) 21:37:37.22 ID:7ICa3Xuq
>>465
-gで、プライマリグループを変更して実行することはある。
newgrpとかsgコマンド知らなかったから。
すれ違いなのはわかっているがこれだけはいわせてくれ
passwdとsudordersの編集は、実行できないようにしとけ？
-gで、プライマリグループを変更して実行することはある。
newgrpとかsgコマンド知らなかったから。
すれ違いなのはわかっているがこれだけはいわせてくれ
passwdとsudordersの編集は、実行できないようにしとけ？
476 ：デフォルトの名無しさん：2014/05/15(木) 22:41:35.54 ID:FUoGOy6E
477 ：デフォルトの名無しさん：2014/05/15(木) 22:42:32.59 ID:FUoGOy6E
478 ：デフォルトの名無しさん：2014/05/15(木) 23:02:53.18 ID:8MS98tJI
479 ：デフォルトの名無しさん：2014/05/15(木) 23:07:56.03 ID:UtPqEVIk
クッソくだらん喧嘩をだらだら続けるな
480 ：デフォルトの名無しさん：2014/05/15(木) 23:08:02.02 ID:FUoGOy6E
あ、常用してないんだｗ
481 ：デフォルトの名無しさん：2014/05/16(金) 09:08:26.94 ID:CZd6eAcT
FUoGOy6EはNG登録した
482 ：デフォルトの名無しさん：2014/05/16(金) 10:34:06.37 ID:ORK55gYr
NG登録した = もう反論はしない（見えないからできない）
なんだけどわかってるのかなぁ？ｗ
まあ、反論なければそのほうが俺は楽でいいけど。
なんだけどわかってるのかなぁ？ｗ
まあ、反論なければそのほうが俺は楽でいいけど。
483 ：デフォルトの名無しさん：2014/05/16(金) 15:03:25.79 ID:7k6X61nc
484 ：デフォルトの名無しさん：2014/05/16(金) 15:43:20.57 ID:T7U0JNMD
「反応しない」っていうのならレスするなよｗ
自分で言ったことぐらい守りましょう。
自分で言ったことぐらい守りましょう。
485 ：デフォルトの名無しさん：2014/05/16(金) 17:56:52.11 ID:w4POSpYE
C:￥ripo￥bbs￥.gitがリポジトリとします
これでコミットしまくったらコミットログがたまりますが、この状態でGitHubプッシュするとすべてのコミットログもGitHubにあがりますよね
朝昼晩とコミットしていてちょっと知り合いにコミットした時間を見られたら困る事情があるので
プッシュするまでのコミットログを全部まとめて一つに書きなおして毎日17:00にコミットしたことにしたいのですが、
いまあるコミットログはgit logで見られるようにしておきたいのでいじらずそのまま残しておきたいのです
こういう場合はどうしたらいいでしょうか？
これでコミットしまくったらコミットログがたまりますが、この状態でGitHubプッシュするとすべてのコミットログもGitHubにあがりますよね
朝昼晩とコミットしていてちょっと知り合いにコミットした時間を見られたら困る事情があるので
プッシュするまでのコミットログを全部まとめて一つに書きなおして毎日17:00にコミットしたことにしたいのですが、
いまあるコミットログはgit logで見られるようにしておきたいのでいじらずそのまま残しておきたいのです
こういう場合はどうしたらいいでしょうか？
486 ：デフォルトの名無しさん：2014/05/16(金) 17:58:05.13 ID:w4POSpYE
17:00にコミットというのは自分でコミットをするものだとお考えください
自動でコミットさせるという意味ではありません
とくに17:00ぴったりというわけじゃなくて夕方過ぎにコミットするものとお考え下さい
自動でコミットさせるという意味ではありません
とくに17:00ぴったりというわけじゃなくて夕方過ぎにコミットするものとお考え下さい
487 ：デフォルトの名無しさん：2014/05/16(金) 19:26:11.51 ID:XlirJvLT
夕方にしたコミットにsquashで朝昼のコミットをまとめればいいじゃないの
488 ：デフォルトの名無しさん：2014/05/16(金) 19:28:33.38 ID:XlirJvLT
コミットを自分のとこだけ残しておきたいならプッシュしないブランチを作ってそこで開発すればいいのよ
そのブランチからプッシュするブランチへマージするためのブランチを作ってそこでrebaseなりsquashなりでまとめてプッシュするブランチへマージ
そんでもってブッシュするの
そのブランチからプッシュするブランチへマージするためのブランチを作ってそこでrebaseなりsquashなりでまとめてプッシュするブランチへマージ
そんでもってブッシュするの
489 ：デフォルトの名無しさん：2014/05/16(金) 21:25:42.84 ID:eLIAKwa7
rebaseしてもauthor dateは変わらないんじゃなかったっけ？
490 ：デフォルトの名無しさん：2014/05/16(金) 21:50:47.36 ID:T7U0JNMD
コミット内容を修正すればさすがに変わるし、
reset authorすればよい
reset authorすればよい
491 ：デフォルトの名無しさん：2014/05/17(土) 15:46:53.71 ID:/Qeglujp
2.0 延期らしい。
今のところ来週リリースが目標ぽい
今のところ来週リリースが目標ぽい
492 ：デフォルトの名無しさん：2014/05/17(土) 15:51:50.79 ID:I7tMhMJh
来週もまた延期の予定です
493 ：デフォルトの名無しさん：2014/05/17(土) 23:27:35.62 ID:F+Anbw5h
何で日本人って見栄はってカタコトの英語でコミットログ書くんですか？
どうせ人様のに目にも止まらないようなプロジェクトなのに
見栄はってるんでしょうか？
どうせ人様のに目にも止まらないようなプロジェクトなのに
見栄はってるんでしょうか？
494 ：デフォルトの名無しさん：2014/05/17(土) 23:29:07.46 ID:PRZCp5x9
日本語入力に切り替えるのが面倒
495 ：デフォルトの名無しさん：2014/05/17(土) 23:29:43.34 ID:bTYlzCR2
496 ：デフォルトの名無しさん：2014/05/17(土) 23:32:20.96 ID:PRZCp5x9
文字コード的な問題を抱えてるとかじゃね
497 ：デフォルトの名無しさん：2014/05/17(土) 23:43:25.77 ID:wwvCM72E
英語で書いてると見栄張ってるっての、正に日本人的だよな
498 ：デフォルトの名無しさん：2014/05/17(土) 23:43:27.81 ID:AjJzM+jl
そういうのでハマっちゃうと時間食うからね。
本能的に避けちゃうんだな。
本能的に避けちゃうんだな。
499 ：デフォルトの名無しさん：2014/05/17(土) 23:43:48.41 ID:613Mhv1z
コミットログが日本語だと git format-patch のファイル名に反映されない
500 ：デフォルトの名無しさん：2014/05/18(日) 00:29:51.39 ID:ooDeoEJd
>>493
自分しか使わないので何も書いてません。
自分しか使わないので何も書いてません。
501 ：デフォルトの名無しさん：2014/05/18(日) 02:01:54.89 ID:xRvInDCX
502 ：デフォルトの名無しさん：2014/05/18(日) 02:07:17.49 ID:aiwStKdm
webブラウザで見たときに英語インターフェースの中に日本語があると浮くから
超てきとーな英語で入れてる
自分用だから自分が分かればいい
超てきとーな英語で入れてる
自分用だから自分が分かればいい
503 ：デフォルトの名無しさん：2014/05/18(日) 03:37:28.40 ID:WINLDOAf
文字化け面倒くさいしな
技術英語でカタコトもくそもないし
技術英語でカタコトもくそもないし
504 ：デフォルトの名無しさん：2014/05/18(日) 03:38:41.45 ID:XTSqz+Em
レガシーなコードがsjisだったりすると、マージの際にコミットログが化けて出る。
英語が書けなけりゃせめてローマ字で書いて。指差して笑うけど。
英語が書けなけりゃせめてローマ字で書いて。指差して笑うけど。
505 ：デフォルトの名無しさん：2014/05/18(日) 07:58:50.19 ID:7h87TJ0i
bagu fix
506 ：デフォルトの名無しさん：2014/05/18(日) 08:45:26.28 ID:8ZcupVW/
当たり前だけどUTF-8でログを書く事。
もしも文字化けとかしててもnkfとか使えば解決するだろ？
下手な英語で書かれるログより、日本語できちんと書かれているログの方が価値がある。
もしも文字化けとかしててもnkfとか使えば解決するだろ？
下手な英語で書かれるログより、日本語できちんと書かれているログの方が価値がある。
507 ：デフォルトの名無しさん：2014/05/18(日) 09:03:44.22 ID:Uw9b9LOt
当たり前だけどGitなどのバージョン管理システムを使う場合、プロジェクト管理規約を
遵守すべきであり規約としてプロジェクト内の公用語を定めるべきである。
プロジェクト内公用語で書かれていないログは、どんなに価値ある内容であっても
ログとしての価値はない。
遵守すべきであり規約としてプロジェクト内の公用語を定めるべきである。
プロジェクト内公用語で書かれていないログは、どんなに価値ある内容であっても
ログとしての価値はない。
508 ：デフォルトの名無しさん：2014/05/18(日) 09:23:04.68 ID:Fz0SuFV0
asciiの範囲内だけ使っておけば文字コード関係で変になる事がないｗ
509 ：デフォルトの名無しさん：2014/05/18(日) 09:40:24.61 ID:8ZcupVW/
>>507
ログの本来の意味を理解せず上辺だけの運用だとこんな感じになるんだろうな。
ログの本来の意味を理解せず上辺だけの運用だとこんな感じになるんだろうな。
510 ：デフォルトの名無しさん：2014/05/18(日) 09:40:34.69 ID:j5Z4jU9Z
fix bug
update function
add text
こんなわけのわからないログを書かれてもね
わかりもしない英語で加工として意味のないログを書く意味が本当にない
update function
add text
こんなわけのわからないログを書かれてもね
わかりもしない英語で加工として意味のないログを書く意味が本当にない
511 ：デフォルトの名無しさん：2014/05/18(日) 09:48:50.69 ID:Uw9b9LOt
512 ：デフォルトの名無しさん：2014/05/18(日) 09:59:41.25 ID:8ZcupVW/
>>511
ちょっと何言ってるのかわからないんですけど・・・
ログの本来の意味を理解しているのであれば、
価値ある内容のログを「ルールと違う方法で書いてるから無価値」なんて判断しないって事を言っている。
ちょっと何言ってるのかわからないんですけど・・・
ログの本来の意味を理解しているのであれば、
価値ある内容のログを「ルールと違う方法で書いてるから無価値」なんて判断しないって事を言っている。
513 ：デフォルトの名無しさん：2014/05/18(日) 10:02:50.82 ID:WINLDOAf
本来のログとして役立つ記録を
英語で書けばいいんじゃないの？
英語で書けばいいんじゃないの？
514 ：デフォルトの名無しさん：2014/05/18(日) 10:12:08.38 ID:Uw9b9LOt
いや、どんな言語で書くかではなくプロジェクト内で「通じる言語で」しかも当然ながら
ログとしての意味のある記録内容を記すべきなのである。
ログとしての意味のある記録内容を記すべきなのである。
515 ：デフォルトの名無しさん：2014/05/18(日) 10:16:46.89 ID:y7sacx+K
更新したファイル名と行番号を書いておくのが一番
516 ：デフォルトの名無しさん：2014/05/18(日) 10:23:08.05 ID:BMv+P6U/
mergeするかどうか、revertするかどうかの判断を
ログを眺めただけで出来れば十分
ログを眺めただけで出来れば十分
517 ：デフォルトの名無しさん：2014/05/18(日) 10:23:10.07 ID:c7NwufzX
変更の目的や意図を書くのが一番重要。
単なる変更点ならdiffを見ればいいから。
単なる変更点ならdiffを見ればいいから。
518 ：デフォルトの名無しさん：2014/05/18(日) 10:29:15.25 ID:y7sacx+K
diffで目的や意図が判ると良いね
519 ：デフォルトの名無しさん：2014/05/18(日) 10:47:04.48 ID:pcGkJ5So
diffで目的や意図は分からんけど、更新したファイル名と行番号だと分かるんだ。
普通の人はそうじゃないから。
普通の人はそうじゃないから。
520 ：デフォルトの名無しさん：2014/05/18(日) 11:03:38.19 ID:c7NwufzX
変更ファイルとか行数とか
わざわざ人間が書く必要ないと思うが。
わざわざ人間が書く必要ないと思うが。
521 ：デフォルトの名無しさん：2014/05/18(日) 11:13:05.15 ID:wDknVmCU
何やったか思い返すヒントになればいいんだから何でもいいんだよ。
522 ：デフォルトの名無しさん：2014/05/18(日) 11:15:16.01 ID:EPtn8OXu
523 ：デフォルトの名無しさん：2014/05/18(日) 11:19:18.17 ID:j5Z4jU9Z
別に英語で書くなって言ってないし
英語もわからない奴が英語でログ書くなって歯なし
英語もわからない奴が英語でログ書くなって歯なし
524 ：デフォルトの名無しさん：2014/05/18(日) 11:28:10.29 ID:Uw9b9LOt
>>522
プロジェクト公用語として、どのような基準を採用するか次第だ。
英語しか選択肢がないと考えがちなのがオープンソース界の悪習だ。
別に日本語のみに限定し、ソースコメントも日本語にすることすら
間違いではない、それをプロジェクト公用語と定めるならば。
プロジェクト公用語として、どのような基準を採用するか次第だ。
英語しか選択肢がないと考えがちなのがオープンソース界の悪習だ。
別に日本語のみに限定し、ソースコメントも日本語にすることすら
間違いではない、それをプロジェクト公用語と定めるならば。
525 ：デフォルトの名無しさん：2014/05/18(日) 11:43:23.99 ID:2P7J7VC/
文書以外で日本語なんて使う気しない
英語コンプはフォルダ名も日本語にしてるのかと
英語コンプはフォルダ名も日本語にしてるのかと
526 ：デフォルトの名無しさん：2014/05/18(日) 11:47:50.98 ID:Uw9b9LOt
527 ：デフォルトの名無しさん：2014/05/18(日) 11:55:22.75 ID:0kvX68pZ
528 ：デフォルトの名無しさん：2014/05/18(日) 13:28:14.89 ID:BExb4OPW
>>526
でも、元々の >>493 はそういう話じゃないんよね
別に日本語でも英語でもその変更がどういう意味なのか分かりゃいいワケで
何故か英語=見栄みたいな扱いにしちゃってるのはおかしいと思わね？
まあ >>493 の周囲には分かりにくいログが多いのだろうけど、そんな人は多分日本語でも似たようなことしか書かないんだろうし
でも、元々の >>493 はそういう話じゃないんよね
別に日本語でも英語でもその変更がどういう意味なのか分かりゃいいワケで
何故か英語=見栄みたいな扱いにしちゃってるのはおかしいと思わね？
まあ >>493 の周囲には分かりにくいログが多いのだろうけど、そんな人は多分日本語でも似たようなことしか書かないんだろうし
529 ：デフォルトの名無しさん：2014/05/18(日) 15:30:49.95 ID:UhKpQ7wy
Add text
みたいなログを書く人間が日本語でまともなログを書けるかなぁ？
プログラミングが出来るって事は、英単語が分からない訳じゃないだろうから、変更点を他人に伝える気自体が無いわけだろう
こんなの英語以前の問題だよ
Add main window toolbar button help text
みたいな糞でもログとして使えるし
みたいなログを書く人間が日本語でまともなログを書けるかなぁ？
プログラミングが出来るって事は、英単語が分からない訳じゃないだろうから、変更点を他人に伝える気自体が無いわけだろう
こんなの英語以前の問題だよ
Add main window toolbar button help text
みたいな糞でもログとして使えるし
530 ：デフォルトの名無しさん：2014/05/18(日) 15:36:35.81 ID:wDknVmCU
log言語の誕生である
531 ：デフォルトの名無しさん：2014/05/18(日) 15:48:36.89 ID:NSHOUep6
BTSを利用してる時でも、コミットログはさぼらない方がいいのかな？
532 ：デフォルトの名無しさん：2014/05/18(日) 15:57:35.48 ID:7v87Hd7x
533 ：デフォルトの名無しさん：2014/05/18(日) 16:41:15.58 ID:aiwStKdm
同僚に対する不満をここでぶちまけられても
俺らにはどうしようもないんだ
俺らにはどうしようもないんだ
534 ：デフォルトの名無しさん：2014/05/18(日) 17:56:48.01 ID:ItRorGEB
>>532
何を変更したのかがわからないクソログ
何を変更したのかがわからないクソログ
535 ：デフォルトの名無しさん：2014/05/18(日) 18:07:20.56 ID:4ihVJdEr
>>532
流石２ｃｈの管理人さんやで
流石２ｃｈの管理人さんやで
536 ：デフォルトの名無しさん：2014/05/18(日) 20:04:06.18 ID:XTSqz+Em
なんでこの変更が必要なのか書いてあればそれでいいや。
537 ：片山博文MZバグロボ ◆T6xkBnTXz7B0 ：2014/05/18(日) 21:11:53.29 ID:wTsBQBni
Gitでバージョン番号を管理する方法ないの？
538 ：デフォルトの名無しさん：2014/05/18(日) 21:16:22.56 ID:C9yMB7Be
539 ：片山博文MZバグロボ ◆T6xkBnTXz7B0 ：2014/05/18(日) 21:29:08.38 ID:wTsBQBni
コミットするたびにソース中のバージョン番号を自動的に更新して欲しい!!
540 ：デフォルトの名無しさん：2014/05/18(日) 21:40:01.78 ID:C9yMB7Be
541 ：デフォルトの名無しさん：2014/05/18(日) 21:40:35.24 ID:7v87Hd7x
prepare-commit-msgフックでコミットメッセージにバージョン番号でも入れりゃいいんじゃねえの
542 ：デフォルトの名無しさん：2014/05/18(日) 21:44:28.59 ID:C9yMB7Be
>>539
少しバージョン番号のつけ方の仕様を決めてくれないかな。
たとえば、仮にバージョン1のソースコードがあったとして、
それをAさんとBさんが個別に修正した時、
それぞれのバージョンはどうしますか？
少しバージョン番号のつけ方の仕様を決めてくれないかな。
たとえば、仮にバージョン1のソースコードがあったとして、
それをAさんとBさんが個別に修正した時、
それぞれのバージョンはどうしますか？
543 ：デフォルトの名無しさん：2014/05/18(日) 21:52:39.89 ID:wDknVmCU
アプリケーションでバージョン番号を持ってるファイルの更新だろな。
どっちかっつーとpush時な気がするな。
どっちかっつーとpush時な気がするな。
544 ：デフォルトの名無しさん：2014/05/18(日) 22:28:18.60 ID:C9yMB7Be
>>543
どういう運用にしたいかによるでしょうね。
git推奨でいえば、バージョン番号 = ハッシュID
この方法が優れているのは、ソースコードに何も書かないでいいし、
複数の人が平行で作業していても、バージョン番号がかぶることがないというメリットが有る。
git推奨の方法以外をやりたいのであれば、その仕様を決めてもらわないと答えようがない。
どういう運用にしたいかによるでしょうね。
git推奨でいえば、バージョン番号 = ハッシュID
この方法が優れているのは、ソースコードに何も書かないでいいし、
複数の人が平行で作業していても、バージョン番号がかぶることがないというメリットが有る。
git推奨の方法以外をやりたいのであれば、その仕様を決めてもらわないと答えようがない。
545 ：デフォルトの名無しさん：2014/05/18(日) 22:49:36.09 ID:7h87TJ0i
リリース前に、バージョン番号を格納するファイルを更新しpusu、そしてtagをつける
ってやってる
ってやってる
546 ：デフォルトの名無しさん：2014/05/18(日) 23:27:23.72 ID:WINLDOAf
547 ：デフォルトの名無しさん：2014/05/18(日) 23:43:08.76 ID:C9yMB7Be
548 ：デフォルトの名無しさん：2014/05/18(日) 23:53:30.20 ID:mKpMCPC5
推奨とか書いちゃうから
549 ：デフォルトの名無しさん：2014/05/19(月) 00:10:30.29 ID:Zm2k/WGd
550 ：デフォルトの名無しさん：2014/05/19(月) 00:16:41.33 ID:PiFbW4Gq
それこそフックで何らかのスクリプト走らすって話じゃね？
551 ：デフォルトの名無しさん：2014/05/19(月) 00:37:55.02 ID:2pHoKbmf
自動なのはビルドだけでバージョンは手でいいんじゃね
552 ：デフォルトの名無しさん：2014/05/19(月) 01:30:50.53 ID:boPMtkif
CIツールでやれ
553 ：デフォルトの名無しさん：2014/05/19(月) 02:00:24.75 ID:lhsjIgd7
時々さ、--versionってやると
バージョン番号としてコミットIDが
表示されるのあるじゃん？
あれってどうやってるの？
コミットしなければ現在の
コミットIDわからないはずなのに。
バージョン番号としてコミットIDが
表示されるのあるじゃん？
あれってどうやってるの？
コミットしなければ現在の
コミットIDわからないはずなのに。
554 ：デフォルトの名無しさん：2014/05/19(月) 03:20:50.33 ID:cOS2qM9v
>>553
それを表示するコードをビルド時にリポジトリ情報から自動生成すればいい
それを表示するコードをビルド時にリポジトリ情報から自動生成すればいい
555 ：デフォルトの名無しさん：2014/05/19(月) 05:02:24.66 ID:ZqE06A31
>>553
キーワード展開でググる。
キーワード展開でググる。
556 ：デフォルトの名無しさん：2014/05/19(月) 14:22:29.51 ID:nfghgbV/
>>493はまさにjap
557 ：デフォルトの名無しさん：2014/05/19(月) 21:43:58.04 ID:lhsjIgd7
558 ：デフォルトの名無しさん：2014/05/19(月) 21:56:35.02 ID:xEeDrkw/
そうだそうだ！
559 ：デフォルトの名無しさん：2014/05/19(月) 22:44:03.09 ID:cOS2qM9v
560 ：デフォルトの名無しさん：2014/05/20(火) 05:21:27.44 ID:7I4ys7NV
PHPerとかサーバで運用しているコードをそのままいじったりするから恐ろしい。
たまにgitにアプリのログやパスワードとか含まれてたりする。
たまにgitにアプリのログやパスワードとか含まれてたりする。
561 ：デフォルトの名無しさん：2014/05/20(火) 05:26:16.72 ID:Q2AhpEnY
> そのままいじったりする
どゆこと？
どゆこと？
562 ：デフォルトの名無しさん：2014/05/20(火) 07:18:02.19 ID:7I4ys7NV
>>561
運用と開発の環境が同じものってこと。バージョンとかでなくて、同一のリソース。
運用と開発の環境が同じものってこと。バージョンとかでなくて、同一のリソース。
563 ：デフォルトの名無しさん：2014/05/20(火) 07:41:36.00 ID:Q2AhpEnY
Webサーバとして公開してるディレクトリでgit initして開発してるってことか
564 ：デフォルトの名無しさん：2014/05/20(火) 08:24:11.40 ID:uQLrwk2U
>>563
git じゃなくて Subversion だけどテストサーバーはその運用だわ。
git じゃなくて Subversion だけどテストサーバーはその運用だわ。
565 ：デフォルトの名無しさん：2014/05/20(火) 12:10:11.33 ID:Y3VmLAx+
開発と運用を分ける場合ってどうやるんですか？
例えばC:￥apache2.2￥htdocs￥kaihatu￥.gitで作って
運用で動かすのはC:￥apache2.2￥htdocs￥honban￥.gitみたいにしたらいいですか？
honbanフォルダでhaihatuをcloneして動かすっていう感じでしょうか？
例えばC:￥apache2.2￥htdocs￥kaihatu￥.gitで作って
運用で動かすのはC:￥apache2.2￥htdocs￥honban￥.gitみたいにしたらいいですか？
honbanフォルダでhaihatuをcloneして動かすっていう感じでしょうか？
566 ：デフォルトの名無しさん：2014/05/20(火) 12:50:55.92 ID:fbMM1sIr
リポジトリの話と実行環境の話がごっちゃになっとる
567 ：デフォルトの名無しさん：2014/05/20(火) 13:32:57.00 ID:oqlsgWjt
ものにもよると思うが開発マシンでそのまま運用するとか恐ろしいな
568 ：デフォルトの名無しさん：2014/05/20(火) 16:19:48.21 ID:zD+BcsMh
これがDevOpsというやつか
569 ：デフォルトの名無しさん：2014/05/20(火) 17:18:53.44 ID:7I4ys7NV
git archiveで取り出して、テスト環境にインストールしてテストして、同じものを本番環境にインストールが普通だよな? 普通だと言ってくれ。
テスト環境でリポジトリから直接インストールは許す。
テスト環境でリポジトリから直接インストールは許す。
570 ：デフォルトの名無しさん：2014/05/20(火) 20:19:01.71 ID:7WHSNOxu
今の時代、スクリプト言語でもソースコードを
そのまま配置するとかやっちゃだめだよ。
デプロイはサーバーにログインして
git pullとかやっていいのは小学生までｗ
そのまま配置するとかやっちゃだめだよ。
デプロイはサーバーにログインして
git pullとかやっていいのは小学生までｗ
571 ：デフォルトの名無しさん：2014/05/20(火) 21:45:26.96 ID:+FFXBZCI
この話git関係ないだろ
572 ：デフォルトの名無しさん：2014/05/20(火) 22:09:24.93 ID:gHSFUybb
>>567
恐れるな！
恐れるな！
573 ：デフォルトの名無しさん：2014/05/20(火) 22:47:06.91 ID:w8F8fDtL
何のためのバージョン管理かわからんなｗ
問題出たら巻き戻せって事？
なんだかテストもしてなさそうｗ
問題出たら巻き戻せって事？
なんだかテストもしてなさそうｗ
574 ：デフォルトの名無しさん：2014/05/20(火) 23:20:14.34 ID:DeZ/1+VP
575 ：デフォルトの名無しさん：2014/05/20(火) 23:30:10.39 ID:oqlsgWjt
本番環境にgit pullでデプロイするのは.gitが残るから問題あるよね
テスト環境ならいいと思うけど
テスト環境ならいいと思うけど
576 ：デフォルトの名無しさん：2014/05/20(火) 23:45:03.16 ID:gZsncm2t
緊急事態が起こって巻き戻すぐらいならええじゃないか
デプロイした先の本番環境で頻繁に巻き戻さないといけない方が余程テスト不足では
デプロイした先の本番環境で頻繁に巻き戻さないといけない方が余程テスト不足では
577 ：デフォルトの名無しさん：2014/05/20(火) 23:54:11.31 ID:w8F8fDtL
本番サーバーがそのままリポジトリのマスターってのもありそう。
578 ：デフォルトの名無しさん：2014/05/20(火) 23:54:26.37 ID:4h/6mNTZ
GitHubでプルリクの流れがよく分かりません。
コミットするときはmasterではなくてbranchにしろとは聞いてますが、
自分が理解するところでは、
①フォークする
②ローカルにcloneで持ってくる
③リモートにフォーク元のmasterリポジトリをaddする
④ローカルにブランチを作る
⑤ローカルのブランチを修正する
⑥ローカルのブランチに変更をコミットする
⑦GitHubのブランチに変更をコミットする
⑧GitHubのフォーク元のmasterリポジトリにpull requestを出す
⑨マージされたらブランチを削除
⑩ローカルでfetchする
こんな感じになるんでしょうか？
コミットするときはmasterではなくてbranchにしろとは聞いてますが、
自分が理解するところでは、
①フォークする
②ローカルにcloneで持ってくる
③リモートにフォーク元のmasterリポジトリをaddする
④ローカルにブランチを作る
⑤ローカルのブランチを修正する
⑥ローカルのブランチに変更をコミットする
⑦GitHubのブランチに変更をコミットする
⑧GitHubのフォーク元のmasterリポジトリにpull requestを出す
⑨マージされたらブランチを削除
⑩ローカルでfetchする
こんな感じになるんでしょうか？
579 ：デフォルトの名無しさん：2014/05/20(火) 23:56:41.46 ID:Q2AhpEnY
580 ：デフォルトの名無しさん：2014/05/21(水) 01:08:18.51 ID:BNHZ/x8Q
最近気づいたけど変更したファイルだけコピーしたくてもxcopyじゃ出来んのな
チェックアウトでファイルの更新日時が更新されるとは
チェックアウトでファイルの更新日時が更新されるとは
581 ：デフォルトの名無しさん：2014/05/21(水) 01:29:27.63 ID:pe3xq3aD
582 ：デフォルトの名無しさん：2014/05/21(水) 02:14:07.74 ID:BNHZ/x8Q
言われてみればたしかにmakeするときはobjファイルとか別ブランチの状態になってたりするからそういう仕様でないと困るね
そのプロジェクトをgitで管理する前はxcopyで更新したファイルだけ移動してたけど移動には別手段考えるしかないか
そのプロジェクトをgitで管理する前はxcopyで更新したファイルだけ移動してたけど移動には別手段考えるしかないか
583 ：デフォルトの名無しさん：2014/05/21(水) 02:20:38.03 ID:5sngE80p
gitにかぎらずだけど、よく考えて作られてるわ。
時たまgitのやり方に合わないやり方をしたいっていう人がいるけど、
よく考えて作られたgitがどうしてそうなっているのかを
考えたほうがいいと思う。
時たまgitのやり方に合わないやり方をしたいっていう人がいるけど、
よく考えて作られたgitがどうしてそうなっているのかを
考えたほうがいいと思う。
584 ：デフォルトの名無しさん：2014/05/21(水) 02:45:19.12 ID:Cs2Lb6yD
585 ：デフォルトの名無しさん：2014/05/21(水) 04:29:31.39 ID:sT3o3DmA
gitと全然関係ないGitHub固有のサービスの話題もここで扱う気なの？
GitHubPagesやGistsやissueやwikiやOrganizationや有料サービスについてや
色々とあると思うんだけど
GitHubPagesやGistsやissueやwikiやOrganizationや有料サービスについてや
色々とあると思うんだけど
586 ：デフォルトの名無しさん：2014/05/21(水) 10:49:12.08 ID:/08zgsVl
とにかくどうしたらいいのかおしえてくだしあ
588 ：デフォルトの名無しさん：2014/05/21(水) 18:08:59.27 ID:T6zeFgZl
ゆとりはgitって名前が付いてるからgithubもこのスレでいいじゃないかっていうけど
そうやって幅を広くすると俺みたいなカスの質問が流れるか軽くあしらわれてしまうのでやめてほしい
そうやって幅を広くすると俺みたいなカスの質問が流れるか軽くあしらわれてしまうのでやめてほしい
589 ：デフォルトの名無しさん：2014/05/21(水) 19:43:13.07 ID:nqnjC0dU
Git 2.0-rc4 リリース
https://github.com/git/git/releases/tag/v2.0.0-rc4
https://github.com/git/git/releases/tag/v2.0.0-rc4
590 ：デフォルトの名無しさん：2014/05/21(水) 19:55:42.24 ID:rgBB9OCe
gitみたいなバージョン管理ソフトで、
rc版使う奴ってどういう奴なの？
もしも不具合とかで全部吹っ飛んだりしたらどうすんの？
バックアップとてたとしても、そんな面倒な事してまで使う物なの？
なんなの？ばかなの？しぬの？
rc版使う奴ってどういう奴なの？
もしも不具合とかで全部吹っ飛んだりしたらどうすんの？
バックアップとてたとしても、そんな面倒な事してまで使う物なの？
なんなの？ばかなの？しぬの？
591 ：デフォルトの名無しさん：2014/05/21(水) 20:08:44.66 ID:MmHyni7x
>>590
人柱を大事にしろよボケ
人柱を大事にしろよボケ
592 ：デフォルトの名無しさん：2014/05/21(水) 20:18:33.19 ID:AVBbOV7Q
593 ：デフォルトの名無しさん：2014/05/21(水) 20:19:24.23 ID:AVBbOV7Q
594 ：デフォルトの名無しさん：2014/05/21(水) 21:09:00.37 ID:EKqVwxDb
最高に意地悪でひねくれたテストを見せてくれ。
595 ：デフォルトの名無しさん：2014/05/21(水) 21:15:19.41 ID:19taQ0OX
pushこまめにしてれば問題ない
596 ：デフォルトの名無しさん：2014/05/21(水) 21:16:23.33 ID:19taQ0OX
テスト環境のをすべてシンボリックリンク貼ればいいだろ
597 ：デフォルトの名無しさん：2014/05/21(水) 21:21:22.37 ID:OinoP915
gitoliteのやり方
https://github.com/sitaramc/gitolite
パッケージにインストール用スクリプトを追加、git cloneしてそのスクリプト実行
ていうかgit関係ない、zipで拾ってきても、git cloneやpullでも大事なのはソースとってきたあとの話
https://github.com/sitaramc/gitolite
パッケージにインストール用スクリプトを追加、git cloneしてそのスクリプト実行
ていうかgit関係ない、zipで拾ってきても、git cloneやpullでも大事なのはソースとってきたあとの話
598 ：デフォルトの名無しさん：2014/05/21(水) 21:44:31.28 ID:igdonOpP
>>590
gitは分散型だからユーザーが多くなれば多くなるほど
それぞれがバックアップを持っている。
だからたとえ一人が壊れても復旧可能。
そしてディスク壊れたらどうすんの？って話と一緒。
バックアップぐらいとれや。
gitは分散型だからユーザーが多くなれば多くなるほど
それぞれがバックアップを持っている。
だからたとえ一人が壊れても復旧可能。
そしてディスク壊れたらどうすんの？って話と一緒。
バックアップぐらいとれや。
599 ：デフォルトの名無しさん：2014/05/21(水) 22:58:13.70 ID:19taQ0OX
>>598
rails事件
rails事件
600 ：デフォルトの名無しさん：2014/05/21(水) 23:03:07.97 ID:igdonOpP
>>599
gitと関係ねーしｗ
gitと関係ねーしｗ
601 ：デフォルトの名無しさん：2014/05/22(木) 06:26:16.29 ID:JO7c/VLA
>>539
GitHubのGistみたいな感じ？あれもGitで実現されてるらしいけど
>>580-583
VSCの仕様はコンパイルする言語向けって感じで
更新したスクリプトファイル等だけを借りてるサーバーにアップロードしたいという需要には応えられない感じだな
需要としてはアップロードに通信量制限があるとかそういう感じ稀なケースくらいだろうからしかたないか
GitHubのGistみたいな感じ？あれもGitで実現されてるらしいけど
>>580-583
VSCの仕様はコンパイルする言語向けって感じで
更新したスクリプトファイル等だけを借りてるサーバーにアップロードしたいという需要には応えられない感じだな
需要としてはアップロードに通信量制限があるとかそういう感じ稀なケースくらいだろうからしかたないか
602 ：デフォルトの名無しさん：2014/05/22(木) 07:30:00.04 ID:O49mbUbG
603 ：デフォルトの名無しさん：2014/05/22(木) 08:00:54.05 ID:JO7c/VLA
なるほどね
簡易なftp通信ツールじゃなく同期ツールを使うのか
簡易なftp通信ツールじゃなく同期ツールを使うのか
604 ：デフォルトの名無しさん：2014/05/22(木) 08:43:15.77 ID:Md3S+Ay9
gitとgithubは(media)wikiとwikipediaのような関係かｗ
605 ：デフォルトの名無しさん：2014/05/22(木) 09:52:08.98 ID:8poss9h8
ふむ
606 ：デフォルトの名無しさん：2014/05/22(木) 17:52:05.88 ID:bnXb1Wgc
＞＞６０４
それはちがうね
wikipediaはmediawikiそのものだから
それはちがうね
wikipediaはmediawikiそのものだから
607 ：デフォルトの名無しさん：2014/05/22(木) 18:25:23.64 ID:uwnOnEuc
そういうこと言ってんじゃない
608 ：デフォルトの名無しさん：2014/05/22(木) 18:48:58.03 ID:2qkQcCiJ
>>601
>VSCの仕様はコンパイルする言語向けって感じで
>更新したスクリプトファイル等だけを借りてるサーバーにアップロードしたいという需要には応えられない感じだな
いや全然違うと思う
VCSが言語を選ぶとかじゃなくて、VCSに向かない作業をやってるのがダメなんでは？
そういうのは専用のデプロイ・デリバリツールを選ぶべき。
上の方で話題に出てた「ビルド時にリビジョン埋め込みたい」みたいな要望も
VCSじゃなくてビルドツール等が行うべき領域。
バージョン管理に向かない言語とかは特にないと思うな
ソースコードそのものがバイナリとかいうのがあるなら分からんけど・・・
あと細かい指摘ですまんがVCSのタイポだよな？
しばらくググって悩んじゃったじゃねーか
>VSCの仕様はコンパイルする言語向けって感じで
>更新したスクリプトファイル等だけを借りてるサーバーにアップロードしたいという需要には応えられない感じだな
いや全然違うと思う
VCSが言語を選ぶとかじゃなくて、VCSに向かない作業をやってるのがダメなんでは？
そういうのは専用のデプロイ・デリバリツールを選ぶべき。
上の方で話題に出てた「ビルド時にリビジョン埋め込みたい」みたいな要望も
VCSじゃなくてビルドツール等が行うべき領域。
バージョン管理に向かない言語とかは特にないと思うな
ソースコードそのものがバイナリとかいうのがあるなら分からんけど・・・
あと細かい指摘ですまんがVCSのタイポだよな？
しばらくググって悩んじゃったじゃねーか
609 ：デフォルトの名無しさん：2014/05/22(木) 18:54:11.54 ID:TFAWZMIx
610 ：デフォルトの名無しさん：2014/05/22(木) 19:22:23.11 ID:f81WwqvH
bitbucketが作ったstash3.0ってなに？
611 ：デフォルトの名無しさん：2014/05/23(金) 18:37:12.92 ID:pr4rIIld
developで開発中、急きょ必要がありmaster(stable)からfixブランチを切り修正masterにマージ
developでは弄ってるがfixでは弄って無いファイルの更新日時まで変更される(これはdevelopから切り替えた時点でおきるが)
ファイル更新日時だけでアップロードしようと思うと無理がある
developでは弄ってるがfixでは弄って無いファイルの更新日時まで変更される(これはdevelopから切り替えた時点でおきるが)
ファイル更新日時だけでアップロードしようと思うと無理がある
612 ：デフォルトの名無しさん：2014/05/23(金) 20:49:08.96 ID:3CistgHw
とうとうgit 2.0が
613 ：デフォルトの名無しさん：2014/05/24(土) 09:01:11.84 ID:9qFFfmjf
gitchainを知らなくていいのって小学生までだよね～
614 ：デフォルトの名無しさん：2014/05/24(土) 11:32:04.32 ID:4TNjChUa
>>601
コミットしたものをサーバーにアップロードしたいのか？
コミットする前にテストしたりするためにサーバーにアップロードしたいのか？どっちかよくわからないけど
前者なら作業用のリポジトリをクローンしたものをローカルに用意しといてpullしてxcopyすればいいし
後者ならムダだと思うかもしれないけど今の挙動のままが正解だと思う
checkoutしてタイムスタンプが更新されたファイルは転送されるべきなんだよ
コミットしたものをサーバーにアップロードしたいのか？
コミットする前にテストしたりするためにサーバーにアップロードしたいのか？どっちかよくわからないけど
前者なら作業用のリポジトリをクローンしたものをローカルに用意しといてpullしてxcopyすればいいし
後者ならムダだと思うかもしれないけど今の挙動のままが正解だと思う
checkoutしてタイムスタンプが更新されたファイルは転送されるべきなんだよ
615 ：デフォルトの名無しさん：2014/05/26(月) 16:40:41.53 ID:E/fV2vLO
git checkout -b topic_foo HEAD
git push origin topic_foo
というのをよくやるんですが、git push origin topic_foo をもっと簡潔にできますか？
具体的には topic_foo を省略したい。
初審者質問でごめんなさい！
git push origin topic_foo
というのをよくやるんですが、git push origin topic_foo をもっと簡潔にできますか？
具体的には topic_foo を省略したい。
初審者質問でごめんなさい！
616 ：デフォルトの名無しさん：2014/05/27(火) 03:17:32.65 ID:Ha9yhWBf
バッチにしろ
617 ：デフォルトの名無しさん：2014/05/27(火) 07:23:22.69 ID:CjDrbeGH
>>615
alias p="git push origin topic_foo"
alias p="git push origin topic_foo"
618 ：デフォルトの名無しさん：2014/05/27(火) 08:25:02.04 ID:aQ+mTKAT
619 ：デフォルトの名無しさん：2014/05/27(火) 09:36:32.14 ID:M7xuRdW4
>>616
必ずしも連続して実行するわけではないので、バッチでない方法がいいなあ。
git checkout はこれでいいと思うので、git push origin topic_foo が簡潔になるよい方法があれば教えてください。
（topic_fooが、実際にはけっこう長い名前なので、入力するのがめんどくさい）
必ずしも連続して実行するわけではないので、バッチでない方法がいいなあ。
git checkout はこれでいいと思うので、git push origin topic_foo が簡潔になるよい方法があれば教えてください。
（topic_fooが、実際にはけっこう長い名前なので、入力するのがめんどくさい）
620 ：デフォルトの名無しさん：2014/05/27(火) 11:40:51.59 ID:empqvUFR
>>615
> git checkout -b topic_foo HEAD
> git push origin topic_foo
> というのをよくやるんですが、git push origin topic_foo をもっと簡潔にできますか？
> 具体的には topic_foo を省略したい。
その前にHEADを省略しろよｗ
git checkout -b topic_foo
git push origin topic_foo
> git checkout -b topic_foo HEAD
> git push origin topic_foo
> というのをよくやるんですが、git push origin topic_foo をもっと簡潔にできますか？
> 具体的には topic_foo を省略したい。
その前にHEADを省略しろよｗ
git checkout -b topic_foo
git push origin topic_foo
621 ：デフォルトの名無しさん：2014/05/27(火) 11:41:37.17 ID:empqvUFR
> （topic_fooが、実際にはけっこう長い名前なので、入力するのがめんどくさい）
TABで補完すれば良い
TABで補完すれば良い
622 ：デフォルトの名無しさん：2014/05/27(火) 12:03:49.03 ID:aQ+mTKAT
>>618を設定しとけば、topic_fooを省略してgit push originでいける
remoteがoriginならこれも省略できるから、git pushでいい
remoteがoriginならこれも省略できるから、git pushでいい
623 ：デフォルトの名無しさん：2014/05/27(火) 16:10:42.92 ID:Ha9yhWBf
バッチすら作れないのか(笑)
619がしょぼいのか619が使ってるosがしょぼいのか(笑)
うちのvistaならファイルすら不要でランチャーにいくらでも作れるんだが(笑)
619がしょぼいのか619が使ってるosがしょぼいのか(笑)
うちのvistaならファイルすら不要でランチャーにいくらでも作れるんだが(笑)
624 ：デフォルトの名無しさん：2014/05/27(火) 18:36:54.81 ID:CjDrbeGH
vistaでなければ、バッチなんてめんどくさいもの作る必要すらない。
625 ：デフォルトの名無しさん：2014/05/27(火) 19:21:12.08 ID:Ha9yhWBf
いやいや面倒でもなければターミナルに切り替える必要もなくただボタン一つ押すだけだから(笑)
626 ：デフォルトの名無しさん：2014/05/27(火) 21:50:46.03 ID:x1QZTJwI
必ずしも連続して実行する訳ではない、と言われてるのに脳内で作れないって決めつけちゃうのヤバいな
これからの日本社会に必要な人材だ
これからの日本社会に必要な人材だ
627 ：デフォルトの名無しさん：2014/05/28(水) 02:29:31.61 ID:JqBWJ9I7
>>625
ボタン押すとかめんどくさすぎる
ボタン押すとかめんどくさすぎる
628 ：デフォルトの名無しさん：2014/05/28(水) 06:37:21.38 ID:3jHSpg0i
バッチってもしかしてブランチ毎に作るんか？ｗ
629 ：デフォルトの名無しさん：2014/05/28(水) 09:27:53.43 ID:CrCNX+z2
主となるブランチが１個なら別にいいだろ
630 ：デフォルトの名無しさん：2014/05/28(水) 09:47:28.15 ID:3jHSpg0i
元の質問はトピックブランチの話をしてるんだから
主となるブランチが1個とかじゃないだろｗ
主となるブランチが1個とかじゃないだろｗ
631 ：デフォルトの名無しさん：2014/05/28(水) 10:02:33.99 ID:TQzWSZnP
トピックブランチっていくつあるの？
632 ：デフォルトの名無しさん：2014/05/28(水) 10:44:05.28 ID:+VRaMc3N
そこからかよｗ
無知が提示する案ほど
迷惑なものはないよなｗ
無知が提示する案ほど
迷惑なものはないよなｗ
633 ：デフォルトの名無しさん：2014/05/28(水) 12:13:27.82 ID:zJ+uQAQa
でも結局>>618でFAだろ？
634 ：デフォルトの名無しさん：2014/05/28(水) 13:56:51.68 ID:3jHSpg0i
作ったトピックブランチを確実にpushする前提なら
(トピックブランチ作ったけどやっぱpushするのやめたーってのが無い前提なら)
push.default=currentにしなくてもpush.default=simpleで(2.0からのデフォルト)
ブランチ作ってすぐgit push -u origin topic_fooをやっとけばいい
それ以降はgit pushだけで済む
(トピックブランチ作ったけどやっぱpushするのやめたーってのが無い前提なら)
push.default=currentにしなくてもpush.default=simpleで(2.0からのデフォルト)
ブランチ作ってすぐgit push -u origin topic_fooをやっとけばいい
それ以降はgit pushだけで済む
635 ：デフォルトの名無しさん：2014/05/28(水) 15:03:48.65 ID:ioEFfNM4
コミットの回数とタグの数をそれぞれ取得する方法おしえて
636 ：デフォルトの名無しさん：2014/05/28(水) 15:29:40.52 ID:3jHSpg0i
コミットの回数
git rev-list --all --no-merges | wc -l
タグの数
git tag | wc -l
git rev-list --all --no-merges | wc -l
タグの数
git tag | wc -l
637 ：デフォルトの名無しさん：2014/05/29(木) 00:23:03.07 ID:RABmUlyV
git add .
git commit -m "前と同じ"
git rebase -i
git push origin <branch>
git rebase master
git push -f origin <branch>
今この状態で、流石にメッセージが前と同じではまずいので直前のコミットとsquashしたいのですが
git rebaseしたらこんなこと言われてしまいます
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-rebase(1) for details
git rebase <branch>
どうすればいいのでしょうか
git commit -m "前と同じ"
git rebase -i
git push origin <branch>
git rebase master
git push -f origin <branch>
今この状態で、流石にメッセージが前と同じではまずいので直前のコミットとsquashしたいのですが
git rebaseしたらこんなこと言われてしまいます
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-rebase(1) for details
git rebase <branch>
どうすればいいのでしょうか
638 ：デフォルトの名無しさん：2014/05/29(木) 00:35:18.93 ID:Kg1bZGF5
>公開リポジトリにプッシュしたコミットをリベースしてはいけない
>
>この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。
>
>この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。
639 ：デフォルトの名無しさん：2014/05/29(木) 00:40:14.69 ID:RABmUlyV
そうなったらまずはgit pushを取り消せばいいのでしょうか？
640 ：デフォルトの名無しさん：2014/05/29(木) 00:59:18.64 ID:erdIUEhx
641 ：デフォルトの名無しさん：2014/05/29(木) 01:05:45.72 ID:bLCAImAr
wcは引数じゃないだろ
642 ：デフォルトの名無しさん：2014/05/29(木) 01:25:09.99 ID:/G0dYxTO
unix使いの大好きなシェル芸
643 ：デフォルトの名無しさん：2014/05/29(木) 02:00:42.20 ID:yg8neWnh
>>640
つ alias
つ alias
644 ：デフォルトの名無しさん：2014/05/29(木) 07:45:11.40 ID:QPTL35Py
645 ：デフォルトの名無しさん：2014/05/29(木) 08:39:11.17 ID:A6IQETei
シェルの引数ってなんだ？wcはただのコマンドだぞ
646 ：デフォルトの名無しさん：2014/05/29(木) 08:42:01.31 ID:dDbteSWz
>>645
シェルへの引数と言いたかったんじゃないの？
シェルへの引数と言いたかったんじゃないの？
647 ：デフォルトの名無しさん：2014/05/29(木) 08:45:00.26 ID:A6IQETei
シェルへ引数なんて渡してないし
648 ：デフォルトの名無しさん：2014/05/29(木) 09:10:15.42 ID:A6IQETei
>>637
git rebaseの引数省略しすぎ
git rebaseの引数省略しすぎ
649 ：デフォルトの名無しさん：2014/05/29(木) 10:02:11.97 ID:bNL2V7UE
wcはトイレだわな
650 ：デフォルトの名無しさん：2014/05/29(木) 11:00:25.25 ID:QPTL35Py
651 ：デフォルトの名無しさん：2014/05/29(木) 11:05:28.42 ID:efebR6WC
Git 2.0.0 リリース
https://github.com/git/git/releases/tag/v2.0.0
https://github.com/git/git/releases/tag/v2.0.0
652 ：デフォルトの名無しさん：2014/05/29(木) 11:14:25.76 ID:1+PX4fUT
msysgitのv2.0.0はまだまだ先かな・・・
653 ：デフォルトの名無しさん：2014/05/29(木) 12:18:16.52 ID:JkDx0bBd
>>636で多いって言ってる人って、
リダイレクトやパイプって使ったことこないの？
Linuxを使う上での基礎。初心者レベルのことなんだが。
自己紹介よろしく。Linuxつかえませーんという自己紹介をしてくれｗ
リダイレクトやパイプって使ったことこないの？
Linuxを使う上での基礎。初心者レベルのことなんだが。
自己紹介よろしく。Linuxつかえませーんという自己紹介をしてくれｗ
654 ：デフォルトの名無しさん：2014/05/29(木) 12:31:49.12 ID:kyPc1SKC
それ「おまえが気持ちよくなれる」以外の何のメリットがあるんだ
655 ：デフォルトの名無しさん：2014/05/29(木) 12:49:31.76 ID:LpHrGA0w
シェル芸とかって言って煽る方もなんだかな。
commit-countとかどんどん増やしていってもきりがないし、どうしても専用コマンドを作らないといけないってもの以外は出力をパイプで処理とかでいいじゃん。
まあ>>635みたいな無能そうな奴の質問には答えないほうがいいのかもしれないな。答えても「わけわかめ」とか言われるんだからw
commit-countとかどんどん増やしていってもきりがないし、どうしても専用コマンドを作らないといけないってもの以外は出力をパイプで処理とかでいいじゃん。
まあ>>635みたいな無能そうな奴の質問には答えないほうがいいのかもしれないな。答えても「わけわかめ」とか言われるんだからw
656 ：デフォルトの名無しさん：2014/05/29(木) 13:45:23.70 ID:1vfDNvKU
コマンドが多機能になっても、単純なコマンド組み合わせた方がわかりやすいから、ついついパイプ使っちゃうな。
657 ：デフォルトの名無しさん：2014/05/29(木) 17:55:22.19 ID:urb8vROk
githubとかでもなんでもsshを使ってgitする方法が安全って言われているじゃないですか
んでsslキーっていうんですかid_rsaっていうファイルありますよね
こういうのをdropboxに置いて管理するのは間違ってますか？
んでsslキーっていうんですかid_rsaっていうファイルありますよね
こういうのをdropboxに置いて管理するのは間違ってますか？
658 ：デフォルトの名無しさん：2014/05/29(木) 18:38:10.80 ID:A6IQETei
>>657
sshのid_rsaファイルのことをsslキーなんて言わない
秘密鍵のid_rsaファイルは普通パスフレーズをつけて暗号化してあるけど、それでも他人から見えるとこに置くべきではない
dropboxは厳密に他人から見えない場所とは言い切れない
その鍵で何を管理してるかで鍵の取り扱い方針は決めるべき
sshのid_rsaファイルのことをsslキーなんて言わない
秘密鍵のid_rsaファイルは普通パスフレーズをつけて暗号化してあるけど、それでも他人から見えるとこに置くべきではない
dropboxは厳密に他人から見えない場所とは言い切れない
その鍵で何を管理してるかで鍵の取り扱い方針は決めるべき
659 ：デフォルトの名無しさん：2014/05/29(木) 19:01:58.24 ID:dDbteSWz
>>658
暗号化して置いておけばよくね？
暗号化して置いておけばよくね？
660 ：デフォルトの名無しさん：2014/05/29(木) 19:08:28.29 ID:urb8vROk
まじっすか
なんかdropboxで共有したらどの環境からでも接続できるよってブログを見かけたんですけどやっぱりセキュリティ的によくないですよね
なんかdropboxで共有したらどの環境からでも接続できるよってブログを見かけたんですけどやっぱりセキュリティ的によくないですよね
661 ：デフォルトの名無しさん：2014/05/29(木) 19:14:49.64 ID:A6IQETei
662 ：デフォルトの名無しさん：2014/05/29(木) 19:16:30.06 ID:Jpnwpx9o
安全のために鍵かけるなら鍵の扱いも安全にしろよｗ
というかid_rsaってPC外に出すもんじゃないんじゃないの？
というかid_rsaってPC外に出すもんじゃないんじゃないの？
663 ：デフォルトの名無しさん：2014/05/29(木) 19:17:11.95 ID:Jpnwpx9o
間違えた
×というかid_rsaってPC外に出すもんじゃないの？
○というかid_rsaってPC外に出さないもんじゃないの？
×というかid_rsaってPC外に出すもんじゃないの？
○というかid_rsaってPC外に出さないもんじゃないの？
664 ：デフォルトの名無しさん：2014/05/29(木) 19:21:19.75 ID:yBXBS2Lg
どうしても移動させるときは暗号化したUSBメモリ
一応パスワードは70文字にしています
パスワードはkeepassに保存していて、パスワードが保存されているデータベースと鍵ファイル？の２つもdropboxで共有しようと思ってました
パスワードはkeepassに保存していて、パスワードが保存されているデータベースと鍵ファイル？の２つもdropboxで共有しようと思ってました
666 ：デフォルトの名無しさん：2014/05/29(木) 19:48:26.76 ID:A6IQETei
667 ：デフォルトの名無しさん：2014/05/29(木) 19:50:15.90 ID:1vfDNvKU
>>659
オンラインの認証は、警備員の見てる前で金庫の暗証番号入力するようなもの。
dropboxや情報漏洩などで盗まれた暗号化された情報は、金庫を持ち帰って機械なども使って開けようとするもの。
警備員の見てる前でそんなことしたら捕まるが、持ち帰ればやりたい放題。
オンラインの認証は、警備員の見てる前で金庫の暗証番号入力するようなもの。
dropboxや情報漏洩などで盗まれた暗号化された情報は、金庫を持ち帰って機械なども使って開けようとするもの。
警備員の見てる前でそんなことしたら捕まるが、持ち帰ればやりたい放題。
668 ：デフォルトの名無しさん：2014/05/29(木) 19:53:24.06 ID:H5LJYYF1
>>666
マスターパスワードは4文字にしてます
マスターパスワードは4文字にしてます
669 ：デフォルトの名無しさん：2014/05/29(木) 19:58:00.86 ID:A6IQETei
>>668
最悪です。
最悪です。
670 ：デフォルトの名無しさん：2014/05/29(木) 20:07:59.65 ID:A6IQETei
>>668
最悪はちょっと言い過ぎたかもだけど
それは暗号化してない秘密鍵をdropboxに置いてるのとほぼ変わらない
つまり他人に見られる可能性のある場所に一般的なパスワードをそのまま置いてるのとほぼ同じ
最悪はちょっと言い過ぎたかもだけど
それは暗号化してない秘密鍵をdropboxに置いてるのとほぼ変わらない
つまり他人に見られる可能性のある場所に一般的なパスワードをそのまま置いてるのとほぼ同じ
671 ：デフォルトの名無しさん：2014/05/29(木) 20:14:11.97 ID:JkDx0bBd
いいえ、最悪です。
672 ：デフォルトの名無しさん：2014/05/29(木) 21:22:37.06 ID:H5LJYYF1
f
673 ：デフォルトの名無しさん：2014/05/30(金) 01:25:20.18 ID:EMzWDMfn
ファイルを作らないでgitに直接データをコミットする方法ありませんか？
rubyのgollumってgitでデータを管理しているそうでファイルを作らないでどうやってgitで管理しているのか疑問に思って質問しました
rubyのgollumってgitでデータを管理しているそうでファイルを作らないでどうやってgitで管理しているのか疑問に思って質問しました
674 ：デフォルトの名無しさん：2014/05/30(金) 01:33:04.77 ID:q6NHkjTH
あるブランチ上にある２つのコミットの間で変更・追加・削除・移動されたファイル名（ファイルパス）の一覧を表示する方法ありますか？
675 ：デフォルトの名無しさん：2014/05/30(金) 01:58:40.65 ID:fAx5Tsbo
>>674
git diff a..b --name-status
git diff a..b --name-status
676 ：デフォルトの名無しさん：2014/05/30(金) 02:07:01.03 ID:q6NHkjTH
677 ：デフォルトの名無しさん：2014/05/30(金) 02:31:09.91 ID:n9pxH6sn
>>673
patchを取り込むのってファイルなくてもできそうな気がするけど、どうだろう?
patchを取り込むのってファイルなくてもできそうな気がするけど、どうだろう?
678 ：デフォルトの名無しさん：2014/05/30(金) 08:32:01.24 ID:2GmvsnCC
>>673
gitのレポジトリの構造は簡単だから、レポジトリに直接アクセスするライブラリとか各種言語向けにいろいろ作られてる
gollumはrubyで書かれてて、rubyにはgritっていうレポジトリに直接アクセス可能なライブラリがあって、gollumもgritを使ってる
ここでたまに話がでるgitlabもgritを使ってるね
gitのレポジトリの構造は簡単だから、レポジトリに直接アクセスするライブラリとか各種言語向けにいろいろ作られてる
gollumはrubyで書かれてて、rubyにはgritっていうレポジトリに直接アクセス可能なライブラリがあって、gollumもgritを使ってる
ここでたまに話がでるgitlabもgritを使ってるね
679 ：デフォルトの名無しさん：2014/05/30(金) 10:42:47.22 ID:V58Lvn6/
>>678
おもしろそうなので grit を調べてみたら、grit はメンテナンスしてないので rugged を薦めてるね。
https://github.com/mojombo/grit/blob/master/README.md
grit
https://github.com/mojombo/grit
rugged
https://github.com/libgit2/rugged
おもしろそうなので grit を調べてみたら、grit はメンテナンスしてないので rugged を薦めてるね。
https://github.com/mojombo/grit/blob/master/README.md
grit
https://github.com/mojombo/grit
rugged
https://github.com/libgit2/rugged
680 ：デフォルトの名無しさん：2014/05/30(金) 12:04:19.72 ID:77FTxa6s
すげえそんなのあるのか
phpかpythonでそのライブラリってないっすか？
phpかpythonでそのライブラリってないっすか？
681 ：デフォルトの名無しさん：2014/05/30(金) 12:12:12.88 ID:wKr0dicp
rugged なら、その上のlibgit2下にずらっとあるけどそれでどうかな
682 ：デフォルトの名無しさん：2014/05/30(金) 13:43:32.48 ID:V58Lvn6/
>>680 >>681
libgit2 を使うなら PHP は php-git、Python は pygit2 だね。
libgit2
http://libgit2.github.com/
https://github.com/libgit2/libgit2
php-git
https://github.com/libgit2/php-git
pygit2
http://www.pygit2.org/
libgit2 を使うなら PHP は php-git、Python は pygit2 だね。
libgit2
http://libgit2.github.com/
https://github.com/libgit2/libgit2
php-git
https://github.com/libgit2/php-git
pygit2
http://www.pygit2.org/
683 ：デフォルトの名無しさん：2014/05/30(金) 13:53:45.96 ID:C8E1zgtw
どうもありがとう！
684 ：デフォルトの名無しさん：2014/05/30(金) 13:59:07.40 ID:v6d8zvnx
どうしたしまして！
685 ：デフォルトの名無しさん：2014/05/30(金) 14:48:31.65 ID:2GmvsnCC
>>679
gritの本家は更新止まってるけど、gitlabがforkしてメンテしてる
https://github.com/gitlabhq/grit
RubyGemsからはgitlab-gritの名前でインストールできる
https://rubygems.org/gems/gitlab-grit
gritの本家は更新止まってるけど、gitlabがforkしてメンテしてる
https://github.com/gitlabhq/grit
RubyGemsからはgitlab-gritの名前でインストールできる
https://rubygems.org/gems/gitlab-grit
686 ：デフォルトの名無しさん：2014/05/30(金) 14:53:30.58 ID:V58Lvn6/
>>685
情報ありがとう
情報ありがとう
687 ：デフォルトの名無しさん：2014/05/30(金) 22:09:59.66 ID:v6d8zvnx
どうしたいしまして！
688 ：デフォルトの名無しさん：2014/05/30(金) 23:42:52.28 ID:VEn3EfW3
Python2/3のgitインターフェースはないですか？
できればbottleみたいにインストール不要なので
gitlib2のPythonバインディングはコンパイルが面倒でした
できればbottleみたいにインストール不要なので
gitlib2のPythonバインディングはコンパイルが面倒でした
689 ：デフォルトの名無しさん：2014/05/31(土) 09:09:25.27 ID:j/TOOJQQ
Git 2.0.0 がリリースされたけど 1.9.4 もリリース
https://github.com/git/git/releases/tag/v1.9.4
https://github.com/git/git/releases/tag/v1.9.4
690 ：デフォルトの名無しさん：2014/05/31(土) 10:26:04.90 ID:hQl0nrcC
なんでやねん
691 ：デフォルトの名無しさん：2014/05/31(土) 12:26:02.52 ID:Q8mJYa9Q
秘密鍵にパスフレーズ振ってるやつなんていねーよ……
692 ：デフォルトの名無しさん：2014/05/31(土) 12:28:52.59 ID:mt1wvbpO
ノートPCに秘密鍵入れといて
ノートPC盗難されたらどうするつもり？
ノートPC盗難されたらどうするつもり？
693 ：デフォルトの名無しさん：2014/05/31(土) 14:00:26.64 ID:3W9FVu4M
694 ：デフォルトの名無しさん：2014/05/31(土) 14:07:47.34 ID:bRH5rrCK
秘密鍵が盗まれたってそれがどこにつながる鍵なのかわからなければ悪用されないじゃん
695 ：デフォルトの名無しさん：2014/05/31(土) 14:08:43.81 ID:ZdLIEqhK
ところがどっこい
696 ：デフォルトの名無しさん：2014/05/31(土) 14:21:11.79 ID:orufI9PA
697 ：デフォルトの名無しさん：2014/05/31(土) 14:43:33.95 ID:bRH5rrCK
暗号化されたってログインされたら意味無いじゃん
698 ：デフォルトの名無しさん：2014/05/31(土) 14:50:07.85 ID:eTy5fHBW
>>696
truecrypt 終わったねえ
truecrypt 終わったねえ
699 ：デフォルトの名無しさん：2014/05/31(土) 16:59:58.04 ID:2ArsU7CW
2.0のリリースノートを機械翻訳したら、何かいろいろ速くしたって書いてあるようだけど
実際どうなんだ
実際どうなんだ
700 ：デフォルトの名無しさん：2014/06/01(日) 11:36:35.94 ID:zOVN/jYA
>>699
計れよ
計れよ
701 ：デフォルトの名無しさん：2014/06/01(日) 13:14:54.21 ID:SAafBPBX
てめーが、やれ
702 ：デフォルトの名無しさん：2014/06/01(日) 14:03:13.82 ID:dFCTVAji
703 ：デフォルトの名無しさん：2014/06/01(日) 14:18:12.44 ID:q7lY0P5T
>>702
裏 とか 対偶 とか知らんの？
裏 とか 対偶 とか知らんの？
704 ：デフォルトの名無しさん：2014/06/01(日) 14:18:29.63 ID:rJY7yXwk
yes
705 ：デフォルトの名無しさん：2014/06/01(日) 14:26:54.79 ID:X2VZJkGd
githubに登録してある公開鍵はすべて誰でも簡単に取得できるから、
秘密鍵が盗まれると簡単にイタズラ可能だよ
秘密鍵が盗まれると簡単にイタズラ可能だよ
706 ：デフォルトの名無しさん：2014/06/01(日) 14:33:26.05 ID:dFCTVAji
707 ：デフォルトの名無しさん：2014/06/01(日) 14:37:41.79 ID:rJY7yXwk
>>705
どうやって取得するの？
どうやって取得するの？
708 ：デフォルトの名無しさん：2014/06/01(日) 14:38:31.41 ID:dFCTVAji
1. パスワードが盗まれたってそれがどこのパスワードかわからなければ悪用されないじゃん
2. つまりどこのパスワードかわかれば悪用されるってことだよね（俺が言ったこと）
3. 裏ガー、対偶ガー
こう言われた気分ｗ
どこのパスワードかわかっても悪用されるとは限らない（キリッ）
こう言ってるように俺は感じたｗ
2. つまりどこのパスワードかわかれば悪用されるってことだよね（俺が言ったこと）
3. 裏ガー、対偶ガー
こう言われた気分ｗ
どこのパスワードかわかっても悪用されるとは限らない（キリッ）
こう言ってるように俺は感じたｗ
709 ：デフォルトの名無しさん：2014/06/01(日) 14:40:36.77 ID:k00SlaTm
具体的に何割とか計算できるもの以外の可能性は
ただごねてるだけと変わらない
ただごねてるだけと変わらない
710 ：デフォルトの名無しさん：2014/06/01(日) 14:40:53.33 ID:X2VZJkGd
711 ：デフォルトの名無しさん：2014/06/01(日) 14:42:14.70 ID:dFCTVAji
本当に悪用されないと思ってるなら
ここで秘密鍵を公開すればいいんだよな。
ここで秘密鍵を公開すればいいんだよな。
712 ：デフォルトの名無しさん：2014/06/01(日) 14:54:25.82 ID:rJY7yXwk
じゃあさ
8gjk39joi4njodgf9
ってパスワードがあったとしたらこれで悪用してみろよ！
8gjk39joi4njodgf9
ってパスワードがあったとしたらこれで悪用してみろよ！
713 ：デフォルトの名無しさん：2014/06/01(日) 14:54:47.95 ID:dFCTVAji
>>712
どうせそれ偽物だろｗ
偽物を貼った時点で自覚してるじゃん
ここに秘密鍵を書くのは怖いことだってｗ
だいたい秘密鍵がバレた時は、
どこに接続しているかの情報もわかることが
大半なのでそこまで書くべきだよ。
え？どこの秘密鍵かは答えられない？
あぁ、それは、どこの秘密鍵かわかれば悪用されるって
自覚しているからだね（最初に俺が言ったこと）
どうせそれ偽物だろｗ
偽物を貼った時点で自覚してるじゃん
ここに秘密鍵を書くのは怖いことだってｗ
だいたい秘密鍵がバレた時は、
どこに接続しているかの情報もわかることが
大半なのでそこまで書くべきだよ。
え？どこの秘密鍵かは答えられない？
あぁ、それは、どこの秘密鍵かわかれば悪用されるって
自覚しているからだね（最初に俺が言ったこと）
714 ：デフォルトの名無しさん：2014/06/01(日) 14:55:35.81 ID:dFCTVAji
（ヒント）わずか22秒で書けると思う？ｗ
715 ：デフォルトの名無しさん：2014/06/01(日) 14:56:09.78 ID:X2VZJkGd
>>712
秘密鍵が何なのか理解できてない？
秘密鍵が何なのか理解できてない？
716 ：デフォルトの名無しさん：2014/06/01(日) 14:56:31.51 ID:rJY7yXwk
偽物ってなんのだよ
このパスワードがどこのサイトのかわからないと使い道ないぞ
あとidもわからないとまったく使えないぞ
これはおれんちのlocalhostのパスワードだから
このパスワードがどこのサイトのかわからないと使い道ないぞ
あとidもわからないとまったく使えないぞ
これはおれんちのlocalhostのパスワードだから
717 ：デフォルトの名無しさん：2014/06/01(日) 14:57:25.03 ID:rJY7yXwk
なんでどこに接続しているかわかるんだよ
718 ：デフォルトの名無しさん：2014/06/01(日) 14:57:58.60 ID:q7lY0P5T
719 ：デフォルトの名無しさん：2014/06/01(日) 15:02:51.61 ID:e/SJ8pUJ
悪用される可能性があるときは、必ず悪用される。
というのが防犯の鉄則だよね
というのが防犯の鉄則だよね
720 ：デフォルトの名無しさん：2014/06/01(日) 15:03:48.27 ID:G7XNVB3u
スレチなので移動をおながいします
721 ：デフォルトの名無しさん：2014/06/01(日) 15:04:54.94 ID:X2VZJkGd
パスワードと公開鍵認証の秘密鍵との違いを理解できてないのか
722 ：デフォルトの名無しさん：2014/06/01(日) 20:00:44.12 ID:Anql4k9d
>>692
ペアの公開鍵を捨てる以外になにがある？
ペアの公開鍵を捨てる以外になにがある？
723 ：デフォルトの名無しさん：2014/06/01(日) 20:15:54.15 ID:n3zMz1VV
トピックブランチ名をチケット番号と紐付けて運用してるとして、
1. ブランチ ticket1 を切る
2. ticket1 にたくさんコミットして、開発・テスト完了
3. ticket1 を develop にマージして push
4. ここで、ticket1 に実装漏れとかバグが発覚
この場合、どんなブランチの使い方が妥当なの？
ticket1 っていう名前を再利用して、そのままブランチ切って開発・マージする方法とか
いったんマージしたのを revert して、ticket1 のトピックブランチを正しく補完してからマージしなおすとか
別の ticket2 を作って、ticket1 と ticket2 は git の外での関連付けに任せる方法とか
1. ブランチ ticket1 を切る
2. ticket1 にたくさんコミットして、開発・テスト完了
3. ticket1 を develop にマージして push
4. ここで、ticket1 に実装漏れとかバグが発覚
この場合、どんなブランチの使い方が妥当なの？
ticket1 っていう名前を再利用して、そのままブランチ切って開発・マージする方法とか
いったんマージしたのを revert して、ticket1 のトピックブランチを正しく補完してからマージしなおすとか
別の ticket2 を作って、ticket1 と ticket2 は git の外での関連付けに任せる方法とか
724 ：デフォルトの名無しさん：2014/06/01(日) 20:38:23.33 ID:MYnj2kml
> いったんマージしたのを revert して、ticket1 のトピックブランチを正しく補完してからマージしなおすとか
漏れてまいそうで（アカン）
漏れてまいそうで（アカン）
725 ：デフォルトの名無しさん：2014/06/01(日) 20:49:21.18 ID:iPeFjK0r
俺なら別のチケット切る
726 ：デフォルトの名無しさん：2014/06/01(日) 22:13:35.46 ID:7u+U5fAC
チケット番号とブランチ名を一緒にしておきたいのはBTSの運用の都合だと思われるので、
BTSを重要視し、ブランチ名を一緒にしておく事が大事だと思うならするならdevelopの最新からもう一度ticket1というブランチを切ってそこから修正すればいいと思うし、
Gitの履歴の方が重要だと思うならticket1_fixとかで新しくブランチ切ればいいんじゃないかな。
BTSを重要視し、ブランチ名を一緒にしておく事が大事だと思うならするならdevelopの最新からもう一度ticket1というブランチを切ってそこから修正すればいいと思うし、
Gitの履歴の方が重要だと思うならticket1_fixとかで新しくブランチ切ればいいんじゃないかな。
727 ：デフォルトの名無しさん：2014/06/01(日) 23:17:53.65 ID:wXEX5FU/
言語ごとにリポジトリを作成した時に自動で.gitignoreを生成するライブラリとかってありますか？
728 ：デフォルトの名無しさん：2014/06/02(月) 00:42:17.96 ID:CbbBfIj2
729 ：デフォルトの名無しさん：2014/06/02(月) 01:05:25.92 ID:/lZkAqJY
ステマ乙
730 ：デフォルトの名無しさん：2014/06/02(月) 01:09:16.33 ID:gFpQKwCr
731 ：デフォルトの名無しさん：2014/06/02(月) 01:25:08.89 ID:6oKdltFr
.gitignoreに全部入れりゃいいじゃん？
たとえばPHPの開発だとして、Ruby標準の
.gitignore（それが何なのかよくわからんが？）を
追加して何が問題なんだ？
だいたい、一つのリポジトリで複数の言語使うことなんて
よくある話で、言語名で.gitignoreを作るという発想がよくわからん。
どうせエディタのテンポラリファイルとかバックアップファイルとかは
言語名指定しても含まれないんだろ？それじゃ片手落ちじゃね？
そもそも、言語標準の.gitignoreって意味分かんないんだよな。
どっちかと言ったら、.gitignoreに入れるものは言語ではなくて
使うツールによって決まるものだろう。
たとえばPHPの開発だとして、Ruby標準の
.gitignore（それが何なのかよくわからんが？）を
追加して何が問題なんだ？
だいたい、一つのリポジトリで複数の言語使うことなんて
よくある話で、言語名で.gitignoreを作るという発想がよくわからん。
どうせエディタのテンポラリファイルとかバックアップファイルとかは
言語名指定しても含まれないんだろ？それじゃ片手落ちじゃね？
そもそも、言語標準の.gitignoreって意味分かんないんだよな。
どっちかと言ったら、.gitignoreに入れるものは言語ではなくて
使うツールによって決まるものだろう。
732 ：デフォルトの名無しさん：2014/06/02(月) 01:28:04.27 ID:gFpQKwCr
そんな事言ったら世の中のフレームワークやライブラリに喧嘩売ることになりますよっと
733 ：デフォルトの名無しさん：2014/06/02(月) 01:30:45.30 ID:l4SS/Bsy
そういうツールが無いのなら自分で作ってしまえばいいの
そしてそのツールを売りに出せばバカ売れ間違いなしなの
そしてそのツールを売りに出せばバカ売れ間違いなしなの
734 ：デフォルトの名無しさん：2014/06/02(月) 01:54:49.93 ID:6oKdltFr
735 ：デフォルトの名無しさん：2014/06/02(月) 01:59:28.89 ID:l4SS/Bsy
そういえばGitHubにもgitignoreのサンプルがあるね
https://github.com/github/gitignore
https://github.com/github/gitignore
736 ：デフォルトの名無しさん：2014/06/02(月) 01:59:52.26 ID:6oKdltFr
基本的な所がわかってないのかもしれないな。
言語名を入力してgit initとか言ってる時点でハテナだし、
（1リポジトリ = 1言語ではない）
言語名が決まったからって.gitignoreは決まらない。
たとえばC言語であっても、Linux用であれば.oを.gitignoreに
追加するだろうけどWindows用だと.objeだし。
その他のOSを考えると、.gitignoreは言語名できまるのではなく、
使うツールで決まるもの。（>>731で既に俺が言ったこと）
言語名を入力してgit initとか言ってる時点でハテナだし、
（1リポジトリ = 1言語ではない）
言語名が決まったからって.gitignoreは決まらない。
たとえばC言語であっても、Linux用であれば.oを.gitignoreに
追加するだろうけどWindows用だと.objeだし。
その他のOSを考えると、.gitignoreは言語名できまるのではなく、
使うツールで決まるもの。（>>731で既に俺が言ったこと）
737 ：デフォルトの名無しさん：2014/06/02(月) 02:10:49.16 ID:l4SS/Bsy
738 ：デフォルトの名無しさん：2014/06/02(月) 02:14:43.55 ID:6oKdltFr
.gitignoreはあとから入れるもんだよなー。
使うツールが決まった時点で追加するものだ。
使うツールが決まった時点で追加するものだ。
739 ：デフォルトの名無しさん：2014/06/02(月) 02:19:55.88 ID:l4SS/Bsy
>>728にコマンドラインから取得する方法まで懇切丁寧に教えてくれてるし
何も困る事ないじゃないですかー
何も困る事ないじゃないですかー
740 ：デフォルトの名無しさん：2014/06/02(月) 02:44:00.18 ID:mMUvacT0
複数言語入れて使いにくいのはおつむの問題
741 ：デフォルトの名無しさん：2014/06/02(月) 12:49:24.52 ID:KoJqCjfS
すいません
もともとgitのソースコードがローカルにあったのでgit pullしてmakeしてインストールしたんですけど
インストールしたバージョンgit version 2.0.0.6.g03cd2b0
なんですけどこれは2.0のリリースのですか？ベータですか？
https://github.com/git/git/releasesでg03cd2b0を検索してもヒットしません
もともとgitのソースコードがローカルにあったのでgit pullしてmakeしてインストールしたんですけど
インストールしたバージョンgit version 2.0.0.6.g03cd2b0
なんですけどこれは2.0のリリースのですか？ベータですか？
https://github.com/git/git/releasesでg03cd2b0を検索してもヒットしません
742 ：デフォルトの名無しさん：2014/06/02(月) 12:51:44.85 ID:RquarvTq
リリースでビルドしたいならタグを使えよ
743 ：デフォルトの名無しさん：2014/06/03(火) 19:31:06.67 ID:5oGupbY1
linuxのgitのdiffコマンドって何のdiffツールですか？
githubみたいなdiffが欲しいんですけどあれってgit diffの結果を出力してるだけなんですかね？
githubみたいなdiffが欲しいんですけどあれってgit diffの結果を出力してるだけなんですかね？
744 ：デフォルトの名無しさん：2014/06/03(火) 21:17:15.22 ID:rCJu7D+N
>>741
git checkout v2.0.0しないと
git checkout v2.0.0しないと
ダメだ一つのフォルダにphpで作ったやつとかrubyで作ったやつをごっちゃにしていれてるとわけわかんねえ
やっぱり言語ごとにフォルダ分け内とダメだね
やっぱり言語ごとにフォルダ分け内とダメだね
746 ：デフォルトの名無しさん：2014/06/03(火) 22:32:05.17 ID:5DO4L7dm
gitで管理する以前の問題では
747 ：デフォルトの名無しさん：2014/06/03(火) 23:29:08.00 ID:LGyoc4CS
>>745
拡張子でわかる
拡張子でわかる
748 ：デフォルトの名無しさん：2014/06/03(火) 23:36:43.88 ID:o0dI1/Bo
この1ヶ月間何やってたのかと
749 ：デフォルトの名無しさん：2014/06/03(火) 23:41:14.87 ID:9AiAEfmm
一ヶ月でけっこスレすすんでるなｗ
言語ごとにというか、ひとつの言語のコードでも機能ごとにある程度フォルダわけないと混乱するだろ
言語ごとにというか、ひとつの言語のコードでも機能ごとにある程度フォルダわけないと混乱するだろ
750 ：デフォルトの名無しさん：2014/06/03(火) 23:41:30.25 ID:bK0U8GNH
そもそもどういうリポジトリなんだ
751 ：デフォルトの名無しさん：2014/06/04(水) 00:13:25.94 ID:Vfc08V0n
c:￥myrepo￥gazoudownloader
c:￥myrepo￥createxml
c:￥myrepo￥bbs
こんな感じでプロジェクトの名前だけ
もうねわけわからん
c:￥myrepo￥createxml
c:￥myrepo￥bbs
こんな感じでプロジェクトの名前だけ
もうねわけわからん
752 ：デフォルトの名無しさん：2014/06/04(水) 00:16:34.88 ID:Vfc08V0n
このプロジェクトはなんだったかな？フォルダの中身を覗いて初めてphpとわかる。php用の環境を立ち上げる
↓
よしこのphpで書いたプロジェクトは終わったから続けて他のphpのプロジェクトを更新するか
↓
あれ？どれがphpで書いたプロジェクトだっけ？これかな？あ、ちがうこれはperlだ。じゃあこれは。ああrubyだった。じゃあこれは・・・よしphpだ。
もうめんどうくせえよ
↓
よしこのphpで書いたプロジェクトは終わったから続けて他のphpのプロジェクトを更新するか
↓
あれ？どれがphpで書いたプロジェクトだっけ？これかな？あ、ちがうこれはperlだ。じゃあこれは。ああrubyだった。じゃあこれは・・・よしphpだ。
もうめんどうくせえよ
753 ：片山博文MZ悪魔崇拝 ◆T6xkBnTXz7B0 ：2014/06/04(水) 00:19:32.02 ID:qVJRsv3N
ReadMe.txtくらい書けよ。
grep使え。
grep使え。
754 ：デフォルトの名無しさん：2014/06/04(水) 00:23:08.01 ID:HmwUcklb
c:\myrepo\php\gazoudownloader
c:\myrepo\php\createxml
c:\myrepo\perl\bbs
とかにすればいいんじゃない？
c:\myrepo\php\createxml
c:\myrepo\perl\bbs
とかにすればいいんじゃない？
755 ：デフォルトの名無しさん：2014/06/04(水) 00:34:07.34 ID:Vfc08V0n
そうするとここのスレの先輩が怒るんですよ
756 ：デフォルトの名無しさん：2014/06/04(水) 00:36:00.26 ID:2MS74yRY
誰も怒ってないと思うが
もうお前がめんどうくせえよ
git関係ねーし
もうお前がめんどうくせえよ
git関係ねーし
757 ：デフォルトの名無しさん：2014/06/04(水) 00:38:13.72 ID:F6AvD4LE
758 ：デフォルトの名無しさん：2014/06/04(水) 00:39:35.70 ID:HmwUcklb
759 ：デフォルトの名無しさん：2014/06/04(水) 00:40:09.95 ID:F6AvD4LE
>>754
それは馬鹿だろｗ
だいたい、プロジェクトごとにリポジトリを分けるのが
普通だってわかってる？
c:\php\myrepo\gazoudownloader
c:\php\myrepo\createxml
c:\php\myrepo\perl\bbs
こうすればいいだけだよ。
git関係ない。
それは馬鹿だろｗ
だいたい、プロジェクトごとにリポジトリを分けるのが
普通だってわかってる？
c:\php\myrepo\gazoudownloader
c:\php\myrepo\createxml
c:\php\myrepo\perl\bbs
こうすればいいだけだよ。
git関係ない。
760 ：デフォルトの名無しさん：2014/06/04(水) 00:41:28.11 ID:u9d9cpJD
整理術の本でも買って読んでなさいって感じ
761 ：デフォルトの名無しさん：2014/06/04(水) 00:45:45.12 ID:HmwUcklb
762 ：デフォルトの名無しさん：2014/06/04(水) 00:45:50.36 ID:2MS74yRY
「超」整理法で日付ディレクトリ最強ですね
763 ：デフォルトの名無しさん：2014/06/04(水) 00:49:28.83 ID:F6AvD4LE
>>761
あぁ？ くだらなすぎてちゃんと見てなかったよｗ
c:php\gazoudownloader (1リポジトリ)
c:php\createxml (1リポジトリ)
c:perl\bbs (1リポジトリ)
これでいいのか？
繰り返し言う。リポジトリの中に言語名を入れる奴は馬鹿。
あぁ？ くだらなすぎてちゃんと見てなかったよｗ
c:php\gazoudownloader (1リポジトリ)
c:php\createxml (1リポジトリ)
c:perl\bbs (1リポジトリ)
これでいいのか？
繰り返し言う。リポジトリの中に言語名を入れる奴は馬鹿。
764 ：デフォルトの名無しさん：2014/06/04(水) 00:51:22.33 ID:F6AvD4LE
だいたいさ、1つのリポジトリで
複数言語使うことなんてよくある話なんだから。
リポジトリに言語名入れるとかありえないって
少し考えればわかるじゃんｗ
複数言語使うことなんてよくある話なんだから。
リポジトリに言語名入れるとかありえないって
少し考えればわかるじゃんｗ
765 ：デフォルトの名無しさん：2014/06/04(水) 00:57:04.62 ID:HmwUcklb
リポジトリの中に言語名のフォルダあるのけっこう普通だと思うけど？
javaの標準的なプロジェクト構成とかそうだし
railsなんかもjavascriptとかcoffeescriptなんかのコードは言語名下のフォルダに収まってる
javaの標準的なプロジェクト構成とかそうだし
railsなんかもjavascriptとかcoffeescriptなんかのコードは言語名下のフォルダに収まってる
766 ：デフォルトの名無しさん：2014/06/04(水) 00:57:43.07 ID:TUGNI46Z
.phpで全部検索すればいい。
それかシンボリックリンクで言語ごとにも分類すればいい。それなら、複数言語にも対応可能。
それかシンボリックリンクで言語ごとにも分類すればいい。それなら、複数言語にも対応可能。
767 ：デフォルトの名無しさん：2014/06/04(水) 00:59:34.87 ID:2MS74yRY
>>765
リポジトリ「名」の中に言語名入れるなって話だろうに
リポジトリ「名」の中に言語名入れるなって話だろうに
768 ：デフォルトの名無しさん：2014/06/04(水) 01:00:11.45 ID:TUGNI46Z
普通だから良い方法とは限らない。
769 ：デフォルトの名無しさん：2014/06/04(水) 01:01:27.99 ID:HmwUcklb
>>767
おう。それはいらんな。
おう。それはいらんな。
770 ：デフォルトの名無しさん：2014/06/04(水) 01:03:07.11 ID:dR3HZjet
771 ：デフォルトの名無しさん：2014/06/04(水) 01:06:12.08 ID:cWUULp7C
複数のリポジトリを一つにまとめるって
subversionの中の一部で流行った
バッドノウハウだよね。
subversionがリポジトリを作りにくい上に
tracが単一リポジトリしか対応していない時代があって
その場合に苦肉の策として考えだされた間違えたやり方。
リポジトリはプロジェクトごとに分けましょう。以上。
subversionの中の一部で流行った
バッドノウハウだよね。
subversionがリポジトリを作りにくい上に
tracが単一リポジトリしか対応していない時代があって
その場合に苦肉の策として考えだされた間違えたやり方。
リポジトリはプロジェクトごとに分けましょう。以上。
772 ：デフォルトの名無しさん：2014/06/04(水) 01:08:55.77 ID:njjTYj+V
こりゃもう「リポジトリ」というものに関して語るスレが必要だね
773 ：デフォルトの名無しさん：2014/06/04(水) 01:09:54.10 ID:pgNO5HMb
おいクソども。
クソでスレ進めんなボケ。
クソでスレ進めんなボケ。
774 ：デフォルトの名無しさん：2014/06/04(水) 01:12:39.69 ID:HmwUcklb
いやこの人は、例えばこんな感じにgithubのリポジトリがある場合に
ore/gazoudownloader
ore/createxml
ore/bbs
ローカルには、こんな感じに置いても何の問題も無いということが解んなかったんじゃない？
c:\php\gazoudownloader
c:\php\createxml
c:\perl\bbs
ore/gazoudownloader
ore/createxml
ore/bbs
ローカルには、こんな感じに置いても何の問題も無いということが解んなかったんじゃない？
c:\php\gazoudownloader
c:\php\createxml
c:\perl\bbs
775 ：デフォルトの名無しさん：2014/06/04(水) 01:12:44.95 ID:BwekaK/m
railsはrubyだけ
symfonyはphpだけ
gollumみたいに複数言語を使うほうがめずらしいよ
symfonyはphpだけ
gollumみたいに複数言語を使うほうがめずらしいよ
776 ：デフォルトの名無しさん：2014/06/04(水) 01:16:02.01 ID:cWUULp7C
>>775
そりゃ、その言語のフレームワークだからだろｗ
アホすぎだｗ
（フレームワークを使ってる/使ってなくてもいいが）
アプリのコード見てみろ。
たとえばgit https://github.com/git/git は
C 45.9% Shell 34.6% Perl 9.7% JavaScript 3.4% Tcl 2.7% Python 2.4% Other 1.4%
だ。今はリポジトリ見れば簡単にわかるようになって便利だな。
リポジトリの上のカラフルなバーをクリックするんだよ。
そりゃ、その言語のフレームワークだからだろｗ
アホすぎだｗ
（フレームワークを使ってる/使ってなくてもいいが）
アプリのコード見てみろ。
たとえばgit https://github.com/git/git は
C 45.9% Shell 34.6% Perl 9.7% JavaScript 3.4% Tcl 2.7% Python 2.4% Other 1.4%
だ。今はリポジトリ見れば簡単にわかるようになって便利だな。
リポジトリの上のカラフルなバーをクリックするんだよ。
777 ：デフォルトの名無しさん：2014/06/04(水) 01:28:41.65 ID:u9d9cpJD
ローカルなんだからディレクトリ名なんか好きにすりゃいいし、
数が増えすぎてわけわからなくなったらwikiでも立ててカタログ作りゃえーやん
数が増えすぎてわけわからなくなったらwikiでも立ててカタログ作りゃえーやん
778 ：デフォルトの名無しさん：2014/06/04(水) 02:04:43.66 ID:zV8qAQiq
svn使ってた時に1リポジトリ複プロジェクトにしたおかげで
gitに変換する時に死んだわ…
俺がリネーム厨だったせいなのが原因だけど
gitに変換する時に死んだわ…
俺がリネーム厨だったせいなのが原因だけど
779 ：デフォルトの名無しさん：2014/06/04(水) 11:50:46.93 ID:JBvZNONu
編集するための環境が複数言語に対応してないことの方が大問題じゃね？ｗ
780 ：デフォルトの名無しさん：2014/06/04(水) 12:19:13.04 ID:PLuHq7Rw
781 ：デフォルトの名無しさん：2014/06/04(水) 12:21:44.90 ID:bEyKGuJO
782 ：デフォルトの名無しさん：2014/06/04(水) 12:43:56.96 ID:u9d9cpJD
いつまでこのスレチの話題続くの？
783 ：デフォルトの名無しさん：2014/06/04(水) 12:54:10.95 ID:PLuHq7Rw
ぷろじぇくと100も200も増えたらどうすんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
１つのフォルダに全部いれとくのかよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
探すのたいへんだぞｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
１つのフォルダに全部いれとくのかよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
探すのたいへんだぞｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
784 ：デフォルトの名無しさん：2014/06/04(水) 21:29:03.04 ID:jJTqmzi2
785 ：デフォルトの名無しさん：2014/06/04(水) 22:38:03.42 ID:q4t2wT6z
>>783は言い間違えたんだよ。
本当に言いたかったのはこっち
ぷろじぇくと100も200も増えたらどうすんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
１つのリポジトリに全部いれとくのかよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
探すのたいへんだぞｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
本当に言いたかったのはこっち
ぷろじぇくと100も200も増えたらどうすんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
１つのリポジトリに全部いれとくのかよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
探すのたいへんだぞｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
786 ：デフォルトの名無しさん：2014/06/04(水) 23:41:02.34 ID:lKY790DW
一つ質問
git mv に失敗したっぽくて、git log --follow してもログが分断されてしまった…
(ようするに消した後、新規追加と同じになってる)
この状況で、ログをくっつける事は可能でしょうか？
git mv に失敗したっぽくて、git log --follow してもログが分断されてしまった…
(ようするに消した後、新規追加と同じになってる)
この状況で、ログをくっつける事は可能でしょうか？
787 ：デフォルトの名無しさん：2014/06/05(木) 00:10:17.95 ID:B5xrGd/9
>>786
git mvは「消した後、新規追加」と同じことをするコマンドだから何も心配はいらない
git mvは「消した後、新規追加」と同じことをするコマンドだから何も心配はいらない
788 ：デフォルトの名無しさん：2014/06/05(木) 01:12:05.22 ID:iGxBJzBl
>>787
でも、git mv に成功した場合は、git log --follow でログが表示されるのが
されないから多分分断されてる
ムリクリfollowするようにしたいけど、その方法を教えてもらえればと
でも、git mv に成功した場合は、git log --follow でログが表示されるのが
されないから多分分断されてる
ムリクリfollowするようにしたいけど、その方法を教えてもらえればと
789 ：デフォルトの名無しさん：2014/06/05(木) 01:23:40.15 ID:fhxWm8Xr
>>788
gitは、あるコミットにおいてrmされたファイルとaddされたファイルの内容を比べて、
中身がだいたい同じ場合それはファイルがmvされたのだと適当に判断する
あんたがmvに成功したと思ってるのは、mvしたファイルの内容がgitの許容範囲内だっただけ
gitは、あるコミットにおいてrmされたファイルとaddされたファイルの内容を比べて、
中身がだいたい同じ場合それはファイルがmvされたのだと適当に判断する
あんたがmvに成功したと思ってるのは、mvしたファイルの内容がgitの許容範囲内だっただけ
790 ：デフォルトの名無しさん：2014/06/05(木) 01:29:08.95 ID:iGxBJzBl
>>789
なるほど、薄々そんな気がしていたがやっぱりそうだったのか…
リファクタリング中だったから、git mv した後いぢり過ぎたのか
これからはgit mv した後はすぐコミットする事にします。どうもでした。
なるほど、薄々そんな気がしていたがやっぱりそうだったのか…
リファクタリング中だったから、git mv した後いぢり過ぎたのか
これからはgit mv した後はすぐコミットする事にします。どうもでした。
791 ：デフォルトの名無しさん：2014/06/05(木) 09:40:58.07 ID:sbCUAgw4
ファイルの移動に限らず、ちょっとした関数の移動でも1コミットにしてるな
「内容を全く変えずに移動」で1コミットになってると、行番号だけがずれてるcherry-pickなんかも受け入れてくれやすい
と散々rebase＆cherry-pickしまくった経験則だけど
「内容を全く変えずに移動」で1コミットになってると、行番号だけがずれてるcherry-pickなんかも受け入れてくれやすい
と散々rebase＆cherry-pickしまくった経験則だけど
792 ：デフォルトの名無しさん：2014/06/05(木) 11:30:52.10 ID:pAA2pjK6
フォルダのどこからでもgit addで追加する場合ってどうやるのか教えてください
git add -Aってカレントフォルダだけですよね
git add -Aってカレントフォルダだけですよね
793 ：デフォルトの名無しさん：2014/06/05(木) 17:28:56.51 ID:kE+YYBnP
794 ：デフォルトの名無しさん：2014/06/05(木) 19:55:24.38 ID:9JC5UGTi
795 ：デフォルトの名無しさん：2014/06/05(木) 20:19:48.42 ID:fhxWm8Xr
>>792
追加するフォルダかファイルのパスを指定する
追加するフォルダかファイルのパスを指定する
796 ：デフォルトの名無しさん：2014/06/06(金) 17:56:42.08 ID:ZbxJIgia
初歩的な質問ですけど
ブランチで開発やってて、他のブランチの結果をpullするって出来ますか？
master -------------
branchA \____?_ _ _ _
branchB \______/
図が難しいので順序が逆ですが
branchBが先にmasterからブランチして
branchAが次にmasterからブランチした。
branchAがbranchBの結果をpullして取り込みたいんですが。
branchBがmasterにmergeすると簡単なのかな？
教えてください。
ブランチで開発やってて、他のブランチの結果をpullするって出来ますか？
master -------------
branchA \____?_ _ _ _
branchB \______/
図が難しいので順序が逆ですが
branchBが先にmasterからブランチして
branchAが次にmasterからブランチした。
branchAがbranchBの結果をpullして取り込みたいんですが。
branchBがmasterにmergeすると簡単なのかな？
教えてください。
797 ：デフォルトの名無しさん：2014/06/06(金) 18:38:12.44 ID:ICJsHYDG
798 ：デフォルトの名無しさん：2014/06/07(土) 07:34:24.03 ID:paHf3aPB
カレント・ディレクトリの tags ファイルをローカル・リポジトリに追加したいのです
が "git add tags" できません。
"git add tags " コマンド自体を実行させても、エラーを返しません。上手くいったか
と思って "git status" で確認すると、インデックスには tags ファイルは追加されて
いません。tags ファイルを別の名前 tags_test に rename すれば "git add
tags_test" でインデックスに追加されます。でも Vim の補完に使うファイルであり
tags ファイル名のままにしておかねばなりません。"git add -- tags" と実行させても
同じです。
"git add tags", "git add -- tags" が働かない理由と対策を教えてもらえないでしょうか。
OS 環境は Windows7 であり git version は下の様になっています
git --version
git version 1.8.1.msysgit.1
が "git add tags" できません。
"git add tags " コマンド自体を実行させても、エラーを返しません。上手くいったか
と思って "git status" で確認すると、インデックスには tags ファイルは追加されて
いません。tags ファイルを別の名前 tags_test に rename すれば "git add
tags_test" でインデックスに追加されます。でも Vim の補完に使うファイルであり
tags ファイル名のままにしておかねばなりません。"git add -- tags" と実行させても
同じです。
"git add tags", "git add -- tags" が働かない理由と対策を教えてもらえないでしょうか。
OS 環境は Windows7 であり git version は下の様になっています
git --version
git version 1.8.1.msysgit.1
799 ：デフォルトの名無しさん：2014/06/07(土) 07:45:02.46 ID:oJ+iP19r
再現しないけど
既に管理下に入ってるんじゃないの？
既に管理下に入ってるんじゃないの？
800 ：デフォルトの名無しさん：2014/06/07(土) 08:00:43.50 ID:paHf3aPB
Repository 内に無いことは最初に確認済みでした。
でも、今 git ls-files で確認してみたら tags ファイルが入っていました。このおっちょちょいが。
失礼しました。ありがとうございました。
でも、今 git ls-files で確認してみたら tags ファイルが入っていました。このおっちょちょいが。
失礼しました。ありがとうございました。
801 ：デフォルトの名無しさん：2014/06/07(土) 18:48:16.19 ID:jSVebn/T
どんなコマンドを入力してもログは絶対に消えないですか
802 ：デフォルトの名無しさん：2014/06/07(土) 18:59:57.78 ID:3R8CEA88
rm -fR .git
803 ：デフォルトの名無しさん：2014/06/09(月) 18:34:36.80 ID:dvi2Sb61
コンフリクトしてpushしたやつを戻すの難しかったお
Git恐怖症になりそう
Git恐怖症になりそう
804 ：デフォルトの名無しさん：2014/06/09(月) 21:41:17.37 ID:nOs0/HFd
コンフリクトしてpushって言ってる言葉自体がわからんｗ
共有リポジトリなら、revertコマンド一つ。
自分専用リポジトリならローカルを適当に書き換えて
push --forceすれば終わりなんだけどな。
共有リポジトリなら、revertコマンド一つ。
自分専用リポジトリならローカルを適当に書き換えて
push --forceすれば終わりなんだけどな。
805 ：デフォルトの名無しさん：2014/06/09(月) 21:50:57.46 ID:35sdSSzp
最悪、ハッシュさえ覚えとけば(普通は覚えるまでもなくreflogに残ってるが)
ブランチの状態をある時点まで戻すのは簡単だからな
これができないような状態にまで壊すのは、意識的にやらない限りなかなか無い
ブランチの状態をある時点まで戻すのは簡単だからな
これができないような状態にまで壊すのは、意識的にやらない限りなかなか無い
806 ：デフォルトの名無しさん：2014/06/10(火) 00:28:24.33 ID:Rfvv6P0m
revert様々やで
807 ：デフォルトの名無しさん：2014/06/10(火) 01:38:29.66 ID:AAMs7V03
途中で分岐させて、片方にコミットAとそのrevertコミット、もう片方にAのチェリーピック食わせてて両方マージしたら暗黙にrevertが優先されて焦った事があった。
マージ賢いけど、賢く運用してる場合に限り賢く振る舞ってくれる感じがする。
マージ賢いけど、賢く運用してる場合に限り賢く振る舞ってくれる感じがする。
808 ：デフォルトの名無しさん：2014/06/10(火) 02:27:26.48 ID:osqTzX66
>>807
試しにやってみたけどcherry-pickした方が残るぞ？どんな条件でそんなこと起こるんだ？
試しにやってみたけどcherry-pickした方が残るぞ？どんな条件でそんなこと起こるんだ？
809 ：デフォルトの名無しさん：2014/06/10(火) 05:19:03.10 ID:8m9M+kuY
再現されない
git init
vim README
git add .
git commit -m "initial commit"
git checkout -b branch1
vim foo1.cpp
git add .
git commit -m "add foo1.cpp" -> 10b43c7
vim foo2.cpp
git add .
git commit -m "add foo2.cpp" -> 2bf1437
vim foo3.cpp
git add .
git commit -m "add foo3.cpp" -> 3b31558
vim foo4.cpp
git add .
git commit -m "add foo4.cpp" -> 086ca1c
git revert 2bf1437 3b31558 -> foo2.cpp foo3.cpp削除
git checkout -b branch2 master
git cherry-pick 2bf1437 3b31558 -> foo2.cpp foo3.cpp作成
git checkout -b branch2m
git merge branch1 -> 問題なく融合(foo1.cpp～foo4.cppが存在)
git checkout -b branch1m branch1
git merge branch2 -> 問題なく融合(foo1.cpp～foo4.cppが存在)
git init
vim README
git add .
git commit -m "initial commit"
git checkout -b branch1
vim foo1.cpp
git add .
git commit -m "add foo1.cpp" -> 10b43c7
vim foo2.cpp
git add .
git commit -m "add foo2.cpp" -> 2bf1437
vim foo3.cpp
git add .
git commit -m "add foo3.cpp" -> 3b31558
vim foo4.cpp
git add .
git commit -m "add foo4.cpp" -> 086ca1c
git revert 2bf1437 3b31558 -> foo2.cpp foo3.cpp削除
git checkout -b branch2 master
git cherry-pick 2bf1437 3b31558 -> foo2.cpp foo3.cpp作成
git checkout -b branch2m
git merge branch1 -> 問題なく融合(foo1.cpp～foo4.cppが存在)
git checkout -b branch1m branch1
git merge branch2 -> 問題なく融合(foo1.cpp～foo4.cppが存在)
810 ：デフォルトの名無しさん：2014/06/10(火) 07:59:18.53 ID:AAMs7V03
そう…再現しねぇんだよ…なんでかなぁ。
811 ：デフォルトの名無しさん：2014/06/10(火) 17:44:37.82 ID:Rfvv6P0m
git resetで前のコミットに戻って編集した後pushしたい時って今までのコミットrevertしてからpushするしか無いの？
812 ：デフォルトの名無しさん：2014/06/10(火) 18:27:22.10 ID:lvdNmXjN
こんな感じ？
C4まで公開済み
↓
[C1]-[C2]-[C3]-[C4]-[C5]-[C6]-[C7]
↑
現在のHEAD
C3まで戻りたいのならC4までresetした後、C3をrevert、でpush可能
C5まで戻りたいのならC5までreset、でpush可能
C4まで公開済み
↓
[C1]-[C2]-[C3]-[C4]-[C5]-[C6]-[C7]
↑
現在のHEAD
C3まで戻りたいのならC4までresetした後、C3をrevert、でpush可能
C5まで戻りたいのならC5までreset、でpush可能
813 ：デフォルトの名無しさん：2014/06/10(火) 19:14:50.43 ID:Rfvv6P0m
>>812
なるほどありがとう
なるほどありがとう
814 ：デフォルトの名無しさん：2014/06/10(火) 20:44:55.54 ID:ZZTnWEBr
>>812
これなんかおかしい
これなんかおかしい
815 ：デフォルトの名無しさん：2014/06/10(火) 21:33:28.07 ID:pZUiJHso
herokuでwordpressみたいなPaaSの運用って思ったよりめんどくさいのね。
Gitの管理していないファイルの扱いをどうしたらいいんだ。
Gitの管理していないファイルの扱いをどうしたらいいんだ。
816 ：デフォルトの名無しさん：2014/06/11(水) 01:19:10.50 ID:ehbBircS
817 ：デフォルトの名無しさん：2014/06/11(水) 07:23:42.77 ID:YrJFhcVC
違うでしょ。
herokuの場合wordpressが作成するデータベースは勝手に消えないけど、アップロードしたファイルは消えちゃう。
解決法としてストレージを外部に持つしか方法がないようだ。
herokuの場合wordpressが作成するデータベースは勝手に消えないけど、アップロードしたファイルは消えちゃう。
解決法としてストレージを外部に持つしか方法がないようだ。
818 ：デフォルトの名無しさん：2014/06/11(水) 12:44:22.03 ID:EyVsoFD4
heroku使うのにwordpress使うってカスがやること
819 ：デフォルトの名無しさん：2014/06/11(水) 13:23:01.02 ID:8t9Ps5Bi
git version 1.8.5.2.msysgit.0 で
git rm -rf dir/
fatal: pathspec 'dir/' did not match any files
ってファイルは消せるのにディレクトリが消せないのはどういうこと？
dir/内は空っぽです
git rm -rf dir/
fatal: pathspec 'dir/' did not match any files
ってファイルは消せるのにディレクトリが消せないのはどういうこと？
dir/内は空っぽです
820 ：デフォルトの名無しさん：2014/06/11(水) 14:31:43.41 ID:xqrpI9NS
PaaSの環境によるけど、herokuでwordpressってすごく普通だけど。
821 ：デフォルトの名無しさん：2014/06/11(水) 15:22:38.37 ID:Rgm1d36A
>>819
Gitはファイルを管理するけどディレクトリそのものは管理しないから
Gitはファイルを管理するけどディレクトリそのものは管理しないから
822 ：デフォルトの名無しさん：2014/06/11(水) 20:03:40.21 ID:ALIRMVK5
.gitkeepでググれ
>>821
確かに…別の場所でpullしたらディレクトリ消えてた
git内では消えてるのにディレクトリそのものは残ってるから2回目以降に表示されてたんだな
ファイルはgit rmでばっさり消すくせにディレクトリは消さないってなんでなん
確かに…別の場所でpullしたらディレクトリ消えてた
git内では消えてるのにディレクトリそのものは残ってるから2回目以降に表示されてたんだな
ファイルはgit rmでばっさり消すくせにディレクトリは消さないってなんでなん
825 ：デフォルトの名無しさん：2014/06/12(木) 00:50:48.34 ID:k+HyAclm
>>823
だから、Gitはファイルを管理するけどディレクトリそのものは管理しない
git rm はGitで管理してるファイルを消すコマンド
ワーキングツリー上の空ディレクトリを消したければ普通のコマンド使え
だから、Gitはファイルを管理するけどディレクトリそのものは管理しない
git rm はGitで管理してるファイルを消すコマンド
ワーキングツリー上の空ディレクトリを消したければ普通のコマンド使え
826 ：デフォルトの名無しさん：2014/06/12(木) 00:51:39.35 ID:k+HyAclm
リロードしてなかった
>>825
一応試したところgit rm -r dir/で実際のディレクトリもちゃんと消えるね
一応試したところgit rm -r dir/で実際のディレクトリもちゃんと消えるね
>>827
もちろん空でないディレクトリに限るけど
もちろん空でないディレクトリに限るけど
829 ：デフォルトの名無しさん：2014/06/12(木) 01:40:04.38 ID:k+HyAclm
830 ：デフォルトの名無しさん：2014/06/12(木) 01:41:26.71 ID:k+HyAclm
またリロードしてなかった
831 ：デフォルトの名無しさん：2014/06/12(木) 02:44:56.35 ID:0fE6ecZu
最初の頃に管理に入れた、とあるファイルが
作り込んだ後になって「各自で別々の内容のまま持つべき」
って話になったんですが、どうすればいいのでしょうか？
git rm --cachedだと各自がpullしたときに消えちゃう…各自の持ってるファイルは現状のままにしたいです
作り込んだ後になって「各自で別々の内容のまま持つべき」
って話になったんですが、どうすればいいのでしょうか？
git rm --cachedだと各自がpullしたときに消えちゃう…各自の持ってるファイルは現状のままにしたいです
832 ：デフォルトの名無しさん：2014/06/12(木) 02:46:03.19 ID:0fE6ecZu
あ、現状のままというか、各自で別々の内容にしていけるように、です。
833 ：デフォルトの名無しさん：2014/06/12(木) 02:52:56.27 ID:bcr4Y1Fv
.gitignoreに書けばいいんじゃないの？
834 ：デフォルトの名無しさん：2014/06/12(木) 02:59:30.25 ID:0fE6ecZu
>>833
既にコミット済みなので、.gitignoreに書いても除外されないんですよね…
既にコミット済みなので、.gitignoreに書いても除外されないんですよね…
835 ：デフォルトの名無しさん：2014/06/12(木) 03:01:38.52 ID:cPATFudP
じゃあコミットからはずせよ
836 ：デフォルトの名無しさん：2014/06/12(木) 03:08:14.85 ID:LUHHUJAl
837 ：デフォルトの名無しさん：2014/06/12(木) 03:28:09.83 ID:bcr4Y1Fv
非管理ディレクトリでも作ってそこにファイル置いてシンボリックリンクでも張ってつかえばええんちゃうの
838 ：デフォルトの名無しさん：2014/06/12(木) 12:01:55.49 ID:Qv1u/W6+
とにかく業務これだけ使えれば万全ってコマンドをあるだけおしえて
commit
add
checkout
branch
remote
log
reflog
reset
これ走ってる
commit
add
checkout
branch
remote
log
reflog
reset
これ走ってる
839 ：デフォルトの名無しさん：2014/06/12(木) 12:24:21.06 ID:f3a/iFpr
grep
rebase
status
diff
revert
こいつらも覚えとき
bisect、blameもおすすめ
rebase
status
diff
revert
こいつらも覚えとき
bisect、blameもおすすめ
840 ：デフォルトの名無しさん：2014/06/12(木) 14:21:17.86 ID:k+HyAclm
>>831みたいなときに
.gitignoreに書いて、git rm --cachedして、その状態をcommitしてたんだけど
そうするとちょっと問題があって
そのcommit以前をチェックアウトした後に、そのcommit以後をチェックアウトすると、
管理から外したファイルが消失しちゃうんだよね
>>836はまったく未知だったわちょっと動作を確かめてみる
.gitignoreに書いて、git rm --cachedして、その状態をcommitしてたんだけど
そうするとちょっと問題があって
そのcommit以前をチェックアウトした後に、そのcommit以後をチェックアウトすると、
管理から外したファイルが消失しちゃうんだよね
>>836はまったく未知だったわちょっと動作を確かめてみる
841 ：デフォルトの名無しさん：2014/06/12(木) 14:23:15.51 ID:fKk4MWnJ
Pro Gitにも書いておいてほしい
842 ：デフォルトの名無しさん：2014/06/13(金) 18:00:50.16 ID:VgtrMdkb
>>836はローカルなリポジトリだけに作用する感じなのかねえ
特定のファイルが最初から.gitignoreに登録されてリポジトリには登録されるべきでなかったことをリモートリポジトリにも反映するには、
git filter-branchで最初から書き換えてしまうしか無いのかな
特定のファイルが最初から.gitignoreに登録されてリポジトリには登録されるべきでなかったことをリモートリポジトリにも反映するには、
git filter-branchで最初から書き換えてしまうしか無いのかな
843 ：デフォルトの名無しさん：2014/06/15(日) 12:29:50.14 ID:ZB+9NljM
日々の作業を自動化するプログラムを書いてgitで管理していくとプロジェクトが50個超えるんですけど
ここの先輩もそんなにいきますか？
ここの先輩もそんなにいきますか？
844 ：デフォルトの名無しさん：2014/06/15(日) 12:33:02.69 ID:C1Yq9FDg
日々の作業がそんなにないんだけど...
845 ：デフォルトの名無しさん：2014/06/15(日) 12:48:11.71 ID:ZuLV4hXG
>>843
それgit関係無いですよね？
それgit関係無いですよね？
846 ：デフォルトの名無しさん：2014/06/15(日) 13:32:29.24 ID:KFTbGwac
そのプログラムとやらをまとめて一個のリポジトリにすりゃええやんけ
そんな自動化できることばっかなら仕事しなくていいんじゃね
裏山
そんな自動化できることばっかなら仕事しなくていいんじゃね
裏山
847 ：デフォルトの名無しさん：2014/06/15(日) 14:58:31.07 ID:cXeYBPF2
自分が書いたコードをレビューしてくれるサイトってありませんか？
848 ：デフォルトの名無しさん：2014/06/15(日) 15:08:34.54 ID:l0ywMHBR
849 ：デフォルトの名無しさん：2014/06/15(日) 15:17:54.95 ID:47+4XIuz
Git関係なくね？てか使ってる言語系のスレで聞けばよくね？
てかフルボッコされたいならこの板で良くね？
てかフルボッコされたいならこの板で良くね？
850 ：デフォルトの名無しさん：2014/06/15(日) 15:40:00.08 ID:cXeYBPF2
githubってあんまりレビューを見かけることがないんですよね
というかレビューをするのが前提って感じでも無いですし
レビューに力を入れているサイトってないんでしょうか
というかレビューをするのが前提って感じでも無いですし
レビューに力を入れているサイトってないんでしょうか
851 ：デフォルトの名無しさん：2014/06/15(日) 15:40:10.00 ID:azJHx8hd
stackoverflowのほうが精神衛生には良さそう
同じボコられるにしたって、匿名と名前ありでは素直に受け取れる度みたいなもんが変わってくると思う
同じボコられるにしたって、匿名と名前ありでは素直に受け取れる度みたいなもんが変わってくると思う
852 ：デフォルトの名無しさん：2014/06/15(日) 15:53:23.78 ID:8GPu+iwa
stackoverflowの日本語版が出来たらそこがいいだろう
853 ：デフォルトの名無しさん：2014/06/15(日) 16:09:10.27 ID:IRi7fyG5
stackoverflowは質問事項を明確にしないと管理人に質問を凍結状態にされるぞ
レビューしてくださいとかダメだ
レビューしてくださいとかダメだ
854 ：デフォルトの名無しさん：2014/06/15(日) 16:12:09.02 ID:qtgrwwOv
stackoverflowで質問したことあるけど勝手にタイトルを変更された
855 ：デフォルトの名無しさん：2014/06/15(日) 19:17:17.20 ID:ZZ/FPeiS
タイトルと質問内容をレビューしてもらったわけだ。
コードレビューならとりあえずgithubに上げてみ。誰かのコードレビューすれば逆にレビューしてくれる。
コードレビューならとりあえずgithubに上げてみ。誰かのコードレビューすれば逆にレビューしてくれる。
856 ：デフォルトの名無しさん：2014/06/16(月) 00:22:54.07 ID:idFh+z/o
857 ：デフォルトの名無しさん：2014/06/16(月) 01:25:32.74 ID:HINNz9l/
いやレビュー目的でgithub見に来てる人っていないでしょ？
海外のチャットで僕の英語を添削してくださいなんて言わないよね
だから添削に特化したlang8みたいなのがあるんだよ
海外のチャットで僕の英語を添削してくださいなんて言わないよね
だから添削に特化したlang8みたいなのがあるんだよ
858 ：デフォルトの名無しさん：2014/06/16(月) 01:30:36.25 ID:MERkKOKe
素晴らしいソフトウェアをもっと素晴らしくするために自分の考えだした素晴らしいアイデアを無償で提供しようってのが公開リポジトリでの交流だろ？
859 ：デフォルトの名無しさん：2014/06/16(月) 01:31:44.76 ID:MERkKOKe
どこぞの誰かが添削してくださいって言って公開してる何の役にもたたんコードを無償でレビューするとかどんな暇人やねん
860 ：デフォルトの名無しさん：2014/06/16(月) 01:38:58.62 ID:MERkKOKe
いっそのことコードを会員相互でレビューしあうサイトでも立ち上げてみたら？需要があるんなら儲かるんじゃね？
861 ：デフォルトの名無しさん：2014/06/16(月) 06:20:11.38 ID:e4oLiDm/
862 ：デフォルトの名無しさん：2014/06/16(月) 06:29:03.47 ID:AdEqdopC
いいかげんGitとは全く関係無いんで他にスレでも立ててやってくれ
863 ：デフォルトの名無しさん：2014/06/16(月) 06:35:35.02 ID:Mvi4rDX6
コードレビューでお金がもらえるサービスを作る
http://peace.2ch.net/test/read.cgi/tech/1402867973/
http://peace.2ch.net/test/read.cgi/tech/1402867973/
864 ：デフォルトの名無しさん：2014/06/16(月) 08:11:44.62 ID:WjthfDAE
865 ：デフォルトの名無しさん：2014/06/16(月) 22:31:52.86 ID:w9HZwqDq
>>863
それ普通にユーキャンだろ…
それ普通にユーキャンだろ…
866 ：デフォルトの名無しさん：2014/06/16(月) 22:37:07.56 ID:MMwlea4w
クソサービスすぎて見てるほうが死にたくなる
867 ：デフォルトの名無しさん：2014/06/16(月) 22:56:47.14 ID:1GPgt9YV
死にたいなら死んでいいと思います。
868 ：デフォルトの名無しさん：2014/06/18(水) 16:43:12.19 ID:bAs8WhGu
gitのサブモジュールって、サブモジュールが更新されたとき、メインのgitでpullすればサブモジュールのgitも最新版になるの？
869 ：デフォルトの名無しさん：2014/06/18(水) 17:03:50.64 ID:yu0xlR7/
ならんならん
870 ：デフォルトの名無しさん：2014/06/18(水) 17:49:25.97 ID:bAs8WhGu
871 ：デフォルトの名無しさん：2014/06/18(水) 17:53:32.85 ID:yu0xlR7/
なんでやねん
872 ：デフォルトの名無しさん：2014/06/18(水) 21:32:10.25 ID:Dv/sTmWi
なんでそうなるんや…
873 ：デフォルトの名無しさん：2014/06/19(木) 02:50:54.18 ID:a+4NSFaT
git/composer/bowerあたりが全部ごっちゃになってるのか…gruntとかnpmとかもか
874 ：デフォルトの名無しさん：2014/06/19(木) 02:52:18.29 ID:GKSvjGH6
875 ：デフォルトの名無しさん：2014/06/19(木) 02:56:00.25 ID:QcTSno45
876 ：デフォルトの名無しさん：2014/06/19(木) 04:35:43.70 ID:ZDR2rCVo
877 ：デフォルトの名無しさん：2014/06/19(木) 09:10:11.76 ID:uhTP2aV5
878 ：デフォルトの名無しさん：2014/06/19(木) 11:01:04.34 ID:QcTSno45
879 ：デフォルトの名無しさん：2014/06/19(木) 17:00:32.13 ID:IwCNAxsR
細かい単位でコミットしてないとダメだなあ
あんまり大きい作業単位でコミットしてるとrevertとか便利そうな機能が使えんし
あんまり大きい作業単位でコミットしてるとrevertとか便利そうな機能が使えんし
880 ：デフォルトの名無しさん：2014/06/19(木) 17:06:48.92 ID:BcmtgtjI
セーブする感覚でやっちゃってる
適当にrebaseしないと散らかりすぎるかのう
適当にrebaseしないと散らかりすぎるかのう
881 ：デフォルトの名無しさん：2014/06/19(木) 20:04:21.46 ID:GjYBKD0X
俺はブランチ切る→そのブランチ内でセーブ感覚でガンガンコミット→squash
882 ：デフォルトの名無しさん：2014/06/19(木) 20:15:00.22 ID:Fdr0qLJN
それがベーシックなやり方だろうね
ブランチ未満の粒度の作業単位は残す必要ないだろうし
ブランチ未満の粒度の作業単位は残す必要ないだろうし
883 ：デフォルトの名無しさん：2014/06/19(木) 20:18:40.23 ID:Df6JFFDt
個人的な好みとしては
rebaseでの根本移動はアリだけど
squashでのコミット潰しとFFマージ主義はナシ
rebaseでの根本移動はアリだけど
squashでのコミット潰しとFFマージ主義はナシ
884 ：デフォルトの名無しさん：2014/06/20(金) 01:16:15.04 ID:9P55PKrO
開発用テストサーバとローカルのコードを同期するのに同期用のブランチを切って使ってる。
それだと本当にタイプミスで動かないものの修正とかでcommit/push/pullになって、コミットログも"a"とかなので、さすがにそんなのは履歴として残すメリットはなんにもないので、
本来コミットするべきタイミングでそういうのはsquashしてトピックブランチにcommitしてる。
原理主義者からは単なる同期にgitを使うなとは言われるかもしれないけど、
他のツールを使うのも色々とめんどくさいしね。
それだと本当にタイプミスで動かないものの修正とかでcommit/push/pullになって、コミットログも"a"とかなので、さすがにそんなのは履歴として残すメリットはなんにもないので、
本来コミットするべきタイミングでそういうのはsquashしてトピックブランチにcommitしてる。
原理主義者からは単なる同期にgitを使うなとは言われるかもしれないけど、
他のツールを使うのも色々とめんどくさいしね。
885 ：デフォルトの名無しさん：2014/06/20(金) 01:25:01.85 ID:nPERQ22c
> squashでのコミット潰しとFFマージ主義はナシ
時と場合によって変えるべき。
なぜ「mergeはこれしかダメ」と決めつける人が多いのだろうか。
squashするべき時はsquashして、するべきじゃない時はsquashしない。
FFマージするべき時はFFマージして、FFマージするべきじゃない時はFFマージしない。
それだけじゃないか。
決めつける人は、自分がやり方ことが明確になっておらず、
ただコマンドを覚えているだけなんだろうな。
時と場合によって変えるべき。
なぜ「mergeはこれしかダメ」と決めつける人が多いのだろうか。
squashするべき時はsquashして、するべきじゃない時はsquashしない。
FFマージするべき時はFFマージして、FFマージするべきじゃない時はFFマージしない。
それだけじゃないか。
決めつける人は、自分がやり方ことが明確になっておらず、
ただコマンドを覚えているだけなんだろうな。
886 ：デフォルトの名無しさん：2014/06/20(金) 01:50:53.36 ID:fQqGdEOm
自分のやり方と違う奴の存在認められないからすぐ叩きが始まるのはいつものことではないか
887 ：デフォルトの名無しさん：2014/06/20(金) 01:55:10.28 ID:7nDrVBi+
1コミットにできないブランチはそもそもブランチの切り方を失敗してる説
888 ：デフォルトの名無しさん：2014/06/20(金) 01:58:44.73 ID:rNGAsf/H
１コミットにまとめようとしてsquashしたらコンフリクトがハンパなく発生して死にたくなった
889 ：デフォルトの名無しさん：2014/06/20(金) 02:00:56.73 ID:nPERQ22c
890 ：デフォルトの名無しさん：2014/06/20(金) 07:49:34.87 ID:XWgQCtQu
squash しなければコンフリクトも小出しになると言いたいのでは。
891 ：デフォルトの名無しさん：2014/06/20(金) 19:41:04.84 ID:FEHr8pGe
squashしたらこんなのがでる
$ git rebase -i HEAD~3
error: could not apply f7701b6... some edited
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply f7701b697f698715b8e2ec3e339655e43e0e6f31... some edited
taro@YOSHIDA ~/myproject/helloworld (master|REBASE-i 2/2)
$
$ git rebase -i HEAD~3
error: could not apply f7701b6... some edited
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply f7701b697f698715b8e2ec3e339655e43e0e6f31... some edited
taro@YOSHIDA ~/myproject/helloworld (master|REBASE-i 2/2)
$
892 ：デフォルトの名無しさん：2014/06/20(金) 19:43:03.58 ID:FEHr8pGe
まとめるコミットが多いとこうういのがたくさん出る
893 ：デフォルトの名無しさん：2014/06/20(金) 20:08:47.08 ID:fQqGdEOm
がんばれがんばれどかべん
よーしだたろう
よーしだたろう
894 ：デフォルトの名無しさん：2014/06/20(金) 21:05:57.10 ID:tmj63HwH
rebaseはマージコミットの時に行った編集を再現できないから、マージコミットを巻き込んでrebaseしたら
何度でも同じコンフリクトが起きるよ
何度でも同じコンフリクトが起きるよ
895 ：デフォルトの名無しさん：2014/06/21(土) 02:40:47.04 ID:GnC4hxCp
そして、「何度でも同じコンフリクト」が起きた時
自動で解決してくれる設定が、
あるから誰か答えてね。
自動で解決してくれる設定が、
あるから誰か答えてね。
896 ：デフォルトの名無しさん：2014/06/21(土) 03:01:15.08 ID:5/17O7zj
initからsquashを使うまでの流れを教えてください
897 ：デフォルトの名無しさん：2014/06/21(土) 10:32:06.18 ID:tx3pF38o
merge --squashはまず使わないが、
rebaseのsquash, fixupはよく使うレレレのおじさん
rebaseのsquash, fixupはよく使うレレレのおじさん
898 ：デフォルトの名無しさん：2014/06/21(土) 11:08:10.55 ID:EfmviY6O
だってgit bookのページに書いてあったsquashってrebaseの話しかなかったんだもん！
899 ：デフォルトの名無しさん：2014/06/21(土) 12:55:15.10 ID:tx3pF38o
ｿｰｶｿｰｶﾖｼﾖｼ
900 ：デフォルトの名無しさん：2014/06/21(土) 16:16:41.34 ID:0wQ4hVhX
バージョン1.15
ならリリースして少し改造
バージョン2.25
なら、一度全て作り直したって感じでいいのかな？
バージョン名の付け方のルールってある？
ならリリースして少し改造
バージョン2.25
なら、一度全て作り直したって感じでいいのかな？
バージョン名の付け方のルールってある？
901 ：デフォルトの名無しさん：2014/06/21(土) 17:20:16.84 ID:ElcRoqBr
>>900
ある、セマンティックなやつが。
ある、セマンティックなやつが。
902 ：デフォルトの名無しさん：2014/06/21(土) 18:28:28.05 ID:oCK5ln20
>>900
ここよりもプログラム系のとこいった方がいいと思うけど、
よくある付け方は、メジャーバージョン変わるのは大きな仕様変更(互換性に影響あるレベル)したとき、
マイナーバージョンは、小さな仕様変更、
表記は無かったけど、ものによってはもう一つ番号加えてパッチバージョンとして、バグ修正用にしたりする。
major.minor.patch といった感じ
ここよりもプログラム系のとこいった方がいいと思うけど、
よくある付け方は、メジャーバージョン変わるのは大きな仕様変更(互換性に影響あるレベル)したとき、
マイナーバージョンは、小さな仕様変更、
表記は無かったけど、ものによってはもう一つ番号加えてパッチバージョンとして、バグ修正用にしたりする。
major.minor.patch といった感じ
903 ：デフォルトの名無しさん：2014/06/21(土) 20:17:05.33 ID:zNQ9d1mJ
>>900
オープンソースだと奇数は開発版、偶数は安定版ていうルールがあることがある
オープンソースだと奇数は開発版、偶数は安定版ていうルールがあることがある
904 ：デフォルトの名無しさん：2014/06/21(土) 20:22:23.46 ID:m/fZKRgt
アルファ版、ベータ版
テスティング版、スタブル版
テスティング版、スタブル版
905 ：デフォルトの名無しさん：2014/06/21(土) 20:29:04.62 ID:m/fZKRgt
前バージョン使ってた人が新バージョンを使う際に新たに学習が必要な場合はメジャーバージョンアップ
前バージョン使ってた人が新バージョンを使う際に新たに学習が必要なく、性能の大幅向上やバグフィクスやセキュリティアップデートはマイナーバージョンアップ
前バージョン使ってた人が新バージョンを使う際に新たに学習が必要なく、誤字脱字の修正や性能の微々たるの変化のある場合はリビジョンアップ
前バージョン使ってた人が新バージョンを使う際に新たに学習が必要なく、性能の大幅向上やバグフィクスやセキュリティアップデートはマイナーバージョンアップ
前バージョン使ってた人が新バージョンを使う際に新たに学習が必要なく、誤字脱字の修正や性能の微々たるの変化のある場合はリビジョンアップ
906 ：デフォルトの名無しさん：2014/06/21(土) 21:01:35.87 ID:4Db89jJs
互換性が壊れる場合はmajor、互換性が壊れない範囲の新機能はminor、外から見てわからん変更とバグ修正はrevision
907 ：デフォルトの名無しさん：2014/06/21(土) 21:06:19.94 ID:tQVBpUxD
マイナーバージョンは修正した数だけ増やす
1.0 メジャーバージョンは新規機能を実装しない
1.1.1 １個修正 マイナーバージョンは修正した数を乗せる
1.2.20 20個修正
1.0 メジャーバージョンは新規機能を実装しない
1.1.1 １個修正 マイナーバージョンは修正した数を乗せる
1.2.20 20個修正
908 ：デフォルトの名無しさん：2014/06/21(土) 21:12:09.56 ID:v5uiY6Gs
バージョン番号が４つ区分されてるやつは何なのさ
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 OPR/22.0.1471.70
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 OPR/22.0.1471.70
909 ：デフォルトの名無しさん：2014/06/21(土) 21:38:55.79 ID:cR4XxXTT
>>908
ソースが同じでも、バイナリにはビルド番号をつけることがある。
ソースが同じでも、バイナリにはビルド番号をつけることがある。
910 ：デフォルトの名無しさん：2014/06/21(土) 21:41:47.53 ID:0wQ4hVhX
パズドラのバージョンが6.5.2
なんだけど6回一からコーディングし直したってこと？
あーいうのって誰からみてもわからいけどソースを何度も組換えたりしてるのかな。
なんだけど6回一からコーディングし直したってこと？
あーいうのって誰からみてもわからいけどソースを何度も組換えたりしてるのかな。
911 ：デフォルトの名無しさん：2014/06/21(土) 21:52:24.22 ID:m/fZKRgt
そんなのパズドラの開発者に聞けよ
バージョン番号なんてどこもオレオレルールでつけてんだから
バージョン番号なんてどこもオレオレルールでつけてんだから
912 ：デフォルトの名無しさん：2014/06/21(土) 21:59:46.56 ID:KMvjaKi+
バージョン番号とかだと途中をすっ飛ばしたりすることもあるしな
913 ：デフォルトの名無しさん：2014/06/21(土) 22:33:56.67 ID:sYh0doPA
途中どころか最初がすっ飛ばされたWindows NTなんてのも
914 ：デフォルトの名無しさん：2014/06/22(日) 01:13:02.79 ID:b9DzNs9Q
WindowsNTって4.0なんだよな。
そう考えるとWindowsってメジャーバージョンほとんど変わってないんだな。
そう考えるとWindowsってメジャーバージョンほとんど変わってないんだな。
915 ：デフォルトの名無しさん：2014/06/22(日) 01:20:05.59 ID:upDz43Y5
NTの最初のバージョンは3.0か3.1だった気がする
916 ：デフォルトの名無しさん：2014/06/22(日) 02:00:52.05 ID:fzAy+jFw
Windows3.1に合わせて3.1から
917 ：デフォルトの名無しさん：2014/06/22(日) 02:01:46.19 ID:Y+HF0vpz
Windowsのバージョンってverで表示される
「6.1.7601」とかのことだろう？
「6.1.7601」とかのことだろう？
918 ：デフォルトの名無しさん：2014/06/22(日) 02:02:12.05 ID:fzAy+jFw
3.1 → 3.5 → 3.51 → 4.0 → 2000 → XP
だな
だな
919 ：デフォルトの名無しさん：2014/06/22(日) 02:07:27.82 ID:Y+HF0vpz
商品名とバージョン番号をごっちゃにしすぎｗ
920 ：デフォルトの名無しさん：2014/06/22(日) 02:10:49.59 ID:fzAy+jFw
もともとMSはバージョン番号と商品名が同じだったのを、95とNT系は2000から
バージョン番号隠すようになっただけだよ
バージョン番号隠すようになっただけだよ
921 ：デフォルトの名無しさん：2014/06/22(日) 02:13:42.83 ID:fzAy+jFw
まあそれ言ったら、SolarisもMacOSも似たような路線
内部のこまかいバージョンの話とは別の話なんで、ごっちゃもなにもない
内部のこまかいバージョンの話とは別の話なんで、ごっちゃもなにもない
922 ：デフォルトの名無しさん：2014/06/22(日) 02:15:23.06 ID:Y+HF0vpz
はいはい、昔のWindowsのバージョン版を
まとめたものを見つけてきてやったよ。
https://gist.github.com/mxpv/2935584
一部適当に抜粋
Windows Name or Service Pack Version Number
---------------------------- --------------
Windows 1.0 1.04
Windows 2.0 2.11
Windows 3.0 3
Windows NT 3.1 3.10.528
Windows 95 4.0.950
Windows Me 4.90.3000
Windows 2000 Professional 5.0.2195
Windows XP Home 5.1
Windows Server 2008 Service Pack 1 (SP1) RTM 6.0.6001.18000
Windows Vista RTM 6.0.6000.16386
Windows 7 RTM 6.1.7600
Windows 8 CTP 6.2.8250
まとめたものを見つけてきてやったよ。
https://gist.github.com/mxpv/2935584
一部適当に抜粋
Windows Name or Service Pack Version Number
---------------------------- --------------
Windows 1.0 1.04
Windows 2.0 2.11
Windows 3.0 3
Windows NT 3.1 3.10.528
Windows 95 4.0.950
Windows Me 4.90.3000
Windows 2000 Professional 5.0.2195
Windows XP Home 5.1
Windows Server 2008 Service Pack 1 (SP1) RTM 6.0.6001.18000
Windows Vista RTM 6.0.6000.16386
Windows 7 RTM 6.1.7600
Windows 8 CTP 6.2.8250
923 ：デフォルトの名無しさん：2014/06/22(日) 02:16:21.09 ID:pzst23eU
NTはOS/2 3.0になるはずだったから3.0から始まる
924 ：デフォルトの名無しさん：2014/06/22(日) 02:18:34.94 ID:pzst23eU
>>922
NT4.0がないぞ
NT4.0がないぞ
925 ：デフォルトの名無しさん：2014/06/22(日) 02:19:20.89 ID:Y+HF0vpz
>>924
適当に抜粋って書いただろ。 リンク先見ろよｗ
Windows 95 4.0.950
Windows NT Workstation 4.0 4.0.1381
Windows 98 4.1.1998
Windows 98 Second Edition 4.1.2222
Windows Me 4.90.3000
適当に抜粋って書いただろ。 リンク先見ろよｗ
Windows 95 4.0.950
Windows NT Workstation 4.0 4.0.1381
Windows 98 4.1.1998
Windows 98 Second Edition 4.1.2222
Windows Me 4.90.3000
926 ：デフォルトの名無しさん：2014/06/22(日) 02:21:26.42 ID:Y+HF0vpz
これ見てわかるのは
Windowsは1.0の時からバージョン番号1.04と
製品名とバージョン番号は一致していないということ。
百歩譲って1.04の上から三文字目までで1.0なんだってことにしても
Windows 2.0は、バージョン番号2.11 の2.1であるべきってことになってしまう。
Windowsは1.0の時からバージョン番号1.04と
製品名とバージョン番号は一致していないということ。
百歩譲って1.04の上から三文字目までで1.0なんだってことにしても
Windows 2.0は、バージョン番号2.11 の2.1であるべきってことになってしまう。
927 ：ID:Y+HF0vpz （連続投稿って言われたからID変えた）：2014/06/22(日) 02:27:51.31 ID:+pyEYukS
928 ：デフォルトの名無しさん：2014/06/22(日) 03:05:54.38 ID:K+SZQQqt
うんず→3.0+mme→3.1→95→98se→2000→Vista
929 ：デフォルトの名無しさん：2014/06/22(日) 03:10:27.16 ID:yfiuaqlG
いい加減にGitと関係ない話題は
930 ：デフォルトの名無しさん：2014/06/22(日) 04:16:35.04 ID:41dfNV8s
まあ関係無い話題で埋めるのもいいけど、使い切ったら次スレ立てといてくれよ
>>1のPro GitのURL直すの忘れないでくれ
>>1のPro GitのURL直すの忘れないでくれ
931 ：デフォルトの名無しさん：2014/06/22(日) 07:56:27.10 ID:JoFGWc9c
cygwin で git を使ってるんだが
2.0 から速くなった気がする
2.0 から速くなった気がする
932 ：デフォルトの名無しさん：2014/06/22(日) 12:41:22.20 ID:h8mHZ8/o
>>930
【スレタイ】
Git 10
【本文】
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 9
http://peace.2ch.net/test/read.cgi/tech/1397276540/
【スレタイ】
Git 10
【本文】
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 9
http://peace.2ch.net/test/read.cgi/tech/1397276540/
933 ：デフォルトの名無しさん：2014/06/22(日) 17:00:32.70 ID:nR1nGnXp
>>931
cygwinの公式パッケージってバージョン1.7.9じゃなかったっけ？
cygwinの公式パッケージってバージョン1.7.9じゃなかったっけ？
934 ：デフォルトの名無しさん：2014/06/22(日) 17:43:36.22 ID:mgZTcG6H
935 ：デフォルトの名無しさん：2014/06/22(日) 18:01:37.92 ID:2YpoFnMx
936 ：デフォルトの名無しさん：2014/06/22(日) 23:52:57.71 ID:UK6G8JDB
俺がプロジェクト名に言語名を入れろって話は怒られたのにこんなスレ違いな話しやがって
937 ：デフォルトの名無しさん：2014/06/22(日) 23:57:11.41 ID:qgZFRwqF
お前が怒られなくなるわけじゃねえから
938 ：デフォルトの名無しさん：2014/06/23(月) 10:18:41.33 ID:9imRHr/V
プロジェクト名に言語名を入れるのは考えるまでもなくデメリットが大きいが、
バージョン番号は必要だからな。
バージョン番号は必要だからな。
939 ：デフォルトの名無しさん：2014/06/23(月) 11:40:55.87 ID:2cPnnJRd
バージョン番号は、git tagしたときの
表示順に影響するかもしれないから
関係有るかもしれないしな。
githubはバージョンの付け方の標準通りに
賢くソートしてくれたはず。
表示順に影響するかもしれないから
関係有るかもしれないしな。
githubはバージョンの付け方の標準通りに
賢くソートしてくれたはず。
940 ：デフォルトの名無しさん：2014/06/23(月) 13:32:38.70 ID:rcMzefHm
じゃあさphpで作ったライブラリは
C:/projects/phpの中に入れるって感じでいいの？
プロジェクト名に言語名を入れないでフォルダ名に言語名を付けてその下にプロジェクトを入れる感じはどう？
C:/projects/phpの中に入れるって感じでいいの？
プロジェクト名に言語名を入れないでフォルダ名に言語名を付けてその下にプロジェクトを入れる感じはどう？
941 ：デフォルトの名無しさん：2014/06/23(月) 13:33:10.12 ID:rcMzefHm
20も30もプロジェクトが増えると「あれ、このプロジェクトって何言語で書いたかな」みたいにそのフォルダをのぞくまでワカラナイんだよ
942 ：デフォルトの名無しさん：2014/06/23(月) 13:34:08.94 ID:rcMzefHm
んで言語が混合する場合はc:/project/otherの中にいれる
あ、あと念の為いいますけどhtml+javascript+jquery+phpの場合はphpとして管理します
あ、あと念の為いいますけどhtml+javascript+jquery+phpの場合はphpとして管理します
943 ：デフォルトの名無しさん：2014/06/23(月) 13:42:56.08 ID:sjU94AhZ
>>940-942
それはprojectsディレクトリ以下を一つのリポジトリにする前提で話をしてるの？
それはprojectsディレクトリ以下を一つのリポジトリにする前提で話をしてるの？
944 ：デフォルトの名無しさん：2014/06/23(月) 13:50:17.34 ID:TU3Y/liM
お恥ずかしいのですが自己解決できないため質問させてください
OSはvista 32bitです
最新のmsysgitをインストールしたのですが、日本語入力ができません
1.8.3以降は日本語がデフォで入力可能だと聞いたのですが……
msysgitにフォーカスをあてるとIMEのバーが黒くなってしまう状態です
原因がわかる方おられませんか？
OSはvista 32bitです
最新のmsysgitをインストールしたのですが、日本語入力ができません
1.8.3以降は日本語がデフォで入力可能だと聞いたのですが……
msysgitにフォーカスをあてるとIMEのバーが黒くなってしまう状態です
原因がわかる方おられませんか？
945 ：デフォルトの名無しさん：2014/06/23(月) 14:06:03.99 ID:xTO7gkHY
そういう場合はサクっとtortoiseGitも入れてしまうのだ。
え？解決になってない？
え？解決になってない？
946 ：デフォルトの名無しさん：2014/06/23(月) 14:28:51.83 ID:TU3Y/liM
>>945
Gitを利用した経験がないためまずはCUIで触ってなれようと思ったのですが、このありさまです
もう一台のＰＣに同じようにインストールしてみたところ、そちらでの日本語入力は問題ありませんでした
なにかＰＣ側で設定がおかしいんでしょうね
Gitを利用した経験がないためまずはCUIで触ってなれようと思ったのですが、このありさまです
もう一台のＰＣに同じようにインストールしてみたところ、そちらでの日本語入力は問題ありませんでした
なにかＰＣ側で設定がおかしいんでしょうね
947 ：デフォルトの名無しさん：2014/06/23(月) 16:43:35.75 ID:Te+HAwBv
GoogleAppsScriptのソースってgitで管理出来ませんか？
948 ：デフォルトの名無しさん：2014/06/23(月) 22:36:15.01 ID:uyVruWrs
結局pyenvに戻って来ました
949 ：デフォルトの名無しさん：2014/06/24(火) 00:04:34.97 ID:pnjDJdog
>>943
c:/projects/php/abc
c:/projects/php/def
c:/projects/ruby/ghi
c:/projects/ruby/jkl
c:/projects/python/mno
c:/projects/python/pqr
c:/projects/php/abc
c:/projects/php/def
c:/projects/ruby/ghi
c:/projects/ruby/jkl
c:/projects/python/mno
c:/projects/python/pqr
950 ：デフォルトの名無しさん：2014/06/24(火) 00:05:24.71 ID:A6Ca/1xX
>>943
言語ディレクトリ内にプロジェクトを作ってプロジェクトごとにリポジトリを作るんだよ
言語ディレクトリ内にプロジェクトを作ってプロジェクトごとにリポジトリを作るんだよ
951 ：デフォルトの名無しさん：2014/06/24(火) 00:14:05.87 ID:M10hum9+
gitonomyでも使え
952 ：デフォルトの名無しさん：2014/06/24(火) 00:37:23.10 ID:yDq5nVzd
言語名で分ける必要性が個人的にはよくわからないな。
そのコードを書く原因となったプロジェクト別に分けるとかのほうが後で見返すのが楽なような気がするけど。
まあなにを第一キーにして分類するかというのは人それぞれっちゃ人それぞれなんだけど。
言語別で分けたいっていう人は、使う言語からプロジェクトが大別される的な感じなのかな。PHPを使ったプロジェクトとRubyを使ったプロジェクトは全然性質が異なる、的な感じで。
そのコードを書く原因となったプロジェクト別に分けるとかのほうが後で見返すのが楽なような気がするけど。
まあなにを第一キーにして分類するかというのは人それぞれっちゃ人それぞれなんだけど。
言語別で分けたいっていう人は、使う言語からプロジェクトが大別される的な感じなのかな。PHPを使ったプロジェクトとRubyを使ったプロジェクトは全然性質が異なる、的な感じで。
953 ：デフォルトの名無しさん：2014/06/24(火) 01:49:51.54 ID:Imybggoz
言語君の話はもうやめてくれ…
954 ：デフォルトの名無しさん：2014/06/24(火) 02:25:00.96 ID:VcS2x6xz
勉強とかだと「言語/プロジェクト/」は割と自然だけど
そうでなければ普通はプロジェクトが主役で、言語はその手段でしかないんだよなあ
そうでなければ普通はプロジェクトが主役で、言語はその手段でしかないんだよなあ
955 ：デフォルトの名無しさん：2014/06/24(火) 02:37:33.45 ID:+d9rugo5
cd /; git init; git add .; git commit -m'init'
したらどうなるの？
したらどうなるの？
956 ：デフォルトの名無しさん：2014/06/24(火) 03:01:36.48 ID:k7EYrAZu
やってみればいいじゃん
957 ：デフォルトの名無しさん：2014/06/24(火) 06:49:44.85 ID:BxyDqmCe
リポジトリをローカルファイルシステムの何処に置くかなんて好きにすればいい
何処に配置されてるなんて情報はgitリポジトリには保存されてないのだから
何処に配置されてるなんて情報はgitリポジトリには保存されてないのだから
958 ：デフォルトの名無しさん：2014/06/24(火) 10:45:38.99 ID:E3n8a7VR
また言語で分けるとか言ってる奴が来てるのか？ｗ
そんなどうでも良い話題でも、みんなちゃんと
答えてあげてるじゃないか。
言語で分けるべきではない。がみんなの回答だよ。
そんなどうでも良い話題でも、みんなちゃんと
答えてあげてるじゃないか。
言語で分けるべきではない。がみんなの回答だよ。
959 ：デフォルトの名無しさん：2014/06/24(火) 12:25:39.58 ID:L6gjd31u
リポジトリの数が増えすぎて管理が大変っていうならリモートリポジトリならgitonomy
などの管理ソフト使えばいいしローカルならそれこそ好きにフォルダ名決めればいい
などの管理ソフト使えばいいしローカルならそれこそ好きにフォルダ名決めればいい
960 ：デフォルトの名無しさん：2014/06/24(火) 12:44:38.20 ID:wbKSVw02
じゃあさjavaでエディタを作るとするじゃん
terapodって名前すするじゃん
それをc#に移植するときとかどうするんだよ
だから
c:/projects/java/terapd
c:/projects/c#/terapd
って言語別にわかれていたほうがいいんだよ
gitonomyなんて無駄なものを入れる必要もないでしょ
terapodって名前すするじゃん
それをc#に移植するときとかどうするんだよ
だから
c:/projects/java/terapd
c:/projects/c#/terapd
って言語別にわかれていたほうがいいんだよ
gitonomyなんて無駄なものを入れる必要もないでしょ
961 ：デフォルトの名無しさん：2014/06/24(火) 12:46:24.03 ID:L6gjd31u
だからローカルなら好きにすればいいじゃん
962 ：デフォルトの名無しさん：2014/06/24(火) 13:34:43.42 ID:yDq5nVzd
>>960
自分なら
terapod-java
terapod-c#
とするかな
じゃあさ、そのterapodで必要な機能を実装するのにC++でラッパーDLL書かなきゃいけなくなったらどうする？
c++/terapod-dll にするの？
まあ、なんでもいいんだけど、実際に複数のプログラムを組み合わせてアプリケーションを作っていると1つの言語で完結しないことも間々あるし、
なんらかのプロジェクトを思い出すときに、まず言語を思い出すって発想がちょっとよくわからないんだよね。
「terapodは…javaで書いたからjavaフォルダの中にあるのか」というのは若干回りくどいように感じるよ。
言語が分類の第一となるキーになるという発想が馴染むケースが、勉強とか以外にあんまり想像できないんだよね。
言語の選択は目的じゃなくて単なる手段なわけだし。
自分なら
terapod-java
terapod-c#
とするかな
じゃあさ、そのterapodで必要な機能を実装するのにC++でラッパーDLL書かなきゃいけなくなったらどうする？
c++/terapod-dll にするの？
まあ、なんでもいいんだけど、実際に複数のプログラムを組み合わせてアプリケーションを作っていると1つの言語で完結しないことも間々あるし、
なんらかのプロジェクトを思い出すときに、まず言語を思い出すって発想がちょっとよくわからないんだよね。
「terapodは…javaで書いたからjavaフォルダの中にあるのか」というのは若干回りくどいように感じるよ。
言語が分類の第一となるキーになるという発想が馴染むケースが、勉強とか以外にあんまり想像できないんだよね。
言語の選択は目的じゃなくて単なる手段なわけだし。
963 ：デフォルトの名無しさん：2014/06/24(火) 13:38:31.46 ID:L6gjd31u
c:/projects/editor/terapd/java
とかでも何でもいいよ。好きにしな。
とかでも何でもいいよ。好きにしな。
964 ：デフォルトの名無しさん：2014/06/24(火) 16:19:36.76 ID:cSTWjjId
言語の学習目的は除いて普通は作る物を決めてからそれに最適な言語を選ぶからな
965 ：デフォルトの名無しさん：2014/06/24(火) 23:22:12.22 ID:UpeRHjTe
sshのconfigでgithubのアカウントを複数管理しているんですけど
configもgithubとかにpushしちゃうものですか？
バックアップとかどうやってとってますか？
configもgithubとかにpushしちゃうものですか？
バックアップとかどうやってとってますか？
966 ：デフォルトの名無しさん：2014/06/24(火) 23:39:15.40 ID:X3HExdh5
githubでgit cloneするときにユーザー名とパスワードを聞かれるんですけど
このパスワードってgithubのアカウントのを入力すればいいんですか？
それともsshキーを作った時に設定したパスワードを入力したらいいんですか？
どっちを入力してもInvalid username or pas
sword.^@fatal: Authentication failed for ～って出ます
このパスワードってgithubのアカウントのを入力すればいいんですか？
それともsshキーを作った時に設定したパスワードを入力したらいいんですか？
どっちを入力してもInvalid username or pas
sword.^@fatal: Authentication failed for ～って出ます
967 ：デフォルトの名無しさん：2014/06/25(水) 03:38:10.84 ID:GQuGFHte
普通ならキーを作った時に設定したのはパスフレーズのはずだぞ
968 ：デフォルトの名無しさん：2014/06/25(水) 04:35:18.90 ID:PrRAheWA
git clone https://github.com/... ならアカウントのでしょ。
969 ：デフォルトの名無しさん：2014/06/25(水) 05:37:45.59 ID:4vpWZdAs
そのプロジェクトにどんな技能を持った土方を投入すべきかを考える立場の人にとっては
言語単位の管理が楽でいい
現場の都合なんか知ったことか
言語単位の管理が楽でいい
現場の都合なんか知ったことか
970 ：デフォルトの名無しさん：2014/06/25(水) 05:53:07.27 ID:x2k8TeiH
cloneでユーザIDとパスワード聞かれるってことはプライベートリポジトリか？
971 ：デフォルトの名無しさん：2014/06/25(水) 08:31:36.55 ID:wdWoGsPu
エスパーすると、Pageantがタスクバーにいない or 鍵が入ってない
972 ：デフォルトの名無しさん：2014/06/25(水) 09:09:53.09 ID:oKcHQ11V
なんか存在しないリポジトリにアクセスするとユーザー名とパスワードを聞かれるようでした
正しいリポジトリにアクセスしたら聞かれなくなりました
それなら最初から聞かないで404 not foundでも表示して欲しいんですけどなんでなんでしょうかね？
正しいリポジトリにアクセスしたら聞かれなくなりました
それなら最初から聞かないで404 not foundでも表示して欲しいんですけどなんでなんでしょうかね？
973 ：デフォルトの名無しさん：2014/06/25(水) 10:13:48.32 ID:QnQpw2y6
>>966
sshかhttpsかどっちでcloneしてるかによるんじゃなかった。
多分sshでやってるけど、鍵を使うように設定してなくて、フォールバックでパスワード認証になってるけど設定されてないんじゃない。
sshかhttpsかどっちでcloneしてるかによるんじゃなかった。
多分sshでやってるけど、鍵を使うように設定してなくて、フォールバックでパスワード認証になってるけど設定されてないんじゃない。
974 ：デフォルトの名無しさん：2014/06/25(水) 14:11:00.00 ID:NedFU3Wc
せっかくプライベートにしてるのに、そういうプロジェクトがあるというヒントを出すわけにいかないから
存在しなくても認証出すんだろ。
存在しなくても認証出すんだろ。
975 ：デフォルトの名無しさん：2014/06/25(水) 14:12:25.02 ID:JWd/N+XK
おれがいってるのはこれ
https://github.com/Shougo/unite.git
https://github.com/Shougo/unite.git
976 ：デフォルトの名無しさん：2014/06/25(水) 14:47:07.15 ID:fb6jKK+E
cloneするurlをタイプミスしたりしたら
977 ：デフォルトの名無しさん：2014/06/25(水) 15:32:42.45 ID:fb6jKK+E
がびーん・・・git reset の使い方を間違ったらしくここ数日の編集が丸っと消えた・・・
978 ：デフォルトの名無しさん：2014/06/25(水) 15:37:44.45 ID:NedFU3Wc
reset ってそういいうものかと。
revert したかった？
revert したかった？
979 ：デフォルトの名無しさん：2014/06/25(水) 15:42:56.67 ID:fb6jKK+E
ありがとう git reflog 復活でけた
980 ：デフォルトの名無しさん：2014/06/25(水) 15:45:24.40 ID:x2k8TeiH
コミットの状態にさえしてれば、ほぼ不死身だ
981 ：デフォルトの名無しさん：2014/06/25(水) 18:02:12.54 ID:E2n+vjmt
git flowとgithug flowってどっちがメジャー？
982 ：デフォルトの名無しさん：2014/06/25(水) 20:57:10.22 ID:az4qdKzA
>>933
ソースをビルドした
ソースをビルドした
983 ：デフォルトの名無しさん：2014/06/25(水) 21:00:04.82 ID:x2k8TeiH
>>981
どっちも
どっちも
984 ：デフォルトの名無しさん：2014/06/25(水) 21:22:05.91 ID:xmlnjG4w
git flowをやるのなら、git flowのツールを使うのが普通だと思うが、
そのgit flowツールの話が出ない所を見るとgit flowはあまり
使われてないのではないか？
かといって、github flowがよく使われているってことにはならないが。
たぶんgit flowとgithub flowは同じぐらい。
同じぐらいだが、一番多いのはそのどちらでもない。
俺俺flowってのが答えだろう。
そのgit flowツールの話が出ない所を見るとgit flowはあまり
使われてないのではないか？
かといって、github flowがよく使われているってことにはならないが。
たぶんgit flowとgithub flowは同じぐらい。
同じぐらいだが、一番多いのはそのどちらでもない。
俺俺flowってのが答えだろう。
985 ：デフォルトの名無しさん：2014/06/25(水) 22:07:09.05 ID:p7rx9Iqg
Aのサーバーが死んでたらBからpullするみたいなことがしたいんだけど、
gitってそういうことできるんだろうか？
gitってそういうことできるんだろうか？
986 ：デフォルトの名無しさん：2014/06/25(水) 22:31:39.51 ID:KDMLN+6a
フェイルオーバーはGitの仕事じゃない気がするけど
987 ：デフォルトの名無しさん：2014/06/25(水) 22:52:39.65 ID:wsqw+sxk
remoteのurlを複数指定できて、先に返事もらった方からpullするとか
同期とれていないと悲しいことになりそうだが
同期とれていないと悲しいことになりそうだが
>>982
cygwinでビルドできるのか、試してみるよありがとう
cygwinでビルドできるのか、試してみるよありがとう