Git 11©5ch.io
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん 転載ダメ©2ch.net
2014/11/17(月) 12:30:50.08ID:Lk6/z9LsGit - 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 10
http://peace.2ch.net/test/read.cgi/tech/1403426425/
0002デフォルトの名無しさん
2014/11/17(月) 15:02:31.45ID:ok9ehdHVバージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ〜 Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
【分散型バージョン管理】 Mercurial 2【hg】
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://peace.2ch.net/test/read.cgi/tech/1356521407/
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/
◆関連スレ 別板
CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/
0003デフォルトの名無しさん
2014/11/17(月) 15:21:36.56ID:ok9ehdHVPro Git 日本語版電子書籍公開サイト
http://progit-ja.github.io/
Gitで困ったときに読む本 2014/10 著:ウラジミール・ガジャ 訳:長尾高弘
http://books.shoeisha.co.jp/book/b183513.html
15時間でわかるGit集中講座 2014/06 著:岡本隆史 織田翔 大山智之
http://gihyo.jp/book/2014/978-4-7741-6575-2
開発効率をUPする Git逆引き入門 2014/04 著:松下雅和 船ヶ山慶 平木聡 土橋林太郎 三上丈晴
http://www.c-r.com/book/detail/970
0004デフォルトの名無しさん
2014/11/17(月) 15:23:39.33ID:ok9ehdHVGit ポケットリファレンス 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 著:Jon Loeliger オライリー本
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8
入門Git 2009/09 著:濱野純
http://www.shuwasystem.co.jp/products/7980html/2380.html
入門git 2009/08 著:Travis Swicegood 監訳:でびあんぐる
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9
0005デフォルトの名無しさん
2014/11/17(月) 16:58:13.71ID:KMJsrmwT0006デフォルトの名無しさん
2014/11/17(月) 17:33:02.93ID:YUWmI/Qt,,ｲ`" ､-' `;_' ' ..::::::::::::::...
,-､ _.._ ( (,(~ヽ'~ ..:::::::::::::::::::::::
）'~ ﾚｰ' 〉 ヽ i`'} .:::::::::::::::::::::::
~つ '-ｰ､ i | i' ...:::::::::::::::::::::::
／ < / 。/ ! ......::::::::::::::::::::::::: これは>>1乙じゃなくて
/ ~^´ /},-'' ,●::::::::::::::::::::::::::::::::::::
i､ ,i' _,,...,-‐-､/ i :::::::: .:::::::::::::
..ゝ <,,-＝=､ ,,-,/ .::::::::::: 放射能がうんたら
) {~''~>`v-''`ｰﾞ`'~ ..::::::::: ........::.
{ ﾚ_ﾉ ..::::::::. ......:::::::::
ノ '' ..::::::: ...::.:...:::::::::
.::::::::: ...:......:::::::::::: .
.:::::::::::. ..... .. ..:::::::::::::::::::::::: :::.
::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.. :: ::..
.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::: ::.
::::::::::::::::: :::::::::::::::::::::::::::::: :::::
.:: ::. :::
0007デフォルトの名無しさん
2014/11/17(月) 17:38:21.03ID:KYBRFuL5抜けてるだろ。手抜きすんな
デザイナーからプログラマーまで 絶対わかるGitバージョン管理
アリスとボブのGit入門レッスン
Web制作者のためのGit入門
わかる Git
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール
GitHub
http://www.amazon.co.jp/dp/B008K411SS
※ いまなら0円！
0008デフォルトの名無しさん
2014/11/17(月) 17:49:05.25ID:LbJ3F7u50009デフォルトの名無しさん
2014/11/17(月) 17:55:41.01ID:bJSEiY3Nブランチも今までたくさん作って来ました
25回目にコミットしたときにログを書き換える方法を教えてください
ログに誤字があるで書き換えたいんです
0010デフォルトの名無しさん
2014/11/17(月) 18:03:43.13ID:ok9ehdHVテンプレ貼ったのは>>1じゃ無いのにかわいそうｗ
基本的にスレで上がった書籍を追加してるよ
Github関連の書籍は他にもあるけど除いてあるよ
次回はこのへん追加しとく？
デザイナーからプログラマーまで 絶対わかるGitバージョン管理 2014/10 著:松島浩道
http://www.sbcr.jp/products/4797380361.html
Web制作者のためのGit入門 2014/06 著:大杉充 外村和仁
https://book.mynavi.jp/ec/products/detail/id=25306
アリスとボブのGit入門レッスン 2012/09 著:川野辺正博
http://www.shuwasystem.co.jp/products/7980html/3500.html
わかるGit 著:冨永和人
http://p.booklog.jp/book/61359
0011デフォルトの名無しさん
2014/11/17(月) 18:05:33.14ID:ok9ehdHV現メインメンテナーの濱野氏の本はProGitの次ぐらいに載せとくかねえ
0012デフォルトの名無しさん
2014/11/17(月) 18:07:21.99ID:ok9ehdHV0013デフォルトの名無しさん
2014/11/18(火) 10:39:19.25ID:SNYtXSA4次は事前にテンプレ候補出しといてねえ
0014デフォルトの名無しさん
2014/11/18(火) 16:23:51.07ID:hq/rBA8+http://fox.2ch.net/test/read.cgi/poverty/1416286592/
0015デフォルトの名無しさん
2014/11/18(火) 18:15:56.52ID:B5/xScPc屑が多過ぎる
0016デフォルトの名無しさん
2014/11/18(火) 18:19:20.20ID:n3svk6HWお前が間違っても落第しないレベルだといいな
0017デフォルトの名無しさん
2014/11/18(火) 18:23:00.88ID:/aEHbgmj対象は医療ミスで訴訟を受けるレベルの深い所だけみたい
0018デフォルトの名無しさん
2014/11/18(火) 18:31:19.12ID:huk+BQqLプログラマ用の資格は幾つもあるよ
それを持ってる奴だけ使うとか信用すればいいじゃん
0019デフォルトの名無しさん
2014/11/18(火) 18:59:52.20ID:z9H1LUO90020デフォルトの名無しさん
2014/11/18(火) 19:17:56.70ID:+HeMrvVp0021デフォルトの名無しさん
2014/11/18(火) 19:22:23.65ID:WFCSoEiB0022デフォルトの名無しさん
2014/11/18(火) 21:57:24.53ID:GfoKGAop0023デフォルトの名無しさん
2014/11/18(火) 23:17:45.16ID:y3qZQj9X0024デフォルトの名無しさん
2014/11/19(水) 07:09:24.22ID:pSOR1byj0025デフォルトの名無しさん
2014/11/19(水) 12:33:22.90ID:JZ2oYyd90026デフォルトの名無しさん
2014/11/19(水) 21:36:48.78ID:pSOR1byj0027デフォルトの名無しさん
2014/11/19(水) 23:22:53.10ID:EYHPnhFF0028デフォルトの名無しさん
2014/11/20(木) 22:28:30.59ID:XNdxy1/i0029デフォルトの名無しさん
2014/11/21(金) 16:21:32.54ID:kFYjyzR/0030デフォルトの名無しさん
2014/11/22(土) 07:52:11.50ID:uJfzZE/k現在、あるリポジトリＡとＢがあり、それぞれファイルを１００個ほど管理しています。
Ａ，Ｂに関連性はありません。
やりたいことは、
Ａの中の特定のファイル２〜３個を履歴込みでＢへ登録or移動したい
です。
リポジトリA,Bを新規リポジトリＺに１本化するとかのサンプルはあるのですが
上記のような場合どうしていいかわかりません。
AをBにマージしてからいらないものを削除すればたしかに必要なファイルと履歴はのこるかもしれませんが
リポジトリが肥大化するしゴミもいろいろ残りそうなので、シンプルにやる方法はないでしょうか？
0031デフォルトの名無しさん
2014/11/22(土) 08:52:03.65ID:VpeaW/bhgit filter-branchを使ってリポジトリAの特定のファイル２〜３個だけの履歴を含んだブランチを作って、
それをBのブランチにマージすればいいんでない？
0032デフォルトの名無しさん
2014/11/22(土) 11:18:34.44ID:783isNag0033デフォルトの名無しさん
2014/11/22(土) 11:41:22.20ID:783isNagこれってgit reset コミットハッシュだけじゃなくてgit reset HEAD@{n}もダメってことですよね？
0034デフォルトの名無しさん
2014/11/22(土) 12:05:39.84ID:9mlDmcy8当たり前。
ってかさ、子供じゃないんだから、「○○しちゃ駄目」とか「△△も駄目」ってのを一つ一つ暗記するんじゃなくて、
「○○したら××という状況になるからやらない方がいい。けど、××という状況にならない、または××になっても解決できるならやってもいい場合もある。」
ってことを自分の頭で考えて判断できるようになるといいね。
0035デフォルトの名無しさん
2014/11/22(土) 15:34:29.76ID:lpYW/WdC0036デフォルトの名無しさん
2014/11/22(土) 16:22:14.62ID:+v/EHt0tgit rebaseはHEAD~0やHEADじゃなくてHEAD~1は最新コミットを指すのですか？
0038デフォルトの名無しさん
2014/11/28(金) 05:50:50.87ID:rofpdZmb0039デフォルトの名無しさん
2014/11/28(金) 07:11:17.10ID:xLUnuPlV0040デフォルトの名無しさん
2014/11/28(金) 11:26:12.19ID:rofpdZmbpushされるの?
0041デフォルトの名無しさん
2014/11/28(金) 12:07:17.98ID:rofpdZmb0042デフォルトの名無しさん
2014/11/28(金) 22:45:02.48ID:uoMVF3+Kほかの人と共有するなら注意が必要だけど。
0043デフォルトの名無しさん
2014/11/28(金) 23:10:57.87ID:5kELuVmQ0044デフォルトの名無しさん
2014/11/28(金) 23:58:07.90ID:rofpdZmbそこで途切れてるbranchというのはイメージそのままだし。
共有しているbranch一覧見た時も、いつも出てきちゃうのか。BTSと連携してるので、そのチケット番号をbranch名にしておけば大丈夫…な…はず。
0045デフォルトの名無しさん 転載ダメ©2ch.net
2014/11/29(土) 02:43:44.54ID:AzYE7zg40046デフォルトの名無しさん
2014/11/29(土) 12:00:44.16ID:hg0pyRtW2014年11月28日15:52 末岡洋子
http://sourceforge.jp/magazine/14/11/29/063600
0047デフォルトの名無しさん
2014/11/29(土) 12:34:10.37ID:IKUaO2mT2.0以降がカスだから？
0048デフォルトの名無しさん
2014/11/29(土) 12:36:01.52ID:UY5TRY2TWindowsにはTeam Foundationがあるんだからいいじゃん
0049デフォルトの名無しさん
2014/11/29(土) 12:49:39.06ID:IKUaO2mTその暴言を吐くのか？馬鹿なの？死ぬの？
0050デフォルトの名無しさん
2014/11/29(土) 13:47:30.31ID:tRG4REsoあれはgitじゃないmsysgitだ！
0051デフォルトの名無しさん
2014/11/29(土) 19:31:48.86ID:A9a31mA5チームのサイズによるだろ
5名以下なら Express Edition で無償
普通の奴も 65,000円ぐらいだし
0052デフォルトの名無しさん
2014/11/29(土) 19:36:10.03ID:1Jq357Cf0053デフォルトの名無しさん
2014/11/29(土) 20:10:26.95ID:f9GHRVfHちょい前に営業さんに聞いたら、あまり出てないですねーって言ってた
まあ、出てないのレベルはよくわからんけどか
0054デフォルトの名無しさん
2014/11/29(土) 20:20:42.02ID:1Jq357Cf全然、って事だろうなｗ
0055デフォルトの名無しさん
2014/11/29(土) 21:33:08.86ID:IKUaO2mT取り敢えず、お前がTeam Foundationという単語だけしか
知らないという事が確定した。
0056デフォルトの名無しさん
2014/11/29(土) 21:50:49.39ID:1Jq357Cf0057デフォルトの名無しさん
2014/11/29(土) 23:04:34.17ID:f9GHRVfHで、どこが間違ってるんだ？
0058デフォルトの名無しさん
2014/11/30(日) 03:59:09.60ID:uxHSis3Uどう思う？
0059デフォルトの名無しさん
2014/11/30(日) 04:40:34.64ID:g5kdkWec0060デフォルトの名無しさん
2014/11/30(日) 05:53:26.40ID:c9Q+Jt/4信者はたくさんいるが、使ってる奴はいない。
0061デフォルトの名無しさん
2014/11/30(日) 08:17:13.85ID:t4/3aPOfなんだ、間違ってないならいいや
知ったかの御託聞かされてもしょうがないし
0062デフォルトの名無しさん
2014/11/30(日) 09:23:39.79ID:awyRf5UB私もいくつかのお客さんとこで Team Foundation を使わされているが、費用的には想像を絶していたよ。
0063デフォルトの名無しさん
2014/11/30(日) 09:41:58.91ID:B2VgLsUL0064デフォルトの名無しさん
2014/11/30(日) 10:00:11.49ID:wey4zK/vGitはLinuxのためにあるんだから、Windowsが後回しになるのは仕方ないことだろ
0065デフォルトの名無しさん
2014/11/30(日) 10:35:11.49ID:e0aRXJPC0066デフォルトの名無しさん
2014/11/30(日) 13:46:09.86ID:kUIpsKvT0067デフォルトの名無しさん
2014/11/30(日) 14:02:33.65ID:Q44JDfrW0068デフォルトの名無しさん
2014/11/30(日) 14:08:35.28ID:v5kZpHtK> 私もいくつかのお客さんとこで Team Foundation を使わされているが、費用的には想像を絶していたよ。
それほんとに Team Foundation の費用か？
ちょっと構成書いてみて
0069デフォルトの名無しさん
2014/11/30(日) 14:13:47.68ID:kUIpsKvTそんなことも知らないのか？
お前が単語しか知らないことが確定した。
0070デフォルトの名無しさん
2014/11/30(日) 14:20:34.61ID:v5kZpHtK構成が書けない時点で、お前が知ったかであることが確定した w
0071デフォルトの名無しさん
2014/11/30(日) 19:44:28.74ID:awyRf5UB例えば、Visual Studio Ultimate with MSDNを「馬鹿正直に1ライセンス」購入すると
\1,709,940
になるってことかな…
0072デフォルトの名無しさん
2014/11/30(日) 19:53:21.13ID:7WEYW95Rだと思った。
お前が単語しか知らないことが確定した。
はい、次の話どうぞ
0073デフォルトの名無しさん
2014/11/30(日) 19:56:06.69ID:CJTIqzdj0074デフォルトの名無しさん
2014/11/30(日) 20:10:15.70ID:awyRf5UBちなみに本当のアスペルガーは何よりもアスペ、アスペと言われるのが恐ろしくて
自分から先に「お前はアスペ、アスペ」と言い出すらしいね…
してみると単語しか知らないことってのが心に突き刺さったままになって「使わずにはおれない」
ということなんだろうなあ…ご愁傷さま…
0075デフォルトの名無しさん
2014/12/01(月) 00:07:58.58ID:dnARwXmU0076デフォルトの名無しさん
2014/12/01(月) 09:14:00.16ID:B1S4sCHX> 自分から先に「お前はアスペ、アスペ」と言い出すらしいね…
このスレで一番最初にアスペって言い出したのは誰かって
思って検索してみたらお前でワロタｗ
0077デフォルトの名無しさん
2014/12/01(月) 09:21:11.29ID:dvWcGq9A医者でもないのにね
0078デフォルトの名無しさん
2014/12/01(月) 12:58:43.22ID:iu+0lcnQ0079デフォルトの名無しさん
2014/12/01(月) 18:59:31.27ID:wOG0sgv/0080デフォルトの名無しさん
2014/12/02(火) 09:41:02.82ID:0iGQaLgn私も単語しか知らないので、team foundationについて、費用、導入方法、メリット教えて下さい。
0081デフォルトの名無しさん
2014/12/02(火) 12:54:48.15ID:gTSu1Ahohttp://www.microsoft.com/ja-jp/dev/products/team-foundation-server.aspx
Team Foundation なるものは ID:awyRf5UB に聞くしかない
0082デフォルトの名無しさん
2014/12/02(火) 13:38:46.02ID:2HEveihy0083デフォルトの名無しさん
2014/12/02(火) 13:57:28.37ID:X7nShCY60084デフォルトの名無しさん
2014/12/02(火) 14:39:26.10ID:FNIO4rhV0085デフォルトの名無しさん
2014/12/02(火) 21:02:37.34ID:gTSu1Aho単語以上を知らないとできない、クールなレスよろ w
0086デフォルトの名無しさん
2014/12/02(火) 21:49:14.43ID:JIq5qYWA0087デフォルトの名無しさん
2014/12/08(月) 11:06:33.30ID:hokbMnTRアドベントカレンダーで初めて知った・・・
いままでずっとeでマニュアル書き換えしていたよ、、、
0088デフォルトの名無しさん
2014/12/09(火) 23:46:33.39ID:2LCVJN5E<<<<<<< HEAD
AAAAAAAAAAAAA
=======
BBBBBBBBBBBBB
>>>>>>> merged-branch
の形にしてくれるマージってないかな。
0089デフォルトの名無しさん
2014/12/09(火) 23:50:26.02ID:jqkVke/ndiff
0090デフォルトの名無しさん
2014/12/10(水) 01:19:55.28ID:6qL25NKnこれみたいなマージするはめになったらマージを中止する
みたいなオプションありますか？
0091デフォルトの名無しさん
2014/12/10(水) 03:35:02.05ID:rVmy1tAp0092デフォルトの名無しさん
2014/12/10(水) 04:20:41.84ID:fAea2ULW0093デフォルトの名無しさん
2014/12/10(水) 07:53:36.46ID:qwB6bqKA0094デフォルトの名無しさん
2014/12/10(水) 19:05:09.74ID:W4PmgbuG0095デフォルトの名無しさん
2014/12/11(木) 02:22:03.75ID:l2zgEmQV0096デフォルトの名無しさん
2014/12/11(木) 23:10:57.76ID:sQ1Sre6L>>94
ありがとう！
これで助かりそうです！
0097名無しさん＠そうだ選挙に行こう
2014/12/13(土) 17:20:43.04ID:FOIn0bzK0098デフォルトの名無しさん
2014/12/14(日) 22:08:25.86ID:9CZ8nEqT>This software was developed to power GitHub, and should be considered production ready.
たょっと調べたらこんなのあったよ
0099デフォルトの名無しさん
2014/12/19(金) 13:22:54.29ID:Rp55Z5Hhブランチを作成、としても名前だけ変わって一本続きで分岐しません
0100デフォルトの名無しさん
2014/12/19(金) 15:59:58.70ID:M007GgfU0101デフォルトの名無しさん 転載ダメ©2ch.net
2014/12/20(土) 06:30:50.23ID:lfXUCENo0102デフォルトの名無しさん
2014/12/20(土) 07:03:55.37ID:9UfcCvZlもうVisual SourceSafeに乗り換えるわ
分散型バージョン管理システム「Git」に脆弱性、任意のコマンドが実行される恐れ - 窓の杜
http://www.forest.impress.co.jp/docs/news/20141219_681222.html
0103デフォルトの名無しさん
2014/12/20(土) 08:58:18.22ID:EPihr/pv優秀なソフトなんですなぁ
0104デフォルトの名無しさん
2014/12/20(土) 09:31:35.59ID:o+cLiwxD0105デフォルトの名無しさん
2014/12/20(土) 09:48:16.53ID:hZSDfw1l0106デフォルトの名無しさん
2014/12/20(土) 12:25:41.96ID:uvfjkA/y0107デフォルトの名無しさん
2014/12/20(土) 12:47:18.21ID:F1BtQojgどうなってるんだ。Appleのせいだな！
0108デフォルトの名無しさん
2014/12/20(土) 13:23:36.06ID:QoTvkGDH>Linux環境には影響はない。
0109デフォルトの名無しさん
2014/12/20(土) 13:31:57.16ID:cUhMXe+F放置って...
いつの話だよ w
0110デフォルトの名無しさん
2014/12/20(土) 14:23:57.82ID:qyYbVqEqTFSがVSSの後継って言ってるし
0111デフォルトの名無しさん
2014/12/20(土) 16:00:55.57ID:cEZQa2xeVSがGitに対応したので使ってるよ。
Gitを使うかTFSを使うかは、OSによって変わるのではなく、チームの内容によって
変わるんじゃないのかな。
オープンソースならGitは良いよね。
てんでバラバラに開発、試行錯誤で良かったものだけマージする。
こういった感じには良いと思う。
でも、チームのスケジュールを完全にコントロールできる、会社とかだったら、
TFSの方が良いよね。
0112デフォルトの名無しさん
2014/12/20(土) 20:00:47.73ID:Q9vEpymj0113デフォルトの名無しさん
2014/12/20(土) 23:36:05.31ID:F1BtQojg>Linux環境には影響はない。
これは嘘だな。
LinuxでもNTFSやHFS+は使えるので、
使っていれば影響はある。
0114デフォルトの名無しさん
2014/12/21(日) 00:06:04.32ID:LfG/evkY会社だとマージしにくい修正が多いから
チェックアウト状態がわかるほうがいいよな
0115デフォルトの名無しさん
2014/12/21(日) 04:08:52.73ID:I8/pKXIXhttp://mercurial.selenic.com/wiki/WhatsNew
svnとかcvsとかは大丈夫なんかねぇ
>>113
NTFSはLinuxでマウントするとちゃんと区別して2つのファイル作れるぞ
HFS+は区別されないけど、Macでコマンド打ってジャーナル無効にしないと
書き込み可能でマウント出来ないんでレアケースじゃないかなぁ
0116デフォルトの名無しさん
2014/12/21(日) 06:30:41.17ID:gQMH/TzB0117デフォルトの名無しさん 転載ダメ©2ch.net
2014/12/21(日) 08:11:16.52ID:gz6N4oXHHFS+は、パーティションで区別設定を有効するれば
gitを使用するソースを、区別するパーティションに格納するという使い方も可能
0118デフォルトの名無しさん
2014/12/21(日) 09:41:45.41ID:vTqE34dVMsysGitやCygWinを使う方法はあるけど、Windowsと環境変数がぶつかると
トラブルが起きることがあるので、安心して使えないのよね
0119デフォルトの名無しさん
2014/12/21(日) 09:53:46.77ID:P3EyVxIm0120デフォルトの名無しさん
2014/12/21(日) 10:22:23.86ID:Zlnv1xeI0121デフォルトの名無しさん
2014/12/21(日) 10:27:32.97ID:vTqE34dVWindows版のVimを使っているところに
Cygwinを入れたらトラブったことがあるんだよ
トラブルの内容は忘れたが、原因が環境変数だったことは覚えている
0122デフォルトの名無しさん
2014/12/21(日) 10:55:27.50ID:kuosliUP0123デフォルトの名無しさん
2014/12/21(日) 11:09:45.81ID:vTqE34dVいや、確かホームディレクトリに関わっていたはず
どっちのVimも同じC:\Documents and Settings〜を見に行くから
そこにあったWindows版Vimの設定ファイル群が
Cygwin版Vimを使った時に更新されてしまうとか、そんなだったと思う
0124デフォルトの名無しさん
2014/12/21(日) 11:31:16.91ID:kuosliUP0125デフォルトの名無しさん
2014/12/21(日) 11:42:15.95ID:vTqE34dVそうだっけ
やっぱり記憶が曖昧だな
当時、苦心して調べた末に
「Windows版とCygwin版のVimは環境変数の衝突により
共存使用不可」という結論に達したんだがなあ
0126デフォルトの名無しさん
2014/12/21(日) 12:15:15.68ID:zMAxnasU0127デフォルトの名無しさん
2014/12/21(日) 12:20:00.76ID:kuosliUPWindows版gvimとCygwin版vimとMsysGit同梱のvimを使い分けてるが別に問題はないな。
0128デフォルトの名無しさん
2014/12/21(日) 12:28:42.01ID:/RNkRysA0129デフォルトの名無しさん
2014/12/21(日) 12:33:07.75ID:o+TCxEQXなので、Cygwinの中からWin32 GVimを起動するときはHOME環境変数を
削除してから起動するとかの対応が必要。あとはTMP, TEMP, SHELLとかも注意。
0130デフォルトの名無しさん
2014/12/21(日) 13:24:19.00ID:Zlnv1xeI0131デフォルトの名無しさん
2014/12/21(日) 14:01:21.01ID:XZ/0moqWunixコマンド群やunix向けツールが手軽に使いたいだけならcygwinほど気軽なものはない
ターミナルとしてすぐ開いて使えるのはよい
0132デフォルトの名無しさん
2014/12/21(日) 15:03:08.94ID:gQMH/TzB0133デフォルトの名無しさん
2014/12/21(日) 15:17:00.96ID:4wVFcLEQ0134デフォルトの名無しさん
2014/12/24(水) 13:30:11.13ID:gcI8XOf/ここ、b.txtだけをコミットしたことにしたいんです
a.txtは3個前のコミット後に編集はしていません
どうしたらいいのかおしえてください
0135デフォルトの名無しさん
2014/12/24(水) 14:40:58.28ID:j+6n37pjgit rebase -i HEAD^^^
# a.txt b.txt のコミットに edit を指定してエディタ終了
git rm a.txt
git commit --amend
git rebase --continue
とかどう？
0136デフォルトの名無しさん
2014/12/24(水) 14:51:57.88ID:sFocZIgX0137デフォルトの名無しさん
2014/12/25(木) 03:47:40.93ID:7tmlSq9Tもう少し簡単にできないものかと思う。
0138デフォルトの名無しさん
2014/12/25(木) 05:08:49.58ID:WpMZaymj0139デフォルトの名無しさん
2014/12/25(木) 09:41:29.23ID:qKZrZOHg0140デフォルトの名無しさん
2014/12/25(木) 12:28:37.08ID:7j1tNoomみたいなオプションがあればちょっとは分かりやすいかな・・・
うちはとりあえず細かくコミットしておいて
rebase -i で squash ぷよぷよしてくっつけて行くのが多いかな
分割はめんどいよね
0141デフォルトの名無しさん
2014/12/25(木) 12:59:00.64ID:Y5il8ylR0142デフォルトの名無しさん
2014/12/26(金) 11:18:57.71ID:vx3/L6UO0143デフォルトの名無しさん
2014/12/26(金) 13:56:39.35ID:KN+qDrDJ0144デフォルトの名無しさん
2014/12/26(金) 15:02:07.48ID:YGnpq5kMgit
0145デフォルトの名無しさん
2014/12/26(金) 15:59:06.01ID:PUSaAK8w0146デフォルトの名無しさん
2014/12/26(金) 16:43:46.33ID:3+AsH2Jegitサーバー立てるだけが一番軽いと思うが
gitlabのようなコミュニケーションには別途httpで掲示板でも構築しとけ
0147デフォルトの名無しさん
2014/12/26(金) 16:58:21.15ID:hTDPC82Aとりあえず掲示板
0148デフォルトの名無しさん
2014/12/26(金) 17:02:47.81ID:KN+qDrDJ0149デフォルトの名無しさん
2014/12/26(金) 18:21:37.08ID:zOzDLp+X0150デフォルトの名無しさん
2014/12/26(金) 18:59:41.73ID:YjiQFeUWgitコマンドだけあれば良くて、sshdもいらないんだよ。
0151デフォルトの名無しさん
2014/12/26(金) 19:34:15.37ID:Kry4Lshd0152デフォルトの名無しさん
2014/12/26(金) 19:48:44.07ID:PtLybYrK0153デフォルトの名無しさん
2014/12/26(金) 20:36:03.08ID:3+AsH2Jeローカルというと他のマシンとは繋がない状態を意味するのか
0154デフォルトの名無しさん
2014/12/26(金) 23:20:36.81ID:rmtyj2850155デフォルトの名無しさん
2014/12/26(金) 23:59:52.59ID:dVFEeQ9K一人開発でリボジトリをローカルHDDに置くやり方だと
あえてGitに移るメリットってないですかね？
0156デフォルトの名無しさん
2014/12/27(土) 00:06:09.09ID:wjq2mj57そうでもないなら大して変わらないんじゃね
0157デフォルトの名無しさん
2014/12/27(土) 00:12:21.59ID:VUv+O6dj0158デフォルトの名無しさん
2014/12/27(土) 00:19:59.37ID:IjiARnNfコミットをやり直して綺麗なコミット履歴を作れるので
この行はどういう理由で変更したんだろう、
というのを後から調べやすくなる (git blame)
あとはでかいソースでも動作が早いとかかな
0159デフォルトの名無しさん
2014/12/27(土) 00:31:15.75ID:c7RrH6WTむしろsvnはなんで通信しないコマンドでもあんなに遅いんだろ
0160デフォルトの名無しさん
2014/12/27(土) 03:44:32.48ID:0O6OCcK7A機能修正
B機能修正
A機能のタイポ修正orz
みたいなコミット
リリース後に気づいたものなら仕方ないが、
ついさっきやらかした簡単なミスをいちいちコミットに残すのは
後からコードを見る人にとって迷惑でしかない。
0161デフォルトの名無しさん
2014/12/27(土) 03:58:40.40ID:Ii6i8G3w0162デフォルトの名無しさん
2014/12/27(土) 04:12:25.83ID:0O6OCcK7SVN ・・・ 複数ファイル単位の管理
git ・・・ 開発単位の管理
SVNまではファイルを管理していたに過ぎない。
gitになってようやく開発ツールになった。
0163デフォルトの名無しさん
2014/12/27(土) 08:43:47.14ID:6QM9MelF0164デフォルトの名無しさん
2014/12/27(土) 08:44:47.03ID:AKOS2ykD大した負荷でもないし
ローカルでもssh経由だと覚えること少なくて済む
0165デフォルトの名無しさん
2014/12/27(土) 08:47:48.55ID:AKOS2ykD構わんよ
0166デフォルトの名無しさん
2014/12/27(土) 15:11:31.55ID:Ii6i8G3w0167デフォルトの名無しさん
2014/12/27(土) 18:45:55.48ID:N9htnTKpこれがわからんのだよな
そういうの残した方がいいと思うんだけど
実際下らないハマり方するのって、どうでもいいって差分だったりしない?
git のログを綺麗のするのが目的になってる感がイマイチ理解できない
0168デフォルトの名無しさん
2014/12/27(土) 19:02:47.62ID:VUv+O6dj0169デフォルトの名無しさん
2014/12/27(土) 19:08:43.78ID:voxLBZvaブランチの切り替えにマージにbisectに。
もうほんの数秒だって遅らせたくない。
これはコードの品質に大きく影響する。
0170デフォルトの名無しさん 転載ダメ©2ch.net
2014/12/27(土) 19:09:11.62ID:gUzMpItvここのコメントの誤字直したからコミット
こんなログが残ってても意味ないし邪魔なだけ
0171デフォルトの名無しさん
2014/12/27(土) 19:17:52.53ID:PS8qPAgg気持ちはわかるが、そう言うのが多い奴はコードに対する意識が低く、コードの品質も低いから残しておくべき
0172デフォルトの名無しさん
2014/12/27(土) 20:02:41.87ID:N9htnTKp結果出してりゃたまにならいいんじゃねえの
git ガーコードの品質ガーって言う奴で
適当な仕事する奴の方が手に負えん
0173デフォルトの名無しさん
2014/12/27(土) 23:03:45.24ID:LHlssG36> これがわからんのだよな
> そういうの残した方がいいと思うんだけど
なんのために？
> git のログを綺麗のするのが目的になってる感がイマイチ理解できない
コードをレビューしないの？ 一つのコミットをレビューすればいい状態と
複数のコミットをレビューしなければいけない状態、
A、B、A' ・・・今からA機能のレビューをします。A'はAの修正なので、
A＋A’で見なければなりません。はい面倒。
ブランチが複数あって（1.0リリース版、1.1開発版）
そこに1.0に緊急リリースのコミットが来た時、A＋A'の二つを持ってきて
それをまた、1.1にも、二つのコミットを持ってくる。
revertしたくなったら、二つのコミットをrevertする。
はい面倒。
0174デフォルトの名無しさん
2014/12/27(土) 23:06:28.85ID:9Xb/3ND5コミットログの修正し直しでそいつの作ったプログラムの品質を判断したいというなら、修正した回数だけ記録するとか、修正されたログだけ抽出して確認できるとかのほうがいいわな
0175デフォルトの名無しさん
2014/12/27(土) 23:06:40.74ID:LHlssG36> 気持ちはわかるが、そう言うのが多い奴はコードに対する意識が低く、コードの品質も低いから残しておくべき
残す目的が変。おかしい。
コミットは"使う"ものなんだが。
作業記録じゃないんだよ？
コミット＝一つの機能の修正であり、
内容を確認したり、別の人が取り込んだりするもの。
その時、一つの機能が、複数のコミットに分散されていたら
使いにくいだろ。
あんた、コミットを使ったことないでしょ？
見返すこともないでしょ。
0176デフォルトの名無しさん
2014/12/27(土) 23:07:45.06ID:qPECBbxH意識の低いやつは残しててもそんなの教訓にしないよ
そういう奴いる場合はマスターレポジトリへのpush権をなくして
コアメンバーがレビューした上で、そいつの個人レポジトリからpullする
って運用もできるのが利点かな
0177デフォルトの名無しさん
2014/12/27(土) 23:13:29.12ID:LHlssG36誤字脱字を訂正する。
赤ペンで間違いに丸をつけたり
取り消し線を使ったり、修正液を使ったり。
そして訂正だらけの試行錯誤したものを
他人に見せるようなもの。
レビューしてください！
見づらいだけだし、こんなのを
保存していたって何の意味もない。
完成版だけがあればいい。
0178デフォルトの名無しさん
2014/12/27(土) 23:40:23.00ID:N9htnTKp> コードをレビューしないの？ 一つのコミットをレビューすればいい状態と
なるほど、レビュー前提だとログ綺麗な方がいいな
つーかレビューできるような環境なら、そもそもそこまでおかしな現象に遭遇せんかもなあ
0179デフォルトの名無しさん
2014/12/28(日) 01:52:43.13ID:hWEKpKUx完成したらマージだろ
おまいら一々本流にコミットしてんの？
0180デフォルトの名無しさん
2014/12/28(日) 01:59:05.50ID:5TbtuF1N作成中はブランチでやって、
一連の機能（小さな修正の組み合わせ）が完成したら
そのブランチをレビューしてもらう
その時、タイポ修正コミットとか、途中の細かい仕様修正前のコミットとか
最終的には見る必要がないコミットがあるとレビューしづらいから取り除く。
そしてレビューが済んだら本流にマージ
だろう？ 違うのかね？
0181デフォルトの名無しさん
2014/12/28(日) 02:00:55.69ID:hWEKpKUx0182デフォルトの名無しさん
2014/12/28(日) 02:02:02.86ID:5TbtuF1Nなんのために？
0183デフォルトの名無しさん
2014/12/28(日) 02:18:10.73ID:hWEKpKUx一個上のラスくらい嫁
0184デフォルトの名無しさん
2014/12/28(日) 02:19:24.28ID:ft77FrlNログに人為的に手を加えるとかただの趣味的な偽装だな
0185デフォルトの名無しさん
2014/12/28(日) 02:22:57.99ID:hWEKpKUxx 一個上のラスくらい嫁
o 自分のレスくらい嫁
0186デフォルトの名無しさん
2014/12/28(日) 02:25:35.96ID:5TbtuF1Nマージしただけじゃレビューしやすくはならんだろ。
マージする時に出来るのは、複数のコミットを一つにまとめる（squash）
そのコミットを残したままマージするかだ。
コミットを残したままマージしたらレビューしやすくはならんから除外だな。
マージすることでレビューしやすくなるということは、複数のコミットを一つにまとめるしかないんだが、
要するに俺が言ってる、途中の細かい修正のコミットを取り除くと言っているのと全く同じことだぞ。
ただしsquashだと一つのコミットにすることしか出来ない。
小さい修正であればレビューできるが、一連の機能、つまり複数のファイルへの修正を
一度に提出されてもレビューできない。
レビューするには、該当の機能（ブランチ）を、無駄のない小さな修正（コミット）の連続
という形にするのが一番やりやすい。
最終的のその形になればいいから、マージをうまく利用してそのような形を作ることも不可能ではないが
いちいち作業用のブランチを作らずにそれをもっと効率よく出来るようにしたのがrebaseだ。
0187デフォルトの名無しさん
2014/12/28(日) 02:30:22.66ID:5TbtuF1N> ミスと修正を淡々と記録していくツールで
そんなのを記録して、何の役に立つの？
0188デフォルトの名無しさん
2014/12/28(日) 02:49:05.34ID:TuEnubjU0189デフォルトの名無しさん
2014/12/28(日) 02:57:37.09ID:ecVHbpnHほとんどが1コミット、多くて2〜3コミット
そのままマージすればハッシュがレビューの証明にもなるし
なので基本できるだけ、ハッシュの変わるmerge --squashやmerge&rebaseはあまりしない
マスターへのマージを本人以外がする場合もあるしね
Linuxカーネルとかこんな感じだよね
0190デフォルトの名無しさん
2014/12/28(日) 02:59:48.75ID:5TbtuF1N> 各コミットのテストが通ってればミスだろうがなんだろうがmasterに突っ込んじゃって構わないよ。
後からそのコミットを参照するときはどうするのさ？
0191デフォルトの名無しさん
2014/12/28(日) 03:02:54.77ID:5TbtuF1N> なので基本できるだけ、ハッシュの変わるmerge --squashやmerge&rebaseはあまりしない
それは整理済みのやつだろ？ リリース済みのやつをrebaseしろとかそういう話はしてないよ。
今の話は、
> レビューする時には整理済みのコミットにするな
こっち。
レビューする前に整理済みにする。タイポとか、途中の軌道修正とか
そういうレビューに値しないコミットは取り除く。
残す意味は無いし、デメリットはあれどメリットはない。
0192デフォルトの名無しさん
2014/12/28(日) 03:06:07.10ID:5TbtuF1N完成（のつもり）でレビュー依頼をする
問題が見つかったので差し戻し
修正して再度レビュー依頼をする。 （新たに修正コミットが作られる）
を何回か繰り返す。
この場合の差し戻しの修正コミットは、最終的には必要ないので
masterにマージされるまでの何処かで削除するべき。
0193デフォルトの名無しさん
2014/12/28(日) 03:09:54.70ID:ecVHbpnHああ、ごめん否定じゃないよ。
> レビューする時には整理済みのコミットにするな
自分はレビューする時には整理済みのコミットにしているよ。って事で、
人に見せるものはできるだけ1コミットが好き。
0194デフォルトの名無しさん
2014/12/28(日) 03:19:52.85ID:ecVHbpnH修正前のブランチは無効って事にして
また整理済みのコミットにするね。
gitでコミットが整理できるようになってからは、
バージョン管理よりもコードのドキュメント化をしている
って意味合いが強くなってきたね
0195デフォルトの名無しさん
2014/12/28(日) 03:21:48.46ID:5TbtuF1N否定ではないと思ったけど念のため。
わかってない人は、コミットを何のために残すのか？
ってのがわかってないんだろうね。
バージョン管理ソフトで管理するのは成果であって作業じゃないんだよ。
これだけ努力しました〜とかこれだけミスしました〜とか
いちいち途中でやったことを記録しても意味ない。
成果（最終的なコミット）を見たいのであって、それに至る作業はどうでもいいわけで。
0196デフォルトの名無しさん
2014/12/28(日) 04:09:19.42ID:TuEnubjUすまん、意味がよく分からなかった。
普通にsha1ハッシュから指定すればいい。
0197デフォルトの名無しさん
2014/12/28(日) 04:13:13.10ID:ZOuXNPglGitに粘着すんな
0198デフォルトの名無しさん
2014/12/28(日) 05:11:47.98ID:e5SRT1ev後からそのコミットを参照する時、
Aという機能のコミットが、a、a'、a''と分かれている時に、
a''で完成しているのに、aを参照したってしょうがないって話。
aを参照して、これバグっているな。いやいやa'で修正されてるじゃん、
みたいなことをやっても無駄になる。
0199デフォルトの名無しさん
2014/12/28(日) 10:37:56.27ID:2faWu2Kj0200デフォルトの名無しさん
2014/12/28(日) 11:07:56.18ID:6jddN6260201デフォルトの名無しさん
2014/12/28(日) 11:30:07.31ID:3MqE8jBWhttp://qiita.com/gogotanaka/items/8c55f69120965b077737
0202デフォルトの名無しさん
2014/12/28(日) 11:35:14.89ID:e5SRT1evまさにこれだね。
> 私が思うに多くのcontributor達が歴史的な理由もあってgitやgit rebase -iを
> よく思わない事が主な理由で、彼らがコミットをそれぞれ独立させるのではなく、
> 思いつくままにコミットを作ってしまう事がいけないのではないかと思っている.
>
> 例えばこんな感じ
>
> 素晴らしいfeatureを思いつき、手をつける
> しまったtypoしてた直さないと
> しまったバグを直さないと
> featureを仕上げる
>
> この様なcontributor達がもし、そのままのcommitをpull-requestに出して、
> それがが受け入れらない（つまりマージされない）という事は当然の報いだとは思うが、
> 多くのcontributorはgit rebase -i とgit commit -pを用いて修正をしている訳で、
> この様なcommitは受け入れられるべきだと思う.
typoとかバグとか最終的に見なくていいものの修正でコミットしたものを
そのままpull-requestするな（レビューに出すな）と
git rebase -i や git commit -pでちゃんと修正しろと。
0203デフォルトの名無しさん
2014/12/28(日) 12:43:33.96ID:TuEnubjUそれこそ、aの変更でキチンと失敗してくれるようなテスト書いとけよって話だな。
でないとa'でホントに修正されてるかも怪しいし。バージョン管理関係無い。
そこらへんのコンセンサスが取りづらいならファストフォワード禁止にしてもいい。
あとで「なんか動き怪しいからお前のマージコミット取り消すわ」ってできる。
0204デフォルトの名無しさん
2014/12/28(日) 13:02:54.15ID:6jddN6260205デフォルトの名無しさん
2014/12/28(日) 13:06:18.22ID:e5SRT1ev> それこそ、aの変更でキチンと失敗してくれるようなテスト書いとけよって話だな。
> でないとa'でホントに修正されてるかも怪しいし。バージョン管理関係無い。
それは理想論。
テストが通ればOKというのなら、レビューそのものの存在意義を否定していることになる。
レビューはするべきだし、レビューで戻りが出て修正するのは当たり前に発生すること。
第一、テストが通ったって、現にバグは存在しているわけで、
あんたがいっていることは現実とかけ離れている
テストを書くことを忘れることだってある。それを見つけるのがレビューでもある。
リリースしてしまったバグは、rebaseでなかったことには出来ないが、
レビューした後の戻りとか、テストで検出できないタイポとか、
リリース前の修正をいちいち残す理由がない。
残してしまったら、あとでリリース内容をみた時に混乱するだけ。
コミットの内容を後で使う。ということを考えないで単なる作業履歴としてしか
みてないから、>>201のいうように"思いつくままにコミットを作"ってしまって、
その汚いコミットをそのままマージしてしまうか、小さいコミットに分けずに
ブランチ全体を一つのコミットにまとめてしまうことになる。
0206デフォルトの名無しさん
2014/12/28(日) 13:07:51.67ID:dl26eyah0207デフォルトの名無しさん
2014/12/28(日) 13:11:30.32ID:e5SRT1ev集まりであることを理解していない。
機能αがあった時、それを構成するのが、a, b, c, dというコミットだったとする。
a, b, c, dというコミットはαを作るために必要な修正であるが、
全体であるαの仕様が変われば、その仕様を構成a, b, c, dの内容も変わる。
場合によっては、aの機能を変えないといけないかもしれないし、
bの修正は不要になるかもしれない。
αが完成するまでは、a, b, c, dは完成しない、つまり後から修正が入るんだよ。
0208デフォルトの名無しさん
2014/12/28(日) 13:13:56.75ID:6jddN6260209188
2014/12/28(日) 13:55:55.03ID:TuEnubjU何か勘違いしてる。
「マージする」という行為は「レビューしましたよ、私はOKですよ」と言っているのに等しい。
勝手にマージしといて「お前のコミットのせいで足撃ったぞバカ！」も何もない。
マージからの多分SVNと同じように中央集権型で運用してるんだろうけど、
マージからのレビューじゃなくて、レビューからのマージにしないと回らないよ。
あと、リリースしたバージョンにはきちんとタグをつけること。
後から見直したいならタグ付けされたコミットだけ追えばよろし。
問題箇所が明らかならblameすればいい。
タイポや戻りの修正を残す理由が無い、というのも間違い。
それは単にログが見づらいからというだけで、
アウトプット側の問題をインプットでなんとかしようとしてる。これは破綻する。
そうじゃないでしょ。一旦公開した修正は必ず残せ。
公開前に気づいてたならrebaseで整形できる。
マージ戦略はコミットIDが頼りだから、公開後のツリーを弄りはじめたら
そこらじゅうでコンフリクトして迷惑かけることになるよ。
可能な限り綺麗にしてたいってのは同意見だけど、
潔癖症がたたって本来の目的を台無しにしちゃ本末転倒でしょ。
0210デフォルトの名無しさん
2014/12/28(日) 13:57:19.69ID:6jddN6260211デフォルトの名無しさん
2014/12/28(日) 14:06:36.55ID:e5SRT1ev勘違いしてるのはあんただ。
> 「マージする」という行為は「レビューしましたよ、私はOKですよ」と言っているのに等しい。
じゃあ、マージする前にレビューするということだろ。
レビューするということは、OKになるかNGになるかということ。
レビューした後にNGになったら、マージしない。
マージせずに何をするかというと、そのブランチを修正する。
そのブランチの修正とは、たとえばタイポの修正のような簡単なものから
関数の引数名前や、仕様そのものの修正までいろいろある。
aという内容に修正しようと思ったら、問題が発生して
最終的にbという内容に変わった。「問題があるa」を残す必要はあるか？
何のために？ その理由が言えないならば、「ない」で決定だ
> それは単にログが見づらいからというだけで、
ログ、つまり過去のコミットが見づらいことが問題にならないということはなぜか？
それはコミットを見ようと思っていないという証拠。
過去のコミットを使うことがないから、過去はどうでもいいやって考えてる。
> そうじゃないでしょ。一旦公開した修正は必ず残せ。
公開とはmaster（などの本流）にマージされた状態だ。
レビュー前は公開されてない状態だ。残す必要はない。
マージ前が非公開状態であることをわかってないね。
0212デフォルトの名無しさん
2014/12/28(日) 14:09:55.21ID:e5SRT1ev> 勝手にマージしといて「お前のコミットのせいで足撃ったぞバカ！」も何もない。
あ？ そうか、お前、「ブランチを誰から見える場所にプッシュする」
という機能を知らないな。
いきなりマージしてるだろ。
お前の言うレビューはブランチを作らないで、適当なディレクトリに
コードを置いて、レビューしてくださいってやってるだろ？
実際にはコードのレビューは含まれていなくて、コードを見ない動作テストのみ意味してそうだが。
0213デフォルトの名無しさん
2014/12/28(日) 14:13:20.77ID:6jddN626えっ
0214デフォルトの名無しさん
2014/12/28(日) 14:16:52.74ID:e5SRT1ev他人が見えるという意味では公開だが機能としてはまだ非公開
作りかけであり公式機能として搭載されたものではない。
0215デフォルトの名無しさん
2014/12/28(日) 14:27:22.01ID:TuEnubjUもう一度言うよ。
アウトプット側の問題をインプットでどうにかしようとするのは間違い。
あなたは目的に合ったログの効果的な閲覧方法を知らないだけで、
SourceTreeやgitkのグラフがデフォルトでゴチャゴチャ入り組んでるのが
堪忍ならないって喚いてるだけ。
マウスのホイールまさぐりながらしかめっ面してるのが目に浮かぶ。
なお悪いコトに、それをインプットの問題と決めつけて「サニタイズ」しようとしてる。
レビューされてる状況はどう考えたって公開状態だって。
公開してもらわないとそもそもレビューできない。
0216デフォルトの名無しさん
2014/12/28(日) 14:29:04.93ID:GunkIiJg0217デフォルトの名無しさん
2014/12/28(日) 14:39:23.56ID:TuEnubjUあとコミットログ読めなくても日本語はちゃんと読もうな。
0218デフォルトの名無しさん
2014/12/28(日) 15:13:59.18ID:MqL9JR4c日本語で入門に最適な電子版の本が無料で公開されてますよ
0219デフォルトの名無しさん
2014/12/28(日) 15:55:18.57ID:4VYgwILn0220デフォルトの名無しさん
2014/12/28(日) 22:18:17.01ID:D/mfuejh0221デフォルトの名無しさん
2014/12/28(日) 23:06:16.85ID:gxYCGP9h運用が回ってるなら、こだわるところでもないと思うのだけど、レビューの所は気になった。
リリースもしないレビューのためのブランチをレビューしても意味ないだろ。
レビューが完了したらコミットはいっさい必要ない。そういうものを使わないとレビューした意味がなくなっちゃうぞ。
0222デフォルトの名無しさん
2014/12/28(日) 23:23:52.88ID:ic2uUfWm0223デフォルトの名無しさん
2014/12/29(月) 09:51:27.00ID:KCHPwPam> リリースもしないレビューのためのブランチをレビューしても意味ないだろ。
どういうこと？ レビューしてOKになったら、そのブランチをリリースするんでしょ？
レビューするということはNGになることもあるわけで、
そのブランチを手直し、最悪取り消しになることもあるけど。
> レビューが完了したらコミットはいっさい必要ない。
レビューが終われば、完璧でありバグが一切入ることが
一切ないという前提ならそのとおりだね。
実際に、そんなことが起こることはありえないけど。
なぜレビューが完了したら（レビュー不足でバグがあって将来再度レビューすることになるかもしれないのに）
コミットが必要なくなるというの？
レビューにコミットが必要ならば、将来起こりえるかもしれない再レビューでコミットが必要になるはずだけど。
0224デフォルトの名無しさん
2014/12/29(月) 09:53:27.76ID:KCHPwPamgitにかぎらず、レビュー（とテスト）は必須でしょ？
人が足りない、そんなことをやれる力がないというのは
単にそのチームの問題であって、必須かどうかは別。
本来やるべきものをやらないだめなところっていうのは
どうしてもあるもんだよｗ
0225デフォルトの名無しさん
2014/12/29(月) 09:58:11.48ID:KCHPwPam> 二人の脳内状況がまるで違う、まで読んだ
俺的には、
過去やったことは見返すことはない。
他人の修正内容を見ることはない。
という人と、
過去やったことを見返すことはある。
他人の修正内容を見ることはある。
という違いだと思うよ。
ソースコードがいくら汚くても、動けばOKみたいに考えてるんじゃないかな。
0226デフォルトの名無しさん
2014/12/29(月) 11:19:49.89ID:/fu+2Q3X一緒に仕事したくない
0227デフォルトの名無しさん
2014/12/29(月) 11:51:26.31ID:YSRjw31O>>142
軽さならgitbucket
0228デフォルトの名無しさん
2014/12/29(月) 12:39:24.92ID:DJCCz1Qd運用の違いなのだろうけど、レビューはある工程の仕上げにするものだから、どんな理由にせよ変更したなら再レビューはするもの何じゃない？
指摘の修正、バグの修正がおわったらそれをみるでしょ。
んで、レビューしたブランチをそのままリリースしていくなら、意味ないと言うのは間違いだった。
僕のアタマの中だとリリースはmasterでブランチは開発途中か緊急のパッチというイメージなのでレビューしたあとマージかけたらまたレビューしないとだめじゃんと、そんな話
0229デフォルトの名無しさん
2014/12/29(月) 12:43:47.32ID:/fu+2Q3X0230デフォルトの名無しさん
2014/12/29(月) 13:43:57.10ID:GQVDlkBsそれだと遅すぎですね。それでは出来てしまってから
想像していたものと違うってことになりかねません。
作りかけでも必要と思った所でレビューするべきです。
0231デフォルトの名無しさん
2014/12/29(月) 13:47:13.61ID:ucyEUbJEレビューってさ、複数人が現実的な時間で理解できるレベルのコードってことだよね。
専門性が高くて、そこに価値があるコードを含む場合どうするの?
結構そういう仕事が多いんだが、なんとかしたいんだよな。
もう git の話じゃないような気もするがw
0232デフォルトの名無しさん
2014/12/29(月) 13:53:37.78ID:ucyEUbJEs/レベル/類い/
なんか読み直したら上からだったすまん
0233デフォルトの名無しさん
2014/12/29(月) 14:09:29.27ID:GQVDlkBsどんなに専門性が高いものであっても
専門性が高い部分と、そうでない部分に分けられる。
それらを分離してコミット（マージ）する。
現実的な時間で理解できないのは、コード内容が複雑だから
複数の関連のないコミットがまとまっていたり、
本来一つにまとめるコミットが分散していたり、
それらを一気にやろうとするから理解できなくなる。
コミットを適切に整理することが、理解できるコードにするための第一歩
そうすれば専門性が本当に高くて自分しかわからないようなものでも
それを最小限の量に抑えられる。
0234デフォルトの名無しさん
2014/12/29(月) 15:15:10.82ID:ucyEUbJEシェーダなんかコードが複雑とかそういう問題じゃないんだよね。 AI とかさ。
メンバー全員が理解すべきかというと、それはありえないし。そりゃ理解できたら凄いけども。
こういうのはレビューよりも、困ったときの bisect 対策で、どうでもいいコミットにも残って欲しかったりもする。
レビューで解決できるなら、そっちの方が絶対スマートなんだが。
0235デフォルトの名無しさん
2014/12/29(月) 15:25:56.34ID:UGzXTa7o正しいかどうか見てたらキリないよ
アルゴリズムが正しいか、それが正しく実装されているかはテストで見るべき
コードレビューはtypoしてないか、コーディング規約守ってるか、
変な書き方(無駄なループ、誰が見ても可読性の低いオレオレ制御構造)してないか、
とかそういうのでしょ、コードレビューで確認するのは
そういうのなら専門じゃなくてもある程度わかるはず
0236デフォルトの名無しさん
2014/12/29(月) 15:44:08.16ID:NKff8BVB> こういうのはレビューよりも、困ったときの bisect 対策で、どうでもいいコミットにも残って欲しかったりもする。
どうでもいいコミットが残っていたら、逆にbisectしづらくなるだろ。
0237デフォルトの名無しさん
2014/12/29(月) 16:33:37.00ID:DJCCz1Qdコードレビューは体裁が主体と言うのは同意するが、一応、仕様を満たしているか、性能を満たせるかの観点もみるべよ。
あと、マージしたときにおかしなゴミを作ってないかも気にするかも。
こっちはレビューの時というより差分取り込んだ時のチェックだけど。。。
差分をvimがっつり食わせてちまちま見てく人
guiとか、めんどくさすぎて差分おっていられない。
0238デフォルトの名無しさん
2014/12/29(月) 16:37:29.46ID:ucyEUbJE> コードレビューってアルゴリズムが合っているかとかそういうのは見ないでしょ
そりゃもちろん。
> そういうのなら専門じゃなくてもある程度わかるはず
うーん、そうか、まあわかるならいいんだけど。
>>236
bisect に頼むのって理屈じゃ解決できないことが多くて、ヒントはクソでもいいから残って欲しい場面があったんだよなあ。
コメント変えて動かなくなるとかw
どうせ二分探索なんだから、そんな時間は増えんし。
ただ、レビューだとか git らしく使うこと考えると確かに汚なくなるしなあ。
うまく混在できんもんかね?
0239デフォルトの名無しさん
2014/12/29(月) 16:49:08.43ID:6oaIhkb/0240デフォルトの名無しさん
2014/12/30(火) 17:08:47.49ID:vQ3qtahCgit hash-object ./hoge でとったSHA1ハッシュが、
openssl sha1 ./hoge でとったSHA1ハッシュと違うんですが、
これはこの当然のことなのでしょうか？
ひとくちにSHA1と言っても、オクテットストリームからSHA-1を計算する方法にいろいろあるということでしょうか？
教えて偉い人かエロい人
0241デフォルトの名無しさん
2014/12/30(火) 17:33:05.09ID:rRsXfMExgitはヘッダを付けてからsha1を計算してるので、ファイルのsha1とは一致しないよ。
http://dqn.sakusakutto.jp/2013/10/git_sha1_how_to_calc.html
0242デフォルトの名無しさん
2014/12/31(水) 11:58:07.89ID:IVUewLBwありがとうございます
ヘッダついてたんですね
ためしにヘッダを自作して hoge_with_header を作り、
$ openssl sha1 ./hoge_with_header
してみました。
$ git hash-object ./hoge
と同じハッシュ値が表示されました！
(∩´∀`)∩ワーイ
よく分かりました
エロい人、どうもありがとうございました
0243デフォルトの名無しさん
2014/12/31(水) 12:38:19.69ID:ptFJkApu0244デフォルトの名無しさん
2015/01/02(金) 13:21:13.66ID:3Vqt3HRo１．github上に存在しないユニークな名前の開発用ブランチをローカルに作ってコード書きました
２．コミットしました
３．githubに開発用ブランチの内容をプッシュしました
４．プルリクエストを作成しました
５．プルリクエストからコードをみてレビューします
こういう流れであってますか？
0245デフォルトの名無しさん
2015/01/03(土) 13:53:33.22ID:duDbuP4G0246デフォルトの名無しさん
2015/01/03(土) 17:04:41.74ID:pLxXRnJ60247デフォルトの名無しさん
2015/01/03(土) 17:08:36.79ID:9yXYqvm6subversionの時は苦痛だった。
0248デフォルトの名無しさん
2015/01/03(土) 18:22:43.25ID:DiYAwK0Kあるいはgit add -p→git commitだ。
0249デフォルトの名無しさん
2015/01/03(土) 19:49:02.62ID:nKSMxGgWSourceTree使え。
0250デフォルトの名無しさん
2015/01/03(土) 20:04:55.00ID:plPB9peD0251デフォルトの名無しさん 転載ダメ©2ch.net
2015/01/05(月) 05:15:42.50ID:nten2NYy0252デフォルトの名無しさん
2015/01/05(月) 20:50:17.24ID:XL9qQW5Wしかも内臓に切り替えてみたらさらに重くなった。システムに導入して使ったほうがいいな。
GUI使わないならMSYS2でgit入れて使った方が快適。
0253デフォルトの名無しさん
2015/01/05(月) 21:03:02.55ID:sE8+tO5+0254デフォルトの名無しさん
2015/01/05(月) 21:08:29.40ID:ES98/mNh特に vimdiff を利用した部分ステージング（って言うのか？add -p のこと）がとても使いやすい。
あと最近 agit.vim というのも導入したが、これも軽くて気に入ってます。
0255デフォルトの名無しさん
2015/01/05(月) 22:22:25.18ID:HnMh9gySブランチを切り替えるときとか重くない？
0256デフォルトの名無しさん
2015/01/05(月) 22:28:43.61ID:DStV81SR0257デフォルトの名無しさん
2015/01/05(月) 23:41:53.11ID:sE8+tO5+Macではそんなことないけど・・・
Windowsの話だろうと思って、試してみた
Windowsでは確かに重いね
0258デフォルトの名無しさん
2015/01/07(水) 21:46:49.89ID:vAZWEKTe>>254
入れてみるわ
0259デフォルトの名無しさん
2015/01/08(木) 19:10:20.19ID:g9S58Eit例えばコミットAの時点でクローンし、修正しプルリクエストを送ろうと思うと対象のリポジトリは既にコミットB、C……とどんどんコミットされていきます。
この場合にPull Requestを送ると迷惑になるでしょうか？
また、どのようにPull Request 送るのが良いのでしょうか？
0260デフォルトの名無しさん
2015/01/08(木) 19:20:54.34ID:lwhEqmhO気にせず送るべし
けど自動テストが通らなかったりマージでコンフリクトするような状況にある場合はリベースしてくれとか言われることもある
0261デフォルトの名無しさん
2015/01/08(木) 21:23:44.75ID:NyXuGLcn一番初めのプルリクエストでマージコンフリクトが起きるのはだめだろうな。
少なくとも一番初めは、出来る限り最新のコミットからの修正である方がいい。
でも、常に最新でなければならないというわけでもない。
なぜならプルリクエスト出した後でもコミットは追加されるから
どちらにしろ、最新にならないから。
コンフリクトが起きなければ、たいてい問題ないし、
コンフリクトが起きれば、その時修正すれば良い。
コンフリクトが起きた状態ではマージできないのだから
どちらかが解決するだけの話。
0262デフォルトの名無しさん
2015/01/09(金) 06:20:08.33ID:GHJOtrq4マージコンフリクトしたときに
修正する範囲も大きくなりすぎて面倒になる
出来るだけ小さいコミットに分けて
マージコンフリクトが起きにくくするのが良い
0263デフォルトの名無しさん
2015/01/09(金) 08:28:20.17ID:grkP3MoTみなさんありがとうございました
0264デフォルトの名無しさん
2015/01/09(金) 10:06:30.99ID:hl4ryjvR0265デフォルトの名無しさん
2015/01/09(金) 18:22:25.85ID:CA8wvY1hgit checkout A a.txt
0266片山博文MZ ◆T6xkBnTXz7B0
2015/01/11(日) 22:29:12.70ID:NXRDqdvf0267デフォルトの名無しさん
2015/01/11(日) 23:13:19.37ID:JCb9imvW0268デフォルトの名無しさん 転載ダメ©2ch.net
2015/01/13(火) 22:34:23.81ID:j85ab1m+0269デフォルトの名無しさん
2015/01/16(金) 19:06:06.01ID:3j38ipf7commit --amendで「直前の」コミットを修正するのだから
素人考えでは当該コミットも編集対象に入れてくれてもよさそうなものだが
ま、実害はないんだけど
どうにも慣れない
0270デフォルトの名無しさん
2015/01/16(金) 19:25:02.72ID:jQDFvNpa0271デフォルトの名無しさん
2015/01/16(金) 21:18:56.48ID:sJQXscVUbブランチはb.txt編集用
aブランチで編集した時に、山下くんがb.txt修正しといてよっていってきました
このときaブランチはまだ作業中なのでコミットしないままbブランチでさくっと修正してコミットして、またaブランチで作業を再開するためのコマンドの流れを教えてください
0272デフォルトの名無しさん
2015/01/16(金) 21:42:11.22ID:8SSd7+M8でも、頻発するようならcontribにあるgit new-workdirで作業ツリーを別に作っとけば便利
0273デフォルトの名無しさん
2015/01/16(金) 22:33:31.07ID:PoJiHUt9git stash
git checkout b
修正、コミット
git checkout a
git stash pop
0274デフォルトの名無しさん
2015/01/16(金) 22:35:30.56ID:lBWuATDIgit commit
git checkout b
b.txt編集
git add .
git commit
git checkout a
編集
git add
git commit --amend
こうはどうか
0275デフォルトの名無しさん
2015/01/17(土) 00:08:07.01ID:OrtXS/LN時間が掛かりそうなときは、コミットしている。
コミットした後元に戻って、git reset HEAD^ すれば
作業中状態に戻せる。がそのまま続けてあとでrebaseやsquashすることもある。
0276デフォルトの名無しさん
2015/01/17(土) 00:47:09.77ID:+rUaI3F00277デフォルトの名無しさん
2015/01/17(土) 10:45:51.13ID:Myj9loPB0278デフォルトの名無しさん
2015/01/17(土) 14:45:49.89ID:nY2kAZv2UNIX混在環境ならともかく、Windowsに閉じた環境で
わざわざUTF-8でテキスト書くヤツなんていないから
0279デフォルトの名無しさん
2015/01/17(土) 14:59:25.58ID:sqhqU9t50280デフォルトの名無しさん
2015/01/17(土) 16:42:25.01ID:dH11oz0d0281デフォルトの名無しさん
2015/01/17(土) 16:48:25.61ID:uQW+pF830282デフォルトの名無しさん
2015/01/17(土) 17:38:26.28ID:c2Xpc2yAほとんど無くなるからな。
そんな文字も含めて全部収録されてる。
絵文字までも使い放題
0283デフォルトの名無しさん
2015/01/17(土) 19:18:35.51ID:IDqsytYO✉
〄
➟
✰
この5つの絵文字Windowsで見える？
0284デフォルトの名無しさん
2015/01/17(土) 19:33:23.73ID:dH11oz0dhtmlだと実体参照で文字コードによらずにUnicodeの文字は示せる。
0285デフォルトの名無しさん
2015/01/17(土) 19:36:59.93ID:PPUSm5YO俺のガラケーでは見えない
0286デフォルトの名無しさん
2015/01/18(日) 01:09:07.11ID:1HDk1G1l見えてる。
0287デフォルトの名無しさん
2015/01/18(日) 01:10:27.37ID:1HDk1G1l思ってるんだけど、ハードリンクが使えないファイルシステムだとどうなるの？
ハードリンクを使わないで同じことをしている？
ということは遅くなりそうだけど。
0288デフォルトの名無しさん
2015/01/18(日) 01:39:18.33ID:sSnZb6HTていうかハードリンクを使ってどうやってブランチ切り替えを高速にするんだよ
0289デフォルトの名無しさん
2015/01/18(日) 01:41:39.24ID:1HDk1G1l>>288
これでもよんだら？
http://git-scm.com/book/ja/v1/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB
0290デフォルトの名無しさん
2015/01/18(日) 06:50:45.06ID:kbt215jdブランチ切り替えとハードリンクについて>>289のリンク先には何も書かれてない
もしかしてこれは釣りというやつなのか
0291デフォルトの名無しさん
2015/01/18(日) 12:10:55.18ID:H4Qq5dvf勉強したら？
http://ton-up.net/technote/2013/11/17/study-git-internals/
ファイル内容が同一だった場合、同一blobへハードリンクする
0292デフォルトの名無しさん
2015/01/18(日) 14:15:54.46ID:AMauToguでも結局ブランチの切り替えとハードリンク関係なくね
0293デフォルトの名無しさん
2015/01/18(日) 16:09:30.83ID:/EJ+6qGQその記事書いた人、いろいろ分かってなさそう。
ハードリンク云々は、あるファイルの中身がバージョンxとyで同じなら、同じblobを参照するってことでは？
その直後のgit gcの説明もメチャクチャだし。
>>292
普段はファイルごとに圧縮するだけで差分は利用してないけど、git gcすれば差分も利用して圧縮するよ。
ただし、cvsやsvnと違って、論理的なデータ形式としては差分は利用してない。
0294デフォルトの名無しさん
2015/01/18(日) 17:54:07.40ID:jsQnL7kd0295デフォルトの名無しさん
2015/01/18(日) 19:17:15.50ID:sSnZb6HT使ってない、でFA
0296デフォルトの名無しさん
2015/01/18(日) 20:18:43.72ID:fm6KJFw00297デフォルトの名無しさん
2015/01/18(日) 20:36:03.50ID:MSgZJjrE0298デフォルトの名無しさん
2015/01/18(日) 20:57:10.26ID:sSnZb6HTそこまで言うなら自分で試してみろ
理屈で考えても>>294の言う通り、ハードリンクの余地なんて無いんだからさ
とりあえず>>291の記事の「ハードリンク」は確実に嘘で、これも試せばわかる
>>297もちょっとおかしいぞ
gitは変更も新規ファイルも区別ないし、オブジェクトは使われなくなってもgcするまで消えないんだから
寿命管理自体してない、する必要ない
0299デフォルトの名無しさん
2015/01/18(日) 22:59:33.30ID:ZNqUKCJigit の object 機構が、user-mode fs のように既存のファイルシステム上にもう一つのファイルシステムのようなものを作っていて、ファイルシステムのハードリンク機能と同じような仕組みをユーザランドでやってるってだけの話だよね。
全体的なデザインが、zfsっぽいなあと思った。
0300デフォルトの名無しさん
2015/01/19(月) 15:01:22.47ID:Gs0FPaUi＞ファイル内容が同一だった場合、同一blobへハードリンクする
同じ内容のファイルのblobは同じハッシュを持つ
treeからblobへの参照はこのハッシュ使っているから同じ内容のファイルのblobの実体は一つになる
しかし、この参照にOSのハードリンクは使って無い
0301デフォルトの名無しさん
2015/01/19(月) 15:16:43.39ID:hvZXdJxV0302デフォルトの名無しさん
2015/01/19(月) 20:12:01.03ID:cOL8vmE70303デフォルトの名無しさん
2015/01/21(水) 14:59:49.21ID:e7cIHMPH0304名無しさん＠お腹いっぱい
2015/01/21(水) 18:32:03.93ID:NLX5ChHY0305デフォルトの名無しさん
2015/01/22(木) 17:11:39.88ID:zLQIDOv9git ac "aaaa"でできるようにしてるんですけど
まちがえてgit "aaaa"ってうっちゃってコミットしてなかったんですよ
そのあとコミットしたつもりでgit checkout master; git merge developやって初めてマージされてないことに気づいたんですが
ここで僕がコミットしたかった内容を取り戻す方法ありませんあk？
0306デフォルトの名無しさん
2015/01/22(木) 17:32:53.67ID:ETHzP6B6それあかんやつや
0307305
2015/01/22(木) 18:52:06.80ID:VHpmgCojコミットしてないとブランチを移動できないはずなのに
0308デフォルトの名無しさん
2015/01/22(木) 21:11:13.14ID:zhp/ccUR0309デフォルトの名無しさん
2015/01/22(木) 23:12:27.92ID:dovnY2vSfsckとか使ったと思うけど調べてみて
0310デフォルトの名無しさん
2015/01/23(金) 07:50:36.75ID:49x/Qskq0311デフォルトの名無しさん
2015/01/23(金) 10:11:10.51ID:zoW4TF5j0312デフォルトの名無しさん
2015/01/23(金) 12:28:54.99ID:iNKYdZ740313デフォルトの名無しさん
2015/01/23(金) 12:47:11.90ID:zoW4TF5j個人の開発に向いた機能だと思いますか？
チーム開発では便利そうだけど個人で使うには冗長な機能が多いと感じます
0314デフォルトの名無しさん
2015/01/23(金) 13:00:26.24ID:iKIZzacCその上で自分の開発に取り入れる上でどのようなメリットがありデメリットがあるかを考えて総合的に選択するかしないかは自分で決めるべきでしょう
どんなものにもやらなければならない縛りはないのです
0315デフォルトの名無しさん
2015/01/23(金) 17:29:33.01ID:uNdTiJaPgit checkout -b test
touch a
git add .
git commit "first"
git branch
１．なんでmasterブランチがないんですか？
２．initすればmasterブランチが作られないんですか？
３．masterブランチってどこで作られるんですか？
４．この場合masterブランチはどうやって作ればいいですか？masterブランチって特別なブランチですよね？git checkout -b masterで十分でしょうか？
0316デフォルトの名無しさん
2015/01/23(金) 17:31:48.14ID:zoW4TF5j下の記事でgit-flowとgithub-flowの比較をしてますが、これらの機能の経験者の方は同意できる内容ですか？
特に結論のこの点が気になります。
＞ GitHub-flowを採用しよう → おそらくこういう考えに至る人が多数派なので、git-flowの利用者が減ってきている・・？
http://qiita.com/jshimazu0820/items/066e061eef700caa1c68
0317デフォルトの名無しさん
2015/01/24(土) 17:42:08.38ID:8pV/y7B7統計的なデータは見たことないんだが、こういう話もでてるみたいだね。
「develop ブランチなんてオワコン」 http://togetter.com/li/673629
個人的にはgit-flowは面倒すぎるので試したことすらない。
チーム開発でも躊躇するくらいだわ。(GitHub flow派でもないが)
とはいえgit-flowがうまくマッチするプロジェクトもあるかもしれない。
コメントから初心者なのかなと思うけど(違ったらごめん)、
Gitの操作に慣れてくるとどのフローがプロジェクトに合うか判断できるようになると思うので
色々試してみるのが遠く見えても近道じゃないかな。がんばって。
0318デフォルトの名無しさん
2015/01/24(土) 17:53:28.41ID:8pV/y7B7> １．なんでmasterブランチがないんですか？
git checkout -b test してるから
> ２．initすればmasterブランチが作られないんですか？
git checkout -b test しなければいい
> ３．masterブランチってどこで作られるんですか？
今試したところ最初のコミットで作られる。
より正確には
・HEAD が git init 直後に指しているのは master
・git init直後 refs/heads/master は存在しない
・git checkout -b test すると HEAD が指す参照(ブランチ)名が test に変わる
・git init後最初のコミットで refs/heads 配下に HEAD が指していた参照が作成される
という動きのようだ。
なので git init後 git checkout -b testしてれば test ブランチが作成され、masterブランチは作成されない
> ４．この場合masterブランチはどうやって作ればいいですか？masterブランチって特別なブランチですよね？git checkout -b masterで十分でしょうか？
それでいい。
master がついてる場所に不満があるなら reset --hard で付け替えればOK
0319デフォルトの名無しさん
2015/01/24(土) 20:14:11.70ID:SgdHfwH0git-flowなんかゴリ押しするんだよなあ
実情に合わねっつーの
0320デフォルトの名無しさん
2015/01/24(土) 20:47:35.98ID:nzZsnS5c0321デフォルトの名無しさん
2015/01/24(土) 20:49:44.30ID:LdIBiv/J0322デフォルトの名無しさん
2015/01/24(土) 21:02:36.39ID:cHjosKFfありがとうございます。Git初心者です。
GitHubは使っていないですし、一人で開発してるので第三者にコードレビューしてもらうのも不可能なので
GitHub flowは候補にならないのかなと思いました。
とりあえずgit-flowをインストールしたので試してみます。
>>319
初心者が「ブランチ管理ってどうやるんだ？」とネットで調べたらgit-flow・github-flowに行き着きました。
0323デフォルトの名無しさん
2015/01/24(土) 21:13:36.91ID:cHjosKFf若干内容が古くなってるようです。
http://www.atmarkit.co.jp/ait/articles/1311/28/news042.html
gitflowのwikiを参考にした方が間違いないと思います。
ほとんど内容は同じですが
「Copy getopt.exe, libintl3.dll and libiconv2.dll」
の部分が違います。
gitflow ： Installing on Windows
https://github.com/nvie/gitflow/wiki/Windows
0324デフォルトの名無しさん
2015/01/24(土) 21:39:41.98ID:5G1Vkj7Bで戻った後やっぱり最新のコミットにもどしたい場合はどうするのがいいですか？
もう一回git checkout 最新ハッシュ:ファイル
で戻るのがベストですか？
0325デフォルトの名無しさん
2015/01/24(土) 21:44:16.32ID:8pV/y7B7そういうことなら
http://d.hatena.ne.jp/kazuhooku/20140204/1391479663
くらいのシンプルなフローでスモールスタートすればいいんじゃないかな。
他のフローほど複雑じゃないし、基本は抑えてある。
あとはブランチやコミットの分割・統合とか、自信持ってできるくらいまで
Gitの操作に熟練すれば自分でどうすべきか見えてくると思う。
0326デフォルトの名無しさん
2015/01/24(土) 21:45:43.06ID:8pV/y7B7git status の出力をよく見たら、どうすればいいか書いてないかな？
0327デフォルトの名無しさん
2015/01/24(土) 21:54:42.20ID:8pV/y7B7残念ながら git-flow 界隈の最新情報にはあまり詳しくない。
WindowsならSouceTreeというGUIツールがgit-flowをサポートする機能を持ってた気がする。
LinuxとかならちゃんとCUIでGitの操作に習熟したほうがいいんじゃないかなと思うが、
Windowsメインならそういうツールのアシストに乗っかるのも手だと思う。
0328デフォルトの名無しさん
2015/01/24(土) 22:32:28.18ID:cHjosKFf参考になります。
テストファーストじゃないですが、シンプルなフローという考え方自体イメージ出来ていませんでした。
その考え方で自分には十分そうな気がします。
>>327
インストール自体は>>323で動作確認しました。
OpenShiftというwebサービスを利用してPaaS環境で開発してますが
Gitでpushしたものが即webアプリケーションで動きます。
OpenShiftは、CUIでのGit/サーバ操作が基本になっています。
windowsでも実用的に問題なく扱えますが、やっぱりwindows独特のトラブルが多いと感じます。
0329デフォルトの名無しさん
2015/01/25(日) 14:22:25.30ID:A4Cd5W0xに --no-ff で merge する程度のやり方で済ませています。
ただ、bug 対策、feature 追加、テスト追加、ドキュメント、ソフト関連メモのために
専用の tracking git directory を設けて、 org mode テキストで管理しています。
Redmine 等も調べたのですが、大げさな割りに自由度がないので自己流のテキスト・
ファイルの塊ですませています。でもプログラム・ソース git との関連が破綻気味に
なってきています。同じバグに複数のシリアル番号を与えることが出たりしています。
小規模なソフト開発で、皆様がプログラム・ソース git と関連文書を どのように管
理・発行しているのか教えてもらえますでしょうか。
0330デフォルトの名無しさん
2015/01/25(日) 14:35:50.12ID:GYzk0jocソースとドキュメントが関連がごちゃごちゃになるなら
ソースコード自体にドキュメントを埋めればいい。
ソースコードからドキュメントを生成することは簡単。
関連するものが分散しているのがそもそもの問題。
0331デフォルトの名無しさん
2015/01/25(日) 14:37:01.79ID:GYzk0jocgithubを見てみればわかる。
gitとは別の「github」というシステムで管理している。
金が無いなら、gitlabでも使えば良い。
0332デフォルトの名無しさん
2015/01/25(日) 14:37:49.44ID:R3Fg53INそしてmasterにコミットして言ってるんですよ
そして切りがいいタイミングでタグつけてるんですよ
0333デフォルトの名無しさん
2015/01/25(日) 19:07:28.69ID:bbm8MHtJ> 同じバグに複数のシリアル番号を与えることが出たりしています。
だから Redmine なりを使いなさいよ
どんな自由度が欲しいのかよくわからんが、
> bug 対策
だけなら、素のままでも使えるでしょ
俺は一人で Trac + Subversion 使ってるけど、便利だよ
0334デフォルトの名無しさん
2015/01/25(日) 19:17:08.19ID:zML2z7Anそれを一人で使えば、ツール使用に要するエネルギーが使用効果を上回り非効率となる
一人ならフォルダ丸ごとコピーして連番を振っておけば十分
0335デフォルトの名無しさん
2015/01/25(日) 19:20:53.53ID:CVtB1D/30336デフォルトの名無しさん
2015/01/25(日) 19:45:10.32ID:Lk9JAYup俺は面倒だから出来る前からGithubに上げて、ぶつぶつ書いたissueを勝手に誰かがやるのを期待しながらコードを書いてる。
0337デフォルトの名無しさん
2015/01/25(日) 20:22:21.80ID:jNZ1CTPYテキトーにやってもそれなりに管理できるのが git/Redmine とかのメリットなんだが w
ログなんて書かなくたって修正した日時とファイルの差分がわかれば色々思い出すし
Redmine をメモ代わりに使うのもありだし
まあ、無理には勧めないけど
0338デフォルトの名無しさん
2015/01/25(日) 20:41:17.87ID:Lk9JAYup0339デフォルトの名無しさん
2015/01/25(日) 21:22:32.30ID:i6m/tzqt現に>>329は破綻しているのだから、それよりは効率的だろう。
sqliteだと複数人で使う気になれないし、言うほど大掛かりなのかなぁ。
0340デフォルトの名無しさん
2015/01/25(日) 21:27:13.83ID:Mazo5ktc物理的に一人かもしれないがやっていることは違う人。
XとYの作業に時系列上のオーバーラップがあるなら、
ローカルリポジトリに閉じていてもそれは本質的には分散作業ということだ。
一人で使う作業が中心であっても、そこを理解してる人は
分散型でないVCSには戻りたくないと思うよ。
0341デフォルトの名無しさん
2015/01/25(日) 21:34:20.75ID:4G7cDz/C0342デフォルトの名無しさん
2015/01/25(日) 22:31:38.25ID:XPwi6yeCにわかには信じがたい
0343デフォルトの名無しさん
2015/01/25(日) 22:40:46.54ID:GYzk0jocそのやり方をしていて破綻してしまっているから
悩んでこうして書き込みをしている。
複数の人でもIssue管理可能なシステムを
使えば、当然一人でも管理可能
0344デフォルトの名無しさん
2015/01/26(月) 00:19:28.61ID:zmR2jPs+0345デフォルトの名無しさん
2015/01/26(月) 00:29:27.20ID:+Dq65ZoG0346デフォルトの名無しさん
2015/01/26(月) 03:27:14.43ID:arRb/hiH私のソフトは数万行の規模であり、10年以上機能追加とバグ対策を経ているものです。
今後も一生開発を続けます。テストはソースとは独立しており数千行の規模です。
Coverage 100% を目指していますが、そこまで まだ力を注げません。
「Redmine は GUI で複数の作業員に統一した管理方法を徹底するツールだ」というのが
以前検討したときの結論です。今回のバグの二重登録は、半年前の bug issue を見逃し
たことで発生しました。Redmine で それが防げるとは思えません。全体管理を専門にす
る担当を置くことで防ぐしかないと思います。
私が issue も git 管理するのは、後で問題を見返したときに、当時の状況・経緯を再
現できるようにしたいからです。Invalid にした機能の理由を後でも分かるようにする
ことを最重要視しています。日常メモだけではゴミが増えすぎるので、そのエッセンス
を issue 文書として別に設けています。
現在破綻気味なのは細かな todo も issue に含めるようにしたためだと思っています。
それにバグが埋もれました。細かな issue 専用のディレクトリを設けて、issue 管理種
類の階層を見直そうと考えています。
ここらの途中変更を Redmine, Git Flow, GitHub enterprise などで許容できるとは思
えません。現状の issue text file 群の git 管理しか方法は無いとするのが現在の私の
考えです。
0347デフォルトの名無しさん
2015/01/26(月) 04:42:53.92ID:+20h4l7eそんなに合わないのならBTSも作っちゃった方が良いんじゃないか
0348デフォルトの名無しさん
2015/01/26(月) 06:02:27.97ID:4je0vE9e0349デフォルトの名無しさん
2015/01/26(月) 08:11:57.99ID:7PO1Rygt好みの問題だと思う
プラグインも色々あるから、自分のやりたいことがあるなら BTS スレで... って今見たら BTS スレないのな
まあ、両方ともネットに情報ゴロゴロ転がってるから調べてみればいい
0350デフォルトの名無しさん
2015/01/26(月) 08:14:01.79ID:7PO1Rygtネタ振りでしょ
0351デフォルトの名無しさん
2015/01/26(月) 10:43:27.72ID:o6RBMBnt0352デフォルトの名無しさん
2015/01/26(月) 11:09:08.69ID:EnKfsnZcまあ、自分一人でオレ流のやり方通したいなら勝手にすれば良いと思う
世の中で誰もそんな使い方してないっていうのはどういう事か理解できないなら仕方ないね
0353デフォルトの名無しさん
2015/01/26(月) 11:14:16.45ID:Qq27LOAA自分の代でおしまいだと決まってるのなら、自分しか理解できない仕様でもかまわないと思うが。
0354デフォルトの名無しさん
2015/01/26(月) 13:11:21.76ID:zXqptoTyなんでバグを見逃したのか、バグが埋もれたのかというと
それはツールが使いにくいからだよ。
完全に防ぐことは出来ないが、Redmineやgithubやgitlabは
それらの問題を見つけやすいインターフェースにになってる。
それに開発中にIssueをコミットなんかしてるから
埋もれるんだよ。あとで詳細を書こうと思って
今は仮で見つけたものを登録しておくとか
TODOを作っていくとか、そのたびにコミットするから
コミットログがごちゃごちゃなって埋もれるわけ。
0355デフォルトの名無しさん
2015/01/26(月) 22:58:47.68ID:qq3+AGQUコミットはそれぞれ別になっていますが
リクエストを複数にする？ブランチを複数にする？全部まとめて1回のリクエストでいい？というあたりがよく分かっていません
修正内容
１．ほぼ間違いなくマージされるであろう修正（ドキュメントの更新）
２．ほぼ間違いなくマージされるであろう機能の改善（１とは関係ない）
３．マージされるかは微妙な機能の改善
（マージされるされないの推測はもちろんこちらの勝手な想像です）
0356デフォルトの名無しさん
2015/01/26(月) 23:00:40.29ID:0p3Uhe6zお前がプルリクを受けた場合どれが一番嬉しい？
0357デフォルトの名無しさん
2015/01/26(月) 23:36:37.74ID:4je0vE9e送られてきた場合は、ほしいところまでpullするなりcherry-pickするなりする。
0358デフォルトの名無しさん
2015/01/26(月) 23:37:32.45ID:qq3+AGQU各コミットを適用するか否かを別々に判断して反映できればいいのだと思うんですが
一つのプルリクにまとめて送ってもそれができるのかどうかが分かってません
0359デフォルトの名無しさん
2015/01/26(月) 23:40:54.76ID:0p3Uhe6z主が分けてほしいと言ってきたら分けて再プルリクすりゃいいし
GitHub flowなんかプルリクページで活発にやりとりするのが基本らしいしな
0360デフォルトの名無しさん
2015/01/26(月) 23:43:09.96ID:qq3+AGQUなるほど確かにcherry-pickしてもらえるのであればコミットさえ分かれてれば大丈夫ということですね
そう考えるとどう送るか＆受け取るかはその人次第って事なんでしょうかね
>>359
プルリクページで相談！
確かにいったん送ってみてこれが間違いなさそうです
ありがとうございます
0361デフォルトの名無しさん
2015/01/27(火) 00:08:20.78ID:zxc1Q4JE0362デフォルトの名無しさん
2015/01/27(火) 00:12:28.64ID:/MLR0G3n0363デフォルトの名無しさん
2015/01/27(火) 07:16:31.21ID:BzqDIclrそう。自由にできるソーシャルコーディング。Github最高だわ。
0364デフォルトの名無しさん
2015/01/27(火) 08:22:02.13ID:Dg/XO2cmまさにそれ
0365デフォルトの名無しさん
2015/01/27(火) 10:21:43.37ID:980R/bxb・こっちのブランチ名は伝わる
・けど、向こうは好きな名前で受け取れるから、大した問題ではない
・とはいえ、適切な名前を付けた方がかっこいい
って理解で合ってるかな？
バグフィックスだからfix/○○にしようと思ってるけど。
0366デフォルトの名無しさん
2015/01/27(火) 12:13:50.23ID:MpwFrzaX長ったらしい英語なら書けるけど、
短くそれでいて意味が通る言葉がでてこない。
だから毎回似たような単語になってしまう。
0367デフォルトの名無しさん
2015/01/27(火) 12:25:16.50ID:KRe6og0K0368デフォルトの名無しさん
2015/01/27(火) 12:27:49.01ID:MpwFrzaXその理屈で言うと
ブランチ名 「 [bug][2.0][important] 」みたいなのでもいいんだろうかｗ
0369デフォルトの名無しさん
2015/01/27(火) 12:29:12.58ID:MpwFrzaX過去に作ったことの有るブランチ名と
同じ名前を作ってしまうことは有るはず。
ほとんど問題無いと思うが。
0370デフォルトの名無しさん
2015/01/27(火) 13:07:18.80ID:EMNyEMKP0371デフォルトの名無しさん
2015/01/27(火) 14:50:54.26ID:BzqDIclr面倒だから自分が今使っているブランチをそのまま投げる。
0372デフォルトの名無しさん
2015/01/27(火) 15:02:51.47ID:im4SxcEjコンフリクトする可能性のある個所を把握しやすくなるとおもわれ
0373デフォルトの名無しさん
2015/01/31(土) 15:25:35.80ID:mHT4AiSW具体的には、ワーキングディレクトリにあるUMLの設計ファイルと、過去のバージョンのUMLの設計ファイルを比較しようとしています。
diffをとることはできませんので、目視で比較したいと思っています。
こういう場合、みなさんどうやって比較していらっしゃいますか？
昔のファイルを
git checkout -- <file> してますか？
そしたらworking directoryのファイルが上書きされてしまって比較にならないような気がするんです。
でも、わざわざワーキングディレクトリをもう1つ作ってそこに旧バージョンをチェックアウトするのも面倒くさそうだし。。。 なんか良い方法ないかなぁ？と
ちなみにSourceTreeを使っております。
0374デフォルトの名無しさん
2015/01/31(土) 15:32:53.41ID:mHT4AiSW自己解決しました
SourceTreeだったらクリック1つで普通に旧バージョンもOpenできたわ・・・・
問題はUML編集ソフト(astah community)が同時に2つのプロジェクトファイルを開けないことです
0375デフォルトの名無しさん
2015/01/31(土) 15:33:44.66ID:mHT4AiSW当面の問題は半分解決したけど、理解できてない感じがします
あへあへ
0376デフォルトの名無しさん
2015/01/31(土) 16:40:58.99ID:FpW6JQXw画像くらいしか扱ってないから
サーバのWebインターフェイス（Webブラウザ）で事足りてる
それ以外は大抵一瞥しただけじゃ
差分が把握できない（ガッツリ検証する必要がある）から
手間としては誤差だな
0377sage
2015/01/31(土) 22:42:58.62ID:NjH9LK3tコメントありがとうございます
サーバの、ってことは gitのリモートリポジトリのwebインターフェースを見るってことですか？ githubとかbitbucketみたいな。
みなさん設計ってどうされてるのかな
万年Newbieなもんで、開発のフローがいまいちわからないdeath
0378デフォルトの名無しさん
2015/01/31(土) 23:50:40.40ID:fD8yMOOPgit show ハッシュ|display -
とかでいいな
0379デフォルトの名無しさん
2015/02/02(月) 12:09:58.81ID:K0nJIStf0380デフォルトの名無しさん
2015/02/02(月) 19:40:50.37ID:5HI2wkL10381デフォルトの名無しさん
2015/02/02(月) 19:43:21.40ID:vZ4lrtxA0382デフォルトの名無しさん
2015/02/03(火) 18:21:20.49ID:pBykX74D以下の通り作業したときなんですが、
1)トピックブランチで作業
2)トピックブランチをmasterにマージ
3)masterをリモートにpush
このときリモートの歴史が進んでいたら
pushに失敗しますので
pullしないといけませんが、
単純にpullすると、
なんかコミットログのツリーが
キモい形になります。
(ローカルのmasterに、
リモート側にpush済みのコミット郡が
ブランチ作業されたみたいな形で
マージされると思います)
そこでちょっと思ったのですが
ひょっとして以下のようにするのが普通だったりしますでしょうか？
1)トピックブランチで作業
2)トピックブランチをmasterにマージ
3)masterをリモートにpush
4)ここでリモートの歴史が進んでいたためにpushに失敗したら
トピックブランチのマージはいったんリセット
5)masterにリモートの歴史をpullしてから2)に戻る
しょうもない質問かもしれませんが
よろしくお願いします。
0383デフォルトの名無しさん
2015/02/03(火) 18:23:53.56ID:9S3xfl3nmasterは弄る前に最新にしておく。
0384デフォルトの名無しさん
2015/02/03(火) 19:30:02.81ID:pBykX74Dmasterにトピックブランチをマージする(いじる)前に、
pullで最新にしておくように心がけようと思います。
チーム内ではそういうルールなしに運用されているため
基本みんな「pushできねー。pullしてpushだ！」とやっちゃってて
コミットログのグラフを見たときに
なんか汚いんですよね、、、
0385デフォルトの名無しさん
2015/02/03(火) 20:40:43.00ID:v7tAs31H0386デフォルトの名無しさん
2015/02/03(火) 20:49:51.52ID:gNNDcbV60387デフォルトの名無しさん
2015/02/03(火) 21:07:23.62ID:uPCf3rg4rebaseだとコミットの歴史が変わるし
ブランチ内ブランチがあっても
平らになっちゃうし、あんまいいことないのでは。
0388デフォルトの名無しさん
2015/02/03(火) 21:22:09.45ID:v7tAs31Hpush前なら気にせずにrebaseしてる
ピックブランチをrebaseしてmasterに--no-ffでマージすれば平らにならないし
0389デフォルトの名無しさん
2015/02/03(火) 21:49:48.82ID:uPCf3rg4トピックブランチ内でさらにブランチ作ったりするから
rebaseだとそれが平らになって困る。
0390デフォルトの名無しさん
2015/02/03(火) 22:15:43.45ID:K3j8Ml+50391デフォルトの名無しさん
2015/02/03(火) 22:20:26.02ID:MgrtGeWO0392デフォルトの名無しさん
2015/02/03(火) 22:23:27.59ID:hYktHZLE0393デフォルトの名無しさん
2015/02/04(水) 09:44:11.25ID:IcwgNPlv残すためじゃないのかなあ。
0394デフォルトの名無しさん
2015/02/04(水) 10:00:14.80ID:qNYKp0Ci0395デフォルトの名無しさん
2015/02/04(水) 14:42:12.35ID:IcwgNPlv> 390 名前：デフォルトの名無しさん [sage]： 2015/02/03(火) 22:15:43.45 ID:K3j8Ml+5
> ブランチ同士の分岐の履歴なんて残す必要あるかね？
概要を把握して、その後細かい部分を見るのが普通なのでは
0396デフォルトの名無しさん
2015/02/04(水) 20:16:00.83ID:e8ld7g+D0397デフォルトの名無しさん
2015/02/04(水) 20:45:13.29ID:spn6YJXiソースツリーの構築・整理に異常なまでに取り憑かれている
コードを書くよりGitをいじっている時間の方が長いんじゃないのか
0398デフォルトの名無しさん
2015/02/04(水) 20:55:26.87ID:2AooNTtiお前がろくにポリシー作って運用した経験がないだけ
0399デフォルトの名無しさん
2015/02/05(木) 00:58:20.74ID:R/9Vbs7X俺がHEADだ！
0400デフォルトの名無しさん
2015/02/05(木) 01:32:57.58ID:p2qjN/vMしかしログは簡潔に見たい。
それらを満たせればいい。
0401デフォルトの名無しさん
2015/02/05(木) 16:04:14.20ID:LnAyM1GBどうやって編集してた時の状態に戻せますか？
0402デフォルトの名無しさん
2015/02/05(木) 18:38:50.54ID:uT6kyrvaどうやって新規ファイルとか更新ファイルを確認できますか？
0403デフォルトの名無しさん
2015/02/05(木) 20:00:24.36ID:6Q4nl3MX消しちゃっててaddもしてないなら無理だよ
>>402
出てくるよ
.gitignoreにそのサブディレクトリ書いてるんじゃない？
0404デフォルトの名無しさん
2015/02/05(木) 23:58:15.07ID:gFkLdicTこうなってコミットきませんどうしてですか？
git status
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: file
0405デフォルトの名無しさん
2015/02/06(金) 14:37:02.29ID:C54JIcai使い切れんだろ
0406デフォルトの名無しさん
2015/02/06(金) 18:42:33.97ID:2I8MpH780407デフォルトの名無しさん
2015/02/06(金) 20:47:59.13ID:US8+cxzh俺は特に設定してないけど--untracked-files=normalの挙動になるんだけどデフォルトで--untracked-files=allにする方法ある？
0408デフォルトの名無しさん
2015/02/06(金) 23:40:37.74ID:+IXbszfD試したことはない
0409デフォルトの名無しさん 転載ダメ©2ch.net
2015/02/07(土) 08:49:43.97ID:X2+EyVwW0410デフォルトの名無しさん
2015/02/07(土) 11:58:53.93ID:C2mSGeUj0411デフォルトの名無しさん
2015/02/07(土) 16:19:28.02ID:9YvHzWPK0412デフォルトの名無しさん
2015/02/08(日) 02:28:29.47ID:lz8L6wsk「3人いれば勝てると思ったのか？」
ですよ。 これは譲れないお
0413デフォルトの名無しさん
2015/02/08(日) 09:37:46.73ID:WvTYGVnx古いログ消したいならgitなんか使うなよ
0414デフォルトの名無しさん
2015/02/08(日) 19:19:50.56ID:vtzM9ypghttp://www1.axfc.net/u/3408068
ページ下部のmsysGitで誰でもビルドできます
https://msysgit.github.io/
0415デフォルトの名無しさん
2015/02/09(月) 05:08:10.36ID:KtLbWHYP0416デフォルトの名無しさん
2015/02/09(月) 09:06:36.31ID:iJdyGTL30417デフォルトの名無しさん
2015/02/09(月) 09:07:35.69ID:NoJnOppA書いてくれたほうが嬉しいよな。
0418デフォルトの名無しさん
2015/02/09(月) 09:31:51.49ID:BLG3WIOGGithub公式のを使え
0419デフォルトの名無しさん
2015/02/09(月) 10:03:16.48ID:/idmoKWngit show test:index.txtじゃだめでした
0420デフォルトの名無しさん
2015/02/09(月) 10:09:28.90ID:AksERyBw0421デフォルトの名無しさん
2015/02/09(月) 10:15:32.62ID:/idmoKWnいやちょっとコードを確認したいだけなんですよ
チェックアウトするのめんどうくさいです
0422デフォルトの名無しさん
2015/02/09(月) 10:18:42.11ID:iJdyGTL3チェックアウト出来なくなってる可能性もあるぞ
0423デフォルトの名無しさん
2015/02/09(月) 10:27:45.93ID:/idmoKWnチェックアウトするなら一回コミットするあらstashしないといけない状態です
コミットが大量にあるのでlogやreflogで探すのが面倒くさいのです
0424デフォルトの名無しさん
2015/02/09(月) 12:07:03.38ID:/idmoKWnlogにブランチ名も表示されればいいんですけどその方法を教えてください
0425デフォルトの名無しさん
2015/02/09(月) 12:22:54.17ID:KtLbWHYPgit cat-file blob test:index.txt
とかは？
0426デフォルトの名無しさん
2015/02/09(月) 12:33:53.12ID:/idmoKWngit show branch:filenameで大丈夫でした
0427デフォルトの名無しさん
2015/02/09(月) 14:16:32.29ID:9He/NoKxここみるとやっぱりrebaseでコミットを纏めるのは良くないと思いました
0428デフォルトの名無しさん
2015/02/09(月) 18:19:02.44ID:RAMLO4Zp公開していないコミットならrebaseしても良い
こいつは色々と間違っている
0429デフォルトの名無しさん
2015/02/09(月) 20:12:36.94ID:NoJnOppArebaseしているかしていないかわかるでしょ？
rebaseしているからあんなきれいなコミットログなわけでさ。
もしrebaseしなかったら、typoの修正やら間違った修正の訂正やら
たくさんあってもっと汚いって。
0430デフォルトの名無しさん
2015/02/09(月) 20:16:56.60ID:sBN76GX20431デフォルトの名無しさん
2015/02/09(月) 20:57:10.91ID:NoJnOppAブランチによってrebaseするべきものと
してはならないものがあるよ。
masterなどのメインブランチはrebaseしてはいけない。
トピックブランチはrebaseしてよい。
0432デフォルトの名無しさん
2015/02/09(月) 21:00:48.51ID:NoJnOppAトピックブランチはpushする前にrebase。
そしてレビューが行われて修正が入った場合、
必要ならばマージする前にrebaseだね。
言っておくけど、rebaseは一個にまとめることじゃないよ。
コミット毎に意味があるようになっていれば複数になってもよい良い。
そしてコミットを綺麗にしてからメインブランチみマージ
簡単にいえば、トピックブランチでミスを一回もしなかったらどうなるか？
その形にしてからマージするということ。
もちろんメインブランチにマージした後のミスはrebaseで直したらだめ。
0433デフォルトの名無しさん
2015/02/09(月) 23:56:12.94ID:bwEZbR4B0434デフォルトの名無しさん
2015/02/10(火) 00:31:08.90ID:arI92W1sコミットは書き換えられても人間はもう戻れないね
0435デフォルトの名無しさん
2015/02/10(火) 00:32:11.94ID:ITYxTq2n0436デフォルトの名無しさん
2015/02/10(火) 07:33:48.17ID:XejRqe5A全員が共有している、共有リモートリポジトリと
個人専用の、個人リモートリポジトリ。
そして、共有リモートリポジトリへ、
個人リモートリポジトリからプルリクエスト（マージ）
githubを使ったやり方がこれだし、
gitlabでも同じようなことが出来る。
共有リモートリポジトリは全員が共有しているわけだから
安易にrebaseしてはいけない。だけど個人リモートリポジトリは
個人のものだからrebaseしてよい。
オープンソースの開発見ればわかるけど、
一旦プルリクエストして、そのやりとりで細かい修正があった時に
それをそのまま取り込んでくれるところはないよ。
相手が無知じゃないかぎり、rebaseしてくれって言われる。
0437デフォルトの名無しさん
2015/02/10(火) 08:58:16.87ID:arI92W1s「rebaseのために」個人リモートリポジトリつくるのは気持ち悪いな
個人で複数マシンで開発してたら
個人リモートリポジトリとはいえrebaseしたくないし
かといってマシンごとにリモートリポジトリ用意するのは馬鹿げているし
0438デフォルトの名無しさん
2015/02/10(火) 09:00:10.04ID:qkxvban6/stable.git
/個人名.git
って感じでずらっとならんでるね
プロジェクトの共有ディレクトリに作ってsshするだけでも楽
0439デフォルトの名無しさん
2015/02/10(火) 09:00:31.12ID:ITYxTq2n0440デフォルトの名無しさん
2015/02/10(火) 09:06:16.39ID:XejRqe5Arebaseのために作るんじゃなくて、
作業を明確に分けるために作るんだよ。
共通のリモートリポジトリに○○さん実験中みたいなのが、
ずらーって並んでいたら、このブランチは何？ってなるでしょ？
まず最初に、作業を明確に分けるために
リポジトリを分ける。（githubみたいに）
そして、ローカルリポジトリをrebaseしていいのと同じで、
個人のリポジトリ＝ローカルと同じで個人が使うものだから
こっちもrebaseしていいわけ。
で、重要なのは、仮定じゃなくて結果ね。
結果として、コミット毎に意味が綺麗に別れれば
あとから、特定の機能をチェリーピックとかしやすくなる。
rebaseが目的なんじゃなくて、開発のしやすさが目的だからさ。
0441デフォルトの名無しさん
2015/02/10(火) 09:11:40.47ID:XejRqe5A> 個人で複数マシンで開発してたら
> 個人リモートリポジトリとはいえrebaseしたくないし
git push -f すればいいだけだよ。
個人リモートリポジトリだからこそ、誰も困らない。
0442デフォルトの名無しさん
2015/02/10(火) 09:15:04.02ID:XejRqe5A用意されているかって言うと、必要だから用意されているわけで
rebaseしたらだめ。なんてルールは無いんだよね。
rebaseされたら困る場合がある。って話は
rebaseしたらだめという意味じゃない。
rebaseされたら困る場合があるなら、
その場合以外でrebaseすればいいわけ。
元々の要求として、rebaseしたいんだから、
rebaseしやすいように、明確にブランチとリポジトリの
利用方法を分ければいいわけさ。
それを一部の困る場合を例にして
全部禁止するのは本末転倒。
0443デフォルトの名無しさん
2015/02/10(火) 09:35:10.28ID:Hs3TdF+4select * 禁止
使わない変数の投機的宣言禁止
0444デフォルトの名無しさん
2015/02/10(火) 09:42:34.95ID:AS1xy/uz0445デフォルトの名無しさん
2015/02/10(火) 17:20:31.00ID:s+vNxlASと思ったら、git fetch して git reset --hard すればいいのか。なるほどー。
http://qiita.com/yaotti/items/b64ab993c78a47941869
0446デフォルトの名無しさん
2015/02/10(火) 19:16:58.15ID:qkxvban6pull ―rebaseで追っかけてたよ
0447デフォルトの名無しさん
2015/02/10(火) 21:08:43.17ID:LzvhV5fNtouch a
git add a
git commit -m "add a"
touch b
ここでaをコミットした段階に作業スペースを戻したいんですが
git reset --hard HEAD^ってやってもbが残ったままになります
resetだけで元に戻せるものだと思ったんですがgit clean -fしないとだめなんでしょうか？
0448デフォルトの名無しさん
2015/02/11(水) 01:06:05.01ID:MoBO6QWurebaseは一本道にすることが目的じゃなくて
意味不明なコミットをなくして、
コミットを使いやすくするのが目的だから
コミットを使いやすくというのは、
特定のコミットがバグの原因だと調査しやすくしたり
他のブランチにコミットを抜き出して取り込んだり
特定のコミットをッ取り消したり、
コミット単位で機能の変更を把握したりすること。
コミットは後から使うために残すもので、
使いものにならないコミット、使わないコミットは
存在する意味が無いですから
0449デフォルトの名無しさん
2015/02/11(水) 11:25:19.20ID:x6JgCX17普通にクローンしたらhelloディレクトリが作られるところをkonnitiwaディレクトリにしたいんです
0450デフォルトの名無しさん
2015/02/11(水) 11:32:28.53ID:YTSnrjVSgit clone --help でできるよ
0451デフォルトの名無しさん
2015/02/11(水) 11:32:37.37ID:uxm1HOmW引数の最後にディレクトリ名追加するだけ
0452デフォルトの名無しさん
2015/02/11(水) 11:38:15.92ID:x6JgCX170453デフォルトの名無しさん
2015/02/11(水) 11:38:55.57ID:x6JgCX17ここのテンプレにつかってもらえませんか？
0454デフォルトの名無しさん
2015/02/11(水) 11:44:13.95ID:yrYT/hzd0455デフォルトの名無しさん
2015/02/11(水) 11:44:56.80ID:sJPqGjE70456デフォルトの名無しさん
2015/02/11(水) 11:52:17.96ID:Uh1U0rAfhttp://www.backlog.jp/git-guide/reference/
0457デフォルトの名無しさん
2015/02/11(水) 12:04:55.83ID:sJPqGjE70458デフォルトの名無しさん
2015/02/11(水) 16:51:35.61ID:MWL67ZBgひさびさにまともな意見を見た。
普段ネット上の解説を見ても無条件に「push -fはやめましょう」とか
「rebaseすると履歴が一本になって見やすいです」とかドヤ顔で
書いてるやつが多くてゲンナリしてるんだよね。
>>442 みたいなレベルでGit使えるやつって実は少ないんじゃないのかと思ってる。
だいたい man 読めば書いてあるんだがなぁ。
0459デフォルトの名無しさん
2015/02/11(水) 17:03:10.91ID:cHTFVS1e> >>442 みたいなレベルでGit使えるやつって実は少ないんじゃないのかと
それが事実かは知らんが
それを認めたら
> それを一部の困る場合を例にして全部禁止する
という方針に正当性を与えるんでは？
0460デフォルトの名無しさん
2015/02/11(水) 17:07:38.54ID:MWL67ZBgなるほど、一理ある
そういう意味では認めたくないねぇ
0461デフォルトの名無しさん
2015/02/11(水) 17:17:53.07ID:oNYh8LxPまず道具を正しく使える人が基準だ。
その人を基準とし、その人にとって
使いやすい方法を選ぶべき。
そして能力が低い人は、
単に能力を上げろってだけの話。
それまでは補助輪つけるのは構わんが、
それは補助輪であり、将来外す事になるのが既定路線であり
そしてプロにとっては邪魔なものであるということ。
0462デフォルトの名無しさん
2015/02/11(水) 17:31:25.86ID:MWL67ZBg参考になる。
まぁ、「補助輪をはずすなんてとんでもない！そんなことしたら転んでしまうぞ！」
という奴ばかりで「邪魔な補助輪なんか外して走ろうぜ」って言ってる奴をあまり見かけない
っていうただの愚痴だ。
0463sage
2015/02/11(水) 18:18:29.29ID:QzvGx1aq>>443
まさにこれ
状況によって使い分けるべきだ、という話だったのを、「rebaseは(常に)ダメ」とか「rebaseは(常に)良い」とか「gotoは(常に)ダメ」いう話とすりかえる人がいるのが問題なだけ。
大きなリスクもあるという話であって、状況によっちゃ使った方が良いんですよ。
リスクをコントロールできない奴は使うな、というだけの話。
火や刃物と一緒ね。
0464デフォルトの名無しさん
2015/02/11(水) 18:22:20.62ID:oNYh8LxPベテラン・・・スキルが高い
新入社員・・・スキルが低い
なわけだよ。実態は置いといて一般的にさ。
なんでベテランが新入社員のスキルに合わせましょう！
新入社員さまさま、あなたさまの知識でわからないことはしません。
あなたさまに合わせて、素人のやり方で仕事します。
なんて、新人にへりくだらなきゃいかんのさ？って話だよ。
普通は、そんなこともわからんのか、ちんたらやってんじゃねーぞ、
そんなものは使い物にならん（ガシャーンって投げ捨て）
わからないならで勉強しろって怒鳴りつけるところだろ。
0465デフォルトの名無しさん
2015/02/11(水) 18:29:10.60ID:+zb7i42Pスキル低い奴に自由にさせるとやらかしてとんでもないことになるから、コーディングルールなり運用手順を決めるんだよ
勉強してスキル上がるまで待てりゃいいけど、そんな余裕のあるところばかりじゃないでしょ
0466デフォルトの名無しさん
2015/02/11(水) 18:32:40.79ID:sK01Ui9b概ね賛同
「普通は、」以降には賛同しかねるがGit関係ないので掘らない
0467デフォルトの名無しさん
2015/02/11(水) 18:37:11.18ID:xmq/DIW5それにベテランってなんのことだよ会社に長く居る人のことを言っているのか、ある分野に長く関わっている人のことを言うのか。
ぶれてて話がわからないからまず定義をしっかりかいてくれよ。
0468デフォルトの名無しさん
2015/02/11(水) 18:49:49.07ID:Fyh5Lzr/スレの質もずいぶん下がったものだ
0469デフォルトの名無しさん
2015/02/11(水) 19:12:00.65ID:9i6616PG0470デフォルトの名無しさん
2015/02/11(水) 19:38:14.39ID:Fyh5Lzr/0471デフォルトの名無しさん
2015/02/11(水) 19:42:05.11ID:uTZsT+lh> コーディングルールなり運用手順を決めるんだよ
そこにちゃんとコードレビュー入ってる？
まともなコードを100としたら、コーディングルールで縛れるのは
ほんの5ぐらいだから。
運用手順っていうのがコードレビューを含めたワークフローのことかな？
ソフトウェアの開発っていうのは、あるものを基盤にして積み重ねていくものだから、
誰かが足を引っ張ると、つまり悪い設計、悪いコードを作ると
それを利用するその他全員の生産性を下げることになるよ。
スキルが低い奴が作ったもの、例えて言うならば、弟子入りしたばかりの
ひよっこが作った作品は、親方がみて判断し作り直しさせたり、
あまりにひどいものは捨てたりして、商品として使えない。客には出せないって
ことをはっきり言わないといけない。それがプロっていうもの。
0472デフォルトの名無しさん
2015/02/11(水) 21:49:13.33ID:+zb7i42Pコードレビューは当然として、作ってから直させるのは無駄なので事前にルールを決めるのはまともな企業なら普通にやってるだろ
また git で変なことされると面倒だから、運用を決めるのも普通だと思うけどな
0473デフォルトの名無しさん
2015/02/11(水) 21:54:30.37ID:fVfIbgvgまともなコードが100だったら5程度なんだってば。
例えば、標準関数にある処理を
知らずに独自実装してしまいました。
みたいなものをコーディングルールで防ぐことは出来ない。
0474デフォルトの名無しさん
2015/02/11(水) 22:03:05.62ID:fVfIbgvgペアプロするしかないんだような。
0475デフォルトの名無しさん
2015/02/11(水) 22:05:51.83ID:plnxZoKt0476デフォルトの名無しさん
2015/02/11(水) 22:08:02.15ID:yrYT/hzdこの2つで互いの欠点を補う。
ただし、共同作業には無駄がつきものなのでできるだけ少数でやったほうがいい。
産業でおk
0477デフォルトの名無しさん
2015/02/11(水) 22:11:04.87ID:+zb7i42P5でも少ない方がいいだろ
なにを必死になってるのかよくわからん
0478デフォルトの名無しさん
2015/02/11(水) 22:12:22.06ID:fVfIbgvgあんなのてにをはは正しく使いましょう。
誤字脱字に気をつけましょう。
慣用句の誤用に気をつけましょうぐらいの
意味でしかないのに。
守るのはあたりまえだけど、それを守った所で
良い文章が出来るわけじゃない。
0479デフォルトの名無しさん
2015/02/11(水) 22:13:53.88ID:fVfIbgvg読み間違ってるよ。
まともなコードが100点だとして、
ルールがあった所で0点の人が
5点になる程度の効果しかないっていってるの。
0480デフォルトの名無しさん
2015/02/11(水) 22:27:20.28ID:Uh1U0rAf根拠もなしに5程度なのを力説しないで、あとの95の内訳を説明すればいいんじゃない？
そうすればそれが過小評価なのかもっともな意見なのかみんな納得すると思うけど。
0481デフォルトの名無しさん
2015/02/11(水) 22:42:37.11ID:fVfIbgvg一つ説明したはずだけど？
> 例えば、標準関数にある処理を
> 知らずに独自実装してしまいました。
他にも
* このモジュールに置くべきでない関数を作ってしまった。
* クラスの役割が単一責任の原則を満たしていない
* AモジュールがBモジュールに依存してるのにBモジュールもAモジュールに依存するなど依存関係がおかしい
* もっと短く効率的な書き方がある。
* やる意味が無い処理をしている。（1以上かつマイナスでない時みたいな）
* コードを共通化出来るのにしていない。
とかルールあっても解決できない問題は山ほどある。
0482デフォルトの名無しさん
2015/02/11(水) 22:55:40.99ID:Y7a0039Iただ毎回似たようなのが繰り返されてると思うから議論防止に何かテンプレに入れた方がいいんじゃね？
* 後から履歴を使いやすいようにrebaseで整理するといいね
* でも公開されてる履歴を改変すると面倒が起きるから基本しちゃいけないよ
* どう運用するかはチームでポリシーを決めよう
まとめるとこういうことだと思うんだけどどうですか
0483デフォルトの名無しさん
2015/02/11(水) 23:57:27.82ID:FjuB8iZN0484デフォルトの名無しさん
2015/02/12(木) 00:18:59.71ID:KAJNjFEz0485デフォルトの名無しさん
2015/02/12(木) 00:25:26.29ID:Il0VyiBXそれは少数精鋭で無駄なく効率よく開発することで低コストでも高い品質で仕上げるやり方と
人を大量に集め無駄が多くて効率が悪くてもコストをかけて物量でせめることで品質を上げるやり方の
違いってことでいいですか？
0486デフォルトの名無しさん
2015/02/12(木) 00:38:11.65ID:6hCiD8D7だいたい答えてもらえてもケースごとにポリシーを構築することに変わりはないんだから
既出の用例から自分で取捨選択できないやつが特定のケースの例示だけ受けても無意味
永遠に空論が積みあがるわ
0487デフォルトの名無しさん
2015/02/12(木) 01:00:47.10ID:ZkwBZ2lH一度これはダメみたいなパターン作っちゃうと
何年も覆らないんだよね
git使ってる意味ないぞ・・ってのが増えていってテンション下がる
0488デフォルトの名無しさん
2015/02/12(木) 01:14:07.27ID:Uh2ZxlVlいやマシだと思え
0489デフォルトの名無しさん
2015/02/12(木) 01:40:06.71ID:CBdFIpzZ0490デフォルトの名無しさん
2015/02/12(木) 05:12:25.42ID:UPnDkHcPcvsの部分取得やキーワード展開は便利だぞ。
ただ分散とかがgitの方が便利なので、天秤にかけてgit使ってるだけ。
0491デフォルトの名無しさん
2015/02/12(木) 07:13:24.29ID:D8Qo7IfRああ、やっぱりまともなコーディングルールを見たことないお子ちゃまが「ぼくのかんがえたこうでいんぐるーる」で語ってたのか w
> あんなのてにをはは正しく使いましょう。
レベルの低い組織がコーディングルール導入しろって言われたときによく「言語の文法を守りましょう。」とかのルールを設定してるよな。
そんなルールは無駄。
コーディングルールは大きく二つある。
1. 全体の統一を図るべき内容を規定する
・名前の付け方とか、モジュールの配置方法とか
2. ありがちな誤用を防止するために規定する
・C 言語の例として if( ) ブロック1 else ブロック2 のブロックは単一の文でも { } で囲むこと、とか
1. の方は個々の組織やプロジェクトによって違うからあまり例はないけど、2. の方は MISRA とか、IPA/SEC のコーディング作法ガイドとかあるから読んでこい。
あまりにもレベルが低すぎてお話にならない。
http://www.ipa.go.jp/sec/publish/index.html#emb
> 良い文章が出来るわけじゃない。
当たり前、良い文を作るためじゃなくて悪い文を作らないようにするためのもんだ。
それこそルールを過剰評価しすぎだよ w
0492デフォルトの名無しさん
2015/02/12(木) 07:28:41.45ID:Uh2ZxlVlそれでも続けるというならコテ付けてくれ
0493デフォルトの名無しさん
2015/02/12(木) 08:29:28.30ID:Il0VyiBX言ってることが、>>478何ら変わってないんだがｗ
それにさ、ルールを決めた所で
そのルールを守っているかどうやってチェックするんだよ？
> MISRA とか、IPA/SEC のコーディング作法ガイド
のような内容は機械でチェックできないぞ。
それこそコードレビューだろ。
0494デフォルトの名無しさん
2015/02/12(木) 08:30:15.27ID:NNFkXciWしかもスレチだし。
0495デフォルトの名無しさん
2015/02/12(木) 09:00:06.37ID:D8Qo7IfR・文法を守りましょう
と
・グローバル変数は g_ で始めること
が、同じにしか見えないならマジで終わってるぞ
確認はレビューでやればいい
ルール決めときゃまともなコーダーは大体それに従うから、不注意とかで間違ってるところだけ指摘すりゃいい
おまえのところはルールもなしに適当にコーディングされたものをレビューでいちいち指摘するのかい？
まあ、文法を守りましょうとかなら指摘はほぼないだろうけどな w
>> MISRA とか、IPA/SEC のコーディング作法ガイド
> のような内容は機械でチェックできないぞ。
QAC、C++TEST とか、PG-Relief MISRA オプションも知らないなら黙ってた方がいい
全てのチェックはできないが 8〜9割は機械的にチェックできる
ネーミングルールのチェックができるものもある
0496デフォルトの名無しさん
2015/02/12(木) 09:48:51.50ID:Fdr/rRsVrebase一本道派だなw
0497447
2015/02/12(木) 09:52:38.93ID:x5e0tI8J0498デフォルトの名無しさん
2015/02/12(木) 10:11:30.52ID:hudT64vw何の罰ゲームだよw
0499デフォルトの名無しさん
2015/02/12(木) 10:14:04.02ID:NNFkXciWそりゃあ残ったままになるわ。バージョン管理されてないもん。
0500sage
2015/02/12(木) 11:45:32.22ID:/2LasYze絶対事故起こしたりしないから、制限速度超えて思うままに道路を走っていい、っていう話な
免許もってない人に合わせて制限時速30kmにしてたら、生産性が落ちる。
0501sage
2015/02/12(木) 11:56:52.26ID:/2LasYzeそういう合意は基本とれてるはずなのに
「rebase禁止! これは絶対！ 初心者がミスるから！ おまえらもrebase禁止！ 禁止で当然！俺らのルールが絶対！ 初心者がいないチーム？ありえない！」
みたいなヤツが出てくるからややこしい。
0502sage
2015/02/12(木) 12:07:36.49ID:/2LasYze共有リポジトリでrebaseしちゃう人が多発しちゃって、不要なマージだらけのログっていう呪いのほうが余程マシなようなチームもあるんじゃね？
・・・知らんけど。
問題は「そういうチームがある(かもしれない)」からといって
それをgitの一般的運用ルールとして他のチームに強制にしようとするアホがいることだ。
rebase禁止縛り？ 自分らで勝手にやれよ。押しつけんな、って話。
0503デフォルトの名無しさん
2015/02/12(木) 12:19:07.16ID:x5e0tI8J* add robot.c
* ロボットの歩行機能実装
* typo
* ロボットの自動停止機能実装
* type
git checkout master
git merge robot dev
こういうばあいはどうやってまとめたらいいですか
0504デフォルトの名無しさん
2015/02/12(木) 12:30:19.07ID:NNFkXciWイミフ
0505sage
2015/02/12(木) 12:57:58.12ID:/2LasYzeログをどう書くかって話かな？
いや、それにしては後半がいみがわからん
イミフ
0506デフォルトの名無しさん
2015/02/12(木) 13:16:08.10ID:x5e0tI8J0507デフォルトの名無しさん
2015/02/12(木) 13:31:40.15ID:Il0VyiBX> 共有リポジトリでrebaseしちゃう人が多発しちゃって、
gitlab使えばいいのに（githubでもいいと思うけど会社で使ってないので）
共有リポジトリでrebase（正確にはpush）できないように
するだけで終わる話。
ローカルや個人リモートリポジトリは別として、
マージはgitlabのウェブ画面からやるのよ。
githubでプルリクエストの処理をウェブ画面でやるのと同じ。
だから共有リポジトリの共有ブランチを守るのは簡単。
下手にgitだけでやろうとするから大変なんだろう。
0508デフォルトの名無しさん
2015/02/12(木) 13:38:06.44ID:Il0VyiBX「コミットログは後から見返すもの」として考えれば
何が必要で何が必要でないかはわかると思うよ。
後で見返した時、あー、あのときの俺はタイポしまくってたなぁ〜
なんて感慨にふけりたいと思う？ｗ
そのコミットでやったものは、
* ロボットの歩行機能実装
* ロボットの自動停止機能実装
の二つでしょ？
これは内容によるけどコメントだけから判断すれば、
それぞれで分けて二つのコミットになりそう。
だから、そのブランチにはその二つのコミットがあり、
そのブランチをマージすることで最終的には、
一つのマージコミットに、その二つのコミットが入った状態にするのが良い。
（マージ自体を二つに分けるという考え方もある）
捕捉
ただし、そのタイポの修正が、全然関係ない部分の修正であれば
別で修正しマージした方がいい。
0509デフォルトの名無しさん
2015/02/12(木) 13:51:15.31ID:x5e0tI8J* ロボットの歩行機能実装
* ロボットの自動停止機能実装
２）typoはrobotブランチから新しいブランチfixtypoを作ってそこでtypoを修正して、git merge robot fixtypoをする
これでいいんですか
0510デフォルトの名無しさん
2015/02/12(木) 15:50:00.58ID:hudT64vwpushに--forceフラグを付けなければ
pushを拒否られてその時に気付くから
通常問題にはならない
0511デフォルトの名無しさん
2015/02/12(木) 18:08:55.97ID:Cso7caDUtypoは、typoをやっちゃったコミットにrebase -iでfixupする
「typoをやっちゃったコミット」が「ロボットの歩行機能実装 」「ロボットの自動停止機能実装」に関係なくて
既に公開済みだったり、そうでなくてもずっと昔の話だったり別の人の作業だったりする場合はそのままにしとく
これは人によるかもしれないけど、typoの修正程度に新しいブランチを作る必要は無い……と思う
add robot.cは、その状態でビルドが通るなら残しておいてもいいし
「ロボットの歩行機能実装」の前準備としてaddしただけで中身空っぽとかならsquashで一緒にしてもいい
現在、devブランチに以下のコミットがあるとして
* typo-A (ずっと以前にやらかしたtypo)
* add robot.c
* ロボットの歩行機能実装
* typo-B (add robot.cでやらかしたtypo)
* ロボットの自動停止機能実装
* typo-C (ロボットの自動停止機能実装でやらかしたtypo)
俺ならこう直す
・typo-Aはmasterに直接cherry-pick
・devブランチは
pick add robot.c
fixup typo-B
squash ロボットの歩行機能実装
pick ロボットの自動停止機能実装
fixup typo-C
この場合、devブランチには「add robot.cとロボットの歩行機能実装をsquashしたもの」と「ロボットの自動停止機能実装」が残る
最後にmasterにマージするわけだが、ここでffでやるかno-ffでやるかは……人によるとしか言えないのでまた争いになる(苦笑)
0512デフォルトの名無しさん
2015/02/13(金) 07:52:50.01ID:9pkMuWgMキーワード展開はdiffとる邪魔になった記憶しかないな
0513デフォルトの名無しさん
2015/02/13(金) 08:05:43.90ID:Y/Hf+FOAgitもcvsも使い方次第ってことだ。
0514デフォルトの名無しさん
2015/02/13(金) 11:20:00.51ID:YHKfbCy6という奴ばかりで「邪魔な補助輪なんか外して走ろうぜ」って言ってる奴をあまり見かけない
っていうただの愚痴だ。
rebase=補助輪
rebase縛り？ 自分らで勝手にやれよ。押しつけんな、って話。
0515デフォルトの名無しさん
2015/02/13(金) 12:29:36.12ID:6M9upxSIどんだけ埋め込んでるんだよｗ
0516sage
2015/02/13(金) 14:07:28.36ID:q/yT9bsRなるほど知りませんでした
ツールによってrebaseの危険性を抑える方法もあるんですね。
なら余計に「rebase禁止」ルールを適用するべき場面は減るわけだ。
そんな特殊なrebase禁止ルールを一般化しようとする人っていったい…
0517sage
2015/02/13(金) 14:21:13.00ID:q/yT9bsRrebase禁止批判を逆にして相対化しようとしたのだろうけれど、
rebase禁止を批判している人は、
rebaseのみに縛ることを主張しているわけではないのだから、
余計にrebase禁止のおかしさが際立っちゃってるように思う。
加えて、rebaseはリスクを抑えるわけじゃないから、補助輪で例えるのもおかしい。
補助輪の例えなら、rebase禁止が補助輪に相当する。
rebase禁止 = 補助輪あり
・リスクを抑えることができる
・効率、合理性で劣る
・ガチ初心者は最初はここからはじめるのがよい
rebase可 = 補助輪なし ・リスクはあるのでリスクを管理する必要がある
・上手ならば問題はない
・合理的。効率的。
0518デフォルトの名無しさん
2015/02/13(金) 14:34:28.88ID:FzPhDDc+大仰に話してるけどものすごく低レベルな内容なのわかってる？
0519デフォルトの名無しさん
2015/02/13(金) 14:36:54.03ID:6M9upxSI0520sage
2015/02/13(金) 14:44:33.35ID:q/yT9bsR低レベルなのも邪魔なのもそうやと思うし、誠にごめんやけど、
変な説やデマを放置すると、またそれが一定の力を持っちゃうからなぁ
でも、嫌な人がいるようなので、
もう僕は例え話にはかかわらないようにしますね。
0521デフォルトの名無しさん
2015/02/13(金) 14:46:37.57ID:FzPhDDc+0522デフォルトの名無しさん
2015/02/13(金) 15:02:53.85ID:FzPhDDc+このスレに常駐しててデマを真に受ける人はほとんどいない
今までも適当にあしらわれてきた
今回はお前があしらわれても根掘り葉掘り聞いてデマレベルのしょうもない話がだらだら続いてるだけ
デマを作ってるのはお前
0523デフォルトの名無しさん
2015/02/13(金) 16:03:34.24ID:0r+sAlU90524デフォルトの名無しさん
2015/02/13(金) 16:07:08.33ID:VTed8hSx0525デフォルトの名無しさん
2015/02/13(金) 16:12:45.37ID:6DiGTjtUたとえばツールを使うんですか
0526デフォルトの名無しさん
2015/02/13(金) 16:27:52.20ID:qJaCJPEr0527sage
2015/02/13(金) 16:35:43.83ID:0qan/45z0528デフォルトの名無しさん
2015/02/13(金) 16:46:36.01ID:YHKfbCy6https://rhodecode.com/
0529デフォルトの名無しさん
2015/02/13(金) 22:08:39.86ID:yrNrrj7G0530デフォルトの名無しさん
2015/02/13(金) 23:47:49.72ID:KU85EYTm0531デフォルトの名無しさん
2015/02/14(土) 07:31:27.11ID:1refxAFi// 19xx.01.01 modified by hogehoge
とか手で編集日とか入れてたんだけど、ある日CVSを知って、その
$Id: .... $
がカッコよくて中2ごころくすぐられまくったなぁ。
そのうち ident でコンパイル後のバイナリも特定できる方法を知って
const static rcsid = "$Id; ...$";
とか書くように。
GitでもIdを埋め込む方法は用意されてるけどcheckoutのスピード落ちそうだし、
コンパイル時とかにコミットハッシュを埋め込んじゃえばツリー全体を特定できるGitだと
そもそもIdの意味が本当に字面だけしかないことに気づいてIdへの情熱が薄くなった。
それ以上に、Gitの機能が色々な面でCVSよりはるかに便利なのでもうCVSには戻れない。
0532デフォルトの名無しさん
2015/02/14(土) 07:45:27.45ID:xzkKcWkn0533デフォルトの名無しさん
2015/02/14(土) 10:32:50.47ID:Tntf/sjh*.*
こういうふうに全てのファイルを無効化してから
↓みたいなサブディレクトリのphpファイルを監視させたい場合って
./tests/my.php
./tests/2015/listen.php
!tests/
!tests/*.php
!tests/2015/*.php
って書かないとだめですか？
0534デフォルトの名無しさん
2015/02/14(土) 11:26:41.62ID:1refxAFiそうみたい。
gitignore(5)によると「It is not possible to re-include a file if a
parent directory of that file is excluded.」とあるので。ちなみに
re-include = !で再度ignoreされなくする
excluded = ignoreされてる
てことね
ところで * がある状態で *.* って必要？
0535デフォルトの名無しさん
2015/02/14(土) 11:38:30.45ID:Tntf/sjh*
*.*
.*
でした
*だけだと漏れてたのを確認した覚えがあるのでこの３つ書いてます
0536デフォルトの名無しさん
2015/02/14(土) 11:56:27.85ID:1refxAFi*
て書くだけで
.foo
とか
foo.bar
とか無視されるから *.* がないと無視されないファイル名って何なのか気になっただけ。
0537デフォルトの名無しさん
2015/02/15(日) 01:03:31.27ID:xq5CRrOm要は雛形を記録したいだけです
0538デフォルトの名無しさん
2015/02/15(日) 01:27:31.31ID:sYDZ2RKuconfig <- .ignoreに入れる
config.skelton <- コミットする
0539デフォルトの名無しさん
2015/02/15(日) 01:34:44.07ID:TTUR8i8sstatusで表示されるのが嫌なら
assume-unchangedとかskip-worktree
0540デフォルトの名無しさん
2015/02/15(日) 16:51:25.43ID:zFq0UCJm*.packという巨大なファイルがあるだけでソースツリーそのものがありません
コードを取り出すコマンドなどあるのでしょうか？
0541デフォルトの名無しさん
2015/02/15(日) 17:07:48.76ID:8pjOc2SBもっとありのままの症状を書いたほうが答えが得られやすいと思うが。
今晒してる情報だけだと、いくつか考えられる可能性はあるが
(a) --bare, あるいは --mirror でクローンしたのでワークツリーがない
→ 余計なオプションをつけるな
(b) clone が途中でコケてる
→ 終了ステータスちゃんと見ろ。
(c) *.pack というファイル自体を Git で管理している。あるいはその他
→ これはそのリポジトリの所有者に聞くのが早い
他の解決へのアプローチとしては、git log --stat とかを眺めて自力で解決する。
または、それがパブリックなリポジトリならURLを晒すと誰か調べてくれることに期待するってあたりか。
0542デフォルトの名無しさん
2015/02/16(月) 21:12:52.09ID:yR7BIbe7HEAD@{3}のところにその修正内容を入れたい場合ってどうやればいいんでしょうか？
いまはgit reset --soft HEAD^でコミットを一個ずつ戻していって
index.phpだけaddしてコミットしたら、残りのファイルを一括でコミットしているので
戻した文だけログが少なくなってしまいます
どうするのがいいのかおしえてください
0543デフォルトの名無しさん
2015/02/16(月) 21:48:21.88ID:JbfKOoLrrebase -iで並び変えてfixupで合成する
0544sage
2015/02/19(木) 05:48:57.58ID:NTq8PsN5なぁ〜〜〜〜にぃ〜〜〜〜！？
やっちまったな！！！！
男はだまって コピーアンドペースト！
男はだまって コピーアンドペースト！
0545デフォルトの名無しさん
2015/02/19(木) 22:33:45.27ID:1LBnym+Mコピーアンドリネームならネタとしては成立するが面白くはない
0546デフォルトの名無しさん
2015/02/20(金) 02:21:50.17ID:g/o9zkKOあの汚点を消したい
0547デフォルトの名無しさん
2015/02/20(金) 09:40:21.47ID:SdYWKWEvバージョン毎のフォルダ圧縮最強の時代が来るよ
0548デフォルトの名無しさん
2015/02/20(金) 09:55:58.70ID:IrmHPKvS何言ってるんだ
0549デフォルトの名無しさん
2015/02/20(金) 11:03:17.05ID:1WGLlPh40550デフォルトの名無しさん
2015/02/20(金) 11:17:51.54ID:3JjqLKV80551デフォルトの名無しさん
2015/02/20(金) 12:40:49.35ID:1WGLlPh4いるよ。
0552デフォルトの名無しさん
2015/02/20(金) 19:09:04.40ID:KUTJ82CZ沢山のバックアップがあるんだけど、あの関数を変更したのはどのバージョンだったかな、よし遡って検索するスクリプトを書こう。
バックアップのそれぞれに readme ファイルを付けておけば、バックアップ検索のときに表示できるようにしよう。
複数人で開発するときに便利なように、バックアップファイルをトランザクショナルに追加できるようにスクリプトを書こう。
バックアップの追加時には最新のバックアップと自動的にマージするようにして、コンフリクトのチェックもしてあげよう。
もうある。
0553デフォルトの名無しさん
2015/02/21(土) 03:44:23.40ID:xSRhDEOz容量が大きくなるほど圧縮伸張に時間がかかｒ
0554デフォルトの名無しさん
2015/02/21(土) 06:04:18.20ID:8qvi7euQsvn・・・複数ファイルのバージョン管理
git・・・プログラムの機能のバージョン管理
0555デフォルトの名無しさん
2015/02/21(土) 12:30:48.10ID:kE8wPpLX0556デフォルトの名無しさん
2015/02/21(土) 15:52:52.04ID:B8QFAMlJ0557デフォルトの名無しさん
2015/02/21(土) 15:53:48.73ID:B8QFAMlJIOの速度にも影響がある。
0558デフォルトの名無しさん
2015/02/21(土) 22:27:15.52ID:ALKeCC2m極論すれば、別にgitとか関係なくて、
・どのくらいのボンクラまで許容するか
・許容できないボンクラを、どうやって処分するか
って話だよね
0559デフォルトの名無しさん
2015/02/22(日) 05:30:36.33ID:vfKk6XwYマニュアルさえ作ればボンクラでも使える筈という信仰が強いんだよね。
それがソフトウェアの世界に入ってきておかしい事になっている気がする。
0560デフォルトの名無しさん
2015/02/22(日) 12:38:15.01ID:uX3Bvmhtそうね
0561デフォルトの名無しさん
2015/02/22(日) 17:43:50.34ID:/3o/v0h5（´・ω・｀）しょぼーん
0562デフォルトの名無しさん
2015/02/22(日) 17:48:54.43ID:TfAgRNIZ0563デフォルトの名無しさん
2015/02/23(月) 13:36:42.48ID:Ug+lllyj0564デフォルトの名無しさん
2015/02/23(月) 13:42:50.25ID:MRd19mpe0565デフォルトの名無しさん
2015/02/23(月) 14:24:43.71ID:QDxEo34K0566デフォルトの名無しさん
2015/02/23(月) 14:26:47.38ID:gAUzZJwv0567デフォルトの名無しさん
2015/02/23(月) 14:29:41.21ID:TEncit8E大仰に話してるけどものすごく低レベルな内容なのわかってる？
0568デフォルトの名無しさん
2015/02/23(月) 14:42:39.24ID:Ug+lllyj高レベルな奴が光臨しましたよ
0569デフォルトの名無しさん
2015/02/23(月) 15:39:34.79ID:UVXbAF4b履歴が汚いのはてめえの作業の仕方に問題があるからである。
履歴を一本に纏める時はブランチをマージするときだけで良い。
それ以外で纏める必要はない。
わざわざ開発ブランチで見栄張ってrebaseしてんじゃねえよ！！！
0570デフォルトの名無しさん
2015/02/23(月) 16:51:30.02ID:YVVJ3Jny開発はデスクトップとノートPCの両方で行っています。
今まで自宅サーバーのsubversionで二台のバージョン管理をしてきたのですが、サーバーの電気代が無駄の
ような気がしてきました。
そこでgitならサーバーを立てずにファイルのやり取りをできると聞いたのですが、検索してみると
githubのような中央サーバーを作るやり方ばかり出てきます。
windowsのデスクトップとノートPCの二台でバージョン管理を行える参考サイトのような物があれば
教えて頂けないでしょうか。
0571デフォルトの名無しさん
2015/02/23(月) 16:58:58.86ID:gAUzZJwvとかでググるのがいいかもね
0572デフォルトの名無しさん
2015/02/23(月) 17:08:30.18ID:Kf7W7KjZ安いNASとかでも十分かも
0573デフォルトの名無しさん
2015/02/23(月) 17:13:44.39ID:YVVJ3Jny調べてみます。
0574デフォルトの名無しさん
2015/02/23(月) 17:28:04.59ID:Kf7W7KjZMantisとかPukiwikiとか入れたら使えた
消費電力はディスク数でも違うだろうけどタイマーで
ON/OFFをスケジューリングできる機種もあるみたい
0575デフォルトの名無しさん
2015/02/23(月) 17:38:38.57ID:jEpPmjFB0576デフォルトの名無しさん
2015/02/23(月) 19:56:28.77ID:XHjPb0no0577デフォルトの名無しさん
2015/02/23(月) 21:03:24.05ID:YX8pSHyr0578デフォルトの名無しさん
2015/02/23(月) 21:28:55.41ID:Bc1+Ke94gitならではのサーバを立てずにできる方法がある？
0579デフォルトの名無しさん
2015/02/23(月) 21:36:03.59ID:xF5e0cAkファイルシステムをマウントすればできると思うけど、windowsでやったことは無いなあ
0580デフォルトの名無しさん
2015/02/23(月) 21:40:21.63ID:dtK9qqJsディレクトリ作って、trunk, branches, tagsディレクトリ作って
リポジトリ用のディレクトリ作って、初期化。
そこに対してインポートする。とかだっけ？
gitだったら、普通に作成したディレクトリを
git化したいなって思った時に、
git init実行すれば終わり。
0581デフォルトの名無しさん
2015/02/23(月) 22:51:55.32ID:AIz5Wz5r状況次第ではformat-patchやamやbundleでメール経由で同期したりdaemonで一時的にサーバー立てるのが便利な場合もある
でも共有フォルダ使ってOKな状況ならソッチのほうがお気楽
0582デフォルトの名無しさん
2015/02/24(火) 08:40:49.63ID:trUfTvKQgitはオフラインでもコミットできるだろう
0583デフォルトの名無しさん
2015/02/24(火) 08:51:56.47ID:vUnjBdYz馬鹿には無理
0584デフォルトの名無しさん
2015/02/24(火) 10:44:56.05ID:PQNah075> 自分が作業してきた履歴を修正せずに残すべき。
> 履歴が汚いのはてめえの作業の仕方に問題があるからである。
> 履歴を一本に纏める時はブランチをマージするときだけで良い。
> それ以外で纏める必要はない。
> わざわざ開発ブランチで見栄張ってrebaseしてんじゃねえよ！！！
まったくです。
履歴が見づらくなるからとか汚くなるからとか言ってるのがいるけどなんで、
そんなレベルのやつが自分で良いと思ってるやり方広めようと思うのやめて ほ し い
0585デフォルトの名無しさん
2015/02/24(火) 12:25:48.63ID:6vv1mCHrまた釣り？ｗ
前回負けたのがよっぽど悔しかったみたいだねｗ
0586デフォルトの名無しさん
2015/02/25(水) 00:05:08.53ID:Wo4XdcUv結局のところは、最終的に履歴がキレイに見えればいいわけで。
自分が会社でSVNを使ってた時は、
1. 自分の修正の途中経過を保存しておけるローカルのSVNのリポジトリで作業して、
2. ちゃんと動くようになったら、他人に見せれるキレイなコードに直して、
3. キレイなコードを会社のSVNにコミットしてた。
Gitはそれが一連の流れとしてできるわけでしょ？
なぜGitの良さを殺して開発効率が悪くなる方向に向かうのかが分からない。
0587デフォルトの名無しさん
2015/02/25(水) 00:58:22.22ID:Wo4XdcUv＞そんなレベルのやつが自分で良いと思ってるやり方広めようと思うのやめて ほ し い
なんでその方法が良いと思ったかというと、その人の経験則によるものなんだろうね。
自分が一番上手く書けると思ってるコーダーと、たくさんのコーダーを抱えるリーダーでは、
重視するものが変わってくる。どっちも経験則によるもので、その経験は否定できない。
0588デフォルトの名無しさん
2015/02/25(水) 04:13:45.41ID:kdMsbAelなんで、そういう1つの方法を良いと思ったかというと、その人の経験則によるものなんだろうね。
それをgitの良さって。
大体、履歴のみ見るステークスホルダーが注文付け出して生産性下がる。
で、開発の経緯は消されて、あとから来た人が同じこと繰り返す。
0589デフォルトの名無しさん
2015/02/25(水) 04:31:12.31ID:zSW92Ygk一般に優れた方法だと勘違いするアホがいるから困る
0590デフォルトの名無しさん
2015/02/25(水) 04:33:10.33ID:vLMr5bhEお前らの開発チーム内状態が改善されるわけじゃねえからな
文句あるんならこのスレじゃなくお前らの所属する開発チームに直談判しろ
0591デフォルトの名無しさん
2015/02/25(水) 08:43:05.38ID:nKN7f0Auと作業したあとで
A と D だけにタグ付けることは可能ですか？
0592デフォルトの名無しさん
2015/02/25(水) 09:29:35.29ID:Wo4XdcUvどうやら、自分が一番上手く書けると思ってるせいで、周りから煙たがられてるコーダーっぽいな
0593デフォルトの名無しさん
2015/02/25(水) 10:33:20.93ID:2phC3Ctb下手くそな奴はすぐ開発ブランチで大量コミットするから汚くなる
0594デフォルトの名無しさん
2015/02/25(水) 10:40:34.85ID:4rpbMsiuそういう当たり前のことができない方が多いのです。
そういう方はコードが汚くなるとか低レベルの環境が前提な
謎のオレオレ手法がうまいやり方と勘違いする。
履歴がきれい 俺すげーw
0595デフォルトの名無しさん
2015/02/25(水) 12:22:12.08ID:jNJiSOpZそれはとてもいいことだよ。
0596デフォルトの名無しさん
2015/02/25(水) 12:51:36.99ID:6KXCrYoxバグってない所まで戻した後直後のコミットを調査する事になる
そういう場合はコミットが細かい方が見やすいな
関連性が薄い変更まで含まれていると問題の切り分けが難しくなる
0597デフォルトの名無しさん
2015/02/25(水) 13:15:30.99ID:4rpbMsiuお前が良いと思い込んでるだけ、お前が綺麗だと思い込んでるだけ
他の人は迷惑してるかも知れんということに気づける頭無いのか?
なんで馬鹿な主張にこだわるのかわからん? 勝ち負けw
0598デフォルトの名無しさん
2015/02/25(水) 13:22:23.83ID:jNJiSOpZお前、本当に他人のこと何も考えてないよなｗ
0599デフォルトの名無しさん
2015/02/25(水) 13:54:02.16ID:4rpbMsiu> 履歴がきれい＝他の人が読んで修正がわかりやすい履歴になっている。
(おまえが見て)履歴がきれい(と思う)＝他の人が読んで修正がわかりやすい履歴になっている(とは限らない)。
当たり前のことわからんやつやw
> それはとてもいいことだよ。
^_^??
0600デフォルトの名無しさん
2015/02/25(水) 17:08:58.50ID:/AlEg9/u限らないのは確かにそうだが、そうする努力までハナから投げてるように聞こえるな、お前は
0601デフォルトの名無しさん
2015/02/25(水) 17:27:02.77ID:kdMsbAelお前は根拠のないことしか言わないの?
0602デフォルトの名無しさん
2015/02/25(水) 17:38:45.61ID:wWqE950b0603デフォルトの名無しさん
2015/02/25(水) 17:42:21.49ID:kdMsbAel事実に基づくそのまま残す方がわかりやすい。
0604デフォルトの名無しさん
2015/02/25(水) 17:56:28.28ID:jNJiSOpZ何を残すかだよ。
gitのログは自分の作業の報告だと思えばいい。
相手に結果だけを報告するか、
あれこれやったんですよ。○○というファイル名にしたんですが
こっちの方がいいんで途中で変えたり、でここでタイポしたんですが
すぐに直しました。途中でコードが重複していたので一つにまとめました。
と、結果に至る作業内容を一つ残らず報告するか。
俺なら、後者を話し出したら途中で遮って「で結論は？」って聞くね。
0605デフォルトの名無しさん
2015/02/25(水) 18:02:06.19ID:8z3MJgH1それこそ、ちょっと席を外すタイミングでもコミットするから
0606デフォルトの名無しさん
2015/02/25(水) 18:03:59.38ID:kdMsbAel俺はそういう人用にtagだけ振ってるね。
履歴消す人はtagって使わないのかな。
0607デフォルトの名無しさん
2015/02/25(水) 18:31:00.18ID:jNJiSOpZえ？ タグでどうやって
意味のあるコミットにするの？
作業履歴としての歴史のブランチがあって、
それを意味がある見せるようの歴史の別のブランチを作った後
それにタグをつけてるわけ？
タグがあるコミットの歴史は、見るためのコミットなんだよね？
あんたタグの使い方間違ってるでしょｗ
0608デフォルトの名無しさん
2015/02/25(水) 18:33:35.99ID:jNJiSOpZ別に作業途中はどうでもいいよｗ
そのあとマージ前とかレビュー前とか
人に見せる時に、最後の結論だけを見せる。
途中にやったことなんて要らない。
もちろん本流にマージするときも、
そんな作業履歴はなくなっている。
でないと、一番重要な本流が
自分ついさっき書いたコードの小さなミスの
修正とかバグの修正とか
必要ない情報で溢れてしまう。
github見ても、大きな所では
作業履歴なんか残ってないでしょ。
0609デフォルトの名無しさん
2015/02/25(水) 18:55:29.97ID:kdMsbAel何言ってんの
0610デフォルトの名無しさん
2015/02/25(水) 19:05:19.85ID:jNJiSOpZ何言ってるのはお前だよ。
あるブランチがあって、
そこに、A、B、C、Dのコミットがある。
レビューする人に見せやすくするために、
意味のないコミットをまとめて
たとえば、A(+C)、B(+D)のように歴史を
まとめましょうって話をしている。
で、タグを使ってどうするわけ？
さっぱりわからんが。
0611デフォルトの名無しさん
2015/02/25(水) 19:30:29.95ID:YonVottM0612デフォルトの名無しさん
2015/02/25(水) 19:36:57.33ID:kdMsbAelそんなんBTS使ってるわ。
0613デフォルトの名無しさん
2015/02/25(水) 19:38:52.38ID:jNJiSOpZ0614デフォルトの名無しさん
2015/02/25(水) 19:39:51.77ID:jNJiSOpZBTS使っても、見せるのはgitのブランチでしょう？？？？
0615デフォルトの名無しさん
2015/02/25(水) 19:41:10.04ID:kdMsbAelBTSでTDDするとかいう発想はできないのか。
開発したことない奴なのかな。
0616デフォルトの名無しさん
2015/02/25(水) 19:43:37.67ID:jNJiSOpZ話がずれていることについて言ってるんだけど？
BTSでTDDすることに何の問題もないよ。
だけど今の話と無関係だろう。
今は、コミットの歴史の話をしている。
0617デフォルトの名無しさん
2015/02/25(水) 19:46:42.04ID:kdMsbAel１つのコミットにまとまってないとレビューできないって結論ありきで言われても話になんないわ。
こいつはもう進歩しないんだろうな。
0618デフォルトの名無しさん
2015/02/25(水) 19:47:06.14ID:jNJiSOpZオープンソースプロジェクト（例 git）の
masterコミットログ見てみ。
そこに、くだらない作業履歴なんか残っちゃいない。
誰だって開発中に小さなミスはするはず。
細かくコミットするのだから、一つの機能追加で
幾つものコミットがあるはずだが
masterのコミットログにはそんなもの残っていない。
もちろん、リリース済み（masterに入ってしまった）
ミスの修正は記録されるが、
masterにマージされるまでの作業履歴は残っていない。
そんなもの必要ないからだ。
0619デフォルトの名無しさん
2015/02/25(水) 19:47:58.10ID:kdMsbAel0620デフォルトの名無しさん
2015/02/25(水) 19:49:05.64ID:kdMsbAel0621デフォルトの名無しさん
2015/02/25(水) 19:51:38.36ID:jNJiSOpZ可能か不可能かの話をしてるんじゃない。
なんでいつもそういう話になるんだ？
可能ならどんなに効率悪くてもいいのかよ？
レビューを"しやすく"って言っただろ。
レビューをしやすくするために、見る必要のない履歴は
無い方がいいだろ。
いちいち報告で、やった内容を全部一から語るのか？
途中で間違えたけど修正しました。って。
そして重要なのは最後。masterにマージされる時
そんなくだらない作業内容は残す必要がない。
オープンソースプロジェクトみろよ。
残ってないだろ。
0622デフォルトの名無しさん
2015/02/25(水) 19:52:19.85ID:jNJiSOpZ> 自分でずらしといて、ずれてるとか戻すとかw
やっぱりBTSが「ずらした内容」だって思ってたんだｗ
0623デフォルトの名無しさん
2015/02/25(水) 19:53:58.79ID:jNJiSOpZクローズドは原則として非公開だから参考にしようがないから。
社内のやり方だけしか知らないと、ガラパゴスになっちゃうよｗ
0624デフォルトの名無しさん
2015/02/25(水) 20:08:13.12ID:17nwZwPi0625デフォルトの名無しさん
2015/02/25(水) 20:10:49.88ID:kdMsbAelその前からずれてるのに気づいてないのか。ほんと主観だけで動いてる人間だな。
>>623
お前に他の技術者とのコネクションがないことは、よくわかった。寂しかったんだな。
>>621
差分をまとめて見ればいい話。
それがコミットというgitの最小単位になってないと出来ないという前提が理解できない。
0626デフォルトの名無しさん
2015/02/25(水) 20:37:55.63ID:mT1+WygHってだけでしょ
0627デフォルトの名無しさん
2015/02/25(水) 20:53:14.73ID:s9t0GhOYVCS運用ポリシーってスレでも立ててそっちでやってくれ
0628デフォルトの名無しさん
2015/02/25(水) 22:05:40.90ID:kOMdcG98いまDにいるなら
git tag tag-for-D
git tag tag-for-A HEAD^^^
でいける
0629デフォルトの名無しさん
2015/02/25(水) 22:17:06.01ID:kOMdcG98「いやいやLinux使わないとか情弱か！」
っていう言い争いと同じだな。
片方のユーザからみたらもう片方側が頭悪すぎワロタに見えるのも同じだろう。
それぞれ大事にしてるものが違うし、
きっとみんながみんな納得いくような単一の結論は出ない。
お互いを改宗させることに努力するより、
同じ宗派の人同士が有意義なGitライフを送れるように情報交換でもしたらどう？
0630デフォルトの名無しさん 転載ダメ©2ch.net
2015/02/25(水) 23:15:48.71ID:yL7bOKNP0631デフォルトの名無しさん
2015/02/26(木) 00:29:40.64ID:EbdO/8ndwindowsしか使えない
それ以外が良い場合もある
と言っているんだから違うだろ。
0632デフォルトの名無しさん
2015/02/26(木) 00:34:46.27ID:kT9/NkZ70633デフォルトの名無しさん
2015/02/26(木) 11:17:42.31ID:rJrYfait両方使える人からみても「Windowsしか知らない人」は馬鹿確定で良いんだよ
「Linuxしか知らない人」は全く居ない訳じゃないけど母数が少ないので微妙
0634デフォルトの名無しさん
2015/02/26(木) 12:02:34.81ID:0ruku8I/> 差分をまとめて見ればいい話。
まとめてみることしか出来ないじゃないかｗ
小さくコミットをまとめるというのは、
要するに大きな機能でも、小さなコミットにまとめられるということ。
なぜ小さなコミットにまとめるのかというと
小さなコミットのほうがコードがわかりやすいから。
その小さなコミットを、全部まとめて大きなコミットにしたら
小さく分ける意味が無いだろｗ
またゴミコミットがあるのも、当然小さく分ける意味をなくしている。
0635デフォルトの名無しさん
2015/02/26(木) 12:08:23.80ID:0ruku8I/> それぞれ大事にしてるものが違うし、
俺が大切にしているのは、
このソフトはどういう修正をして
バージョンを積み重ねてきたかという結果だよ。
リリースもしていないものの作業なんか必要ない。
でもなぜか結果じゃなくて過程を残そうとするやつがいる。
ソースコードに修正履歴を残すのと同じ種類の人間だろうね。
あとから見ても必要にならないものまで残そうとする。
0636デフォルトの名無しさん
2015/02/26(木) 12:35:15.42ID:pCR98cc0>お互いを改宗させることに努力するより、
>同じ宗派の人同士が有意義なGitライフを送れるように情報交換でもしたらどう？
という意見についてはどう思うんだ?
0637デフォルトの名無しさん
2015/02/26(木) 12:42:34.36ID:c8SpDIVp0638デフォルトの名無しさん
2015/02/26(木) 13:03:34.40ID:0ruku8I/改宗させようなんて思っちゃいないｗ
ここを見たその他の人が洗脳されないようにしているだけだ。
0639デフォルトの名無しさん
2015/02/26(木) 13:24:17.25ID:pCR98cc0どんな人が洗脳されるというんだろ。
グループで協力してソフトウェアをつくっている人ならこうするのが当然、
ってお互いに言い合っているように見えるんだけど。
0640デフォルトの名無しさん
2015/02/26(木) 13:52:37.01ID:0ruku8I/バージョン管理ソフトなんだからバージョンを管理するのに
必要な情報のみを入れましょうといってる俺と、
なぜか過去の作業報告書を兼ねて、必要ない修正まで記録して
バージョンごとの違いを見難くしましょうと言ってる人の違い。
作業報告書なら別に管理しろよ。
それがgithubでいうならば、Issueやプルリクなんだが。
第一コードの履歴だけじゃ作業報告にもならりゃしない。
Issueやプルリクなら日本語で書かれた経緯が記録される。
0641デフォルトの名無しさん
2015/02/26(木) 14:15:15.10ID:ScTUDd1D人が作業した内容をコミットの仕事
タグだけをみりゃあいい
何も全部のコミットをみなくていいだろ
0642デフォルトの名無しさん
2015/02/26(木) 14:20:23.62ID:s5JPbxDvまたおまえかｗ
タグは特定のコミットに名前をつけるだけだぞｗ
そのタグの履歴を見たら、
まー、ごみだらけで、何やってるか意味不明。
そんなコミット使い物にならねぇ。
なくすべきだね。
そして不要な情報のない正しいコミット履歴を
持ったものにタグをつける。
完璧♪
0643デフォルトの名無しさん
2015/02/26(木) 14:22:54.05ID:s5JPbxDv★タグ 1.0
・ちょっと修正
・さっきの間違えた
・○機能仮実装
・リファクタリング
・○機能ミス修正
・おっと最初の修正のタイポ修正だ
・バグ修正
★タグ 1.1
ほらね。何をやってるのかさっぱりだｗ
0644デフォルトの名無しさん
2015/02/26(木) 14:42:02.65ID:pCR98cc0「必要ない修正まで記録してバージョンごとの違いを見難くしましょうと言ってる人」に
洗脳される人が出ないように啓蒙活動をしているということか?
そんなので洗脳される人がいるとは思えないけど。
0645デフォルトの名無しさん
2015/02/26(木) 15:37:43.43ID:xcIprWeJ洗脳される人が出ないように必死に啓蒙活動している変な奴が少数いて
そいつが騒いで迷惑かけてるということか。やれやれ。
0646デフォルトの名無しさん
2015/02/26(木) 19:35:29.87ID:EbdO/8ndお前はそんな意味のわからないタグしかつけてないのか?
>>636
履歴をまとめる人は唯一神しか認めてない。
それ以外が良い場合もあるという人は、唯一神を含め八百万の神を認めている。
前者が変わらないとどうしようもない。
0647デフォルトの名無しさん
2015/02/26(木) 19:42:03.41ID:cGnKpNs30648デフォルトの名無しさん
2015/02/26(木) 19:57:45.91ID:s5JPbxDv> お前はそんな意味のわからないタグしかつけてないのか?
お前タグの付け方間違ってるんじゃね？
普通はリリースしたバージョンに対してつけるものだ。
gitだとこうだな。 https://github.com/git/git/tags
お前が言うタグはどういうものか
それと同じ使い方をしている例をgithubでもなんでもいいから
探してきてくれ。
0649デフォルトの名無しさん
2015/02/26(木) 19:59:05.68ID:s5JPbxDv0650デフォルトの名無しさん
2015/02/26(木) 20:23:59.37ID:EbdO/8ndそれはリリースタグという、タグの一種でしかない。
お前がガラパゴスのイグアナだったな。
0651デフォルトの名無しさん
2015/02/26(木) 20:25:20.59ID:s5JPbxDv0652デフォルトの名無しさん
2015/02/26(木) 22:57:34.06ID:wcxWcVKQふむ。これをどんなふうに綺麗にするんだ？
作業途中の一時的なcommitのことかと思ってたけど、後から見つかったバグやタイポの
修正なんかもということになると話が違ってくるな。
0653デフォルトの名無しさん
2015/02/27(金) 04:26:54.32ID:2fOguya90654デフォルトの名無しさん
2015/02/27(金) 11:41:41.56ID:qn8r0NuBリリース前か、リリース後かだよ。
リリース前ならrebaseするべき。
リリース後ならできない。
ここでいう「リリース」の定義は、みんなで
共有しているブランチにマージされた時。
マージされてないならrebaseして、
マージした後の共有ブランチはみんなが見るのだから
見やすくするのがいい。
0655デフォルトの名無しさん
2015/02/27(金) 11:42:46.84ID:qn8r0NuB> みんなが自分と同じやり方じゃなきゃヤダー、とワガママ言ってる害虫が一匹消えれば済む話だな。
というか、一般的なやり方を見習えばいいだけだよ。
他の人のやり方は、オープンソースプロジェクトを見ればいいんだから
参考にするべきものがないってことは無いはず。
0656デフォルトの名無しさん
2015/02/27(金) 12:00:40.29ID:qn8r0NuBgit bisectの問題をどうやって解決するわけ？
0657デフォルトの名無しさん
2015/02/27(金) 13:10:52.50ID:zjr7XITY身内に変なのがいたらそいつに直接オレオレルールを叩き込めばいいだけじゃねえの
0658デフォルトの名無しさん
2015/02/27(金) 16:24:47.33ID:vP93htBG0659デフォルトの名無しさん
2015/02/27(金) 16:53:17.23ID:qn8r0NuB一般的なルールだって言ってるだろｗ
gitの基本的な使い方だよ。
0660デフォルトの名無しさん
2015/02/27(金) 17:08:09.39ID:zjr7XITY0661デフォルトの名無しさん
2015/02/27(金) 20:15:42.29ID:QLxLlF4F> 一般的なルールだって言ってるだろｗ
お前にとっては
だろ？
> gitの基本的な使い方だよ。
勝手に決めるな、ボケ
0662デフォルトの名無しさん
2015/02/27(金) 20:21:22.73ID:zjr7XITY0663デフォルトの名無しさん
2015/02/27(金) 20:26:55.17ID:2fOguya9自分が見てるものだけを持ち出して一般的って何だよ。
その理論だと、やり方はひとつのみが正しいということにならないか。
まあ、お前がやってない一般的なやり方は屁理屈つけて、例外とされるんだろうけどな。
0664デフォルトの名無しさん
2015/02/27(金) 20:57:44.76ID:ecUd+uRQ開発する上で都合の良い方法をその人たちで決めればいいことだろ
チームに変な奴がいるんならここでやらずにそいつを説得すべきだし、「俺の思う正しい使い方」を啓蒙したいんだったらQiitaにでも行ってくれ
0665デフォルトの名無しさん
2015/02/27(金) 23:16:10.22ID:0rXS1k1Wうん、だから、リリース後のコミットが>>643のようにならないようにするために
どう「コミットを綺麗に」すると言っているんだろう？
まさか、すべてのバグを出し切るまでリリースすべきじゃないとか？
0666デフォルトの名無しさん
2015/02/27(金) 23:43:44.73ID:3vgt2owk0667デフォルトの名無しさん
2015/02/28(土) 00:31:26.07ID:NODjEs0Yそいつがオレのやり方
0668デフォルトの名無しさん
2015/02/28(土) 02:45:52.64ID:j2d9gp8Y0669デフォルトの名無しさん
2015/02/28(土) 06:58:11.35ID:rF9gi1YF下っ端で聞いてもらえないから、ここて言ってるだけかもだけど。
0670デフォルトの名無しさん
2015/02/28(土) 07:02:32.75ID:Mpa44gki0671デフォルトの名無しさん
2015/02/28(土) 11:13:43.53ID:0J8+8Slxそれで君が見ているものは何なんだ？
まさか、自社限定の井の中の蛙とか？
もっと広い世界を見ようぜ。
それが一般的というものなんだからさ。
例として、gitのやり方を見てみよう。
https://github.com/git/git/commits/master
どんな機能が追加されたのかわかりやすい。
0672デフォルトの名無しさん
2015/02/28(土) 11:50:04.81ID:ZxxxP0A6レビュー前提である程度まとめてコミットした方がいいし、
ゲームとか、レビューが現実的じゃないケースで
バグったら洒落にならんもんなら細かい方がいいんじゃないの。
0673デフォルトの名無しさん
2015/02/28(土) 12:13:36.38ID:0XiMknGf修正の修正はどっちのケースでもまとめてあった方が後から読みやすいと思うが
それを無駄・有害・有用のどれにとるかはPLの好み次第
0674デフォルトの名無しさん
2015/02/28(土) 12:23:48.66ID:Fo4WfMm10675デフォルトの名無しさん
2015/02/28(土) 13:08:09.13ID:1GqpuynKgit request-pull
0676デフォルトの名無しさん
2015/02/28(土) 13:14:50.76ID:ZxxxP0A6複雑なシステムだと意図通り動くとは限らないよ
0677デフォルトの名無しさん
2015/02/28(土) 13:48:17.58ID:rF9gi1YFそうじゃないよ。
自分の見ているものが絶対と思っているかどうかの違いだ。
ホント救いようないな。
0678デフォルトの名無しさん
2015/02/28(土) 17:50:22.20ID:qDsQcJHpgit rebase -i HEAD~20でエディット画面になりますが
修正したいログのpickをeditに書き換えて保存して終了後、git commit --amendでまたエディット画面になるので修正してgit rebase --continueをするんですが
20個もやってられないので、最初のgit rebase -i HEAD~20ときに立ち上がるエディット画面のところでまとめてログを書き換える方法を教えてください
0679デフォルトの名無しさん
2015/02/28(土) 18:07:46.23ID:Mpa44gki0680デフォルトの名無しさん
2015/02/28(土) 19:47:26.42ID:0J8+8Slx一般論はどうでもいいよｗ
自分が見ているもの＝さまざまなプロジェクトが
俺の言ってるとおりになっているんだが。
0681デフォルトの名無しさん
2015/02/28(土) 19:54:48.06ID:qDsQcJHpそれだとブランチを変えてもコミットログを20個編集するために
commit --amend
rebase --continueを20回やるのには変わらないと思うんですが・・・
0682デフォルトの名無しさん
2015/02/28(土) 20:14:15.86ID:b3fgjTUc「俺の言ってるとおり」っていうのはどのレスのことなんだろう。
もしあんたが ID:s5JPbxDv ID:qn8r0NuB ならとりあえず>>665に答えてくれんか。
0683デフォルトの名無しさん
2015/02/28(土) 21:31:24.89ID:rF9gi1YFそれしか見てないなら、他のを批評するのは何故か。
俺は他のパターンも見てるし、
そのやり方でコストが割に合ってないのも見てる。
0684デフォルトの名無しさん
2015/02/28(土) 22:27:13.82ID:HNTVjZlmエディット画面で
pick ハッシュ メッセージ
exec git commit --amend -m'新しいメッセージ'
って言う風にexecを使えばまとめてできそう
http://qiita.com/yuku_t/items/fed530acb97385ecbeee
ちなみにコミットメッセージを書き換えるだけならeditよりrのほうが楽だよ
0685デフォルトの名無しさん
2015/03/01(日) 01:32:38.05ID:XRCWDhmX履歴を削除したいです。
1,2,3,4,5があったとして、
5だけ残したいです。
やり方を教えていただけないでしょうか？
0686デフォルトの名無しさん
2015/03/01(日) 10:32:38.67ID:Lvi8ZCHX20個前のコミットのメッセージを1個書き換えるだけじゃなくて20個全部書き変えたいってことでいい？
git commit は-Fでエディタを立ち上げずにコミットメッセージを書いたファイルを指定できるから予め20個編集済みのファイルを用意しとくか、
既存のメッセージを機械的に書き換えられるなら git showのオプションを調整してログメッセージだけ表示させたやつを
perlなりsedなりで書き換えた後git commit -F - --amend にパイプで食わせるようにするとかで一気に行けそうだが。
0687デフォルトの名無しさん
2015/03/01(日) 10:50:10.22ID:Lvi8ZCHX0688デフォルトの名無しさん
2015/03/01(日) 13:53:52.15ID:odvvrg+G検証できるもので語ろうよｗ
検証できない事だと嘘付いても調べようがないからね。
それを利用して、さも自分が知っている秘密の世界（笑）では
自分の都合のいいことが起きているという。
でも科学の世界では第三者が検証できなければ意見としてみなされない。
だから検証できるものを出すのが重要。
俺は出した。git本家のリポジトリだ。
君はなにか出したかね？ 信用される行動を取りましょう。
0689デフォルトの名無しさん
2015/03/01(日) 13:55:38.63ID:Sga1DM1F一理ある
0690デフォルトの名無しさん
2015/03/01(日) 14:02:41.32ID:gGwPkrj1では、それが一般的というのを立証してください。
0691デフォルトの名無しさん
2015/03/01(日) 14:15:17.53ID:odvvrg+G立証方法は数でいいかな？
より多くのプロジェクトでやっているやり方が
より一般的である。
この定義は問題ないだろう。
今のところgitという例がひとつ出た。
反対意見のプロジェクトは0だから
今の所一般的なのはgit風である。
反対プロジェクトが出たら、また一つ探してくることにするよ。。
0692デフォルトの名無しさん
2015/03/01(日) 14:21:22.22ID:gGwPkrj1いくら数を挙げようと母集団の数が不明なので一般的かどうかわからない。
そんなの語るなよ。
ということになる。
0693デフォルトの名無しさん
2015/03/01(日) 14:22:48.73ID:gGwPkrj10694デフォルトの名無しさん
2015/03/01(日) 14:24:45.39ID:odvvrg+Gじゃあ、検証可能でもっといい方法があったら
それに変更することにするよ。
それまでは、より多くのプロジェクト（誰でも検証可能なものに限る）で
使われている方が一般的という定義にしておくね。
あ、仮だから、仮。
文句ばかり言って、何もだいたい手段を言わない人を
黙らせるための仮の定義だからね〜。
0695デフォルトの名無しさん
2015/03/01(日) 14:25:03.53ID:xRGCCXFw0696デフォルトの名無しさん
2015/03/01(日) 14:32:47.00ID:M4V41Yry「ほら、gitも俺の主張するやり方してるだろ？」と言われても、その「俺の主張するやり方」が
よくわからないんだが。
>>643と>>671の決定的な違いと考えている点は何？
commit直後に修正入れるようなみっともないことしないよう、ちゃんとデバッグしろということ？
0697デフォルトの名無しさん
2015/03/01(日) 14:33:18.51ID:gGwPkrj10698デフォルトの名無しさん
2015/03/01(日) 14:36:02.18ID:gGwPkrj1より多くのプロジェクトで使われてるやり方がいいとか。
0699デフォルトの名無しさん
2015/03/01(日) 14:36:18.63ID:odvvrg+G> commit直後に修正入れるようなみっともないことしないよう、ちゃんとデバッグしろということ？
コミットはこまめにやるべきだから、ちゃんとデバッグしなくてもいいというか
事実上できないよ。
その代わり、ちゃんとデバッグしてからmasterなり
他人に公開しているブランチにマージする。
こまめにやったコミットをデバッグして、
問題があったらもちろんrebaseして、
きれいなコミットにしてからマージする。
それがgitなどの多くのプロジェクトで極普通に行われている方法。
0700デフォルトの名無しさん
2015/03/01(日) 14:38:01.87ID:odvvrg+Gそれぞれの環境にあったやり方はあるだろう。
例えば、ソースコード管理をせずに
ソースコードに修正履歴のコメントを書く
という環境もあるだろう。
そういう環境があることを否定しているのではなく、
より良い環境とは何か？というのを
多くのプロジェクトをみて学びなさいということ。
0701デフォルトの名無しさん
2015/03/01(日) 14:38:45.42ID:gGwPkrj1より良いって何だよ。オマエの自己満足だけだろ。
0702デフォルトの名無しさん
2015/03/01(日) 14:39:59.34ID:gGwPkrj1オマエの言う方法が絶対的に良いのなら、何故他の方法を取れるような実装になっているのだと思う?
0703デフォルトの名無しさん
2015/03/01(日) 14:50:02.94ID:M4V41Yryあぁ、もちろん、commitというのは公開するcommitのつもりで書いた。
>>699の内容はおおむね理解できる。結局のところ>>643と>>671の違いは、共有する
branchにマージする前にちゃんとデバッグしたかどうか、ということでいいんだね？
0704デフォルトの名無しさん
2015/03/01(日) 14:50:29.67ID:gGwPkrj1586 デフォルトの名無しさん sage 2015/02/25(水) 00:05:08.53 ID:Wo4XdcUv
>>584
結局のところは、最終的に履歴がキレイに見えればいいわけで。
自分が会社でSVNを使ってた時は、
1. 自分の修正の途中経過を保存しておけるローカルのSVNのリポジトリで作業して、
2. ちゃんと動くようになったら、他人に見せれるキレイなコードに直して、
3. キレイなコードを会社のSVNにコミットしてた。
Gitはそれが一連の流れとしてできるわけでしょ？
なぜGitの良さを殺して開発効率が悪くなる方向に向かうのかが分からない。
0705デフォルトの名無しさん
2015/03/01(日) 14:57:42.12ID:lheYQzbzまずコミットをまとめる派の意見
git init
touch a
git add a
git commit -m "Initial commit"
git checkout -b testbranch
touch b
git add b
git commit -m "add b"
touch c
git add c
git commit -m "add c"
このあと何をしてコミットをまとめるのかおしえてくれ
0706デフォルトの名無しさん
2015/03/01(日) 17:51:56.32ID:DwkMIW7d0707デフォルトの名無しさん
2015/03/01(日) 19:03:16.52ID:WF1g/fUFより完璧にバージョン管理する方法とか、手続きにとらわれすぎて可哀想。
0708デフォルトの名無しさん
2015/03/01(日) 19:24:04.81ID:1tKuG656スカッシュしようｚ
0709デフォルトの名無しさん
2015/03/01(日) 20:58:42.01ID:Lvi8ZCHX俺もあの考え方をベースに単純化して運用してる。
0710デフォルトの名無しさん
2015/03/01(日) 21:33:37.81ID:odvvrg+Gその例じゃわかりづらいだろｗ
まずmasterブランチがあるとする。
そのmasterを元にAさんがある機能を作るとする。
git checkout master // masterにいる
git checkout -b new_feature // 新しい機能作成
そのブランチで開発をする。
touch new_class && vi new_class
git add new_class
git commit -m 'add new_class' # new_classを作成
vi existing_class
git add existing_class
git commit -m 'improve existing_class' # 新機能追加のために、既存のexisting_classクラスを拡張
vi new_class
git add new_class
git commit -m 'fix new_class' # existing_classを書いている時に、new_classにバグや修正やタイポが発覚して修正した
git checkout master
git merge new_feature # 新機能をmasterにマージ
この時のmasterのコミット履歴がこんなふうになったってしょうがないってこと。
* Merge new_feature
- fix new_class (新クラス完成版）
- improve xisting_class (既存クラスの拡張）
- add new_class (バグがある新クラス）
0711デフォルトの名無しさん
2015/03/01(日) 21:34:46.93ID:odvvrg+G2つのファイル作成で成り立つ機能を1週間かけて作る。コミットはこまめにする。
その1週間の作業で間違えることなく完璧に作業していればこれだけで良くなる。
new_featureブランチ（rebase版）
- add new_classB (新クラスBの追加）
- add new_classA (新クラスAの追加）
- improve existing_class2 (既存クラス2の拡張）
- improve existing_class1 (既存クラス1の拡張）
だが1週間かかるような仕事をミスせずにやれる人はいなし
理想的な順番で修正できる人も居ないので、作業履歴的にはこうなる。
new_featureブランチ（全部履歴残す版）
- fix existing_class1
- fix new_classB
- fix existing_class2
- fix new_classA
- fix new_classA
- fix existing_class1
- fix new_classB
- fix existing_class2
- fix new_classA
- fix existing_class1
- add new_classB (新クラスBの追加）※この時点ではバグあり
- fix new_classA
- fix existing_class1
- improve existing_class2 (既存クラス2の拡張）※この時点ではバグあり
- fix existing_class1
- add new_classA (新クラスAの追加）※この時点ではバグあり
- fix existing_class1
- improve existing_class1 (既存クラス1の拡張）※この時点ではバグあり
0712デフォルトの名無しさん
2015/03/01(日) 21:35:36.94ID:odvvrg+G他人が結局何をしたのか？なんて把握できるわけがないし、
squash等で全部まとめてみるという考えもあるがそうすると
new_featureブランチ（squash版）
- existing_class1 + existing_class2+ new_classA + new_classB (新クラスA,Bの追加と既存クラス1,2の修正）
diffの内容＝new_classBとnew_classA とexisting_class2とexisting_class1の
修正内容を一度に全部まとめてみることになる。
既存クラスの拡張が、単純な関数の追加だけならまだわかるけど、
それぞれいくつかの既存の関数の修正だと、
全部まとめてみると、二つの独立した機能拡張をまぜて見ないといけなくなる。
小さな修正を見るよりも、大きな修正を見るほうが大変なのは言うまでもない。
で、もちろん、new_featureブランチ（全部履歴残す版）のようなものをmasterに入れることはない。
入れると、git bisectで問題箇所を調べるときの障害にもなる。
（使ったことある？ 二分探索で自動的にコミットをチェックアウトしてバグを調べる機能）
ブランチの段階でプルリクエスト（レビュー依頼）する。
もちろんレビュー依頼をするときには、rebaseしておく。
そこでまた修正があるとしたら、途中もしくは最後にrebaseしてからマージ
有名なプロジェクトをみても途中の作業履歴が残っていないので
それが一般的であるとうことがわかる。
0713デフォルトの名無しさん
2015/03/01(日) 21:37:40.19ID:odvvrg+G> プログラムなんて完成させりゃいいのに、
> より完璧にバージョン管理する方法とか、手続きにとらわれすぎて可哀想。
その考えもわかるけど、それだとsquashするほうがまだましだだから
どちらにしろ履歴は残さないよ。
0714デフォルトの名無しさん
2015/03/01(日) 22:02:54.92ID:IMZWcmr0まって、俺初心者だからそのあとのコミットのまとめかたをおしえて
実際に打って確認しないとどっち派がいいのか判断できない
態度がでかい初心者で申し訳ないが重用なのでたのむ
0715デフォルトの名無しさん
2015/03/01(日) 22:14:43.93ID:Lvi8ZCHXbisectについて補足する。
「new_featureブランチ（全部履歴残す版）」だと
bisectが止まったコミットが本当にmasterのHEADに影響してるか信頼できない。
(bisectが止まったコミットを調べて原因発見したと思っても、
後の修正コミットで何度も試行錯誤されて変更されたりしてると、
最終的にHEADで問題を引き起こしてる原因とは違ってたなんてことがおこる)
逆にトピックブランチのコミットを全部ひとつにスカッシュしてしまうと
bisectで止まったときに見ないと行けない変更量が必要以上にでかくて調べるのが面倒。
「new_featureブランチ（rebase版）」くらいの
ひとつひとつは意味のある単位で、かつできるだけ小さい粒度の複数のコミット
にまとめるのが妥当な落とし所って感じ。
もちろんbisect以外に「あのトピックでどうなってたっけ？」みたいに見直すだけの時も、
そのトピックの成立がわかりやすいストーリーになってるほうが読み解くのに効率が良い。
(むしろこっちのほうがシチュエーションとしてはよくある)
0716デフォルトの名無しさん
2015/03/01(日) 22:15:59.98ID:odvvrg+Gまとめること自体は、rebaseだよ。
git rebase -i （編集を開始したいコミット）
ってやればエディタが表示される。
そこで順番を並び替えたり
まとめたりするものを選ぶだけ。
ただ、ここでコンフリクト起きたりすると
それを解消するのに時間がかかって本末転倒になるから、
コミットはほんとうに小さく分けてこまめに整理しながらやること。
あと大きな機能は小さな機能に分割してリリースすることだね。
ただしちゃんとした設計ができてないと、あとから大幅に変更することになって
最悪コードやレビューがムダになりかねないから、
小さな機能でもリリース（master等の共有ブランチにマージ）するなら
しっかり作りこまないといけない。
基本は小さく作ることだよ。そうすればコミットをまとめるのも楽になる。
0717デフォルトの名無しさん
2015/03/02(月) 01:36:08.77ID:Hi7dFbSg0718デフォルトの名無しさん
2015/03/02(月) 12:18:20.70ID:D9yRCRO6彡ﾊヽヽミ （｀・ω・´ ） ブゥーチッブゥーチッ♪
（ ´・ω・｀） .／ >‐ 、-ヽ ペーペケッペッペペーペーペペ♪
/ ヽ /丶ﾉ､_。.ﾉ ._｡） ブゥーチッブゥーチッ♪
/ / ヽ| → 〈 、〈Y ,ーiｰ〈ト ペーペケッペッペペーペーペペ♪
（_二つ ） .＼_ξ ~~~~~~Y
| イ |＿＿/＿_|
| l⌒ヽ ヽ |、,ﾉ | ､_ﾉ
結 果 に コ ミ ッ ト す る ラ イ ザ ッ プ
＿＿＿＿＿＿＿＿＿＿＿＿＿ ＿＿
┃ライザップ | |検索|←をｸﾘｯｸ!!
0719デフォルトの名無しさん
2015/03/02(月) 16:26:14.86ID:gM8IX5Rj企業なんかではうまく行かない。
0720デフォルトの名無しさん
2015/03/02(月) 17:22:43.92ID:EtBBafF00721デフォルトの名無しさん
2015/03/02(月) 18:26:22.01ID:zSbcYqf6> 有名なプロジェクトをみても途中の作業履歴が残っていないので
> それが一般的であるとうことがわかる。
オープンソースとか参考にしている時点で、レベル低すぎて話にならん
>>719
> まだ主観をルール化しようとしてる奴がいるのか。
> 企業なんかではうまく行かない。
それがわからない、一本道真理教がキコキコ三輪車漕いでるっぽい
0722デフォルトの名無しさん
2015/03/02(月) 23:15:51.93ID:dTBqd0rI一本道真理教だとか、キコキコ三輪車だとかが、必ずしも悪いわけじゃないんだけどね
プロジェクトにいる技術者のレベルが低い場所では、そういうやり方の方がうまく行く場合がよくある
0723デフォルトの名無しさん
2015/03/02(月) 23:54:14.33ID:EtBBafF0> オープンソースとか参考にしている時点で、レベル低すぎて話にならん
gitを作ってるgit本家もオープンソースですよ（笑）
何を勘違いしているのか。
むしろ参考にするべきものだ。
社内のオレオレルールを一般的と勘違いしているのかね？
それともうちは馬鹿ばかりだからgitを使うことで精一杯。
正しい使い方ができるレベルにないって話かね？
0724デフォルトの名無しさん
2015/03/03(火) 00:44:29.63ID:MRrEf2ESどっちが上とかそういう問題ではなく。
0725デフォルトの名無しさん
2015/03/03(火) 01:13:52.24ID:/le7LDNvその理由が全く述べられてないのが問題。
だから説得力が全くない。
0726デフォルトの名無しさん
2015/03/03(火) 01:15:51.42ID:/le7LDNvそれならそもそもgitを使わないほうがいいんじゃないですかね？ｗ
0727デフォルトの名無しさん
2015/03/03(火) 01:42:06.19ID:E+oz4UV1馬鹿「社内の開発はオープンソースとは違う！」
みんな「それで？」
馬鹿「え？」
みんな「え？じゃなくて、何が違うの？」
馬鹿「オープンソースとは違う」
みんな「いや、違うのは分かったから、何が違うの？」
馬鹿「・・・」
みんな「違うは違うだろうけど、それがどうgitの使い方に影響を与えるの？」
馬鹿「・・・」
みんな「社内の開発は、オープンソースとは違うから、こうするべきだっていいたいんだよね？」
馬鹿「・・・」
みんな「なにか言おうよ？明確な理由があるんでしょ？」
馬鹿「り、履歴は全部残すべき」
みんな「だからさぁ。その理由を言えって」
馬鹿「社内はオープンソースとは違う。」
みんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」
馬鹿「違うから、残すべき！」
みんな「だからその理由は？」
馬鹿「オープンソースを参考にしている時点でレベルが低い！」
みんな「だめだこいつ。話にならない。」
0728デフォルトの名無しさん
2015/03/03(火) 01:47:09.05ID:MRrEf2ESあなたが、gitをオープンソース開発の手法専用にしか使えないのならそうだろう。
まあ、いくつも使い方があると混乱してしまう人も居るから、手法ごとにツールを変えるのもひとつの手だよね。
0729デフォルトの名無しさん
2015/03/03(火) 01:51:36.20ID:dPTRZFO0>>727の続きですか？
馬鹿「gitはオープンソース開発の手法専用ではない！」
みんな「うん、で、どんな手法で使っているから、履歴は残すべきってなるの？」
いつもの手だね。否定するだけしてじゃあどうするのか？の答えが全くない
言われたことに「それは違う」というだけの簡単なお仕事ｗ
0730デフォルトの名無しさん
2015/03/03(火) 01:56:12.15ID:MRrEf2ESあなたがわからないなら説明してもいいが、両方経験したことある人は大抵わかるんじゃないかな。
例えばある日、開発を行ってたAさんが交通事故にあった。Bさんが引き継ぐことになったが、やりかけのチケットが意味のあるコミットになってないからと共有されてなかった。
オープンソースなら、なかったものかそもそも気付かれずに、他の人がやるだろう。
社内ならそれには社のリソースを使っていたのだから、共有されているべきだ。
ストレージを共有するとか他の手段もあるが、gitで共有するのもひとつの手段だ。
0731デフォルトの名無しさん
2015/03/03(火) 01:56:52.85ID:2hZYgmelなんか、ファイルコピーを利用した履歴保存テクニックとか
エクセルで作る仕様書講座。みたいな臭いがするなｗ
専用に作られたものを使わずに、今の俺が知ってるのがこれだけだからという
消極的な理由で、適していない道具を使って無理やりやろうとする。
より良い方法を調べて改善していこうよ。それともそれをしないのが
（あんたの）社内の伝統なのかな？
必死で主張しているあなたの"社内"が透けて見えるね。
0732デフォルトの名無しさん
2015/03/03(火) 01:57:42.96ID:MRrEf2ESその話じゃないよ。馬鹿乙。
0733デフォルトの名無しさん
2015/03/03(火) 02:02:40.38ID:MRrEf2ES会うこともない数万人が見るものと、
席を隣にしてる数人が見るものを、
同じ方法でコストも含め同じく良い結果が得られるの?
0734デフォルトの名無しさん
2015/03/03(火) 02:03:35.72ID:2hZYgmel> 例えばある日、開発を行ってたAさんが交通事故にあった。Bさんが引き継ぐことになったが、やりかけのチケットが意味のあるコミットになってないからと共有されてなかった。
それはプッシュすればいいだけの話だが？
git使ってるならコミットは毎日よりも短いタイミングで行ってる。
もしかしてコミット＝プッシュと勘違いしている？
コミットを共有リポジトリにプッシュすればいいだけの話で、
過去の意味のない履歴を残す理由にはなってないよ。
プッシュした後も、そのブランチが個人のものならrebaseできるし
してもいいってわかってるかな？
リモートの誰からも見える個人の情報をプッシュするのと
（リモートにある）共有されたブランチにマージするのは別の話。
交通事故〜の話なら、個人のリモートブランチ（またはリポジトリ）にプッシュすれば十分。
そしてこれは履歴を残す話とは全く関係ない。
わかってるのかな？
0735デフォルトの名無しさん
2015/03/03(火) 02:05:10.00ID:2hZYgmel違うと主張したいのなら
「違う」と言うだけではなく、
その理由を書くように
0736デフォルトの名無しさん
2015/03/03(火) 02:11:11.03ID:2hZYgmel「どんな場合でもpushしたものはrebaseしたらいけない。」という
gitを中途半端に学習した初心者の間違った理解っていうものを
ひしひしと感じるね。
0737デフォルトの名無しさん
2015/03/03(火) 02:13:42.82ID:MRrEf2ESオープンソース開発で個人のブランチを共有するの?
0738デフォルトの名無しさん
2015/03/03(火) 02:14:17.63ID:2hZYgmelsubversionはコミット＝プッシュだから、
「作りかけだからプッシュしない」と考えるようになる。
gitだと作りかけでプッシュしても、後から直せるから
どのタイミングでもプッシュっ出来るんだよ。
0739デフォルトの名無しさん
2015/03/03(火) 02:16:33.03ID:MRrEf2ESわからないのに知りたいなら、
教えてください、お願いします。だろが。
なんで馬鹿様基準で書くと思ってるんだ。
0740デフォルトの名無しさん
2015/03/03(火) 02:16:51.79ID:2hZYgmelオープンソースとか関係なく、他人に見せるべき情報なら共有するが？
githubの例で言えば、オリジナルのリポジトリを
個人がフォーク（これは共有される）して
ブランチを作ってプルリクエストを送る。
もちろんしたくないなら、ローカルで作業しても構わないが、
少なくともプルリクの段階では、個人リポジトリに作った
個人のブランチを共有することになる。
0741デフォルトの名無しさん
2015/03/03(火) 02:18:16.14ID:7ibvECcgいえ、知りたくありません。
だって反論はここにない方が
私にとっては都合がいいですから（笑）
0742デフォルトの名無しさん
2015/03/03(火) 02:37:55.45ID:MRrEf2ESうん、経験のある多くのやつはわかってると思うから、わからない奴は黙ってればいいよ。
0743デフォルトの名無しさん
2015/03/03(火) 02:39:35.46ID:MRrEf2ES見せたい、見せたくないに関わらず、社のリソースを使ってやってることだから見せるってこと。
0744デフォルトの名無しさん
2015/03/03(火) 03:11:03.14ID:7ibvECcgそのセリフはみんなから「あぁ、言い返せないんだ」って思われるだけですよｗ
「反論意見はない」
あなたも私も両方が満足する答えでだからこれでいいと思います。
>>743
はい、見せればいいと思いますが？
ちなみに世の中にはこんな人がいるかもしれませんね。
「赤ペンで添削された報告書をそのまま出す人」
いわく。修正した過程が重要なんです！
0745デフォルトの名無しさん
2015/03/03(火) 03:25:27.82ID:MRrEf2ESわかってる人からは、なんでそんな馬鹿な質問してるんだろうと思われてるよ。
0746デフォルトの名無しさん
2015/03/03(火) 03:26:49.98ID:MRrEf2ES作業量を評価する時に試行錯誤を評価する場合がある。
コミット量のグラフとか見たことないか?
0747デフォルトの名無しさん
2015/03/03(火) 03:32:46.41ID:7ibvECcgだといいですねｗｗｗ
思っていることは想像
事実をだけを見れば「反論理由はない」
あなたも私も満足する結論ですｗ
>>7466
> コミット量のグラフとか見たことないか?
githubにあるやつですね。gitlabにも最近つきました。
で、それがどうかしたんですか？
あーわかった。rebaseすると、コミット量が減ると思っってるんですね。
それはマヌケです。
0748デフォルトの名無しさん
2015/03/03(火) 03:34:40.93ID:7ibvECcgfix typo
fix typo
fix typo
というコミット数の水増しで
評価を水増しできる会社で働きたいですｗ
0749デフォルトの名無しさん
2015/03/03(火) 03:51:13.37ID:MRrEf2ES0750デフォルトの名無しさん
2015/03/03(火) 03:52:37.28ID:MRrEf2ES0751デフォルトの名無しさん
2015/03/03(火) 03:55:23.75ID:7ibvECcg説明が必要なものなら、コミットログ
（場合によってはソースコード）に書けば？
fix typo
fix typo
fix typo
fix typo
のようなコミットに説明が必要だから残さないといけないと
いう考えがわからない。
全部残す or 全く残さない
の二元論になってるね。
考えているようで全く何も考えてないよね。
必要か必要でないかを考えないで
全部残しておくなら、馬鹿でもできるもの。
0752デフォルトの名無しさん
2015/03/03(火) 03:57:39.57ID:7ibvECcg間違って直したものも含めてやったこと全てを
報告したら怒られました。何が行けないんでしょうか？
みたいなレベルで仕事している人いるのかなぁ？＿
報告は必要な物を簡潔にでしょ？
0753デフォルトの名無しさん
2015/03/03(火) 04:52:02.58ID:MRrEf2ES0754デフォルトの名無しさん
2015/03/03(火) 06:49:47.01ID:gtrHHVSl「おーしおまえら、帰宅前は作業中の状態でもいいからコミットしてリポジトリにプッシュしとけよ。
でもマージ依頼するときはちゃんとコミット整理してからな」
で終わる話だった。
0755デフォルトの名無しさん
2015/03/03(火) 07:24:17.62ID:QODsipDBそれ、残さないとしたらどうやるの？
0756デフォルトの名無しさん
2015/03/03(火) 08:05:07.45ID:t8TD3w310757デフォルトの名無しさん
2015/03/03(火) 08:30:26.65ID:gtrHHVSl公式ドキュメントのチュートリアルとrebaseのman(特に -i 関連)を10回くらい読んでから
>>710 からの流れを10回くらい読め
0758デフォルトの名無しさん
2015/03/03(火) 08:47:18.20ID:QODsipDBその関係あるかないかわかんないfixを全部ひとつのcommitにまとめちゃうの？
0759デフォルトの名無しさん
2015/03/03(火) 09:00:37.58ID:5uN1b58Uタイポした元のコミットとまとめて、機能変更の履歴としては不要なタイポしたというログをなくす
0760デフォルトの名無しさん
2015/03/03(火) 09:15:53.35ID:QODsipDBたいがい後から見つかるものじゃない？
その場合は>>761のままでいいってこと？
0761デフォルトの名無しさん
2015/03/03(火) 10:04:18.64ID:7ibvECcgテストしてリリース（レビューも終わって共有しているブランチにマージ）して
しまったものは仕方ないよ。 その歴史は改ざんできない。
だけど、バグやタイポっていうのは確かに後から見つかるが、
ずっとあとではなく、より近い未来の方が見つかる。
修正した所にバグが発生するのだからね。
だからリリースよりも前に見つかる物の方がより多い。
その多い問題を直すことが出来るし、直した方がいいという話をしている。
ちなみに、
> その機能変更がまだローカルだったらそれでいいけど
共有と公開は違う。
1. ローカルは非公開
2. 公開は他の人が参照できるリモートリポジトリやブランチにプッシュすること
3. 共有とは、他の人も修正を加えるブランチにマージすること
ローカルでない = 共有 ではない。
共有する前に公開して、そこにレビューが行われてから、共有される。
情報共有みたいな言葉があるから勘違いするかもしれないけど
公開したからって直ちにそれが共有されるわけじゃない。
0762デフォルトの名無しさん
2015/03/03(火) 10:09:33.13ID:7ibvECcgその他のブランチは共有されたものなのか、個人のものなのかわかりづらいだろう。
そこは名前つけルールなどで解決できるが、個人的には
「公開された個人専用のリモートリポジトリ」を用意することをおすすめする。
githubであるプロジェクトをフォークして、自分専用の
公開されたリポジトリを作るのと同じようなもの。
俺が社内用として勧めるgitlabでも標準的な機能として採用されている。
個人のリポジトリは、gitlabにおける個人のネームスペース以下に
作られるから、それが共有されたものなのか、
単に公開されたものなのかはっきりわかる。
0763デフォルトの名無しさん
2015/03/03(火) 11:36:18.76ID:QsPjojm3履歴を利用する人も目的も違いから必要な粒度も違うっしょ
0764デフォルトの名無しさん
2015/03/03(火) 11:44:51.25ID:7ibvECcgそれは>>727にまとめてあるから言わなくていいよｗ
ここまでの流れまとめ
馬鹿「社内の開発はオープンソースとは違う！」
みんな「それで？」
馬鹿「え？」
みんな「え？じゃなくて、何が違うの？」
馬鹿「オープンソースとは違う」
みんな「いや、違うのは分かったから、何が違うの？」
馬鹿「・・・」
みんな「違うは違うだろうけど、それがどうgitの使い方に影響を与えるの？」
馬鹿「・・・」
みんな「社内の開発は、オープンソースとは違うから、こうするべきだっていいたいんだよね？」
馬鹿「・・・」
みんな「なにか言おうよ？明確な理由があるんでしょ？」
馬鹿「り、履歴は全部残すべき」
みんな「だからさぁ。その理由を言えって」
馬鹿「社内はオープンソースとは違う。」
みんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」
馬鹿「違うから、残すべき！」
みんな「だからその理由は？」
馬鹿「オープンソースを参考にしている時点でレベルが低い！」
みんな「だめだこいつ。話にならない。」
0765デフォルトの名無しさん
2015/03/03(火) 14:26:24.69ID:e2dsJS3J履歴もその中に含まれるからだろ
社内開発はそうじゃない
１に生活ぶ、２に納期、３４がなくて５に責任
0766デフォルトの名無しさん
2015/03/03(火) 14:38:08.25ID:DHBCPxMI0767デフォルトの名無しさん
2015/03/03(火) 14:44:36.11ID:gcsDknOwお前日本語理解出来ないのな…
0768デフォルトの名無しさん
2015/03/03(火) 14:45:40.16ID:DHBCPxMIアレを理解できる人がいるのなら、説明して見せてよ。
本人以外がｗ
0769デフォルトの名無しさん
2015/03/03(火) 14:46:43.94ID:DHBCPxMIみんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」
馬鹿「社内開発は１に生活ぶ、２に納期、３４がなくて５に責任 」
みんな「だから違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」
0770デフォルトの名無しさん
2015/03/03(火) 14:51:58.03ID:5yCpJehD0771デフォルトの名無しさん
2015/03/03(火) 14:52:22.13ID:DHBCPxMIgitはリリースされたものを改ざんすることは難しいよ。
なぜなら、リリースされたものの複製を
みんなが持っているから。
0772デフォルトの名無しさん
2015/03/03(火) 14:57:06.05ID:DHBCPxMIそれをいうのなら、忙しすぎて他人が何やったか
誰もコードをレビューをしてないって言うべきじゃないの？
誰かにレビューを依頼する時、その依頼をされた人は
そのコードを見ないといけない。当たり前だけど。
その時大量の修正をいきなり渡しても、
その修正が妥当か判断することは出来ない。
書いた本人は、何をやったかわかっているのだから
書いた本人が、綺麗にしてからレビューを依頼するほうが効率的だよね？
コードを他人に見てもらおうと考えてないし、見ることを全く考慮しないコード
何を修正するにも、影響が範囲がわかりません、どこで問題が起きたのかわかりません
解析に時間がかかります。というのが忙しい原因の一つだろうね。
0773デフォルトの名無しさん
2015/03/03(火) 15:00:06.53ID:BotLogjUソース出せって言っても出さない朝鮮人の下請けが居たよ
コミッターだったらしいけどまあ微妙で赤字になった
だからさっさとコミットしろって意味じゃねーの？
0774デフォルトの名無しさん
2015/03/03(火) 15:02:09.72ID:gcsDknOw>>765はオプソは履歴を残すが社内開発はそうじゃない(残さない)と書いてある
その是非は置いといて、それ以前にその日本語が理解出来てないって馬鹿にしてたんだが
それすら分からんのな…
0775デフォルトの名無しさん
2015/03/03(火) 15:02:24.23ID:DHBCPxMIそれだと、ソース出したくないなら、コミットしないから意味無いでしょ？
内部でちゃんと保存していますといって終わり。
コミットしろという言葉が通用するなら、
プッシュしろっていう言葉も通用するわけで、
それは人の問題。
0776デフォルトの名無しさん
2015/03/03(火) 15:03:11.55ID:DHBCPxMI> その是非は置いといて、それ以前にその日本語が理解出来てないって馬鹿にしてたんだが
日本が理解できてないってどこの部分が？
あんたこそ日本語が理解できてないんじゃないの？ｗ
0777デフォルトの名無しさん
2015/03/03(火) 15:04:34.17ID:e2dsJS3J0778デフォルトの名無しさん
2015/03/03(火) 15:04:40.40ID:DHBCPxMI議事録とかもなさそうだね。
社内開発の内容を残さない会社なのだから。
0779デフォルトの名無しさん
2015/03/03(火) 15:08:27.57ID:JJuvbvrG> 後で変更できないからコミット自体をためらうという弊害はあるな
そうそう。それがsubversionで実際に起きていた問題の一つなんだよ。
作りかけでもいいから、とりあえず提出しろ、もし問題があればすぐに指摘できるから。
問題があればそれを直せばいいだけ。完成してから出すんじゃない。
その時に問題がわかっても既に手遅れになっている。
これが最近俺が言っている事。
最低でも一日に一回は作りかけのものをプッシュするようにって
言っているよ。ミスはあとで変更すればいいだけだからね。
git使ってるならプッシュしない理由がない。
作業途中も見れるから、完成したときには問題のないコードになっていることもある。
0780デフォルトの名無しさん
2015/03/03(火) 15:13:55.10ID:gcsDknOw>>765
オプソは見せる為のもので履歴も含まれる
↓
社内開発はそうじゃない(残さない、他に優先すべき事がある)
↓
>>766
> それが履歴残すことで、解決できるのかよｗ
↑
ぷっ
0781デフォルトの名無しさん
2015/03/03(火) 15:16:59.83ID:JJuvbvrGあー本当にわかってなかったのかｗ
>>765
オプソは見せる為のもので履歴も含まれる
↓
社内開発はそうじゃない(残さない、他に優先すべき事がある)
（他に優先するべきもののために、履歴は全部そのままとっておくほうがいい）
↓
>>766
> それが履歴残すことで、解決できるのかよｗ
こういう流れだよ？
最初から、履歴を整理する？ or 履歴を全部残すか？
って話だっただろ。
0782デフォルトの名無しさん
2015/03/03(火) 15:23:47.78ID:gcsDknOwあっそ
結局全部残すのが前提で糞みたいな議論を延々続けてんのかよ
0783デフォルトの名無しさん
2015/03/03(火) 15:36:50.84ID:JJuvbvrG分かったならいちいち勘違いで噛み付くなよ。
せっかく履歴はあとで見やすいように整理するべきって
結論になってたんだから。
0784デフォルトの名無しさん
2015/03/03(火) 16:39:18.61ID:MRrEf2ES○○ちゃんはこうやってるから
> みんな「違うのは分かったから、
自分=みんな
これは…典型的な小学生だな
0785デフォルトの名無しさん
2015/03/03(火) 16:42:57.93ID:MRrEf2ES結局印象操作によるゴリ押ししかできないと。
0786デフォルトの名無しさん
2015/03/03(火) 16:56:09.55ID:1CZ2jV0Yはっきりさせようか。
0787デフォルトの名無しさん
2015/03/03(火) 18:02:00.73ID:MRrEf2ESそれ1つで、どんなプロジェクトにも対応できるという主張と、
プロジェクトごとに、それぞれ違う手法が最適という主張だから、
後者は想定がないんじゃ。
0788デフォルトの名無しさん
2015/03/03(火) 18:13:41.29ID:4hsfxXF60789デフォルトの名無しさん
2015/03/03(火) 18:52:03.07ID:rHlcBo7Gコミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん
そしたらそれを修正するためのコストがかかるんだよ
だからコミットを何でもかんでもまとめるべきではない
まとめるときはまとめるという行動を必要最低限にするべき
プッシュスルまでにこまめにまとめると自爆するんだよ
0790デフォルトの名無しさん
2015/03/03(火) 19:23:00.20ID:S1+TduGPそこまででっかいもの作ってないし、何を上げていいのかサッパリだ
0791デフォルトの名無しさん
2015/03/03(火) 19:34:01.44ID:rHlcBo7G誰にも見せたくないならbitbucket
0792デフォルトの名無しさん
2015/03/03(火) 21:31:57.00ID:gtrHHVSl> コミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん
コマンドの使い方が適切ならそんな間違いは大抵防げると思うけど。
例えばどんなシチュエーション？
0793デフォルトの名無しさん
2015/03/03(火) 21:37:30.08ID:/6Kzu3OZnの打ち間違えとか
0794デフォルトの名無しさん
2015/03/03(火) 21:38:09.51ID:QODsipDBうーん、わかったようなわからんような。
要はレビュー等でリリース前にバグを潰せればfixの履歴を残す必要がない、と。
それはそれでいいけど、gitの運用ポリシーとかそういうのとは関係ない話のような。
0795デフォルトの名無しさん
2015/03/03(火) 21:58:50.48ID:Lc+IT+xe0796デフォルトの名無しさん
2015/03/03(火) 22:04:50.52ID:gtrHHVSlnが小さい分には無害だから大きく指定してしまうってことだよな？
それをよくやってしまうようなら git log --oneline で出てくるハッシュをもとに指定するようにするだけで、かなり防げそうだ。
例えば master から分岐してるトピックだとして git log --online master で
cccccc Yet another good change
bbbbbb Add another good change
aaaaaa Add my good change
と表示されるなら
git rebase -i aaaaaa^
とするように習慣づけるとか。
master が分岐後進んでないならシンプルに
git rebase -i master
でもいけるので、トピックいじってるときは master を pull しないようにしとく、とかでも良いかもしれん。
上流のmasterを見るだけなら origin/master を見ればいいわけだし。
0797デフォルトの名無しさん
2015/03/03(火) 22:16:09.02ID:gtrHHVSl0798デフォルトの名無しさん
2015/03/03(火) 23:59:48.29ID:EHrBe6ew自分一人でやってるなら、自分が好きなように履歴をまとめていいと思う。
ただし技術レベルが低い他の人が入ってくると、
・typoとかう○こしに行ったとか、どうでもいいコミットをリモートリポジトリに入れまくって場を荒らす
・まとめちゃいけない履歴をまとめてしまって、とんでもない状態になる
という、2つのリスクが生じる。
それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない
0799デフォルトの名無しさん
2015/03/04(水) 00:49:25.14ID:g/89t28n> コミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん
ありえないなｗ
自由にまとめられるのはローカルにあるもの、もしくは
自分専用リポジトリにあるものだけ。
ローカルにあるmasterの過去の履歴を変えてpushしたら他人に影響出るけど
過去の履歴を変えているならば、いつもどおりにpushはできずにエラーになる。
push --forceしなければ変えられない。
その上、みんなが共有しているものはgit push出来ないようにしている。
（gitlabならウェブ管理画面から設定するだけ。githubはしらないがpre-commitに仕込めば良さそうだ）
つまり共有しているものに対しては、pushは許されずに、マージのみ可能にしているから
すでにgithubに上がっているコミットを間違えて修正することはない。
0800デフォルトの名無しさん
2015/03/04(水) 00:53:09.34ID:OQ0tAhEv0801デフォルトの名無しさん
2015/03/04(水) 00:54:43.94ID:OQ0tAhEvサーセン
0802デフォルトの名無しさん
2015/03/04(水) 00:57:59.30ID:g/89t28n> ただし技術レベルが低い他の人が入ってくると、
> ・typoとかう○こしに行ったとか、どうでもいいコミットをリモートリポジトリに入れまくって場を荒らす
> ・まとめちゃいけない履歴をまとめてしまって、とんでもない状態になる
そういうのはsubversionでも同じでしょ？
そういうのを防ぐために、githubやgitlabといったものがあるんだよ。
さっきも書いたように、masterや特定の共有ブランチには誰もpush --forceできない。
そして技術レベルが低い人には、masterへのマージ権限もなくしてしまう。
そうすると履歴を荒らすなんてことは不可能になる。
もちろんローカルは自由になんでもできるが、
それを共有するためには、正しい履歴で技術レベルが低い人は
レビューを通さないとマージされない。
運用ルールを決めるのではなく、まずツールを導入して正しく理解して使うことが重要。
よく日本はパッケージを買って、そのパッケージに業務を合わせようとするのではなく
パッケージのほうを業務にあわせてカスタマイズしようとするから、無駄が多いって言われるね。
0803デフォルトの名無しさん
2015/03/04(水) 01:07:38.89ID:g/89t28n> それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
> Git運用ルールができたとしても、短絡的ではあるが分からなくはない
そういうルールができたら、
「機能がひと通り完成して全体が出来るまでプッシュしない」
ってなってしまうと思うけど？
マージする段階では綺麗になっていないといけないが、
それよりか前の段階では、自由にrebaseしていいならば、
小さくコミットしていけるわけだが。
ま、git使ってるならばローカルで何やっても自由で他人にはわからないんだがねｗ
共有 と 共有していない 状態で、ルールが違うってことを認識しないとね。
0804デフォルトの名無しさん
2015/03/04(水) 07:56:20.04ID:UWB+qgaN0805デフォルトの名無しさん
2015/03/04(水) 09:24:37.42ID:bZIB5PLEあなたが言ってるのはツールの使い方であり、他人の使い方ではない
同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
チームがこじれることって多い
日本はパッケージのほうを業務にあわせてカスタマイズしようとする・・・としたら、
それはおそらく文化的な側面によるものだろう
0806デフォルトの名無しさん
2015/03/04(水) 12:41:41.68ID:Rd+EJUJR履歴を改ざんリスクに晒す必要などない
権限ユーザがいないと共有リポジトリの更新が止まるならより悪化してるじゃないか
0807デフォルトの名無しさん
2015/03/04(水) 12:45:58.77ID:EBrrhcuH大げさに言い過ぎじゃね？
0808デフォルトの名無しさん
2015/03/04(水) 13:45:30.69ID:r+Qv6+bp0809デフォルトの名無しさん
2015/03/04(水) 13:58:04.42ID:aiebJTF+0810デフォルトの名無しさん
2015/03/04(水) 15:08:40.97ID:eBFKbFS90811デフォルトの名無しさん
2015/03/04(水) 15:21:59.38ID:b8zh+3o7[alias]
a=add .
ac=!git a&&git commit
って書いてあったんですが、エイリアスの中からエイリアスを書いたら不具合でませんか？
あと!ってなんですか？
0812デフォルトの名無しさん
2015/03/04(水) 21:03:17.57ID:g/89t28n> 同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
> チームがこじれることって多い
意味がわからん（苦笑）
じゃあ両方に権限与えればいいんじゃね？
この際だからさ、git以外も含めて全部権限与えろよ？
それで混乱したって、チームがこじれるよりマシだだから
お前はそれを選択するんだろう？
git関係ないじゃん。
0813デフォルトの名無しさん
2015/03/04(水) 21:05:07.53ID:g/89t28n> 履歴の書き換えぐらいで何のリスクになるん？
> 大げさに言い過ぎじゃね？
全くその通り。
共有されてない所でやるのだから、
単に最初から間違えなかった形にしてから
提出するだけの話。
なんのリスクなのかさっぱりわからんよね。
0814デフォルトの名無しさん
2015/03/04(水) 21:32:20.16ID:1PNNe6DT共有するコードに要求される品質レベルはプロジェクト次第なんだから
ルールだって違って当たり前。
0815デフォルトの名無しさん
2015/03/04(水) 21:42:45.98ID:zH//+mv4＞じゃあ両方に権限与えればいいんじゃね？
＞この際だからさ、git以外も含めて全部権限与えろよ？
＞それで混乱したって、チームがこじれるよりマシだだから
＞お前はそれを選択するんだろう？
いや、自分ならこっちを取るな
『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない』
＞git関係ないじゃん。
「rebase禁止」も「rebaseオッケー」も、Gitの機能とは関係ない、Gitの運用ルールの話だよ
0816デフォルトの名無しさん
2015/03/04(水) 21:46:27.28ID:g/89t28n> 『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
え？ なんの関係があるの？ 権限の話でしょ？
そのコードをマージするのは誰？
メインブランチにマージするのは誰？
マージするのは入社何年目の人？
入社何年目かの同じ年次の人は
全員、同じ権限を与えるっていうのが
あんたのやり方なんでしょ？
ならどんなにダメな人でも、マージする権限持ってるわけだよね。
手をつないでみんなでゴールしましょう的な
ゆとりの発想。
0817デフォルトの名無しさん
2015/03/04(水) 21:46:37.95ID:zH//+mv4＞共有するコードに要求される品質レベルはプロジェクト次第なんだから
＞ルールだって違って当たり前。
自分もそう思う
違う点があるとすれば、自分は「Gitの運用ルールを決めるのは、要求される品質レベルじゃなく、
プロジェクトに集まった人の技術レベルじゃないか」と思ってるところだ
0818デフォルトの名無しさん
2015/03/04(水) 21:49:02.70ID:g/89t28n正しいやり方っと言うのはある。
それは当然高い技術を持った人のやり方。
そして技術が低いものがやる
初心者向けのやり方。
それは、正しいやり方よりも劣っているが仕方ない。
初心者なのだから。
0819デフォルトの名無しさん
2015/03/04(水) 21:49:34.02ID:zH//+mv4＞ならどんなにダメな人でも、マージする権限持ってるわけだよね。
いや、自分なら逆の方向をとる。
どんな良い人でも○○の職階を持っていない人、または自分以外は
マージする権限を与えない、って方に倒す。
0820デフォルトの名無しさん
2015/03/04(水) 21:50:47.84ID:g/89t28n> マージする権限を与えない、って方に倒す。
同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
チームがこじれることって多い
↑これお前が言った言葉。
年次が同じなら同じ権限を与えるんでしょう（笑）
0821デフォルトの名無しさん
2015/03/04(水) 21:52:03.71ID:zH//+mv4＞つまりは馬鹿向けのやり方ってことかｗ
その通り。
例えプロジェクトリーダーでも、プロジェクトに集まったバカをクビにする権限は持たないしね。
だから、まさにこの言葉の通りだ
『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない』
0822デフォルトの名無しさん
2015/03/04(水) 21:52:57.09ID:zH//+mv4＞年次が同じなら同じ権限を与えるんでしょう（笑）
そう。
だから、両方に権限を与えない方に倒す。
0823デフォルトの名無しさん
2015/03/04(水) 21:53:13.82ID:g/89t28nそれじゃ意味がわかりにくいから
ちゃんと正確に言おうよ。
※↓正しいやり方が出来ない人のための馬鹿向けのやり方です
『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない』
※↑正しいやり方が出来ない人のための馬鹿向けのやり方です
0824デフォルトの名無しさん
2015/03/04(水) 21:53:46.10ID:g/89t28nじゃあ誰もマージする権限を持てないってことになるなｗ
0825デフォルトの名無しさん
2015/03/04(水) 21:54:51.08ID:zH//+mv4元の文章より長くなっただけで分かりにくい。
0826デフォルトの名無しさん
2015/03/04(水) 21:55:20.81ID:zH//+mv4そう。自分以外は。
0827デフォルトの名無しさん
2015/03/04(水) 21:55:35.90ID:g/89t28n正しいやり方、普通の人のやり方ではないということが
一番重要な点だから、これは省略してはいけない。
※↓正しいやり方が出来ない人のための馬鹿向けのやり方です
『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない』
※↑正しいやり方が出来ない人のための馬鹿向けのやり方です
0828デフォルトの名無しさん
2015/03/04(水) 21:56:26.55ID:g/89t28n勝手にルールかえんなよｗ
お前と同じ年次であれば全員同じ権限だ。
お前が言ったことだろドアホｗ
まさにゆとりの発想ｗ
同じ年なら、権限も一緒♪
0829デフォルトの名無しさん
2015/03/04(水) 21:58:45.40ID:aiebJTF+0830デフォルトの名無しさん
2015/03/04(水) 21:59:03.84ID:zH//+mv4もとの文章の>>798の方が分かりやすい。
0831811
2015/03/04(水) 22:00:25.21ID:YgBYjps40832デフォルトの名無しさん
2015/03/04(水) 22:00:54.46ID:zH//+mv4そこは>>828に書いてある通りだ
＞どんな良い人でも○○の職階を持っていない人、または自分以外は
＞マージする権限を与えない、って方に倒す。
自分だけはプロジェクトリーダーだから特別なんだ。
0833デフォルトの名無しさん
2015/03/04(水) 22:01:46.44ID:zH//+mv40834デフォルトの名無しさん
2015/03/04(水) 22:02:25.17ID:zH//+mv40835デフォルトの名無しさん
2015/03/05(木) 06:14:47.33ID:gzqC2V5Z> 自分だけはプロジェクトリーダーだから特別なんだ。
関係ないよ。
同じ年次であれば、同じ権限を持たせないと
チームがこじれる。
俺だけは特別だって言ってるならなおさら。
0836デフォルトの名無しさん
2015/03/05(木) 06:15:56.70ID:gzqC2V5Z他の人もプロジェクトリーダーにするべきだな。
0837デフォルトの名無しさん
2015/03/05(木) 16:38:24.90ID:7kn/eyTEこのスレ見て分かるように
年中揉めてるよな君ら
なんか構造的な欠陥があんじゃねえの
0838デフォルトの名無しさん
2015/03/05(木) 16:52:43.04ID:wT1PXWMM0839デフォルトの名無しさん
2015/03/05(木) 17:58:44.68ID:yLaAbW6D0840デフォルトの名無しさん
2015/03/05(木) 18:27:01.72ID:wT1PXWMM一理ある
0841デフォルトの名無しさん
2015/03/05(木) 22:04:15.46ID:2/2fvpIn納得
0842デフォルトの名無しさん
2015/03/05(木) 22:11:46.42ID:gzqC2V5Zgitをぶち壊すような使い方を押し付けるのだけはやめてほしいね。
0843デフォルトの名無しさん
2015/03/05(木) 23:48:41.01ID:BXUnQ96Q0844デフォルトの名無しさん
2015/03/06(金) 01:13:51.86ID:dcg9agNJ馬鹿を舐めてはイクない
馬鹿を相手にしてはイクない
0845デフォルトの名無しさん
2015/03/06(金) 10:42:00.29ID:IZ+FNf9n0846デフォルトの名無しさん
2015/03/06(金) 19:38:38.75ID:96rr2Nz5gitをぶち壊すような運用にはならないと思う
gitのコンセプトが活きない運用には、なるかもしれないけど
0847デフォルトの名無しさん
2015/03/06(金) 19:49:32.53ID:96rr2Nz5git使ってるやつらがgitなんだから、しゃーない
だけど、開発者が自虐でgit（バカ）って付けたつもりが、
ユーザは本当にバカの集まりだったんだから、開発者も愕然としたろうな
0848デフォルトの名無しさん
2015/03/07(土) 01:18:14.91ID:xwMIcR01まあ確かに。個人のPCの中まで覗いてあれこれ言う訳もないのだから
rebaseし放題ではあるなｗ
レビューによる細かい修正が入ったら、別のブランチに変更すればOKだろう。
（見える所で）rebaseはしてない。ただ綺麗にしたブランチに仕切り直ししただけ。
意味をわかってないのにルールを作ろうとする人には、この程度の技で乗りきれるだろうｗ
0849デフォルトの名無しさん 転載ダメ©2ch.net
2015/03/08(日) 13:23:19.05ID:D6u4eQdv0850デフォルトの名無しさん
2015/03/08(日) 16:36:03.50ID:Zck1rhOdadd
commit
merge
rebase
status
log
branch
reflog
checkout
これしか使いませんよね、他にもありますか？
これ以上何か覚えるのは無駄な気がします
0851デフォルトの名無しさん
2015/03/08(日) 16:36:58.19ID:Zck1rhOdinitは一回しか使わないので除外しました
0852デフォルトの名無しさん
2015/03/08(日) 16:39:06.22ID:VvSj/2Rgremoteがなければ、他人のブランチ追加できないし、
bisectがなければ、バグの箇所の二分探索ができないだろ。
よく使うものをリストを作成してあげた
しかもコメント付きだぞ。
これを覚えれば良い。
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
grep Print lines matching a pattern
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
rebase Forward-port local commits to the updated upstream head
reset Reset current HEAD to the specified state
rm Remove files from the working tree and from the index
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify a tag object signed with GPG
0853デフォルトの名無しさん
2015/03/08(日) 17:17:38.08ID:Zck1rhOd0854デフォルトの名無しさん
2015/03/08(日) 17:23:00.48ID:YHgFNUWD0855デフォルトの名無しさん
2015/03/08(日) 18:59:26.56ID:Q2y8dnyFなんか壊れてしまって、最後にコミットした内容がなくなってるんですがどうやって復活できますか？
reflogで最後にコミットしたのにチェックアウトしても内容が空でした
0856デフォルトの名無しさん
2015/03/08(日) 19:08:09.67ID:Q2y8dnyF0857デフォルトの名無しさん
2015/03/08(日) 19:53:36.90ID:YHgFNUWD壊れたってのはローカルリポジトリ？
かなりの確率で「壊れた」じゃなくて「壊した」だと思うけど
reflogに頼らざるを得ない状況で
最後の1コミットを試行錯誤で復元するくらいなら
書き直した方が早いんじゃね
0858デフォルトの名無しさん
2015/03/08(日) 20:17:53.01ID:YHgFNUWD結論は変わらないが
コミット時にaddし忘れてたとか間違ってaddしたとか
IDEが同期できてないとかいうオチじゃないの
diffはなんて言ってるの？
0859デフォルトの名無しさん
2015/03/08(日) 23:30:13.34ID:i6ndjJIT0860デフォルトの名無しさん
2015/03/09(月) 01:52:44.65ID:vDboz7xO0861デフォルトの名無しさん
2015/03/09(月) 02:01:10.71ID:qBHtyy+C0862デフォルトの名無しさん
2015/03/09(月) 08:36:43.74ID:tTQKX5CU858の最後の、「コマンドが喋った！」的なところだろう
0863デフォルトの名無しさん
2015/03/09(月) 09:11:49.55ID:vDboz7xOgit showはどう考えてもgitにshowさせている
そういう文化で気持ち悪がられても強くなれ！としか
0864デフォルトの名無しさん
2015/03/09(月) 09:29:41.11ID:tTQKX5CUこちらは、diffたんは何て言ってるの？ってことを指したつもりだ
＞そういう文化で気持ち悪がられても強くなれ！としか
ちなみに、この返しも相当気持ち悪い
0865デフォルトの名無しさん
2015/03/09(月) 12:37:48.79ID:GhZk1PLG> git showはどう考えてもgitにshowさせている
無意識だろうけど、擬人法になってる
コンピューターをこういう理解の仕方してる事が気持ち悪い
0866デフォルトの名無しさん
2015/03/09(月) 14:57:09.19ID:dbEYjzPy0868デフォルトの名無しさん
2015/03/09(月) 16:55:11.05ID:c72WnppV0869デフォルトの名無しさん
2015/03/09(月) 18:42:02.52ID:gk6yvFxP0870デフォルトの名無しさん
2015/03/09(月) 18:45:15.14ID:gk6yvFxP0871852
2015/03/10(火) 00:40:13.55ID:cMNbMZ7xrevertがない、stashがない
0872デフォルトの名無しさん
2015/03/10(火) 01:08:52.11ID:gHEPbU2O0873デフォルトの名無しさん
2015/03/10(火) 02:58:23.06ID:8d1ozIG0運用リポジトリ・・・開発・テスト用リポジトリから最新のバージョンをフェッチしマージして使う、DBパスワード等は当然実際のもの
こんな感じでおｋ？
0874デフォルトの名無しさん
2015/03/10(火) 03:19:48.67ID:cA+NWIlxそういう運用がありえないとは言わんが
少なくとも当然ではないだろう
0875デフォルトの名無しさん
2015/03/10(火) 03:25:07.57ID:++yEJXLu0876デフォルトの名無しさん
2015/03/10(火) 11:44:38.42ID:yUlh75KQ0877デフォルトの名無しさん
2015/03/10(火) 15:03:46.74ID:cVDS0tan0878デフォルトの名無しさん
2015/03/10(火) 18:47:46.87ID:AWzDSsUv0879デフォルトの名無しさん
2015/03/10(火) 20:16:07.93ID:cMNbMZ7x一般的にはデータベースのパスワードはリポジトリに入れない。
リポジトリに入れない設定ファイルとして分離しする。
そのリポジトリをオープンにしたら？って考えればわかるでしょ？
パスワード関連の設定はアプリのデプロイに関連する話
そういうデプロイのシステムがなければ、
単にサーバーに設定ファイルを置く。
あと開発・テスト・運用リポジトリなんて分け方はしないしブランチにもしない。
すべて同一のリポジトリの同一のブランチを使う。
でないとそれぞれが本当に同じものなのか分からないし、
同期をとる作業が面倒になる。
0880デフォルトの名無しさん
2015/03/10(火) 20:33:04.05ID:AWzDSsUv0881デフォルトの名無しさん
2015/03/10(火) 20:56:42.81ID:cMNbMZ7x誰にいってんの？
このタイミングだと俺に言ってるように見えるから言っておくけど、
リポジトリのどこにもパスワードは入れない。
タグはバージョンと考えればいい。
1.0、1.1、2.0bata1、2.0rc1 こういったものがタグ名の候補
0882sage
2015/03/11(水) 11:52:10.48ID:MzuOpnCI結論から言えば、 >>654 のやりかたがいいとおもいました。
自分だけ(あるいは十分に小さなチーム内)で閉じている時なら、rebaseにより歴史を改竄して「分かりやすい歴史」「重要な部分のみを含む歴史」にする。
一旦、統合ブランチ(通常は開発ブランチ/場合によってはmasterブランチが統合ブランチになる)などにマージして、他の人と共有したら、もうrebaseによる歴史の改竄はしない、バグやtypo修正もそのまま正直に表す。
これが上手くいくのは、自分だけで開発している段階が、一番小さく重要でない修正が多いから。
こういう理解でいいでしょうか？
0883デフォルトの名無しさん
2015/03/11(水) 12:45:23.30ID:s6Q6JS6Jrubyのまつもと先生のリポジトリだってrebaseされずmergeログ残しまくってるな
天才がそうしてるんだからrebase厨が間違ってる
0884sage
2015/03/11(水) 13:06:09.72ID:MzuOpnCIいらない人がいるのはわかっています。
だからといって要る人からrebaseを奪うのはどうなのでしょう？
・ローカルのfeatureブランチの小さなfixやtypo修正のコミットが統合ブランチに残って邪魔
・bisectがうまくいかない
という話には、どう反論されますか？
0885sage
2015/03/11(水) 13:10:52.39ID:MzuOpnCIA successful Git branching model では、安定(運用)ブランチと、開発ブランチと、
機能の実装とテストのブランチを分けているように思います。
リポジトリを分けるという話はまだ聞いたことがないけど。
0886sage
2015/03/11(水) 13:19:52.06ID:MzuOpnCI質問なのですが、まつもと先生がマージ前にrebaseしていないということは、どのようにして分かるのですか？
初心者の僕の疑問なのですが、
ローカルリポジトリにあるローカルブランチでrebaseをして歴史を改竄後、ローカルブランチをpushしたら、改竄後のcommitとブランチ「のみ」がリモートに残り、みんなに公開されると思います。
だから、rubyのリモートリポジトリを見ただけで、matzのローカルリポジトリを見ないと、rebaseを使ってないとは断言できないように思いました。
僕の理解は間違っていますか？
教えて偉い人、教えてエロい人
もし >>883 さんがまつもと先生のローカルリポジトリを見たのならごめんなさい。
0887デフォルトの名無しさん
2015/03/11(水) 13:22:00.61ID:s6Q6JS6J質問する前にgithubでリポジトリ覗いてこいや
0888デフォルトの名無しさん
2015/03/11(水) 13:26:04.71ID:1lChT+Cl曖昧に書いてしまってすまんね
パスワード入れないってのはもちろんわかるのでOK
>>880の最後の段落で言っている、「開発・テスト・運用リポジトリなんて分け方はしないしブランチにもしない」ってとこへの質問
自分的には開発ブランチと運用ブランチは分けて適宜マージするから
そうしないとするならブランチは1本で運用中のバージョンはタグ振ってそれに固定してるのかなあと思ったことからの質問でした
0889デフォルトの名無しさん
2015/03/11(水) 15:11:20.41ID:lItiyTLiID:MzuOpnCI からしてオープンて
0890sage
2015/03/11(水) 15:16:01.21ID:MzuOpnCI覗きました。
具体的には mruby のリポジトリをクローンして git log --graph しました。(ブランチはmasterブランチしかありません)
rubyのリポジトリも git log --graph で樹形図を見ました。
しかしrebaseに関して情報が見えません。
rebase前とrebase後を比べれば、commit IDや親のIDが変わっているはずだ、というのは分かります。
しかし見ているのはrebase後のものなので、前とIDを比較することもできず困っています。
ここからどうすれば分かるのですか？
0891882
2015/03/11(水) 15:21:43.53ID:MzuOpnCI何を自演しているということですか？
僕が質問と回答の両方をしているという意味ですか？
僕は今日ひさしぶりに書き込んで、このIDだけしか書いてないです。
自演ではありません。
0892882
2015/03/11(水) 15:34:59.45ID:MzuOpnCIこれってrebaseとかは関係なく、svnと連携しているからですかね？
mrubyのほうは履歴がごちゃごちゃしています。
多いところでは5本くらいブランチが並行して走ってます。
ただ、これを見ても、ローカルでrebaseしてないとは僕には分からないのですが、
rebaseしていないということは、どのように分かりますか？
0893デフォルトの名無しさん
2015/03/11(水) 15:50:28.72ID:Mn0szBmXおまえが無駄な情報はrebaseして残すなっていってるがその無駄な情報がログに残ってんだろ
rebase使ってるか使ってないか判断できるだろ
0894デフォルトの名無しさん
2015/03/11(水) 16:25:30.59ID:tSCLM+GC全体的なログは要所要所でエクセルに記載すればよい。
0895882
2015/03/11(水) 16:26:25.54ID:MzuOpnCIrebaseすれば、ログには残らない
対偶をとって、
ログに残っているのだから、rebaseしていない。
と、このような推論をされたのでしょうか？
そうでしたら、その推論は論理的に間違っています。
なぜなら、変更は1つではなく、たくさんあるからです。
命題論理ではなく、述語論理を使わなくてはなりません。
(1) 全ての無駄な変更をrebaseすれば、その変更はログには残らない。
よって
(2) 無駄な変更がログに残っているのだから、全ての無駄な変更をrebaseした、とは言えない。
と、このような推論が正しいです。
(1)から、
(3) 無駄な変更がログに残っているのだから、matzはrebaseしない
を推論しているとすれば、その推論は論理的に間違っています。
形式的に言うと、
∃¬rebase(x) … rebaseしていない変更が存在する
から論理的に正しく推論されるのは、
¬∀rebase(x) … すべての無駄な変更をrebaseしている、とは言えない
であり、
∀¬rebase(x) … (matzは) 常にrebaseしない
や
¬∃rebase(x) … (matzが) rebaseすることはない
は推論できない、ということだと思います。
¬と∀や∃の位置が異なることが分かると思います。
0896882
2015/03/11(水) 16:27:42.36ID:MzuOpnCI>>893 さんのおかげで ruby / mruby のリポジトリを見ました。
ありがとうございます。
0897882
2015/03/11(水) 16:41:23.48ID:MzuOpnCI共有リポジトリに残すべきでない、つまらない情報というのは
LookupDNS() という関数を作った
↓
f() g() h() から LookupDNS() を使うように修正
↓ ←見直してたら LookupDns() でなければならないことに気づいたので
LookupDns() に修正してコミット
こういう履歴を、rebase を使えば
LookupDns() という関数を作った
↓
f() g() h() から LookupDns()を使うように修正
というようなシンプルな履歴になおせるということだと思います。
他にも、コード修正してたら意味もなくスペースを変なところに追加してしまった、スペースはなかったことにしたい、だとかいうのも、あとで改竄できますね。
このような細かすぎて害(コスト)の方が大きい履歴の場合、rebaseを使ってはどうですか？ というのが、rebase容認派の意見だと思います。
エクセルなどで文書化するのもひとつの方法ですが、それはそれで、コードとドキュメントの整合性を常に確認しなくてはならない、という新たなコストが発生してしまうので、silver bullet ではないと思います。
0898デフォルトの名無しさん
2015/03/11(水) 17:08:53.02ID:ymVn+M/Ubisect がうまくいかないってどういうこと?
bisect したい時ってクソみたいなコミット残した方が良くない?
0899882
2015/03/11(水) 20:21:08.91ID:MzuOpnCIあくまで勉強中の僕の理解ですが
- rebaseをして歴史をほぼ一直線にしておくと、bisectで原因となるcommitを狭い範囲に絞れる。
- 一方、普通のmergeでは、bisectで見つかるのはマージコミットで、具体的に原因となるコミットを探すためには、更にbisectをかける必要があり、コストが増える。
これがbisectとmergeに伴うコストです.
後者は、CIなどで コミット→テスト→赤が増える→自動でbisect というふうに自動化している場合、
bisectが一発で原因特定してくれないと、人間が手動でbisectをかけなおさないといけないのがけっこう面倒(しかも毎回利子が付く技術的負債)なのではないか、と予想しています。
おっしゃってる「クソみたいなコミット」はどのようなものでしょうか？
ローカルで名前を変更した直後にまた変更するようなら、前の変更は他の人に共有する必要がない「クソみたいなコミット」だと思います。
一方、それが本質的な変更なら、rebaseしてもそのコミットを消さずに、そのままpushしなくてはなりませんね。
bisectで絞り込むには、ある程度粒度が細かい方が良いでしょうね。
rebaseするにしても、rebaseの際にどの程度のコミットを消し、どのコミットを残し、どのコミットをまとめるか、というのは、プロジェクトによって最適解が違うような気がしてます。
0900デフォルトの名無しさん
2015/03/11(水) 20:42:38.49ID:fyi4MFv20901デフォルトの名無しさん
2015/03/11(水) 20:53:33.97ID:jTFm1PKF0902882
2015/03/11(水) 21:22:30.41ID:MzuOpnCIそうではないですよ。
すくなくとも僕はそんな二項対立でとらえていません。
いろいろな手法にメリットとデメリットが存在する、という見方です。
実際、小さなチームで机を付き合わせてる場合なんか、いったん共有したものすら、口頭で確認の上、rebaseして良い場合もあるでしょう。
一方、rebaseを前面的に禁止にしないと弊害が大きいような寄せ集めチームも日本のどこかにはあるでしょう。
一言でいえば、ケースバイケースなんだと思います。
bisectを自動化する上では、--no-ffもやめて完全に一本道にすることに、メリットもあるよね、というだけです。
メリットがデメリットよりも大きいかは、ケースバイケースだと思います。
マージコミットの粒度が小さければ、--no-ffなマージでも十分にしぼりこめたと言えますから、そのメリットは小さくなるはずです。
マージコミットの粒度が大きいような手法なら、ffだけで一本道にすることのメリットは大きくなるとおもいます。
>>901
なぜそのように言えますか？
マージコミットの粒度が大きい場合、そのように言えないと思います。
0903デフォルトの名無しさん
2015/03/11(水) 21:52:00.26ID:8pzVHB9Lgit厨ってまじで馬鹿しかいないの？
0904882
2015/03/11(水) 22:07:01.71ID:MzuOpnCI僕も含め、みんなそうしていると思いますよ
その中で並行して議論したり情報交換をしたりしているのだと思います
0905デフォルトの名無しさん
2015/03/11(水) 22:08:58.30ID:tSCLM+GC0906デフォルトの名無しさん
2015/03/11(水) 22:11:05.63ID:aOAwaNrR副店長の佐藤伸弦が暴行事件を起こしていた
0907882
2015/03/11(水) 22:13:43.61ID:MzuOpnCIMacでSourceTree使って開発/gitの勉強してます
(ときどきCUI)
SourceTreeのWindows版は重いとか聞きました
0908デフォルトの名無しさん
2015/03/11(水) 22:16:52.58ID:4jyDbHWwaddとcommitとlogとstatusとpushとcloneでmasterブランチしか使ってない
0909デフォルトの名無しさん
2015/03/12(木) 00:04:17.35ID:T2FqaOXK＞実際、小さなチームで机を付き合わせてる場合なんか、いったん共有したものすら、口頭で確認の上、rebaseして良い場合もあるでしょう。
＞一方、rebaseを前面的に禁止にしないと弊害が大きいような寄せ集めチームも日本のどこかにはあるでしょう。
＞一言でいえば、ケースバイケースなんだと思います。
gitが本来備えている機能を禁止するかどうかの基準は、自分の意見もこれに合ってる
そして、rebaseを禁止した方が「手っ取り早い」寄せ集めチームは、日本の至る所にあると思う
0910デフォルトの名無しさん
2015/03/12(木) 01:52:17.03ID:iIvxM21/要するにバカが沢山いるってことだろ？
それはgitの正しい使い方とは別の話だよね？
0911デフォルトの名無しさん
2015/03/12(木) 02:10:22.46ID:J+f2qoWUうだうだ言ってるけど結局適切な運用方法を自分で決められない初心者ゆえの議論だから
状況ごとの使い分けで悩まない人間からすれば実にどうでもいい
0912デフォルトの名無しさん
2015/03/12(木) 02:14:27.83ID:ko4MAwtxツールを合わせようと考えるんだよな。
新しいものを導入するっていうことは、
今までのやり方を変えるということなのに、
今までのやり方はそのままで、ツールをそれに合わせようとする。
えとね。ツールっていうのは「ある使い方」をするために作られたんだよ。
それがgitが持っているコマンドでもあるの。
だからツールはどのように使うために作られたか？をしっかり考えて
ツールのやり方に合わせることが大事なの。
オリジナルを考えて良いのはそれからだよ。
料理でも一緒。ろくに使えないのに最初からアレンジするなと。
0913デフォルトの名無しさん
2015/03/12(木) 08:30:04.15ID:gjsjWNGM＞日本人ってすぐ自分のやり方に
＞ツールを合わせようと考えるんだよな。
＞新しいものを導入するっていうことは、
＞今までのやり方を変えるということなのに、
この発想は、力関係が「自社＜顧客」で、顧客からツールのカスタマイズを要求される業務系SEが
顧客に対して不満を持っているからこう思うんだろうな
多様性を受け入れられないツールは、なかなか世に受け入れられないだろう
gitだって、様々な機能を、使わなかったりすることができるわけで
0914デフォルトの名無しさん
2015/03/12(木) 08:37:56.91ID:iTa1Ycx/せっかくパッケージが機能を提供しているのに自分の業務に合わないからと
余計なコストをかけてカスタマイズしていると。
逆に、そのツールが提供している機能が自分にとって不要なら使わないってのは
普通の使い方だな。
0915デフォルトの名無しさん
2015/03/12(木) 08:46:08.23ID:slvzoIOC0916デフォルトの名無しさん
2015/03/12(木) 08:46:30.77ID:k728FJc2作る側だけでなく使う側も頭柔らかくした方が
話はスムーズにいくわな
0917デフォルトの名無しさん
2015/03/12(木) 09:50:10.65ID:HXGIM/Mtそうそう、自分の仕事に道具の方を合わせるのは
IT業界に限らず料理でも大工でも同じだよね。
工芸品を作る人がハサミやノミから自作するとか普通だし
道具に振り回されることなく自分の道を持つのは大事だ。
0918デフォルトの名無しさん
2015/03/12(木) 09:57:26.19ID:slvzoIOC0919デフォルトの名無しさん
2015/03/12(木) 09:57:54.02ID:bakilSIy業務プロセスを効率化して担当者のクビを切りたいってことなんだから
人間の方がシステム様に従うべき
0920デフォルトの名無しさん
2015/03/12(木) 11:30:40.77ID:yGIdqSj4そんな奴はクビで良いだろ
0921デフォルトの名無しさん
2015/03/12(木) 11:35:34.08ID:JAX26FfH0922デフォルトの名無しさん
2015/03/12(木) 12:29:25.92ID:YPmUEtYXツールのやり方にあわせてるだけだと言うけど、実はツールに振り回されてるだけ。
アホやで…
0923デフォルトの名無しさん
2015/03/12(木) 12:47:23.27ID:F0MvcS+70924デフォルトの名無しさん
2015/03/12(木) 13:53:25.20ID:a1xHiT2r0925デフォルトの名無しさん
2015/03/12(木) 14:52:47.80ID:vh7FaECF日本のIT業界(限定ではないかもしれない)の問題点だな
個人レベルなら能力高い奴が多いのに、それを集団レベルの能力に高められない
個人レベルの能力によって先行していた事業が、規模が大きくなってくると海外の集団の力によって駆逐される
ソフトウェア開発は個人の力に頼った工芸品レベルの仕事じゃダメなんだよ
0926デフォルトの名無しさん
2015/03/12(木) 16:34:27.78ID:JQAIBPM0このスレ見始めたけどもうCVSでいいやと思った
0927デフォルトの名無しさん
2015/03/12(木) 16:52:11.25ID:a1xHiT2r0928デフォルトの名無しさん
2015/03/12(木) 17:42:40.38ID:Li5a03Xw0929デフォルトの名無しさん
2015/03/12(木) 17:54:24.63ID:HK8QII+7分散VCSでは結局gitの一人勝ち？
0930デフォルトの名無しさん
2015/03/12(木) 18:00:44.02ID:HXGIM/Mtそれは確かに問題なんだけど、視点を少し変えてみて、
チームメンバーはリーダーの道具だと考えるといいかも。
メンバーをリーダー仕様に改造してしまう
0931デフォルトの名無しさん
2015/03/12(木) 19:27:59.17ID:vh7FaECFチームリーダが変わらない前提ですか？ｗ
日本の良い製品ってそういうチームリーダの能力に頼ったのが多いですねｗ
そいでリーダがいなくなるととたんにガタガタになる
0932デフォルトの名無しさん
2015/03/12(木) 20:03:16.20ID:oHJi5BAm0933デフォルトの名無しさん
2015/03/12(木) 22:27:25.54ID:LbMzp29a0934デフォルトの名無しさん
2015/03/12(木) 22:38:24.17ID:dseXfxJ0逆じゃねーの、レベル高いとこはメンバー主体で動くもんだよ。
メンバーをツールなんて考えるクソ野郎の下で働きたい馬鹿なんてお前ぐらいだろ
0935デフォルトの名無しさん
2015/03/12(木) 22:58:37.78ID:LbMzp29a0936デフォルトの名無しさん
2015/03/13(金) 00:40:48.87ID:VBJF/bRa仕事のやり方が間違ってることに気付かない人もいる
0937デフォルトの名無しさん
2015/03/13(金) 08:11:51.37ID:t68YpJQlメンバーのモチベーションって、お前が考えるほど
そんな単純な話じゃないから
会社とそのメンバーの間の雇用形態とか、いろいろ
絡んでるわけで
0938デフォルトの名無しさん
2015/03/13(金) 08:41:43.65ID:Oaowwqwo0939デフォルトの名無しさん
2015/03/13(金) 09:09:16.87ID:5rFfWrMG> メンバーのモチベーションって、お前が考えるほど
> そんな単純な話じゃないから
そのとおりだな。
だからやる気がある人が、ワークフローを作って、
他の人はそのワークフローに従えば
簡単に仕事ができるっていうような
ワークフローを作った方がいい。
間違ってもいけないのは、ワークフローは意味が無い押し付けではない。
管理を楽にするためのものじゃないってこと。
開発を楽にするためのもの。だから原則として自由。
自由だけどそこに流れを作って従ったほうが楽になるようにする。
もちろんもっといい方法があれば変えてもいい。
川の流れ（フロー）がより単純に効率化したものになるのと一緒。
0940デフォルトの名無しさん
2015/03/13(金) 23:41:48.42ID:BBGHOBJy目的のブランチを全部チェックアウトしてから、「すべてのブランチ」「リモートブランチを隠す」「日付で並び替え」にすると、
思った通りの表示になりました
自己解決しました
すみません
0941デフォルトの名無しさん
2015/03/15(日) 03:25:30.42ID:zzD8LMvkそれぞれに置いてある.gitを同期させたいです。
日に1回メールで差分を送りあえればいいのですが、
このような用途に便利なコマンドってありますか？
0942デフォルトの名無しさん
2015/03/16(月) 21:43:08.19ID:QB5QI8vVhttps://github.com/git/git/releases/tag/v2.3.3
0943デフォルトの名無しさん
2015/03/21(土) 15:33:13.29ID:Q1d90rrO0944デフォルトの名無しさん
2015/03/21(土) 16:07:50.91ID:H38ILMNrそれで困る場合にあえてやるのが
fetchしてmergeなわけで。
0945デフォルトの名無しさん
2015/03/21(土) 17:46:57.56ID:Q1d90rrOpullって、fetchしてmergeしてcommitするの？
0946デフォルトの名無しさん
2015/03/21(土) 18:28:54.66ID:K0I3ekpnその後にcommitが必要ってことは、単にoriginを追っかけてるのではなく独自のコミットが混ざっててffになってないってことだろ
その独自のコミットをプルリクエスト送って本家に反映してもらえ
それか独自のコミットが要らんならgit reset --hard origin/masterしてしまえ
0947デフォルトの名無しさん
2015/03/21(土) 23:16:34.42ID:yCLS+855Pull Requestとか面倒くさいだけじゃないんですか
何で他人の修正が正しいか確認して、マージまでしてあげないといけないんですかね
責任もって自分でコミットして下さいと思っちゃうんですが。
余計な仕事増えてるだけじゃん
分散型とか言ってるけど結局マスターはサーバーに一つなわけで何が分散なのかも分からないし
addとかpushとか２度手間してるだけじゃないんですか
全然意味が分かりませんね
0948デフォルトの名無しさん
2015/03/21(土) 23:19:02.10ID:iwfo5L6e0949デフォルトの名無しさん
2015/03/22(日) 00:45:31.58ID:oZrJVPWF使いこなせないなら、無理に使わなくてもいいんだよ
0950デフォルトの名無しさん
2015/03/22(日) 01:00:18.87ID:3FK3Abm70951デフォルトの名無しさん
2015/03/22(日) 01:33:49.89ID:ak1//3lv君は多くの人に責任をもたせることのリスクを知らないのかい？
0952デフォルトの名無しさん
2015/03/22(日) 01:56:42.24ID:GQIkJ90fそれは会社の偉い人であれば
当然知っていることだと思いますが？
0953デフォルトの名無しさん
2015/03/22(日) 02:14:07.43ID:ak1//3lvだから偉い人がgitを採用するんです。
多くの人に責任をもたせるとリスクが大きいから、pull requestを使って限られた人しかマージできないようにする。
面倒くさいけど、こうすることで責任もってコミットさせられない関係者も開発に参加できます。
大規模開発になるほど大事なことですね。
0954デフォルトの名無しさん
2015/03/22(日) 02:54:16.88ID:GQIkJ90fなんで採用されないんだって文句をいうだけ。
0955デフォルトの名無しさん
2015/03/22(日) 03:01:45.75ID:ak1//3lvそらそうやろ
え、下克上でもすんの？ｗ
0956デフォルトの名無しさん
2015/03/22(日) 03:31:35.27ID:3FK3Abm70957デフォルトの名無しさん
2015/03/22(日) 04:00:52.21ID:GQIkJ90f提案とかできないんだｗ
0958デフォルトの名無しさん
2015/03/22(日) 04:33:12.01ID:ak1//3lv提案等が一通り終わっても、採用しなかったら文句いうしかないって話な
まず提案するのは当たり前。
手を尽くしてダメだったら、下克上(=自分が偉くなる)をしないかぎりはどうしようもない。
どうしようもあるならそれは手を尽くしてない証拠。
ってかものすごい脱線してんだけど。
>>947
>>951-953
の論理の流れよめてる？
>>947が面倒くさい「だけ」とメリットが存在しないと主張するpull requestだが、
偉い人がgitを採用する理由のひとつがpull requestという機能である、
それは ID: GQIkJ90f が言った「偉い人が当然知っていること」から自明に導けるだろ？、という話。
偉い人がgitを採用しなかったら、俺がどうするかなんてどうでもいい。
そもそも俺は夜中にgitのメリットを説いてるgit推奨派なのに、簡単に諦めるわけないだろｗｗｗ
俺なら偉い人にgit採用させるから、採用しなかったときの話はどっちでも論理的に正しいよ。
0959デフォルトの名無しさん
2015/03/22(日) 04:48:21.29ID:3FK3Abm7gitに替わるVCSの使い方の指導から全部自分が積極的にやるとか
gitに替わるVCSを使った結果大きなトラブルに発展したなら相応の責任を取るとか
gitに替わるVCSの良さを他の社員にも伝え仲間を作り仲間と一緒に上司や上司の上司を説得するとか
世の中を変えたいのなら相応のパワーがいる
0960デフォルトの名無しさん
2015/03/22(日) 05:16:59.37ID:ak1//3lv僕はgit推奨派だから、他のVCSを提案することはない(現時点では)。
cvs/svn/gitくらいしかまともに使ったことないが、その中では俺はgit推奨だな。
BitKeeperとかBazaarとかMercurialとか名前は分かるけど、gitから乗り換えるほどのメリットがあるとは聞いたことがない。
gitなら使えるエンジニアも多いし資料も教材もツールも多いから合意もとりやすいね。
ユーザの多いsubversionからの段階的移行もできるし。
これもgitのメリットだ。
0961デフォルトの名無しさん
2015/03/22(日) 11:20:18.54ID:dJAS/eZ72.Forkしたリポジトリをローカルにcloneする
3.ローカル環境でコード修正しコミットする
4.コミットしたソースをForkしたリポジトリにpushする
5.開発したいリポジトリにPull Requestを送る
なんでこんなに手順を踏まないといけないのバカなの
SVNだったら
1.チェックアウトする
2.コード修正しコミット
以上。
なのになんでこんな無意味に手順増やすのバカなの
分散型とか言うけどコミットせずにローカルでいつまでももってたら
Masterの最新のソースとどんどん乖離して後でコミットするときマージが面倒になるだけじゃん
Gitのやり方って面倒臭さを増やす方向にしかなってないと思うんだけどなんなん
大体Gitが良いとか言ってる奴はGitしか使ったことないんだろ
Web系でＬＬ言語使ってＧＵＩとか表面的なことしかできないバカだから面倒な手順を増やすことをかっこいいとか思ってるんだろ
GitでもSVNみたいな使い方ができる（キリッとか言うんだろうけど、それを言うってことは完全にＧｉｔはＳＶＮに負けてるってことを
認めてることになりますよね。分散型で面倒な作業増やしてすいませんって謝罪しろよ。
全然意味が分かりませんね
0962デフォルトの名無しさん
2015/03/22(日) 11:38:54.40ID:st2tKls6プロジェクト管理者がなぜそのような選択をしたかというと、個々の開発者に任せておけないから。
お前はそこまで信用できないと言われているようなもの。
SVNなら云々は信用されていない末端のざれ言に過ぎない
0963デフォルトの名無しさん
2015/03/22(日) 11:49:34.77ID:dJAS/eZ7GitGit巷が煩いからちょっと調査してるだけだ
Web系エンジニアは信用ができない低スキル技術者ばかりだから
簡単にMasterリポジトリをいじくれないようにする仕組みが必要ということですか
無能のためのツールということですかなるほど無能と一緒に仕事しないといけないなんて
大変でうね同情しますよ
0964デフォルトの名無しさん
2015/03/22(日) 11:51:56.40ID:dJAS/eZ7Issueでやり取りする時間もエネルギーも無駄だと思うんだが
全然意味が分かりませんえｎ
0965デフォルトの名無しさん
2015/03/22(日) 12:24:40.34ID:+U+vfFwl価値観なんて人それぞれなんだから。
さようなら、もう来ないでね。
0966デフォルトの名無しさん
2015/03/22(日) 12:34:14.67ID:3gWalJmt→C++はCに負けてるってことを認めてることになりますよね
という論理か
0967デフォルトの名無しさん
2015/03/22(日) 12:35:07.87ID:BPOqoFcy逆に言えば、リーダーから信頼がないからgitを使わせられてるわけ。
gitっつーのは信頼できないやつと作業した成果物の信頼性を高めるツールだよね
0968デフォルトの名無しさん
2015/03/22(日) 12:42:24.20ID:ak1//3lv> 俺は仕事ではＳＶＮしか使っていない
> GitGit巷が煩いからちょっと調査してるだけだ
あ、なるほど 使えないのね(可愛そうな捨て犬を見るが飼えないので申し訳ないといった目で
0969デフォルトの名無しさん
2015/03/22(日) 12:43:37.41ID:ak1//3lv「信用しない」側の人間やリーダーもgitを使う必要があるのですがそれは……
0970デフォルトの名無しさん
2015/03/22(日) 12:47:43.52ID:3gWalJmt0971デフォルトの名無しさん
2015/03/22(日) 12:55:22.81ID:ak1//3lv「使わせる」ことも重視してると思うぞ、っと。
0972デフォルトの名無しさん
2015/03/22(日) 12:55:57.17ID:dJAS/eZ7Git使いは３回まわってワンしてる動画をアップして謝罪するべき
結局、forkしてcloneしてcommitしてpushしてpullRequestしてとか面倒臭いだけなんや
最終的にはSVNのような使い方をするのが理想的なGitの使い方なんやろうが
完全にSVNの完全勝利
0973デフォルトの名無しさん
2015/03/22(日) 13:01:27.02ID:ak1//3lv「ＳＶＮ」だけ全角
あっ・・・（察し）
>>972
勝利って連呼するだけとか。。。。
草加かよ
0974デフォルトの名無しさん
2015/03/22(日) 13:46:41.71ID:9ijd/r0x0975デフォルトの名無しさん
2015/03/22(日) 14:29:07.85ID:nW67tQ7U> SVNだったら
> 1.チェックアウトする
> 2.コード修正しコミット
> 以上。
> なのになんでこんな無意味に手順増やすのバカなの
嘘つくなよｗ
gitだとディレクトリを作ってgit initすれば
そこがリポジトリになる。
SVNだと、まずリポジトリを作らないといけない。
面倒くさいよな？
0976デフォルトの名無しさん
2015/03/22(日) 14:31:18.91ID:nW67tQ7Usvn co svn://example.com/repo/thread/trunk thread
みたいに毎回URLを指定しないといけない。
git だと git checkout a b
これだけで済む。
0977デフォルトの名無しさん
2015/03/22(日) 14:34:06.99ID:nW67tQ7Uファイルの一部分だけコミットすることが出来ない。
これはものすごく不便で開発中にちょこっと
書き換えている時一旦それを戻さないといけない。
gitだと、git add -p などで一部のファイルや
ファイルの一部分だけをコミットできる。
svnは使いにくい以前に使えないものだっていうのがわかる事例だね。
0978デフォルトの名無しさん
2015/03/22(日) 17:49:05.71ID:3PVMrWZMまだ手元に途中でワチャワチャしたのがある状態で
でも先方の変更を手元に反映したいときってあるじゃん
特に自分が今いじってないファイルとか
そういうときいちいちcommitするのって手間じゃない？
だいたい手元でもまだcommitしたくないときどうするの？
0979デフォルトの名無しさん
2015/03/22(日) 17:49:49.76ID:3PVMrWZMそれcvsなら出来るよ
0980デフォルトの名無しさん
2015/03/22(日) 18:46:12.88ID:3gWalJmtその状況ってsvnもgitも対応方法変わらないんじゃない？
手元の変更はそのままにして先方の変更を取得すればいいだけでしょ
コンフリクトしたら手元でマージするんだろうし
ちなみにgitはsvnと違って手元でcommitしても手元にしか変化ないからcommitしたくない状況が発生しない
>>979 じゃあgit=svn+cvsなんじゃね
0981デフォルトの名無しさん
2015/03/22(日) 18:51:58.32ID:st2tKls6commitを避けることに意味はない。
pushする前に弄るのだからcommentなんて
適当につけておけばいいだけだし。
0982デフォルトの名無しさん
2015/03/22(日) 19:05:24.29ID:3PVMrWZMありがとう
そうか手元だけなんだからどんどこcommitしてもいいのか
よく考えたらそうだな
0983デフォルトの名無しさん
2015/03/22(日) 22:52:23.55ID:SQ+ft/kn＞4.コミットしたソースをForkしたリポジトリにpushする
＞5.開発したいリポジトリにPull Requestを送る
＞なんでこんなに手順を踏まないといけないのバカなの
これは、gitの「コードレビューをするために、リポジトリ反映までに
ワンクッション置く」ための機能であって、分散型とは関係ない。
とはいえ、ワンクッション置いてコードレビューするやり方が世の中で
どれほど上手くいってるか、自分には分からない。
リーダーのコードレビューの遅れは他のメンバーの作業着手の遅れにつながり、
仮に気に入らないコードを見つけても、なぜ気に入らないかを書いたやつに
説明するのもめっちゃコストがかかる。それに、数kloc分のコーディングが
完了した後のやつを見たって、根が深かったり箇所が多すぎたりしてもはや
手遅れって場合も多い。
gitのこの機能も、ないよりマシかもだが、自分にとってはありがたみは
あんまりない。
ツールの機能を活かしたいからって理由で人の作業手順を変えるのは、
とても難しい。ツールのその機能は活きたが、別の理由で開発効率は落ちた、
とかなったら目も当てられないし。
0984デフォルトの名無しさん
2015/03/22(日) 23:35:15.04ID:hieHVjt2その話はsvnでも同じ。gitに関係ない話はやめてくれ
0985デフォルトの名無しさん
2015/03/23(月) 00:25:46.96ID:oD0yNGZ6同時進行で作業してる場合にtestブランチの更新をtest2ブランチに取り入れる方法をおしえてください
git pullみたいなの
0986デフォルトの名無しさん
2015/03/23(月) 00:53:35.59ID:fJQV4FlMそうそう、svnでのレポジトリ作成、めんどいな。あとグループ開発の時のメンバー登録。
あと、961は「Gitはこんなに手順あって面倒くさい」って言ってるけど、メンバーみなdeveloperやmasterにしちまえばsvnのようにも使えるし、使い方なんじゃないかと思うんだがなぁ。
0987デフォルトの名無しさん
2015/03/23(月) 02:15:19.41ID:0YgjQ2W7＞そうそう、svnでのレポジトリ作成、めんどいな。あとグループ開発の時のメンバー登録。
svnだって、全然めんどくさくない。
リポジトリ作成なんて、visual SVNのGUIを使えば一発だし、メンバー登録も同様。
そんなとこで比べっこしてても、けっきょく何の意味もない。
0988デフォルトの名無しさん
2015/03/23(月) 02:18:26.43ID:0YgjQ2W7gitがわざわざ提供してる機能が実際に有効に機能してるかを改めて考えてみるって意味では、gitに関係してると思うが
0989デフォルトの名無しさん
2015/03/23(月) 05:36:34.33ID:BMVzdvQz0990デフォルトの名無しさん
2015/03/23(月) 06:14:57.27ID:y4ouI4960992デフォルトの名無しさん
2015/03/23(月) 07:02:19.76ID:/U7AVK6rコマンドラインでもできるし、たいして変わらん
0993デフォルトの名無しさん
2015/03/23(月) 08:10:26.30ID:BMVzdvQzヘッドレス環境で作業してる時や自動化のことを考えると、CUIのが便利だが。
0994デフォルトの名無しさん
2015/03/23(月) 10:02:47.93ID:0YgjQ2W7そもそも、リポジトリ作成なんて何回もやることじゃない＝自動化の価値ないし、
ユーザ登録だって、リーダーが自らやることじゃなく、下っ端にやらせるべき安い仕事だろう
0995デフォルトの名無しさん
2015/03/23(月) 10:57:08.04ID:5dh1GAQdcvsとなんら変わりがないので
手間がやたらかかる分gitの方が評判悪い
0996デフォルトの名無しさん
2015/03/23(月) 11:18:06.50ID:BMVzdvQzそうか、いくつものプロジェクトを任されないやつは気楽でいいな。
一式立ち上げるのスクリプトにしてる。
部下の手間やオペミスを気にしない立派な方は言うことが違うな。
0997デフォルトの名無しさん
2015/03/23(月) 12:14:29.10ID:5dh1GAQdどのくらいの頻度でプロジェクトの新規立ち上げするの？
やっぱり1日1個くらいのペースでどんどん増えていくもの？
うちの会社は半年に1個くらいしかプロジェクトないので
いつも手書きのメモ見ながら作ってるわ・・・
0998デフォルトの名無しさん
2015/03/23(月) 12:27:44.21ID:aBYp+bVstest2ブランチをチェックアウトしてる状態で
git merge test
0999デフォルトの名無しさん
2015/03/23(月) 12:59:01.94ID:iTA2cPA11000デフォルトの名無しさん
2015/03/23(月) 13:04:52.26ID:Gcg1WhfX1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。