Git 11©2ch.net

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 10
http://peace.2ch.net/test/read.cgi/tech/1403426425/

◆関連スレ
バージョン管理システムについて語るスレ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/

◆関連書籍(1)
Pro 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

◆関連書籍(2)
Git ポケットリファレンス 2012/07 著:岡本隆史 武田健太郎 相良幸範　
http://gihyo.jp/book/2012/978-4-7741-5184-7

Gitによるバージョン管理 2011/10 著:岩松信洋 上川純一 まえだこうへい 小川伸一郎
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Git 2010/02 著: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

宣伝うぜえ

　　　　 　　　　　　　　　　ノ 　　　　 ﾟ.ﾉヽ　 , /}　　　　　　...
　　　　　　　　　　　　,,ｲ`"　　　　　､-' 　 `;_' '　　　　..::::::::::::::...
　　　,-､　　_.._　　　(　　　　　　　　(,(~ヽ'~　　　　　..:::::::::::::::::::::::
　）'~ 　ﾚｰ'　　〉　　 ヽ　　　　　　　i`'}　　　　　　　.:::::::::::::::::::::::
　~つ　　 　　'-ｰ､　　i　　　　　　　|　i'　　　　　...:::::::::::::::::::::::
　／　　　　　　 <　　/　　　　　。/ 　 !　　......:::::::::::::::::::::::::　　　　これは>>1乙じゃなくて
/　　　　　　　　　~^´　　　　 /},-''　,●::::::::::::::::::::::::::::::::::::
i､　　　　　　　　,i'　_,,...,-‐-､/　　　 i　 ::::::::　　.:::::::::::::
..ゝ　　　　　　　　<,,-＝=､　　　,,-,/　　　　　 .:::::::::::　　　　　　　　　　　　放射能がうんたら
　)　　　　　　　{~''~>`v-''`ｰﾞ`'~　　　　　　　..:::::::::　　　　　　　　　　　　　　　　　　　　　　　　　　........::.
　{　　　　　　　 ﾚ_ﾉ　　　　　　　　　　　　..::::::::.　　　　　　　　　　　　　　　　　　　　　　　　　......:::::::::
ノ　　　　　　　　　''　　　　　　　　　　　..:::::::　　　　　　　　　　　　　　　　　　　　　　　 ...::.:...:::::::::
　　　　　　　　　　　　　　　　　　　　 .:::::::::　　　　　　　　　　　　　　　　　　　　　...:......::::::::::::　.
　　　　　　　　　　　　　　　　　　　　.:::::::::::.　　　　　　　　.....　　　　　 ..　　..::::::::::::::::::::::::　　　:::.
　　　　　　　　　　　　　　　　　　　　::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::..　::　 ::..
　　　　　　　　　　　　　　　　　　　 .::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::　:::　　　　::.
　　　　　　　　　　　　　　　　　　　　:::::::::::::::::　::::::::::::::::::::::::::::::　:::::
　　　　　　　　　　　　　　　　　　　　　　　　　 .::　　　 ::.　　:::

>>1
抜けてるだろ。手抜きすんな

デザイナーからプログラマーまで 絶対わかるGitバージョン管理
アリスとボブのGit入門レッスン
Web制作者のためのGit入門
わかる Git
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

GitHub
http://www.amazon.co.jp/dp/B008K411SS
※ いまなら0円！

Git作者本人の本がなんとも目立たぬ位置にｗ

300回コミットしました
ブランチも今までたくさん作って来ました
25回目にコミットしたときにログを書き換える方法を教えてください
ログに誤字があるで書き換えたいんです

>>7
テンプレ貼ったのは>>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

>>8
現メインメンテナーの濱野氏の本はProGitの次ぐらいに載せとくかねえ

2013年の本が無いのは偶然なのかな

次スレ無いのに997で埋めとか書いてたから急いで立てたわ
次は事前にテンプレ候補出しといてねえ

医療プログラマーが超高難易度の免許制に　／　フリーソフトやオープンソースの無作為配布も全面禁止
http://fox.2ch.net/test/read.cgi/poverty/1416286592/

プログラマー免許制は賛成だよ
屑が多過ぎる

>>15
お前が間違っても落第しないレベルだといいな

>>14
対象は医療ミスで訴訟を受けるレベルの深い所だけみたい

>>15
プログラマ用の資格は幾つもあるよ
それを持ってる奴だけ使うとか信用すればいいじゃん

いくつか資格持ってるが、工数がないと結局品質の低いものしか作れない。

免許を持ってる奴がランサーズやクラウドワークスに依頼して作らせれば安く済むね

それってプロジェクトメンバーの中に数人免許持ってる奴がいればいいってやつじゃねえの？

まあ医療用プログラムも医療器具になるし。

車も自動操縦制動システムとかエレベーターとかトラック荷台の自動昇降機も免許持ったプログラマに書かせろ

OSが原因で医療ミスが起きた場合は、どうなるんだろうな？

OSは初回起動時に「責任とりません」に「同意」ボタン押してるの忘れたのか

ということは、「責任とりません」に「同意」を求めるOSは、医療現場から排除されるわけか

人の命に関わるところや原子力関係には使うなって謳ってるのはOracleだっけか。

セラック25放射線事故の思い出

医者に問診受けるとき大抵Windowsの画面見るけどな

どう対処していいか分からないことがあるので教えてください。
現在、あるリポジトリＡとＢがあり、それぞれファイルを１００個ほど管理しています。
Ａ，Ｂに関連性はありません。

やりたいことは、
Ａの中の特定のファイル２〜３個を履歴込みでＢへ登録or移動したい
です。

リポジトリA,Bを新規リポジトリＺに１本化するとかのサンプルはあるのですが
上記のような場合どうしていいかわかりません。
AをBにマージしてからいらないものを削除すればたしかに必要なファイルと履歴はのこるかもしれませんが
リポジトリが肥大化するしゴミもいろいろ残りそうなので、シンプルにやる方法はないでしょうか？

>>30
git filter-branchを使ってリポジトリAの特定のファイル２〜３個だけの履歴を含んだブランチを作って、
それをBのブランチにマージすればいいんでない？

git resetってデフォルトで--softを指定したってことですよね？

リモートリポジトリにプッシュしたコミットをgit reset コミットハッシュで元に戻したらいけないっていうのを学んだんですけど
これってgit reset コミットハッシュだけじゃなくてgit reset HEAD@{n}もダメってことですよね？

>>33
当たり前。

ってかさ、子供じゃないんだから、「○○しちゃ駄目」とか「△△も駄目」ってのを一つ一つ暗記するんじゃなくて、
「○○したら××という状況になるからやらない方がいい。けど、××という状況にならない、または××になっても解決できるならやってもいい場合もある。」
ってことを自分の頭で考えて判断できるようになるといいね。

え、なんで戻しちゃいけないの?

なんでgit showのHEAD~0は最新コミットを指すのに
git rebaseはHEAD~0やHEADじゃなくてHEAD~1は最新コミットを指すのですか？

>>31
ありがとうございます。
試してみます。

試したけど、やっぱ使わないコードって、そのままbranchでpushしておくのが一般的? もっといい方法ある?

マージして即取り消しとか

>>39
pushされるの?

あー取り消しってコミットの取り消しでなくて、コード上で取り消したものをコミットってことかな。

もしまた必要になったらrebaseで簡単に持ってこれるから>>38でいいと思うよ。
ほかの人と共有するなら注意が必要だけど。

いらんブランチ消せずに増えてくのが>>38の欠点

>>39だとわかりにくそうなので、branchをpushしときます。
そこで途切れてるbranchというのはイメージそのままだし。
共有しているbranch一覧見た時も、いつも出てきちゃうのか。BTSと連携してるので、そのチケット番号をbranch名にしておけば大丈夫…な…はず。

v2.2.0

「Git 2.2」リリース、細かな機能強化や性能改善が行われる
2014年11月28日15:52 末岡洋子
http://sourceforge.jp/magazine/14/11/29/063600

なんで公式サイトから落とせるWin版がいつまで経っても1.9なの？
2.0以降がカスだから？

Windowsのことなんか知ったこっちゃないから
WindowsにはTeam Foundationがあるんだからいいじゃん

お前、Team Foundationを「チームで」使うのにいくら掛かるか知ってて
その暴言を吐くのか？馬鹿なの？死ぬの？

>>47
あれはgitじゃないmsysgitだ！

>>49
チームのサイズによるだろ
5名以下なら Express Edition で無償
普通の奴も 65,000円ぐらいだし

SubversionやGitがあるのに使ってる奴ってどの位いるんだろ・・・？

>>52
ちょい前に営業さんに聞いたら、あまり出てないですねーって言ってた
まあ、出てないのレベルはよくわからんけどか

MSのプロダクト全体からみたら我々のレベルでそこそこのでも
全然、って事だろうなｗ

>>51
取り敢えず、お前がTeam Foundationという単語だけしか
知らないという事が確定した。

何でそんなに噛み付いてるの？人恋しいの？

>>55
で、どこが間違ってるんだ？

間違ってないが、お前が単語しか知らないことが確定したんだよ。
どう思う？

本気でTFS使えなんて誰も言ってないだろ

>>52
信者はたくさんいるが、使ってる奴はいない。

>>58
なんだ、間違ってないならいいや
知ったかの御託聞かされてもしょうがないし

知ったかとかじゃなくて、実際を知っているか、その名称や存在だけしか知らないかの違いじゃないかな？
私もいくつかのお客さんとこで Team Foundation を使わされているが、費用的には想像を絶していたよ。

お布施が高すぎるとかですかね

まぁTeam Foundationがあるじゃんっていうのは半分冗談だけど
GitはLinuxのためにあるんだから、Windowsが後回しになるのは仕方ないことだろ

そんな感じで世のOffice全部OpenOfficeとかに置換されていっちゃえばいいんだけどなあ

それだと競争が無くなっちゃうからダメ。

オプソにしたからといって競争が無くなる訳じゃない

>>62
> 私もいくつかのお客さんとこで Team Foundation を使わされているが、費用的には想像を絶していたよ。

それほんとに Team Foundation の費用か？
ちょっと構成書いてみて

>>68
そんなことも知らないのか？
お前が単語しか知らないことが確定した。

>>69
構成が書けない時点で、お前が知ったかであることが確定した w

構成と言われてもお客さんのところだから勝手に実際を話す訳にもいかんのだが…
例えば、Visual Studio Ultimate with MSDNを「馬鹿正直に1ライセンス」購入すると

\1,709,940

になるってことかな…

>>71
だと思った。

お前が単語しか知らないことが確定した。

はい、次の話どうぞ

では、Team Foundation とやらに IDE が含まれると言うソースよろしく

なんか単語しか知らないことってのが余程気に入ったか心に突き刺さったか、どっちだろう？

ちなみに本当のアスペルガーは何よりもアスペ、アスペと言われるのが恐ろしくて
自分から先に「お前はアスペ、アスペ」と言い出すらしいね…

してみると単語しか知らないことってのが心に突き刺さったままになって「使わずにはおれない」
ということなんだろうなあ…ご愁傷さま…

github flowってとにかく開発用のブランチを作ってmasterにマージしていくって認識で合ってますか？

>>74
> 自分から先に「お前はアスペ、アスペ」と言い出すらしいね…

このスレで一番最初にアスペって言い出したのは誰かって
思って検索してみたらお前でワロタｗ

アスペって言いたかっただけでしょ
医者でもないのにね

余程いままで言われ続けてきたんだろうな

被害妄想に凝り固まっているのであろう。

>>72
私も単語しか知らないので、team foundationについて、費用、導入方法、メリット教えて下さい。

Team Foundation Server ならマイクロソフトの営業に電話するなり Web ページ見ればいい
http://www.microsoft.com/ja-jp/dev/products/team-foundation-server.aspx

Team Foundation なるものは ID:awyRf5UB に聞くしかない

そんな単語しか知らなくてもできるレスは求められてない

MSの製品の名前が出ると荒れる流れってなんか数年ぶりに見た気がするｗ

標準的なgit用ユーザって「git」でいいの？「gitrepo」なの？

>>82
単語以上を知らないとできない、クールなレスよろ w

あんたらそろそろ別のスレでやってくんねーかなぁ

git add -p中のオプションs (split the current hunk into smaller hunks)を、
アドベントカレンダーで初めて知った・・・
いままでずっとeでマニュアル書き換えしていたよ、、、

かならず

<<<<<<< HEAD
AAAAAAAAAAAAA
=======
BBBBBBBBBBBBB
>>>>>>> merged-branch

の形にしてくれるマージってないかな。

>>88

diff

>>88
これみたいなマージするはめになったらマージを中止する
みたいなオプションありますか？

マージテスト用にマージ先のブランチから新しいブランチ切ってそこでやればいいのに

戻せばいいだけだと思ってるけど？

abort オプションある

merge --abort

icdiffってどうなの

>>93
>>94
ありがとう！
これで助かりそうです！

昔このスレで読んだ覚えがあるんですがrubyのgollumみたいにgitを使ったwikiを作る時に使うライブラリ、誰かおしえてください

https://github.com/github/grit
>This software was developed to power GitHub, and should be considered production ready.
たょっと調べたらこんなのあったよ

TortoiseGitでどうやって分岐するんですか？
ブランチを作成、としても名前だけ変わって一本続きで分岐しません

brunch側だけ中身変えてcommitしてみ

２．２．１

これだからオプソは…
もうVisual SourceSafeに乗り換えるわ

分散型バージョン管理システム「Git」に脆弱性、任意のコマンドが実行される恐れ - 窓の杜
http://www.forest.impress.co.jp/docs/news/20141219_681222.html

そういやVSSはセキュリティパッチが一度もリリースされてないな
優秀なソフトなんですなぁ

webにさらしてVSSを使ってる奴がいるとでも

WindowsでGit使ってる人っているんだね（笑い）

MSもほぼ放置状態のVSSかあ・・・

HFS+ってMacOSXもアウトかよ！
どうなってるんだ。Appleのせいだな！

>この脆弱性はNTFS/FAT/HFS+といった大文字と小文字を区別しないファイルシステムにのみ影響するため、
>Linux環境には影響はない。

>>106
放置って...
いつの話だよ w

VSSってもう開発してないでしょ
TFSがVSSの後継って言ってるし

>>105
VSがGitに対応したので使ってるよ。

Gitを使うかTFSを使うかは、OSによって変わるのではなく、チームの内容によって
変わるんじゃないのかな。

オープンソースならGitは良いよね。
てんでバラバラに開発、試行錯誤で良かったものだけマージする。
こういった感じには良いと思う。

でも、チームのスケジュールを完全にコントロールできる、会社とかだったら、
TFSの方が良いよね。

マトモな人も居て安心した

>この脆弱性はNTFS/FAT/HFS+といった大文字と小文字を区別しないファイルシステムにのみ影響するため、
>Linux環境には影響はない。

これは嘘だな。

LinuxでもNTFSやHFS+は使えるので、
使っていれば影響はある。

>>111
会社だとマージしにくい修正が多いから
チェックアウト状態がわかるほうがいいよな

Mercurialも修正したみたいだな。
http://mercurial.selenic.com/wiki/WhatsNew
svnとかcvsとかは大丈夫なんかねぇ

>>113
NTFSはLinuxでマウントするとちゃんと区別して2つのファイル作れるぞ
HFS+は区別されないけど、Macでコマンド打ってジャーナル無効にしないと
書き込み可能でマウント出来ないんでレアケースじゃないかなぁ

レアケースを「影響ない」と断言するのは良くない

NTFSは、ファイルシステムは区別するけど Win32APIが区別しない

HFS+は、パーティションで区別設定を有効するれば
gitを使用するソースを、区別するパーティションに格納するという使い方も可能

最大シェアOSのWindowsにネイティブ対応して欲しい
MsysGitやCygWinを使う方法はあるけど、Windowsと環境変数がぶつかると
トラブルが起きることがあるので、安心して使えないのよね

何言ってるの？

大文字小文字を区別できないのにどう対応しろと

>>119
Windows版のVimを使っているところに
Cygwinを入れたらトラブったことがあるんだよ
トラブルの内容は忘れたが、原因が環境変数だったことは覚えている

推奨しないって言ってんの無視してインストーラでPATHに追加する選択したんだろ。

>>122
いや、確かホームディレクトリに関わっていたはず
どっちのVimも同じC:\Documents and Settings〜を見に行くから
そこにあったWindows版Vimの設定ファイル群が
Cygwin版Vimを使った時に更新されてしまうとか、そんなだったと思う

cygwinのホームディレクトリは全然別の場所だし、そんなところ見に行かないと思うが？

>>124
そうだっけ
やっぱり記憶が曖昧だな
当時、苦心して調べた末に
「Windows版とCygwin版のVimは環境変数の衝突により
共存使用不可」という結論に達したんだがなあ

Macは知らんけどWindowsでもどっかのレジストリいじるとNTFSで大文字小文字区別ってできるんじゃないっけ

>>125
Windows版gvimとCygwin版vimとMsysGit同梱のvimを使い分けてるが別に問題はないな。

ObCaseInsensitive を 0 にするやつか

HOME環境変数を設定していると競合する可能性はある。
なので、Cygwinの中からWin32 GVimを起動するときはHOME環境変数を
削除してから起動するとかの対応が必要。あとはTMP, TEMP, SHELLとかも注意。

Windowsでcygwin使うなら仮想環境構築したほうが楽だろ

cygwinで競合やらつまづく点があるならやめて仮想環境にして解決するのは同意
unixコマンド群やunix向けツールが手軽に使いたいだけならcygwinほど気軽なものはない
ターミナルとしてすぐ開いて使えるのはよい

mingwとminttyあればcygwinいらんね

逆にcygwinでmingwが使えるようになって、素のmingwがいらなくなった気がする

3個前のgit commitにa.txtとb.txtをコミットしたんですけど
ここ、b.txtだけをコミットしたことにしたいんです
a.txtは3個前のコミット後に編集はしていません
どうしたらいいのかおしえてください

>>134
git rebase -i HEAD^^^
# a.txt b.txt のコミットに edit を指定してエディタ終了
git rm a.txt
git commit --amend
git rebase --continue
とかどう？

a.txtは

コミットを分割したいことってよくあるよな。
もう少し簡単にできないものかと思う。

そういうのhgやbzrとか他の分散型VCSとかはどうなんだろ

rebase するしかない？

git rebase --edit 45fc20a4
みたいなオプションがあればちょっとは分かりやすいかな・・・

うちはとりあえず細かくコミットしておいて
rebase -i で squash ぷよぷよしてくっつけて行くのが多いかな
分割はめんどいよね

便秘の原因は筋力不足

Gitlab以外にローカルで軽いツールありませんか？

git そのものじゃいかんの？

>>142
git

ラボ？

>>142
gitサーバー立てるだけが一番軽いと思うが
gitlabのようなコミュニケーションには別途httpで掲示板でも構築しとけ

いかにも2chねらーらしい提案だな
とりあえず掲示板

git ローカルで使うのにサーバーなんていらん

sshdだけでいいな

>>149
gitコマンドだけあれば良くて、sshdもいらないんだよ。

リポジトリはdropboxに保存したらいいのかな

そしたらrebaseするたびに、ファイルの転送が行われるんだろうなｗ

gitlab使ってる言うからてっきり社内LANでやってのかと思ったが
ローカルというと他のマシンとは繋がない状態を意味するのか

Lovely Angle Nurse

Subversionから移るかどうか迷ってます
一人開発でリボジトリをローカルHDDに置くやり方だと
あえてGitに移るメリットってないですかね？

プロジェクトフォルダとリポジトリフォルダの対応付けがめんどくせぇ〜〜〜〜って感じてるならそれから開放される
そうでもないなら大して変わらないんじゃね

好きなVCS使え

>>155
コミットをやり直して綺麗なコミット履歴を作れるので
この行はどういう理由で変更したんだろう、
というのを後から調べやすくなる (git blame)
あとはでかいソースでも動作が早いとかかな

スピード差はでかいよなあ
むしろsvnはなんで通信しないコマンドでもあんなに遅いんだろ

Subversionやっていて悩みだったのが、

A機能修正
B機能修正
A機能のタイポ修正orz

みたいなコミット

リリース後に気づいたものなら仕方ないが、
ついさっきやらかした簡単なミスをいちいちコミットに残すのは
後からコードを見る人にとって迷惑でしかない。

svnはほとんど使わなかったな。cvs使い続けてた。

CVS ・・・ ファイル単位の管理
SVN ・・・ 複数ファイル単位の管理
git ・・・ 開発単位の管理

SVNまではファイルを管理していたに過ぎない。
gitになってようやく開発ツールになった。

githubとかそういうオンラインサービスを使わないでDropboxとかのオンラインストレージで保存したいんですけどやめたほうがいいですか？

sshは普通入ってるし
大した負荷でもないし
ローカルでもssh経由だと覚えること少なくて済む

>>163
構わんよ

ローカルでssh使ってる奴いるのか。

>>ついさっきやらかした簡単なミスをいちいちコミットに残すのは
これがわからんのだよな
そういうの残した方がいいと思うんだけど
実際下らないハマり方するのって、どうでもいいって差分だったりしない?
git のログを綺麗のするのが目的になってる感がイマイチ理解できない

仮想環境にアクセスするのにssh使うよ

何か一つ上げろといわれたら速度かなあ。
ブランチの切り替えにマージにbisectに。
もうほんの数秒だって遅らせたくない。
これはコードの品質に大きく影響する。

このファイルが漏れてたから、追加でコミット
ここのコメントの誤字直したからコミット
こんなログが残ってても意味ないし邪魔なだけ

>>170
気持ちはわかるが、そう言うのが多い奴はコードに対する意識が低く、コードの品質も低いから残しておくべき

毎度毎度ならイラつくだろうけど
結果出してりゃたまにならいいんじゃねえの

git ガーコードの品質ガーって言う奴で
適当な仕事する奴の方が手に負えん

>>167
> これがわからんのだよな
> そういうの残した方がいいと思うんだけど

なんのために？

> git のログを綺麗のするのが目的になってる感がイマイチ理解できない

コードをレビューしないの？ 一つのコミットをレビューすればいい状態と
複数のコミットをレビューしなければいけない状態、
A、B、A' ・・・今からA機能のレビューをします。A'はAの修正なので、
A＋A’で見なければなりません。はい面倒。


ブランチが複数あって（1.0リリース版、1.1開発版）
そこに1.0に緊急リリースのコミットが来た時、A＋A'の二つを持ってきて
それをまた、1.1にも、二つのコミットを持ってくる。
revertしたくなったら、二つのコミットをrevertする。
はい面倒。

ログは綺麗な方がいいに決まってる。後からログを見直すときに、機能追加のログとタイポ修正ログが同時に必要ってことなんかないしな。
コミットログの修正し直しでそいつの作ったプログラムの品質を判断したいというなら、修正した回数だけ記録するとか、修正されたログだけ抽出して確認できるとかのほうがいいわな

>>171
> 気持ちはわかるが、そう言うのが多い奴はコードに対する意識が低く、コードの品質も低いから残しておくべき

残す目的が変。おかしい。

コミットは"使う"ものなんだが。
作業記録じゃないんだよ？

コミット＝一つの機能の修正であり、
内容を確認したり、別の人が取り込んだりするもの。

その時、一つの機能が、複数のコミットに分散されていたら
使いにくいだろ。

あんた、コミットを使ったことないでしょ？
見返すこともないでしょ。

>>171
意識の低いやつは残しててもそんなの教訓にしないよ

そういう奴いる場合はマスターレポジトリへのpush権をなくして
コアメンバーがレビューした上で、そいつの個人レポジトリからpullする
って運用もできるのが利点かな

例えるなら、ボールペンで文書を書いて、
誤字脱字を訂正する。
赤ペンで間違いに丸をつけたり
取り消し線を使ったり、修正液を使ったり。

そして訂正だらけの試行錯誤したものを
他人に見せるようなもの。

レビューしてください！
見づらいだけだし、こんなのを
保存していたって何の意味もない。

完成版だけがあればいい。

>>173
> コードをレビューしないの？ 一つのコミットをレビューすればいい状態と

なるほど、レビュー前提だとログ綺麗な方がいいな
つーかレビューできるような環境なら、そもそもそこまでおかしな現象に遭遇せんかもなあ

作成中はブランチでやって
完成したらマージだろ
おまいら一々本流にコミットしてんの？

>>179
作成中はブランチでやって、
一連の機能（小さな修正の組み合わせ）が完成したら
そのブランチをレビューしてもらう

その時、タイポ修正コミットとか、途中の細かい仕様修正前のコミットとか
最終的には見る必要がないコミットがあるとレビューしづらいから取り除く。

そしてレビューが済んだら本流にマージ

だろう？ 違うのかね？

ブランチのブランチをブランチにマージだ

>>181
なんのために？

レビューしやすくするためだろ
一個上のラスくらい嫁

ミスと修正を淡々と記録していくツールで
ログに人為的に手を加えるとかただの趣味的な偽装だな

間違えた

x 一個上のラスくらい嫁

o 自分のレスくらい嫁

>>183
マージしただけじゃレビューしやすくはならんだろ。

マージする時に出来るのは、複数のコミットを一つにまとめる（squash）
そのコミットを残したままマージするかだ。
コミットを残したままマージしたらレビューしやすくはならんから除外だな。

マージすることでレビューしやすくなるということは、複数のコミットを一つにまとめるしかないんだが、
要するに俺が言ってる、途中の細かい修正のコミットを取り除くと言っているのと全く同じことだぞ。

ただしsquashだと一つのコミットにすることしか出来ない。
小さい修正であればレビューできるが、一連の機能、つまり複数のファイルへの修正を
一度に提出されてもレビューできない。

レビューするには、該当の機能（ブランチ）を、無駄のない小さな修正（コミット）の連続
という形にするのが一番やりやすい。

最終的のその形になればいいから、マージをうまく利用してそのような形を作ることも不可能ではないが
いちいち作業用のブランチを作らずにそれをもっと効率よく出来るようにしたのがrebaseだ。

>>184
> ミスと修正を淡々と記録していくツールで

そんなのを記録して、何の役に立つの？

各コミットのテストが通ってればミスだろうがなんだろうがmasterに突っ込んじゃって構わないよ。

レビューする時には整理済みのコミットにするな
ほとんどが1コミット、多くて2〜3コミット

そのままマージすればハッシュがレビューの証明にもなるし
なので基本できるだけ、ハッシュの変わるmerge --squashやmerge&rebaseはあまりしない
マスターへのマージを本人以外がする場合もあるしね
Linuxカーネルとかこんな感じだよね

>>188
> 各コミットのテストが通ってればミスだろうがなんだろうがmasterに突っ込んじゃって構わないよ。

後からそのコミットを参照するときはどうするのさ？

>>189
> なので基本できるだけ、ハッシュの変わるmerge --squashやmerge&rebaseはあまりしない

それは整理済みのやつだろ？ リリース済みのやつをrebaseしろとかそういう話はしてないよ。

今の話は、

> レビューする時には整理済みのコミットにするな

こっち。

レビューする前に整理済みにする。タイポとか、途中の軌道修正とか
そういうレビューに値しないコミットは取り除く。

残す意味は無いし、デメリットはあれどメリットはない。

あと、レビューして戻りがあった時もそうだな。


完成（のつもり）でレビュー依頼をする
問題が見つかったので差し戻し
修正して再度レビュー依頼をする。　（新たに修正コミットが作られる）

を何回か繰り返す。

この場合の差し戻しの修正コミットは、最終的には必要ないので
masterにマージされるまでの何処かで削除するべき。

>>191
ああ、ごめん否定じゃないよ。
> レビューする時には整理済みのコミットにするな
自分はレビューする時には整理済みのコミットにしているよ。って事で、
人に見せるものはできるだけ1コミットが好き。

>>192
修正前のブランチは無効って事にして
また整理済みのコミットにするね。

gitでコミットが整理できるようになってからは、
バージョン管理よりもコードのドキュメント化をしている
って意味合いが強くなってきたね

>>193
否定ではないと思ったけど念のため。

わかってない人は、コミットを何のために残すのか？
ってのがわかってないんだろうね。

バージョン管理ソフトで管理するのは成果であって作業じゃないんだよ。
これだけ努力しました〜とかこれだけミスしました〜とか
いちいち途中でやったことを記録しても意味ない。

成果（最終的なコミット）を見たいのであって、それに至る作業はどうでもいいわけで。

>>190
すまん、意味がよく分からなかった。
普通にsha1ハッシュから指定すればいい。

ログを直したくないなら水銀つかえで終わる話
Gitに粘着すんな

>>196
後からそのコミットを参照する時、
Aという機能のコミットが、a、a'、a''と分かれている時に、
a''で完成しているのに、aを参照したってしょうがないって話。

aを参照して、これバグっているな。いやいやa'で修正されてるじゃん、
みたいなことをやっても無駄になる。

水銀燈

Hard gay

Ruby - [翻訳] 私のコミットをまとめないで - Qiita
http://qiita.com/gogotanaka/items/8c55f69120965b077737

>>201
まさにこれだね。

> 私が思うに多くの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でちゃんと修正しろと。

>>198
それこそ、aの変更でキチンと失敗してくれるようなテスト書いとけよって話だな。
でないとa'でホントに修正されてるかも怪しいし。バージョン管理関係無い。

そこらへんのコンセンサスが取りづらいならファストフォワード禁止にしてもいい。
あとで「なんか動き怪しいからお前のマージコミット取り消すわ」ってできる。

正論

>>203
> それこそ、aの変更でキチンと失敗してくれるようなテスト書いとけよって話だな。
> でないとa'でホントに修正されてるかも怪しいし。バージョン管理関係無い。

それは理想論。

テストが通ればOKというのなら、レビューそのものの存在意義を否定していることになる。
レビューはするべきだし、レビューで戻りが出て修正するのは当たり前に発生すること。

第一、テストが通ったって、現にバグは存在しているわけで、
あんたがいっていることは現実とかけ離れている
テストを書くことを忘れることだってある。それを見つけるのがレビューでもある。

リリースしてしまったバグは、rebaseでなかったことには出来ないが、
レビューした後の戻りとか、テストで検出できないタイポとか、
リリース前の修正をいちいち残す理由がない。

残してしまったら、あとでリリース内容をみた時に混乱するだけ。
コミットの内容を後で使う。ということを考えないで単なる作業履歴としてしか
みてないから、>>201のいうように"思いつくままにコミットを作"ってしまって、
その汚いコミットをそのままマージしてしまうか、小さいコミットに分けずに
ブランチ全体を一つのコミットにまとめてしまうことになる。

元に質問そっちのけで大暴走してるなｗ

それから、ブランチ（1つの機能）が複数のコミット（細かい修正）の
集まりであることを理解していない。

機能αがあった時、それを構成するのが、a, b, c, dというコミットだったとする。

a, b, c, dというコミットはαを作るために必要な修正であるが、
全体であるαの仕様が変われば、その仕様を構成a, b, c, dの内容も変わる。

場合によっては、aの機能を変えないといけないかもしれないし、
bの修正は不要になるかもしれない。

αが完成するまでは、a, b, c, dは完成しない、つまり後から修正が入るんだよ。

図解して

>>205
何か勘違いしてる。
「マージする」という行為は「レビューしましたよ、私はOKですよ」と言っているのに等しい。
勝手にマージしといて「お前のコミットのせいで足撃ったぞバカ！」も何もない。
マージからの多分SVNと同じように中央集権型で運用してるんだろうけど、
マージからのレビューじゃなくて、レビューからのマージにしないと回らないよ。

あと、リリースしたバージョンにはきちんとタグをつけること。
後から見直したいならタグ付けされたコミットだけ追えばよろし。
問題箇所が明らかならblameすればいい。

タイポや戻りの修正を残す理由が無い、というのも間違い。
それは単にログが見づらいからというだけで、
アウトプット側の問題をインプットでなんとかしようとしてる。これは破綻する。

そうじゃないでしょ。一旦公開した修正は必ず残せ。
公開前に気づいてたならrebaseで整形できる。
マージ戦略はコミットIDが頼りだから、公開後のツリーを弄りはじめたら
そこらじゅうでコンフリクトして迷惑かけることになるよ。

可能な限り綺麗にしてたいってのは同意見だけど、
潔癖症がたたって本来の目的を台無しにしちゃ本末転倒でしょ。

ほー

>>209
勘違いしてるのはあんただ。

> 「マージする」という行為は「レビューしましたよ、私はOKですよ」と言っているのに等しい。

じゃあ、マージする前にレビューするということだろ。
レビューするということは、OKになるかNGになるかということ。

レビューした後にNGになったら、マージしない。
マージせずに何をするかというと、そのブランチを修正する。

そのブランチの修正とは、たとえばタイポの修正のような簡単なものから
関数の引数名前や、仕様そのものの修正までいろいろある。

aという内容に修正しようと思ったら、問題が発生して
最終的にbという内容に変わった。「問題があるa」を残す必要はあるか？
何のために？ その理由が言えないならば、「ない」で決定だ

> それは単にログが見づらいからというだけで、
ログ、つまり過去のコミットが見づらいことが問題にならないということはなぜか？

それはコミットを見ようと思っていないという証拠。
過去のコミットを使うことがないから、過去はどうでもいいやって考えてる。

> そうじゃないでしょ。一旦公開した修正は必ず残せ。
公開とはmaster（などの本流）にマージされた状態だ。
レビュー前は公開されてない状態だ。残す必要はない。
マージ前が非公開状態であることをわかってないね。

>>209
> 勝手にマージしといて「お前のコミットのせいで足撃ったぞバカ！」も何もない。

あ？ そうか、お前、「ブランチを誰から見える場所にプッシュする」
という機能を知らないな。

いきなりマージしてるだろ。

お前の言うレビューはブランチを作らないで、適当なディレクトリに
コードを置いて、レビューしてくださいってやってるだろ？
実際にはコードのレビューは含まれていなくて、コードを見ない動作テストのみ意味してそうだが。

>マージ前が非公開状態である

えっ

>>213
他人が見えるという意味では公開だが機能としてはまだ非公開
作りかけであり公式機能として搭載されたものではない。

>>211
もう一度言うよ。
アウトプット側の問題をインプットでどうにかしようとするのは間違い。

あなたは目的に合ったログの効果的な閲覧方法を知らないだけで、
SourceTreeやgitkのグラフがデフォルトでゴチャゴチャ入り組んでるのが
堪忍ならないって喚いてるだけ。
マウスのホイールまさぐりながらしかめっ面してるのが目に浮かぶ。

なお悪いコトに、それをインプットの問題と決めつけて「サニタイズ」しようとしてる。

レビューされてる状況はどう考えたって公開状態だって。
公開してもらわないとそもそもレビューできない。

ギット？ジット？ちょっと興味をもったので、なにか書籍を買ってみます

>>212 の職場環境を察すると同情を禁じ得ない。
あとコミットログ読めなくても日本語はちゃんと読もうな。

>>216
日本語で入門に最適な電子版の本が無料で公開されてますよ

二人の脳内状況がまるで違う、まで読んだ

git な人たちってレビューなしの環境はありえない感じなのかな?

なかなかアツい議論だがどっちも、そこまで間違ったこといってるとも思えないけどな。

運用が回ってるなら、こだわるところでもないと思うのだけど、レビューの所は気になった。

リリースもしないレビューのためのブランチをレビューしても意味ないだろ。
レビューが完了したらコミットはいっさい必要ない。そういうものを使わないとレビューした意味がなくなっちゃうぞ。

スレのこの調子じゃレビューとやらもｇｄｇｄになりそうだね

>>221
> リリースもしないレビューのためのブランチをレビューしても意味ないだろ。

どういうこと？ レビューしてOKになったら、そのブランチをリリースするんでしょ？
レビューするということはNGになることもあるわけで、
そのブランチを手直し、最悪取り消しになることもあるけど。

> レビューが完了したらコミットはいっさい必要ない。
レビューが終われば、完璧でありバグが一切入ることが
一切ないという前提ならそのとおりだね。
実際に、そんなことが起こることはありえないけど。

なぜレビューが完了したら（レビュー不足でバグがあって将来再度レビューすることになるかもしれないのに）
コミットが必要なくなるというの？

レビューにコミットが必要ならば、将来起こりえるかもしれない再レビューでコミットが必要になるはずだけど。

>>220
gitにかぎらず、レビュー（とテスト）は必須でしょ？

人が足りない、そんなことをやれる力がないというのは
単にそのチームの問題であって、必須かどうかは別。

本来やるべきものをやらないだめなところっていうのは
どうしてもあるもんだよｗ

>>219
> 二人の脳内状況がまるで違う、まで読んだ

俺的には、

過去やったことは見返すことはない。
他人の修正内容を見ることはない。

という人と、

過去やったことを見返すことはある。
他人の修正内容を見ることはある。

という違いだと思うよ。

ソースコードがいくら汚くても、動けばOKみたいに考えてるんじゃないかな。

迷惑なやつだな
一緒に仕事したくない

だいぶ亀レスだけど

>>142
軽さならgitbucket

>>223
運用の違いなのだろうけど、レビューはある工程の仕上げにするものだから、どんな理由にせよ変更したなら再レビューはするもの何じゃない？

指摘の修正、バグの修正がおわったらそれをみるでしょ。


んで、レビューしたブランチをそのままリリースしていくなら、意味ないと言うのは間違いだった。
僕のアタマの中だとリリースはmasterでブランチは開発途中か緊急のパッチというイメージなのでレビューしたあとマージかけたらまたレビューしないとだめじゃんと、そんな話

Git はあなたの使い方を固定し縛るものではない

> レビューはある工程の仕上げにするものだから

それだと遅すぎですね。それでは出来てしまってから
想像していたものと違うってことになりかねません。

作りかけでも必要と思った所でレビューするべきです。

>>224
レビューってさ、複数人が現実的な時間で理解できるレベルのコードってことだよね。
専門性が高くて、そこに価値があるコードを含む場合どうするの?
結構そういう仕事が多いんだが、なんとかしたいんだよな。
もう git の話じゃないような気もするがw

>>231
s/レベル/類い/

なんか読み直したら上からだったすまん

> 専門性が高くて、そこに価値があるコードを含む場合どうするの?

どんなに専門性が高いものであっても
専門性が高い部分と、そうでない部分に分けられる。

それらを分離してコミット（マージ）する。

現実的な時間で理解できないのは、コード内容が複雑だから
複数の関連のないコミットがまとまっていたり、
本来一つにまとめるコミットが分散していたり、
それらを一気にやろうとするから理解できなくなる。

コミットを適切に整理することが、理解できるコードにするための第一歩

そうすれば専門性が本当に高くて自分しかわからないようなものでも
それを最小限の量に抑えられる。

> 現実的な時間で理解できないのは、コード内容が複雑だから

シェーダなんかコードが複雑とかそういう問題じゃないんだよね。 AI とかさ。
メンバー全員が理解すべきかというと、それはありえないし。そりゃ理解できたら凄いけども。

こういうのはレビューよりも、困ったときの bisect 対策で、どうでもいいコミットにも残って欲しかったりもする。
レビューで解決できるなら、そっちの方が絶対スマートなんだが。

コードレビューってアルゴリズムが合っているかとかそういうのは見ないでしょ
正しいかどうか見てたらキリないよ
アルゴリズムが正しいか、それが正しく実装されているかはテストで見るべき
コードレビューはtypoしてないか、コーディング規約守ってるか、
変な書き方(無駄なループ、誰が見ても可読性の低いオレオレ制御構造)してないか、
とかそういうのでしょ、コードレビューで確認するのは
そういうのなら専門じゃなくてもある程度わかるはず

>>234
> こういうのはレビューよりも、困ったときの bisect 対策で、どうでもいいコミットにも残って欲しかったりもする。

どうでもいいコミットが残っていたら、逆にbisectしづらくなるだろ。

>>235
コードレビューは体裁が主体と言うのは同意するが、一応、仕様を満たしているか、性能を満たせるかの観点もみるべよ。

あと、マージしたときにおかしなゴミを作ってないかも気にするかも。
こっちはレビューの時というより差分取り込んだ時のチェックだけど。。。
差分をvimがっつり食わせてちまちま見てく人
guiとか、めんどくさすぎて差分おっていられない。

>>235
> コードレビューってアルゴリズムが合っているかとかそういうのは見ないでしょ

そりゃもちろん。

> そういうのなら専門じゃなくてもある程度わかるはず

うーん、そうか、まあわかるならいいんだけど。


>>236
bisect に頼むのって理屈じゃ解決できないことが多くて、ヒントはクソでもいいから残って欲しい場面があったんだよなあ。
コメント変えて動かなくなるとかw
どうせ二分探索なんだから、そんな時間は増えんし。

ただ、レビューだとか git らしく使うこと考えると確かに汚なくなるしなあ。
うまく混在できんもんかね?

UMLとか設計の段階でレビューしてれば、コードレビューってプログラマーの勉強会みたいなもんじゃないか。

質問です

git hash-object ./hoge でとったSHA1ハッシュが、
openssl sha1 ./hoge でとったSHA1ハッシュと違うんですが、
これはこの当然のことなのでしょうか？

ひとくちにSHA1と言っても、オクテットストリームからSHA-1を計算する方法にいろいろあるということでしょうか？

教えて偉い人かエロい人

>>240
gitはヘッダを付けてからsha1を計算してるので、ファイルのsha1とは一致しないよ。
http://dqn.sakusakutto.jp/2013/10/git_sha1_how_to_calc.html

>>241
ありがとうございます
ヘッダついてたんですね

ためしにヘッダを自作して hoge_with_header を作り、
$ openssl sha1 ./hoge_with_header
してみました。
$ git hash-object ./hoge
と同じハッシュ値が表示されました！
(∩´∀`)∩ワーイ


よく分かりました
エロい人、どうもありがとうございました

よくがんばりました(花まる)

githubを使ってコードレビューする流れをおしえてください

１．github上に存在しないユニークな名前の開発用ブランチをローカルに作ってコード書きました
２．コミットしました
３．githubに開発用ブランチの内容をプッシュしました
４．プルリクエストを作成しました
５．プルリクエストからコードをみてレビューします

こういう流れであってますか？

OK

指定した範囲の行数のみコミットする方法教えてください

gitは>>246が簡単にできるからいいよね。
subversionの時は苦痛だった。

git gatter elを使うんだ。
あるいはgit add -p→git commitだ。

>>246
SourceTree使え。

SourceTree重すぎ

tig使え

SourceTreeはいいんだけど、重すぎなんだよなあ・・・
しかも内臓に切り替えてみたらさらに重くなった。システムに導入して使ったほうがいいな。
GUI使わないならMSYS2でgit入れて使った方が快適。

SourceTree重いって思ったことなんてないけど、Windowsの話?

vim ユーザーなら、有名だと思いますが fugitive.vim というプラグインがおすすめです。
特に vimdiff を利用した部分ステージング（って言うのか？add -p のこと）がとても使いやすい。
あと最近 agit.vim というのも導入したが、これも軽くて気に入ってます。

>>253
ブランチを切り替えるときとか重くない？

Vistaにインストールするには.Net4.0を手放さなければならないからSourceTreeとかくそすぎる

>>255
Macではそんなことないけど・・・
Windowsの話だろうと思って、試してみた
Windowsでは確かに重いね

winだとmsysとかcygwin使わない限りgitが1.9.5の上すごい遅い。特にrebaseは地獄。

>>254
入れてみるわ

GitでPull Requestを送りたいと思っているのですが、対象のリポジトリはとても頻繁に更新されています。

例えばコミットAの時点でクローンし、修正しプルリクエストを送ろうと思うと対象のリポジトリは既にコミットB、C……とどんどんコミットされていきます。

この場合にPull Requestを送ると迷惑になるでしょうか？

また、どのようにPull Request 送るのが良いのでしょうか？

>>259
気にせず送るべし
けど自動テストが通らなかったりマージでコンフリクトするような状況にある場合はリベースしてくれとか言われることもある

>>259
一番初めのプルリクエストでマージコンフリクトが起きるのはだめだろうな。
少なくとも一番初めは、出来る限り最新のコミットからの修正である方がいい。

でも、常に最新でなければならないというわけでもない。
なぜならプルリクエスト出した後でもコミットは追加されるから
どちらにしろ、最新にならないから。

コンフリクトが起きなければ、たいてい問題ないし、
コンフリクトが起きれば、その時修正すれば良い。

コンフリクトが起きた状態ではマージできないのだから
どちらかが解決するだけの話。

コミットの幅が大きすぎると
マージコンフリクトしたときに
修正する範囲も大きくなりすぎて面倒になる
出来るだけ小さいコミットに分けて
マージコンフリクトが起きにくくするのが良い

>>260-262
みなさんありがとうございました

Aブランチのa.txtの最新をBブランチでチェックアウトする方法をおしえてください

git checkout B
git checkout A a.txt

レポジトリーの中にレポジトリーを入れるのは可能ですか？

サブモジュールとかそうなってんじゃねえの

２．２．２

rebase -iで指定した当該コミットが修正できないのはどういう思想？
commit --amendで「直前の」コミットを修正するのだから
素人考えでは当該コミットも編集対象に入れてくれてもよさそうなものだが

ま、実害はないんだけど
どうにも慣れない

amendが直前のrebaseの別名と思え

aブランチはa.txt編集用
bブランチはb.txt編集用

aブランチで編集した時に、山下くんがb.txt修正しといてよっていってきました
このときaブランチはまだ作業中なのでコミットしないままbブランチでさくっと修正してコミットして、またaブランチで作業を再開するためのコマンドの流れを教えてください

そういう時はさくっと一時的にでもコミットしちゃうのがgit流
でも、頻発するようならcontribにあるgit new-workdirで作業ツリーを別に作っとけば便利

一応その場合に対処するための機能がstashじゃないの
git stash
git checkout b
修正、コミット
git checkout a
git stash pop

git add .
git commit
git checkout b
b.txt編集
git add .
git commit
git checkout a
編集
git add
git commit --amend
こうはどうか

すぐに作業に戻れそうならstashだな。

時間が掛かりそうなときは、コミットしている。
コミットした後元に戻って、git reset HEAD^ すれば
作業中状態に戻せる。がそのまま続けてあとでrebaseやsquashすることもある。

Windows版は完全にメンテナがやる気を無くしてるな…

ごめんてな

SJISのテキストに対応して欲しい
UNIX混在環境ならともかく、Windowsに閉じた環境で
わざわざUTF-8でテキスト書くヤツなんていないから

そうでもない

今更SJIS使うやつなんて居るのか。

機種依存文字とか撃たせる気なの？

UTF8なら機種依存文字という概念自体が
ほとんど無くなるからな。
そんな文字も含めて全部収録されてる。
絵文字までも使い放題

✁
✉
〄
➟
✰
この5つの絵文字Windowsで見える？

文字があるかとフォントがあるかは別の話では。
htmlだと実体参照で文字コードによらずにUnicodeの文字は示せる。

>>283
俺のガラケーでは見えない

>>283
見えてる。

gitってハードリンクを使うことで高速なブランチ切り替えを実現していると
思ってるんだけど、ハードリンクが使えないファイルシステムだとどうなるの？

ハードリンクを使わないで同じことをしている？
ということは遅くなりそうだけど。

別にハードリンクなんか使ってないが
ていうかハードリンクを使ってどうやってブランチ切り替えを高速にするんだよ

自己解決しました。

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

リポジトリをクローンするときリモート先が同じファイルシステムの場合はハードリンクを使う方法があると書いてある
ブランチ切り替えとハードリンクについて>>289のリンク先には何も書かれてない

もしかしてこれは釣りというやつなのか

>>290
勉強したら？
http://ton-up.net/technote/2013/11/17/study-git-internals/
ファイル内容が同一だった場合、同一blobへハードリンクする

Gitって差分管理してないのか！知らんかったので勉強になりました

でも結局ブランチの切り替えとハードリンク関係なくね

>>291
その記事書いた人、いろいろ分かってなさそう。
ハードリンク云々は、あるファイルの中身がバージョンxとyで同じなら、同じblobを参照するってことでは？
その直後のgit gcの説明もメチャクチャだし。

>>292
普段はファイルごとに圧縮するだけで差分は利用してないけど、git gcすれば差分も利用して圧縮するよ。
ただし、cvsやsvnと違って、論理的なデータ形式としては差分は利用してない。

ハードリンクしたらファイル変更した時blobまで書き換わっちゃうだろ

ハードリンクのあるOSでls -laしてみるだけだろ
使ってない、でFA

そりゃファイルの中身が違うならば使ってないだろうさｗ

ハードリンクじゃなくてコピーオンライトでは

>>296
そこまで言うなら自分で試してみろ
理屈で考えても>>294の言う通り、ハードリンクの余地なんて無いんだからさ

とりあえず>>291の記事の「ハードリンク」は確実に嘘で、これも試せばわかる

>>297もちょっとおかしいぞ
gitは変更も新規ファイルも区別ないし、オブジェクトは使われなくなってもgcするまで消えないんだから
寿命管理自体してない、する必要ない

>>298
git の object 機構が、user-mode fs のように既存のファイルシステム上にもう一つのファイルシステムのようなものを作っていて、ファイルシステムのハードリンク機能と同じような仕組みをユーザランドでやってるってだけの話だよね。
全体的なデザインが、zfsっぽいなあと思った。

>>291
＞ファイル内容が同一だった場合、同一blobへハードリンクする
同じ内容のファイルのblobは同じハッシュを持つ
treeからblobへの参照はこのハッシュ使っているから同じ内容のファイルのblobの実体は一つになる
しかし、この参照にOSのハードリンクは使って無い

結局最初の人以外は誰もOSのハードリンクを使ってるなんて思ってないので終了

使い初めの頃、速いからハードリンクかと思ったけど、リンク数が1だったので、ないなと思った。

ネットワーク上からサブディレクトリだけ取得できますか。

https://www.youtube.com/watch?v=GfCtux5pjAI

開発用ブランチでgit add .;git commit -m "aaaa"っていうのを
git ac "aaaa"でできるようにしてるんですけど
まちがえてgit "aaaa"ってうっちゃってコミットしてなかったんですよ
そのあとコミットしたつもりでgit checkout master; git merge developやって初めてマージされてないことに気づいたんですが
ここで僕がコミットしたかった内容を取り戻す方法ありませんあk？

節子
それあかんやつや

そして、コミットしてないのにmasterブランチに移動できたのがよくわかりません
コミットしてないとブランチを移動できないはずなのに

まだワーキングコピーに残ってて git diff HEAD すると出てこない？

addでステージ済なら復活させられたはず
fsckとか使ったと思うけど調べてみて

ブランチ切り替え前後でいじったファイルに変更がなければブランチ切り替えできるね

ブランチの管理にgit-flowってのが便利そうだけど、使ってる人いたら利点や感想など教えてもらえますか？

Google先生に頼めば大量に解説されている記事を紹介してもらえますか

>>312
個人の開発に向いた機能だと思いますか？
チーム開発では便利そうだけど個人で使うには冗長な機能が多いと感じます

解説された記事を読みましょう
その上で自分の開発に取り入れる上でどのようなメリットがありデメリットがあるかを考えて総合的に選択するかしないかは自分で決めるべきでしょう
どんなものにもやらなければならない縛りはないのです

git init
git checkout -b test
touch a
git add .
git commit "first"
git branch

１．なんでmasterブランチがないんですか？
２．initすればmasterブランチが作られないんですか？
３．masterブランチってどこで作られるんですか？
４．この場合masterブランチはどうやって作ればいいですか？masterブランチって特別なブランチですよね？git checkout -b masterで十分でしょうか？

いろいろ記事を読んでみましたが、初心者は実際にやってみないとわからないなという感じです。

下の記事でgit-flowとgithub-flowの比較をしてますが、これらの機能の経験者の方は同意できる内容ですか？
特に結論のこの点が気になります。
＞ GitHub-flowを採用しよう → おそらくこういう考えに至る人が多数派なので、git-flowの利用者が減ってきている・・？

http://qiita.com/jshimazu0820/items/066e061eef700caa1c68

>>316
統計的なデータは見たことないんだが、こういう話もでてるみたいだね。
「develop ブランチなんてオワコン」 http://togetter.com/li/673629

個人的にはgit-flowは面倒すぎるので試したことすらない。
チーム開発でも躊躇するくらいだわ。(GitHub flow派でもないが)
とはいえgit-flowがうまくマッチするプロジェクトもあるかもしれない。

コメントから初心者なのかなと思うけど(違ったらごめん)、
Gitの操作に慣れてくるとどのフローがプロジェクトに合うか判断できるようになると思うので
色々試してみるのが遠く見えても近道じゃないかな。がんばって。

>>315
> １．なんで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

アホなコンサルがネットに書いてあるからって理由で
git-flowなんかゴリ押しするんだよなあ
実情に合わねっつーの

まずはアホなコンサルを呼んでいるアホを糾弾しろ

git でコンサル？

>>317
ありがとうございます。Git初心者です。
GitHubは使っていないですし、一人で開発してるので第三者にコードレビューしてもらうのも不可能なので
GitHub flowは候補にならないのかなと思いました。
とりあえずgit-flowをインストールしたので試してみます。

>>319
初心者が「ブランチ管理ってどうやるんだ？」とネットで調べたらgit-flow・github-flowに行き着きました。

ちなみにwindowsでgit-flowのインストールをググると日本語でこのページが出てきますが
若干内容が古くなってるようです。
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

最新コミットのところでgit checkout ハッシュ:ファイル
で戻った後やっぱり最新のコミットにもどしたい場合はどうするのがいいですか？
もう一回git checkout 最新ハッシュ:ファイル
で戻るのがベストですか？

>>322
そういうことなら
http://d.hatena.ne.jp/kazuhooku/20140204/1391479663
くらいのシンプルなフローでスモールスタートすればいいんじゃないかな。
他のフローほど複雑じゃないし、基本は抑えてある。

あとはブランチやコミットの分割・統合とか、自信持ってできるくらいまで
Gitの操作に熟練すれば自分でどうすべきか見えてくると思う。

>>324
git status の出力をよく見たら、どうすればいいか書いてないかな？

>>323
残念ながら git-flow 界隈の最新情報にはあまり詳しくない。
WindowsならSouceTreeというGUIツールがgit-flowをサポートする機能を持ってた気がする。
LinuxとかならちゃんとCUIでGitの操作に習熟したほうがいいんじゃないかなと思うが、
Windowsメインならそういうツールのアシストに乗っかるのも手だと思う。

>>325
参考になります。
テストファーストじゃないですが、シンプルなフローという考え方自体イメージ出来ていませんでした。
その考え方で自分には十分そうな気がします。

>>327
インストール自体は>>323で動作確認しました。

OpenShiftというwebサービスを利用してPaaS環境で開発してますが
Gitでpushしたものが即webアプリケーションで動きます。
OpenShiftは、CUIでのGit/サーバ操作が基本になっています。
windowsでも実用的に問題なく扱えますが、やっぱりwindows独特のトラブルが多いと感じます。

一人で Git を使っています。daily branch に commit をためて、切の良い所で master
に --no-ff で merge する程度のやり方で済ませています。

ただ、bug 対策、feature 追加、テスト追加、ドキュメント、ソフト関連メモのために
専用の tracking git directory を設けて、 org mode テキストで管理しています。
Redmine 等も調べたのですが、大げさな割りに自由度がないので自己流のテキスト・
ファイルの塊ですませています。でもプログラム・ソース git との関連が破綻気味に
なってきています。同じバグに複数のシリアル番号を与えることが出たりしています。

小規模なソフト開発で、皆様がプログラム・ソース git と関連文書を どのように管
理・発行しているのか教えてもらえますでしょうか。

何をテキストで管理しているのか全くわからんが、
ソースとドキュメントが関連がごちゃごちゃになるなら
ソースコード自体にドキュメントを埋めればいい。
ソースコードからドキュメントを生成することは簡単。
関連するものが分散しているのがそもそもの問題。

Issueの話ならgitで管理するのが間違い。
githubを見てみればわかる。
gitとは別の「github」というシステムで管理している。
金が無いなら、gitlabでも使えば良い。

ぼくはね開発は全部developブランチを作成してそこでやってるんですよ
そしてmasterにコミットして言ってるんですよ
そして切りがいいタイミングでタグつけてるんですよ

>>329
> 同じバグに複数のシリアル番号を与えることが出たりしています。

だから Redmine なりを使いなさいよ
どんな自由度が欲しいのかよくわからんが、
> bug 対策
だけなら、素のままでも使えるでしょ
俺は一人で Trac + Subversion 使ってるけど、便利だよ

GitもRedmineもチーム開発のためのツールでしょ
それを一人で使えば、ツール使用に要するエネルギーが使用効果を上回り非効率となる
一人ならフォルダ丸ごとコピーして連番を振っておけば十分

一人でもそんな管理方法イヤすぎるｗ

真面目な管理が必要になるほどでかいプロジェクトを一人で開発するってことあるか？
俺は面倒だから出来る前からGithubに上げて、ぶつぶつ書いたissueを勝手に誰かがやるのを期待しながらコードを書いてる。

>>336
テキトーにやってもそれなりに管理できるのが git/Redmine とかのメリットなんだが w
ログなんて書かなくたって修正した日時とファイルの差分がわかれば色々思い出すし
Redmine をメモ代わりに使うのもありだし
まあ、無理には勧めないけど

修正日時と差分が知りたくなるようなものはGithubに上げるよ。

俺も一人だけどredmine+gitだな。
現に>>329は破綻しているのだから、それよりは効率的だろう。
sqliteだと複数人で使う気になれないし、言うほど大掛かりなのかなぁ。

開発者が私だけであっても機能Xを開発する私と修正Yを開発する私は
物理的に一人かもしれないがやっていることは違う人。
XとYの作業に時系列上のオーバーラップがあるなら、
ローカルリポジトリに閉じていてもそれは本質的には分散作業ということだ。
一人で使う作業が中心であっても、そこを理解してる人は
分散型でないVCSには戻りたくないと思うよ。

tracって使いやすいですか？redmineと比較してどうですか？

このスレを見るくらいはGitを使ってる人でも一人ならフォルダ管理でいいっていう人もいるのか
にわかには信じがたい

>>329が答えじゃないか。

そのやり方をしていて破綻してしまっているから
悩んでこうして書き込みをしている。

複数の人でもIssue管理可能なシステムを
使えば、当然一人でも管理可能

半日程度で終わるくらいのプロトタイピング時はディレクトリコピーでいいかなーとは思う

5分10分で作ったアプリはファイルに保存すらしなかったりするしなぁ

>>329 です。皆様 issue 管理についての御意見ありがとうございます。

私のソフトは数万行の規模であり、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 管理しか方法は無いとするのが現在の私の
考えです。

なんかエクセル方眼紙的な使い方だな
そんなに合わないのならBTSも作っちゃった方が良いんじゃないか

Githubにあげて楽になれよ。俺はソースをもらってく。

>>341
好みの問題だと思う
プラグインも色々あるから、自分のやりたいことがあるなら BTS スレで... って今見たら BTS スレないのな
まあ、両方ともネットに情報ゴロゴロ転がってるから調べてみればいい

>>342
ネタ振りでしょ

ネタ振り〜してる間に〜

>>346
まあ、自分一人でオレ流のやり方通したいなら勝手にすれば良いと思う
世の中で誰もそんな使い方してないっていうのはどういう事か理解できないなら仕方ないね

そのソフトでなんらかの事業をやってるとして、将来その業務を第三者に引き継がせることが出来るんだろうか。
自分の代でおしまいだと決まってるのなら、自分しか理解できない仕様でもかまわないと思うが。

>.346
なんでバグを見逃したのか、バグが埋もれたのかというと
それはツールが使いにくいからだよ。

完全に防ぐことは出来ないが、Redmineやgithubやgitlabは
それらの問題を見つけやすいインターフェースにになってる。

それに開発中にIssueをコミットなんかしてるから
埋もれるんだよ。あとで詳細を書こうと思って
今は仮で見つけたものを登録しておくとか
TODOを作っていくとか、そのたびにコミットするから
コミットログがごちゃごちゃなって埋もれるわけ。

githubでプルリクするとき、修正が以下のような３点だった場合、どういうまとまりで出せばいいでしょうか？
コミットはそれぞれ別になっていますが
リクエストを複数にする？ブランチを複数にする？全部まとめて1回のリクエストでいい？というあたりがよく分かっていません
修正内容
１．ほぼ間違いなくマージされるであろう修正（ドキュメントの更新）
２．ほぼ間違いなくマージされるであろう機能の改善（１とは関係ない）
３．マージされるかは微妙な機能の改善
（マージされるされないの推測はもちろんこちらの勝手な想像です）

逆の立場になって考えてみろ
お前がプルリクを受けた場合どれが一番嬉しい？

俺は面倒だから全部一気に送る。
送られてきた場合は、ほしいところまでpullするなりcherry-pickするなりする。

正直、プルリクエストやgitの機能を理解してない部分が多く、どれが一番うれしいのかわかってないのです
各コミットを適用するか否かを別々に判断して反映できればいいのだと思うんですが
一つのプルリクにまとめて送ってもそれができるのかどうかが分かってません

もう面倒だからプルリク送ってプルリクページで主と相談すりゃいいと思うよ
主が分けてほしいと言ってきたら分けて再プルリクすりゃいいし
GitHub flowなんかプルリクページで活発にやりとりするのが基本らしいしな

>>357
なるほど確かにcherry-pickしてもらえるのであればコミットさえ分かれてれば大丈夫ということですね
そう考えるとどう送るか＆受け取るかはその人次第って事なんでしょうかね

>>359
プルリクページで相談！
確かにいったん送ってみてこれが間違いなさそうです
ありがとうございます

基本は全部別ブランチにしてプルリクエストも分けろだが、各自masterブランチで作業してマージしあってるプロジェクトもあるから作者どうしてるか次第だな

失敗してもええんやで

>>360
そう。自由にできるソーシャルコーディング。Github最高だわ。

>>353
まさにそれ

githubにプルリク投げる時のブランチ名について質問だけど、
・こっちのブランチ名は伝わる
・けど、向こうは好きな名前で受け取れるから、大した問題ではない
・とはいえ、適切な名前を付けた方がかっこいい
って理解で合ってるかな？
バグフィックスだからfix/○○にしようと思ってるけど。

ブランチ名とかコミットログの一行目とか難しいよな。

長ったらしい英語なら書けるけど、
短くそれでいて意味が通る言葉がでてこない。

だから毎回似たような単語になってしまう。

後で一覧を眺めた時に要不要や関係あるなしを一瞬で識別・判断できれば十分

>>367
その理屈で言うと
ブランチ名 「 [bug][2.0][important] 」みたいなのでもいいんだろうかｗ

てか、普通にかぶるよね？ ブランチ名。

過去に作ったことの有るブランチ名と
同じ名前を作ってしまうことは有るはず。

ほとんど問題無いと思うが。

git checkout -b fix-コミット番号-修正内容

>>365
面倒だから自分が今使っているブランチをそのまま投げる。

対象範囲をブランチ名で、詳細をコミットタイトルで表すようにしてる
コンフリクトする可能性のある個所を把握しやすくなるとおもわれ

Gitで、新旧のバイナリファイルを比較したいです。
具体的には、ワーキングディレクトリにあるUMLの設計ファイルと、過去のバージョンのUMLの設計ファイルを比較しようとしています。

diffをとることはできませんので、目視で比較したいと思っています。
こういう場合、みなさんどうやって比較していらっしゃいますか？
昔のファイルを
git checkout -- <file>
してますか？
そしたらworking directoryのファイルが上書きされてしまって比較にならないような気がするんです。
でも、わざわざワーキングディレクトリをもう1つ作ってそこに旧バージョンをチェックアウトするのも面倒くさそうだし。。。
なんか良い方法ないかなぁ？と

ちなみにSourceTreeを使っております。

あっ

自己解決しました
SourceTreeだったらクリック1つで普通に旧バージョンもOpenできたわ・・・・


問題はUML編集ソフト(astah community)が同時に2つのプロジェクトファイルを開けないことです

ん？
でも皆さんコマンドラインではどうしてるんですか？

当面の問題は半分解決したけど、理解できてない感じがします

あへあへ

バイナリデータかつ比較する必要が出てくるのって
画像くらいしか扱ってないから
サーバのWebインターフェイス（Webブラウザ）で事足りてる

それ以外は大抵一瞥しただけじゃ
差分が把握できない（ガッツリ検証する必要がある）から
手間としては誤差だな

>>376
コメントありがとうございます

サーバの、ってことは gitのリモートリポジトリのwebインターフェースを見るってことですか？ githubとかbitbucketみたいな。

みなさん設計ってどうされてるのかな
万年Newbieなもんで、開発のフローがいまいちわからないdeath

やったことなかったけど、画像を見るんだったら
git show ハッシュ|display -
とかでいいな

github apiであるユーザーのパブリックなリポジトリの数を取得する方法おしえてください

github固有の話題はスレチだっつってんだろ

わかりました

ちょっとお聞きしたいのですが、、、

以下の通り作業したときなんですが、

1)トピックブランチで作業
2)トピックブランチをmasterにマージ
3)masterをリモートにpush

このときリモートの歴史が進んでいたら
pushに失敗しますので
pullしないといけませんが、
単純にpullすると、
なんかコミットログのツリーが
キモい形になります。
(ローカルのmasterに、
リモート側にpush済みのコミット郡が
ブランチ作業されたみたいな形で
マージされると思います)

そこでちょっと思ったのですが
ひょっとして以下のようにするのが普通だったりしますでしょうか？

1)トピックブランチで作業
2)トピックブランチをmasterにマージ
3)masterをリモートにpush
4)ここでリモートの歴史が進んでいたためにpushに失敗したら
トピックブランチのマージはいったんリセット
5)masterにリモートの歴史をpullしてから2)に戻る

しょうもない質問かもしれませんが
よろしくお願いします。

>>382
masterは弄る前に最新にしておく。

ありがとうございます。
masterにトピックブランチをマージする(いじる)前に、
pullで最新にしておくように心がけようと思います。

チーム内ではそういうルールなしに運用されているため
基本みんな「pushできねー。pullしてpushだ！」とやっちゃってて
コミットログのグラフを見たときに
なんか汚いんですよね、、、

fetchとrebaseでいいんじゃ

githubフローでも使えばいいじゃねえの

>>385
rebaseだとコミットの歴史が変わるし
ブランチ内ブランチがあっても
平らになっちゃうし、あんまいいことないのでは。

>>387
push前なら気にせずにrebaseしてる
ピックブランチをrebaseしてmasterに--no-ffでマージすれば平らにならないし

俺の使い方が変なのかもしれんが
トピックブランチ内でさらにブランチ作ったりするから
rebaseだとそれが平らになって困る。

ブランチ同士の分岐の履歴なんて残す必要あるかね？

FF派・アンチFF派の不毛な争いがまた始まる

残すためじゃなくて残さないためにNOFFするんだよ(カーン

残すためじゃなくて残さないためにNOFFするってどういうことですか?
残すためじゃないのかなあ。

merge派とrebaseで履歴一本派でそれぞれconfigでffをどう設定したらいいですか？

>>390
> 390 名前：デフォルトの名無しさん [sage]： 2015/02/03(火) 22:15:43.45 ID:K3j8Ml+5
> ブランチ同士の分岐の履歴なんて残す必要あるかね？
概要を把握して、その後細かい部分を見るのが普通なのでは

この場合の「概要」と「細かい部分」ってなんのこと？さっぱり意味がわからん。

ここの人達恐いよ
ソースツリーの構築・整理に異常なまでに取り憑かれている
コードを書くよりGitをいじっている時間の方が長いんじゃないのか

んなわけがない
お前がろくにポリシー作って運用した経験がないだけ

バージョン管理はするが過去は振り返らない
俺がHEADだ！

過去は改変せず、ありのまま残せ。
しかしログは簡潔に見たい。
それらを満たせればいい。

ファイルを編集してgit addするまえにgit checkout . で元に戻しちゃったんですけど
どうやって編集してた時の状態に戻せますか？

git statusだとサブディレクトリ内のファイルが出てこないんですが
どうやって新規ファイルとか更新ファイルを確認できますか？

>>401
消しちゃっててaddもしてないなら無理だよ

>>402
出てくるよ
.gitignoreにそのサブディレクトリ書いてるんじゃない？

error: pathspec 'add file' did not match any file(s) known to git.
こうなってコミットきませんどうしてですか？

git status

Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

new file: file

よそのリポジトリに何百何千とスター付けてるアカウントはそのブクマをどう管理してるんだろ
使い切れんだろ

何の話？gitにスターとかアカウントとかそんな機能あったっけ？

>>403
俺は特に設定してないけど--untracked-files=normalの挙動になるんだけどデフォルトで--untracked-files=allにする方法ある？

status.showUntrackedFiles
試したことはない

2.3.0

最新から5件のタグだけ残してそれより古いログを削除するのはどうやるんですか？

出たね（´・ω・｀）

やっぱり、言ってみたい言葉の第一位は
「3人いれば勝てると思ったのか？」
ですよ。 これは譲れないお

>>410
古いログ消したいならgitなんか使うなよ

Windows用のgit2.3.0をビルドしました
http://www1.axfc.net/u/3408068

ページ下部のmsysGitで誰でもビルドできます
https://msysgit.github.io/

このご時世に野良ビルドは怖くて使えんぞ

同意します

ビルドの手順をコマンド一行一行ごと
書いてくれたほうが嬉しいよな。

野良どころかブログ定住すらしてないのか
Github公式のを使え

指定したブランチの最新コミットの特定のファイルを表示する方法を教えてください
git show test:index.txtじゃだめでした

思考停止してチェックアウトしちまえよ

ええええ
いやちょっとコードを確認したいだけなんですよ
チェックアウトするのめんどうくさいです

logはどうなってんの
チェックアウト出来なくなってる可能性もあるぞ

編集した状態なのでコミット前です
チェックアウトするなら一回コミットするあらstashしないといけない状態です
コミットが大量にあるのでlogやreflogで探すのが面倒くさいのです

あ、もしくはどこのブランチでコミットされたものか表示できるほうほうありませんか？
logにブランチ名も表示されればいいんですけどその方法を教えてください

showで見えるようだが・・・バージョンによるのか？
git cat-file blob test:index.txt
とかは？

あ、ソースコードが似てたから勝手に勘違いしてました
git show branch:filenameで大丈夫でした

http://nullnote.com/web/git/merge_rebase/
ここみるとやっぱりrebaseでコミットを纏めるのは良くないと思いました

>>427
公開していないコミットならrebaseしても良い
こいつは色々と間違っている

github見れば沢山実例はあるんだから
rebaseしているかしていないかわかるでしょ？

rebaseしているからあんなきれいなコミットログなわけでさ。
もしrebaseしなかったら、typoの修正やら間違った修正の訂正やら
たくさんあってもっと汚いって。

pushする前にrebase

>>427
ブランチによってrebaseするべきものと
してはならないものがあるよ。

masterなどのメインブランチはrebaseしてはいけない。
トピックブランチはrebaseしてよい。

>>438
トピックブランチはpushする前にrebase。
そしてレビューが行われて修正が入った場合、
必要ならばマージする前にrebaseだね。

言っておくけど、rebaseは一個にまとめることじゃないよ。
コミット毎に意味があるようになっていれば複数になってもよい良い。

そしてコミットを綺麗にしてからメインブランチみマージ

簡単にいえば、トピックブランチでミスを一回もしなかったらどうなるか？
その形にしてからマージするということ。
もちろんメインブランチにマージした後のミスはrebaseで直したらだめ。

http://jbbs.shitaraba.net/sports/42269/

rebase -i を知ってしまうと
コミットは書き換えられても人間はもう戻れないね

トラブルで揉めないように事前にしっかりとルール作りやってればええねん

リモートリポジトリを二つに分ければいいんだよ。
全員が共有している、共有リモートリポジトリと
個人専用の、個人リモートリポジトリ。

そして、共有リモートリポジトリへ、
個人リモートリポジトリからプルリクエスト（マージ）

githubを使ったやり方がこれだし、
gitlabでも同じようなことが出来る。

共有リモートリポジトリは全員が共有しているわけだから
安易にrebaseしてはいけない。だけど個人リモートリポジトリは
個人のものだからrebaseしてよい。

オープンソースの開発見ればわかるけど、
一旦プルリクエストして、そのやりとりで細かい修正があった時に
それをそのまま取り込んでくれるところはないよ。
相手が無知じゃないかぎり、rebaseしてくれって言われる。

個人リモートリポジトリつくるやり方は否定しないが
「rebaseのために」個人リモートリポジトリつくるのは気持ち悪いな

個人で複数マシンで開発してたら
個人リモートリポジトリとはいえrebaseしたくないし
かといってマシンごとにリモートリポジトリ用意するのは馬鹿げているし

kernel.orgだと
/stable.git
/個人名.git
って感じでずらっとならんでるね
プロジェクトの共有ディレクトリに作ってsshするだけでも楽

後半は関係ない話だよね

>>437
rebaseのために作るんじゃなくて、
作業を明確に分けるために作るんだよ。

共通のリモートリポジトリに○○さん実験中みたいなのが、
ずらーって並んでいたら、このブランチは何？ってなるでしょ？

まず最初に、作業を明確に分けるために
リポジトリを分ける。（githubみたいに）

そして、ローカルリポジトリをrebaseしていいのと同じで、
個人のリポジトリ＝ローカルと同じで個人が使うものだから
こっちもrebaseしていいわけ。

で、重要なのは、仮定じゃなくて結果ね。
結果として、コミット毎に意味が綺麗に別れれば
あとから、特定の機能をチェリーピックとかしやすくなる。
rebaseが目的なんじゃなくて、開発のしやすさが目的だからさ。

>>437
> 個人で複数マシンで開発してたら
> 個人リモートリポジトリとはいえrebaseしたくないし

git push -f すればいいだけだよ。
個人リモートリポジトリだからこそ、誰も困らない。

まああたりまえだけどさ、なんでrebaseって機能が
用意されているかって言うと、必要だから用意されているわけで
rebaseしたらだめ。なんてルールは無いんだよね。

rebaseされたら困る場合がある。って話は
rebaseしたらだめという意味じゃない。

rebaseされたら困る場合があるなら、
その場合以外でrebaseすればいいわけ。

元々の要求として、rebaseしたいんだから、
rebaseしやすいように、明確にブランチとリポジトリの
利用方法を分ければいいわけさ。

それを一部の困る場合を例にして
全部禁止するのは本末転倒。

goto 禁止
select * 禁止
使わない変数の投機的宣言禁止

必死にrebaseして一本道にしているのって本末転倒だな

git push -f した後、別のリポジトリから git pull -f って出来たっけ？
と思ったら、git fetch して git reset --hard すればいいのか。なるほどー。
http://qiita.com/yaotti/items/b64ab993c78a47941869

linux-rtの場合はrebaseブランチってのがあって
pull ―rebaseで追っかけてたよ

git init
touch a
git add a
git commit -m "add a"
touch b
ここでaをコミットした段階に作業スペースを戻したいんですが
git reset --hard HEAD^ってやってもbが残ったままになります
resetだけで元に戻せるものだと思ったんですがgit clean -fしないとだめなんでしょうか？

>>444
rebaseは一本道にすることが目的じゃなくて
意味不明なコミットをなくして、
コミットを使いやすくするのが目的だから

コミットを使いやすくというのは、
特定のコミットがバグの原因だと調査しやすくしたり
他のブランチにコミットを抜き出して取り込んだり
特定のコミットをッ取り消したり、
コミット単位で機能の変更を把握したりすること。

コミットは後から使うために残すもので、
使いものにならないコミット、使わないコミットは
存在する意味が無いですから

git cloneしたときの作られるディレクトリ名を指定してクローンすることって出来ますか？
普通にクローンしたらhelloディレクトリが作られるところをkonnitiwaディレクトリにしたいんです

>>449
git clone --help でできるよ

git help clone で出るよ
引数の最後にディレクトリ名追加するだけ

ありがとうございます

自分の勉強のため逆引きみたいなのを作ろうと思うんですけど
ここのテンプレにつかってもらえませんか？

出来によっては。しかし--helpでほぼ十分なんだな。

物次第じゃね？出来てからまた来れば？

>>453
http://www.backlog.jp/git-guide/reference/

そこをテンプレに入れるかどうかは微妙な所だよね

>>442 >>448
ひさびさにまともな意見を見た。
普段ネット上の解説を見ても無条件に「push -fはやめましょう」とか
「rebaseすると履歴が一本になって見やすいです」とかドヤ顔で
書いてるやつが多くてゲンナリしてるんだよね。
>>442 みたいなレベルでGit使えるやつって実は少ないんじゃないのかと思ってる。
だいたい man 読めば書いてあるんだがなぁ。

とドヤ顔で言われましても

> >>442 みたいなレベルでGit使えるやつって実は少ないんじゃないのかと
それが事実かは知らんが
それを認めたら
> それを一部の困る場合を例にして全部禁止する
という方針に正当性を与えるんでは？

>>459
なるほど、一理ある
そういう意味では認めたくないねぇ

能力の問題と行為の問題は別に考えんといかんよ。

まず道具を正しく使える人が基準だ。
その人を基準とし、その人にとって
使いやすい方法を選ぶべき。

そして能力が低い人は、
単に能力を上げろってだけの話。

それまでは補助輪つけるのは構わんが、
それは補助輪であり、将来外す事になるのが既定路線であり
そしてプロにとっては邪魔なものであるということ。

>>461
参考になる。
まぁ、「補助輪をはずすなんてとんでもない！そんなことしたら転んでしまうぞ！」
という奴ばかりで「邪魔な補助輪なんか外して走ろうぜ」って言ってる奴をあまり見かけない
っていうただの愚痴だ。

>>442
>>443

まさにこれ
状況によって使い分けるべきだ、という話だったのを、「rebaseは(常に)ダメ」とか「rebaseは(常に)良い」とか「gotoは(常に)ダメ」いう話とすりかえる人がいるのが問題なだけ。

大きなリスクもあるという話であって、状況によっちゃ使った方が良いんですよ。
リスクをコントロールできない奴は使うな、というだけの話。
火や刃物と一緒ね。

どの業界でも普遍なことだと思うけどさ

ベテラン・・・スキルが高い
新入社員・・・スキルが低い

なわけだよ。実態は置いといて一般的にさ。

なんでベテランが新入社員のスキルに合わせましょう！
新入社員さまさま、あなたさまの知識でわからないことはしません。
あなたさまに合わせて、素人のやり方で仕事します。
なんて、新人にへりくだらなきゃいかんのさ？って話だよ。

普通は、そんなこともわからんのか、ちんたらやってんじゃねーぞ、
そんなものは使い物にならん（ガシャーンって投げ捨て）
わからないならで勉強しろって怒鳴りつけるところだろ。

>>464
スキル低い奴に自由にさせるとやらかしてとんでもないことになるから、コーディングルールなり運用手順を決めるんだよ
勉強してスキル上がるまで待てりゃいいけど、そんな余裕のあるところばかりじゃないでしょ

>>464
概ね賛同
「普通は、」以降には賛同しかねるがGit関係ないので掘らない

ここで言う新入社員というのが新卒限定なのか中途も入っているのか分からない。
それにベテランってなんのことだよ会社に長く居る人のことを言っているのか、ある分野に長く関わっている人のことを言うのか。
ぶれてて話がわからないからまず定義をしっかりかいてくれよ。

rebaseごときで初歩的なことを長々と…
スレの質もずいぶん下がったものだ

ベテランで絶対ヘマして事故起こしたりしないからって制限速度超えて思うままに道路を走っていいわけじゃない

1，2レスで終わる内容に何十レス使うつもりだって話

>>465
> コーディングルールなり運用手順を決めるんだよ
そこにちゃんとコードレビュー入ってる？

まともなコードを100としたら、コーディングルールで縛れるのは
ほんの5ぐらいだから。

運用手順っていうのがコードレビューを含めたワークフローのことかな？

ソフトウェアの開発っていうのは、あるものを基盤にして積み重ねていくものだから、
誰かが足を引っ張ると、つまり悪い設計、悪いコードを作ると
それを利用するその他全員の生産性を下げることになるよ。

スキルが低い奴が作ったもの、例えて言うならば、弟子入りしたばかりの
ひよっこが作った作品は、親方がみて判断し作り直しさせたり、
あまりにひどいものは捨てたりして、商品として使えない。客には出せないって
ことをはっきり言わないといけない。それがプロっていうもの。

>>471
コードレビューは当然として、作ってから直させるのは無駄なので事前にルールを決めるのはまともな企業なら普通にやってるだろ
また git で変なことされると面倒だから、運用を決めるのも普通だと思うけどな

だからコーディングルールで保てる質は
まともなコードが100だったら5程度なんだってば。

例えば、標準関数にある処理を
知らずに独自実装してしまいました。

みたいなものをコーディングルールで防ぐことは出来ない。

作ってから直させるのは無駄なので
ペアプロするしかないんだような。

もうGit関係ないよねこれ

コーディング規約を決めるのもコードレビューを行うのも当然
この2つで互いの欠点を補う。
ただし、共同作業には無駄がつきものなのでできるだけ少数でやったほうがいい。

産業でおk

>>473
5でも少ない方がいいだろ
なにを必死になってるのかよくわからん

コーディングルールを過剰評価し過ぎだよ。

あんなのてにをはは正しく使いましょう。
誤字脱字に気をつけましょう。
慣用句の誤用に気をつけましょうぐらいの
意味でしかないのに。

守るのはあたりまえだけど、それを守った所で
良い文章が出来るわけじゃない。

>477
読み間違ってるよ。

まともなコードが100点だとして、
ルールがあった所で0点の人が
5点になる程度の効果しかないっていってるの。

>>479
根拠もなしに5程度なのを力説しないで、あとの95の内訳を説明すればいいんじゃない？
そうすればそれが過小評価なのかもっともな意見なのかみんな納得すると思うけど。

>>480
一つ説明したはずだけど？

> 例えば、標準関数にある処理を
> 知らずに独自実装してしまいました。

他にも
* このモジュールに置くべきでない関数を作ってしまった。
* クラスの役割が単一責任の原則を満たしていない
* AモジュールがBモジュールに依存してるのにBモジュールもAモジュールに依存するなど依存関係がおかしい
* もっと短く効率的な書き方がある。
* やる意味が無い処理をしている。（1以上かつマイナスでない時みたいな）
* コードを共通化出来るのにしていない。

とかルールあっても解決できない問題は山ほどある。

このスレときどき「Gitの履歴、運用はかくあるべし」論が出てくるな
ただ毎回似たようなのが繰り返されてると思うから議論防止に何かテンプレに入れた方がいいんじゃね？

* 後から履歴を使いやすいようにrebaseで整理するといいね
* でも公開されてる履歴を改変すると面倒が起きるから基本しちゃいけないよ
* どう運用するかはチームでポリシーを決めよう

まとめるとこういうことだと思うんだけどどうですか

SIerで銀行仕事してる人と自社サービス作ってる人と大学で研究してる人はそれぞれ手法違うだろうよとしか

そこでMISRAや医療系規約ですよ！

>>483
それは少数精鋭で無駄なく効率よく開発することで低コストでも高い品質で仕上げるやり方と
人を大量に集め無駄が多くて効率が悪くてもコストをかけて物量でせめることで品質を上げるやり方の
違いってことでいいですか？

さっきから出てくる例えがバカすぎる
だいたい答えてもらえてもケースごとにポリシーを構築することに変わりはないんだから
既出の用例から自分で取捨選択できないやつが特定のケースの例示だけ受けても無意味
永遠に空論が積みあがるわ

日本の大手みたいなとこだと
一度これはダメみたいなパターン作っちゃうと
何年も覆らないんだよね
git使ってる意味ないぞ・・ってのが増えていってテンション下がる

どんな糞ルールがあろうとCVSよりかはマシだと思う
いやマシだと思え

低い方が高い方に合わせるのは現実的には無理だよな。

>>488
cvsの部分取得やキーワード展開は便利だぞ。
ただ分散とかがgitの方が便利なので、天秤にかけてgit使ってるだけ。

>>478
ああ、やっぱりまともなコーディングルールを見たことないお子ちゃまが「ぼくのかんがえたこうでいんぐるーる」で語ってたのか w

> あんなのてにをはは正しく使いましょう。

レベルの低い組織がコーディングルール導入しろって言われたときによく「言語の文法を守りましょう。」とかのルールを設定してるよな。
そんなルールは無駄。
コーディングルールは大きく二つある。
1. 全体の統一を図るべき内容を規定する
・名前の付け方とか、モジュールの配置方法とか
2. ありがちな誤用を防止するために規定する
・C 言語の例として if( ) ブロック1 else ブロック2 のブロックは単一の文でも { } で囲むこと、とか

1. の方は個々の組織やプロジェクトによって違うからあまり例はないけど、2. の方は MISRA とか、IPA/SEC のコーディング作法ガイドとかあるから読んでこい。
あまりにもレベルが低すぎてお話にならない。
http://www.ipa.go.jp/sec/publish/index.html#emb

> 良い文章が出来るわけじゃない。

当たり前、良い文を作るためじゃなくて悪い文を作らないようにするためのもんだ。
それこそルールを過剰評価しすぎだよ w

正論だろうとスレチの話題をする奴はお子ちゃま以下

それでも続けるというならコテ付けてくれ

>>491
言ってることが、>>478何ら変わってないんだがｗ

それにさ、ルールを決めた所で
そのルールを守っているかどうやってチェックするんだよ？

> MISRA とか、IPA/SEC のコーディング作法ガイド
のような内容は機械でチェックできないぞ。

それこそコードレビューだろ。

分かりきってることをグダグダ話す意味がわからない。
しかもスレチだし。

>>493
・文法を守りましょう
と
・グローバル変数は g_ で始めること
が、同じにしか見えないならマジで終わってるぞ

確認はレビューでやればいい
ルール決めときゃまともなコーダーは大体それに従うから、不注意とかで間違ってるところだけ指摘すりゃいい
おまえのところはルールもなしに適当にコーディングされたものをレビューでいちいち指摘するのかい？
まあ、文法を守りましょうとかなら指摘はほぼないだろうけどな w

>> MISRA とか、IPA/SEC のコーディング作法ガイド
> のような内容は機械でチェックできないぞ。
QAC、C++TEST とか、PG-Relief MISRA オプションも知らないなら黙ってた方がいい
全てのチェックはできないが 8〜9割は機械的にチェックできる
ネーミングルールのチェックができるものもある

ぐだぐだ関係無いこと書いてドヤ顔なやつは
rebase一本道派だなw

だれかおねがいします

rebaseなし縛りで不要なマージだらけの履歴とか普通に見づらいだろJK
何の罰ゲームだよw

>>497
そりゃあ残ったままになるわ。バージョン管理されてないもん。

>>469
絶対事故起こしたりしないから、制限速度超えて思うままに道路を走っていい、っていう話な
免許もってない人に合わせて制限時速30kmにしてたら、生産性が落ちる。

>>482
そういう合意は基本とれてるはずなのに

「rebase禁止! これは絶対！ 初心者がミスるから！ おまえらもrebase禁止！ 禁止で当然！俺らのルールが絶対！ 初心者がいないチーム？ありえない！」

みたいなヤツが出てくるからややこしい。

>>498
共有リポジトリでrebaseしちゃう人が多発しちゃって、不要なマージだらけのログっていう呪いのほうが余程マシなようなチームもあるんじゃね？
・・・知らんけど。


問題は「そういうチームがある(かもしれない)」からといって
それをgitの一般的運用ルールとして他のチームに強制にしようとするアホがいることだ。

rebase禁止縛り？ 自分らで勝手にやれよ。押しつけんな、って話。

* typo
* add robot.c
* ロボットの歩行機能実装
* typo
* ロボットの自動停止機能実装
* type
git checkout master
git merge robot dev
こういうばあいはどうやってまとめたらいいですか

>>503
イミフ

>>503
ログをどう書くかって話かな？

いや、それにしては後半がいみがわからん

イミフ

rebaseでまとめるときの話です

>>502
> 共有リポジトリでrebaseしちゃう人が多発しちゃって、

gitlab使えばいいのに（githubでもいいと思うけど会社で使ってないので）

共有リポジトリでrebase（正確にはpush）できないように
するだけで終わる話。

ローカルや個人リモートリポジトリは別として、
マージはgitlabのウェブ画面からやるのよ。
githubでプルリクエストの処理をウェブ画面でやるのと同じ。

だから共有リポジトリの共有ブランチを守るのは簡単。
下手にgitだけでやろうとするから大変なんだろう。

>>503
「コミットログは後から見返すもの」として考えれば
何が必要で何が必要でないかはわかると思うよ。

後で見返した時、あー、あのときの俺はタイポしまくってたなぁ〜
なんて感慨にふけりたいと思う？ｗ

そのコミットでやったものは、
* ロボットの歩行機能実装
* ロボットの自動停止機能実装
の二つでしょ？

これは内容によるけどコメントだけから判断すれば、
それぞれで分けて二つのコミットになりそう。

だから、そのブランチにはその二つのコミットがあり、
そのブランチをマージすることで最終的には、
一つのマージコミットに、その二つのコミットが入った状態にするのが良い。
（マージ自体を二つに分けるという考え方もある）

捕捉

ただし、そのタイポの修正が、全然関係ない部分の修正であれば
別で修正しマージした方がいい。

１）masterにコミットログが追加されるのは２件のみ
* ロボットの歩行機能実装
* ロボットの自動停止機能実装

２）typoはrobotブランチから新しいブランチfixtypoを作ってそこでtypoを修正して、git merge robot fixtypoをする

これでいいんですか

公開したコミットをresetやrebaseで誤って消すような事をしても
pushに--forceフラグを付けなければ
pushを拒否られてその時に気付くから
通常問題にはならない

>>509
typoは、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でやるかは……人によるとしか言えないのでまた争いになる(苦笑)

>>490
キーワード展開はdiffとる邪魔になった記憶しかないな

>>512
gitもcvsも使い方次第ってことだ。

まぁ、「補助輪をはずすなんてとんでもない！そんなことしたら転んでしまうぞ！」
という奴ばかりで「邪魔な補助輪なんか外して走ろうぜ」って言ってる奴をあまり見かけない
っていうただの愚痴だ。

rebase=補助輪

rebase縛り？ 自分らで勝手にやれよ。押しつけんな、って話。

>>512
どんだけ埋め込んでるんだよｗ

>>507
なるほど知りませんでした
ツールによってrebaseの危険性を抑える方法もあるんですね。

なら余計に「rebase禁止」ルールを適用するべき場面は減るわけだ。

そんな特殊なrebase禁止ルールを一般化しようとする人っていったい…

>>514
rebase禁止批判を逆にして相対化しようとしたのだろうけれど、
rebase禁止を批判している人は、
rebaseのみに縛ることを主張しているわけではないのだから、
余計にrebase禁止のおかしさが際立っちゃってるように思う。

加えて、rebaseはリスクを抑えるわけじゃないから、補助輪で例えるのもおかしい。
補助輪の例えなら、rebase禁止が補助輪に相当する。

rebase禁止 = 補助輪あり
・リスクを抑えることができる
・効率、合理性で劣る
・ガチ初心者は最初はここからはじめるのがよい

rebase可 = 補助輪なし
・リスクはあるのでリスクを管理する必要がある
・上手ならば問題はない
・合理的。効率的。

いい歳した人間が三輪車でドヤ顔でキコキコやってるのを見せられる側の気にもなってもらえませんかね
大仰に話してるけどものすごく低レベルな内容なのわかってる？

ネタもないならスルーしとけばいいのに...

>>518
低レベルなのも邪魔なのもそうやと思うし、誠にごめんやけど、
変な説やデマを放置すると、またそれが一定の力を持っちゃうからなぁ

でも、嫌な人がいるようなので、
もう僕は例え話にはかかわらないようにしますね。

この会話が基準になってしょうもない話をどんどん持ち込まれるようになっても困る

>>520
このスレに常駐しててデマを真に受ける人はほとんどいない
今までも適当にあしらわれてきた
今回はお前があしらわれても根掘り葉掘り聞いてデマレベルのしょうもない話がだらだら続いてるだけ
デマを作ってるのはお前

コードレビューやってる人達ってどんなコード書いてるの

どういうこと？プログラマの大抵はコードレビューやってる人達だと思うけど

コードレビューってどうやるのかおしえてください
たとえばツールを使うんですか

OHP を使うこともあるし slideshare で済ませることもある

印刷はしますか？

>>525
https://rhodecode.com/

まずコードレビューの意味をだな

まずスレタイの文字をだな

>>490
// 19xx.01.01 modified by hogehoge
とか手で編集日とか入れてたんだけど、ある日CVSを知って、その
$Id: .... $
がカッコよくて中2ごころくすぐられまくったなぁ。
そのうち ident でコンパイル後のバイナリも特定できる方法を知って
const static rcsid = "$Id; ...$";
とか書くように。

GitでもIdを埋め込む方法は用意されてるけどcheckoutのスピード落ちそうだし、
コンパイル時とかにコミットハッシュを埋め込んじゃえばツリー全体を特定できるGitだと
そもそもIdの意味が本当に字面だけしかないことに気づいてIdへの情熱が薄くなった。
それ以上に、Gitの機能が色々な面でCVSよりはるかに便利なのでもうCVSには戻れない。

同意

*
*.*
こういうふうに全てのファイルを無効化してから
↓みたいなサブディレクトリのphpファイルを監視させたい場合って
./tests/my.php
./tests/2015/listen.php

!tests/
!tests/*.php
!tests/2015/*.php
って書かないとだめですか？

>>533
そうみたい。
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されてる
てことね

ところで * がある状態で *.* って必要？

あ、すいません
*
*.*
.*
でした
*だけだと漏れてたのを確認した覚えがあるのでこの３つ書いてます

そうなんだ。いや、手元だと
*
て書くだけで
.foo
とか
foo.bar
とか無視されるから *.* がないと無視されないファイル名って何なのか気になっただけ。

スケルトンのファイルをコミットしたら２度目以降はコミットに含めないようにしたいんですがどうやるんでしょうか？
要は雛形を記録したいだけです

>>537
config <- .ignoreに入れる
config.skelton <- コミットする

そもそも自分でAddしなければコミットには含まれないでしょ

statusで表示されるのが嫌なら
assume-unchangedとかskip-worktree

git clone xxx してリモートサーバーからデータを取得したのですが、
*.packという巨大なファイルがあるだけでソースツリーそのものがありません
コードを取り出すコマンドなどあるのでしょうか？

>>540
もっとありのままの症状を書いたほうが答えが得られやすいと思うが。

今晒してる情報だけだと、いくつか考えられる可能性はあるが
(a) --bare, あるいは --mirror でクローンしたのでワークツリーがない
→ 余計なオプションをつけるな
(b) clone が途中でコケてる
→ 終了ステータスちゃんと見ろ。
(c) *.pack というファイル自体を Git で管理している。あるいはその他
→ これはそのリポジトリの所有者に聞くのが早い

他の解決へのアプローチとしては、git log --stat とかを眺めて自力で解決する。
または、それがパブリックなリポジトリならURLを晒すと誰か調べてくれることに期待するってあたりか。

index.phpを修正してコミットしたんですが
HEAD@{3}のところにその修正内容を入れたい場合ってどうやればいいんでしょうか？
いまはgit reset --soft HEAD^でコミットを一個ずつ戻していって
index.phpだけaddしてコミットしたら、残りのファイルを一括でコミットしているので
戻した文だけログが少なくなってしまいます
どうするのがいいのかおしえてください

とりあえずコミットする
rebase -iで並び変えてfixupで合成する

Gitに感動したあまり、コードを書かずにGitをいじってるやつがいたんですよぉ

なぁ〜〜〜〜にぃ〜〜〜〜！？

やっちまったな！！！！

男はだまって　コピーアンドペースト！

男はだまって　コピーアンドペースト！

コピペでバージョン管理が要らなくなる訳じゃないような

コピーアンドリネームならネタとしては成立するが面白くはない

俺の人生filter-branchしたい
あの汚点を消したい

10年も経って容量のことなんてだれも気にしなくなれば
バージョン毎のフォルダ圧縮最強の時代が来るよ

来ねえよ
何言ってるんだ

10年以上履歴管理システム使ってるわけだが。

10年以上前に造ったリポジトリ今も使ってるひといる？

>>550
いるよ。

>>547
沢山のバックアップがあるんだけど、あの関数を変更したのはどのバージョンだったかな、よし遡って検索するスクリプトを書こう。
バックアップのそれぞれに readme ファイルを付けておけば、バックアップ検索のときに表示できるようにしよう。
複数人で開発するときに便利なように、バックアップファイルをトランザクショナルに追加できるようにスクリプトを書こう。
バックアップの追加時には最新のバックアップと自動的にマージするようにして、コンフリクトのチェックもしてあげよう。

もうある。

>>547
容量が大きくなるほど圧縮伸張に時間がかかｒ

cvs・・・ファイルバージョンの管理
svn・・・複数ファイルのバージョン管理
git・・・プログラムの機能のバージョン管理

容量のことなんてだれも気にしなくても圧縮はする律義さ

履歴を残す人と、履歴を作る人がいる。

>>555
IOの速度にも影響がある。

ここの>>464とかでやってるやりとりって、見てて面白いね
極論すれば、別にgitとか関係なくて、
・どのくらいのボンクラまで許容するか
・許容できないボンクラを、どうやって処分するか
って話だよね

日本企業の場合は工場生産での成功体験が強いせいか、
マニュアルさえ作ればボンクラでも使える筈という信仰が強いんだよね。
それがソフトウェアの世界に入ってきておかしい事になっている気がする。

>>558
そうね

40歳になってもいまだ性交体験ない
（´・ω・｀）しょぼーん

G#

ここの奴らは自分がボンクラじゃないと思ってんのか

盆暗

毎日が盆と暮

正月は来ない

いい歳した人間が三輪車でドヤ顔でキコキコやってるのを見せられる側の気にもなってもらえませんかね
大仰に話してるけどものすごく低レベルな内容なのわかってる？

>>567
高レベルな奴が光臨しましたよ

自分が作業してきた履歴を修正せずに残すべき。
履歴が汚いのはてめえの作業の仕方に問題があるからである。
履歴を一本に纏める時はブランチをマージするときだけで良い。
それ以外で纏める必要はない。
わざわざ開発ブランチで見栄張ってrebaseしてんじゃねえよ！！！

windowsで自宅開発してます。
開発はデスクトップとノートPCの両方で行っています。
今まで自宅サーバーのsubversionで二台のバージョン管理をしてきたのですが、サーバーの電気代が無駄の
ような気がしてきました。

そこでgitならサーバーを立てずにファイルのやり取りをできると聞いたのですが、検索してみると
githubのような中央サーバーを作るやり方ばかり出てきます。
windowsのデスクトップとノートPCの二台でバージョン管理を行える参考サイトのような物があれば
教えて頂けないでしょうか。

git push 共有フォルダ

とかでググるのがいいかもね

DropBoxでの同期を利用してる人が多いね

安いNASとかでも十分かも

ありがとうございました。
調べてみます。

BuffaloのNASでWeb/DBサーバ機能が使えたんで
MantisとかPukiwikiとか入れたら使えた

消費電力はディスク数でも違うだろうけどタイマーで
ON/OFFをスケジューリングできる機種もあるみたい

dropboxって不正アクセスあったしなあああああああああああ

windows自体が使いにくいからなぁ。

ownCloudで自分だけのdropboxを作るお（´・ω・｀）

共有フォルダにリポジトリを置くだけならsubversionでもできるよね
gitならではのサーバを立てずにできる方法がある？

>>578
ファイルシステムをマウントすればできると思うけど、windowsでやったことは無いなあ

subversionはリポジトリを作るのがめんどくさかったなｗ

ディレクトリ作って、trunk, branches, tagsディレクトリ作って
リポジトリ用のディレクトリ作って、初期化。
そこに対してインポートする。とかだっけ？


gitだったら、普通に作成したディレクトリを
git化したいなって思った時に、
git init実行すれば終わり。

>>578
状況次第ではformat-patchやamやbundleでメール経由で同期したりdaemonで一時的にサーバー立てるのが便利な場合もある
でも共有フォルダ使ってOKな状況ならソッチのほうがお気楽

>>578
gitはオフラインでもコミットできるだろう

>>578
馬鹿には無理

>>569
> 自分が作業してきた履歴を修正せずに残すべき。
> 履歴が汚いのはてめえの作業の仕方に問題があるからである。
> 履歴を一本に纏める時はブランチをマージするときだけで良い。
> それ以外で纏める必要はない。
> わざわざ開発ブランチで見栄張ってrebaseしてんじゃねえよ！！！

まったくです。
履歴が見づらくなるからとか汚くなるからとか言ってるのがいるけどなんで、
そんなレベルのやつが自分で良いと思ってるやり方広めようと思うのやめて ほ し い

>>584
また釣り？ｗ

前回負けたのがよっぽど悔しかったみたいだねｗ

>>584
結局のところは、最終的に履歴がキレイに見えればいいわけで。
自分が会社でSVNを使ってた時は、

1. 自分の修正の途中経過を保存しておけるローカルのSVNのリポジトリで作業して、
2. ちゃんと動くようになったら、他人に見せれるキレイなコードに直して、
3. キレイなコードを会社のSVNにコミットしてた。

Gitはそれが一連の流れとしてできるわけでしょ？
なぜGitの良さを殺して開発効率が悪くなる方向に向かうのかが分からない。

>>584
＞そんなレベルのやつが自分で良いと思ってるやり方広めようと思うのやめて ほ し い

なんでその方法が良いと思ったかというと、その人の経験則によるものなんだろうね。

自分が一番上手く書けると思ってるコーダーと、たくさんのコーダーを抱えるリーダーでは、
重視するものが変わってくる。どっちも経験則によるもので、その経験は否定できない。

> なぜGitの良さを殺して開発効率が悪くなる方向に向かうのかが分からない。

なんで、そういう1つの方法を良いと思ったかというと、その人の経験則によるものなんだろうね。
それをgitの良さって。
大体、履歴のみ見るステークスホルダーが注文付け出して生産性下がる。
で、開発の経緯は消されて、あとから来た人が同じこと繰り返す。

特別な条件下での代替手法はそれとはっきり示してさないと
一般に優れた方法だと勘違いするアホがいるから困る

このスレでどうでもいい議論続けたって
お前らの開発チーム内状態が改善されるわけじゃねえからな
文句あるんならこのスレじゃなくお前らの所属する開発チームに直談判しろ

A->B->C->D
と作業したあとで
A と D だけにタグ付けることは可能ですか？

>>588
どうやら、自分が一番上手く書けると思ってるせいで、周りから煙たがられてるコーダーっぽいな

こまめにブランチを作って小さく作っていけばマージする時以外にコミットをまとめる必要はねえんだよ
下手くそな奴はすぐ開発ブランチで大量コミットするから汚くなる

>>593
そういう当たり前のことができない方が多いのです。
そういう方はコードが汚くなるとか低レベルの環境が前提な
謎のオレオレ手法がうまいやり方と勘違いする。

履歴がきれい 俺すげーw

履歴がきれい＝他の人が読んで修正がわかりやすい履歴になっている。

それはとてもいいことだよ。

履歴はバグった時に参照する事が多いと思われる
バグってない所まで戻した後直後のコミットを調査する事になる
そういう場合はコミットが細かい方が見やすいな
関連性が薄い変更まで含まれていると問題の切り分けが難しくなる

>>595
お前が良いと思い込んでるだけ、お前が綺麗だと思い込んでるだけ
他の人は迷惑してるかも知れんということに気づける頭無いのか?

なんで馬鹿な主張にこだわるのかわからん? 勝ち負けw

>>597
お前、本当に他人のこと何も考えてないよなｗ

>>595
> 履歴がきれい＝他の人が読んで修正がわかりやすい履歴になっている。
(おまえが見て)履歴がきれい(と思う)＝他の人が読んで修正がわかりやすい履歴になっている(とは限らない)。

当たり前のことわからんやつやw

> それはとてもいいことだよ。
^_^??

>>599
限らないのは確かにそうだが、そうする努力までハナから投げてるように聞こえるな、お前は

>>592
お前は根拠のないことしか言わないの?

マネージャvsプログラマvsデザイナ

主観に基づくキレイにするより、
事実に基づくそのまま残す方がわかりやすい。

>>603
何を残すかだよ。

gitのログは自分の作業の報告だと思えばいい。

相手に結果だけを報告するか、
あれこれやったんですよ。○○というファイル名にしたんですが
こっちの方がいいんで途中で変えたり、でここでタイポしたんですが
すぐに直しました。途中でコードが重複していたので一つにまとめました。
と、結果に至る作業内容を一つ残らず報告するか。

俺なら、後者を話し出したら途中で遮って「で結論は？」って聞くね。

コミット単位の問題
それこそ、ちょっと席を外すタイミングでもコミットするから

>>604
俺はそういう人用にtagだけ振ってるね。

履歴消す人はtagって使わないのかな。

>>606
え？ タグでどうやって
意味のあるコミットにするの？

作業履歴としての歴史のブランチがあって、
それを意味がある見せるようの歴史の別のブランチを作った後
それにタグをつけてるわけ？
タグがあるコミットの歴史は、見るためのコミットなんだよね？

あんたタグの使い方間違ってるでしょｗ

>>605
別に作業途中はどうでもいいよｗ

そのあとマージ前とかレビュー前とか
人に見せる時に、最後の結論だけを見せる。
途中にやったことなんて要らない。

もちろん本流にマージするときも、
そんな作業履歴はなくなっている。

でないと、一番重要な本流が
自分ついさっき書いたコードの小さなミスの
修正とかバグの修正とか
必要ない情報で溢れてしまう。

github見ても、大きな所では
作業履歴なんか残ってないでしょ。

>>607
何言ってんの

>>609
何言ってるのはお前だよ。

あるブランチがあって、
そこに、A、B、C、Dのコミットがある。

レビューする人に見せやすくするために、
意味のないコミットをまとめて
たとえば、A(+C)、B(+D)のように歴史を
まとめましょうって話をしている。

で、タグを使ってどうするわけ？
さっぱりわからんが。

まーたはじまったよ

>>610
そんなんBTS使ってるわ。

なんでBTS（バグ管理システム）がでてくるの？

BTS用に、別のブランチを作るって話？？？
BTS使っても、見せるのはgitのブランチでしょう？？？？

VCSで履歴を作ったりしてるのに、
BTSでTDDするとかいう発想はできないのか。
開発したことない奴なのかな。

>>615
話がずれていることについて言ってるんだけど？

BTSでTDDすることに何の問題もないよ。
だけど今の話と無関係だろう。

今は、コミットの歴史の話をしている。

レビューの話じゃないのか。
１つのコミットにまとまってないとレビューできないって結論ありきで言われても話になんないわ。
こいつはもう進歩しないんだろうな。

コミットの歴史の話に戻すと、
オープンソースプロジェクト（例 git）の
masterコミットログ見てみ。
そこに、くだらない作業履歴なんか残っちゃいない。

誰だって開発中に小さなミスはするはず。
細かくコミットするのだから、一つの機能追加で
幾つものコミットがあるはずだが
masterのコミットログにはそんなもの残っていない。

もちろん、リリース済み（masterに入ってしまった）
ミスの修正は記録されるが、
masterにマージされるまでの作業履歴は残っていない。
そんなもの必要ないからだ。

自分でずらしといて、ずれてるとか戻すとかw

なんでオープンソースの手法が基準なんだ

>>617
可能か不可能かの話をしてるんじゃない。
なんでいつもそういう話になるんだ？
可能ならどんなに効率悪くてもいいのかよ？

レビューを"しやすく"って言っただろ。
レビューをしやすくするために、見る必要のない履歴は
無い方がいいだろ。

いちいち報告で、やった内容を全部一から語るのか？
途中で間違えたけど修正しました。って。

そして重要なのは最後。masterにマージされる時
そんなくだらない作業内容は残す必要がない。

オープンソースプロジェクトみろよ。
残ってないだろ。

>>619
> 自分でずらしといて、ずれてるとか戻すとかw

やっぱりBTSが「ずらした内容」だって思ってたんだｗ

>>620
クローズドは原則として非公開だから参考にしようがないから。
社内のやり方だけしか知らないと、ガラパゴスになっちゃうよｗ

┐(´д｀)┌ﾔﾚﾔﾚ

>>622
その前からずれてるのに気づいてないのか。ほんと主観だけで動いてる人間だな。

>>623
お前に他の技術者とのコネクションがないことは、よくわかった。寂しかったんだな。

>>621
差分をまとめて見ればいい話。
それがコミットというgitの最小単位になってないと出来ないという前提が理解できない。

差分をまとめて見る手間を減らすためにレビューイがコミットをまとめておいたらレビューアは嬉しいね
ってだけでしょ

うだうだこういう話が続いてると本当うんざりする
VCS運用ポリシーってスレでも立ててそっちでやってくれ

>>591
いまDにいるなら
git tag tag-for-D
git tag tag-for-A HEAD^^^
でいける

「WindowsのほうがいいOSだ！」
「いやいやLinux使わないとか情弱か！」

っていう言い争いと同じだな。
片方のユーザからみたらもう片方側が頭悪すぎワロタに見えるのも同じだろう。

それぞれ大事にしてるものが違うし、
きっとみんながみんな納得いくような単一の結論は出ない。

お互いを改宗させることに努力するより、
同じ宗派の人同士が有意義なGitライフを送れるように情報交換でもしたらどう？

２．３．１

>>629
windowsしか使えない
それ以外が良い場合もある
と言っているんだから違うだろ。

OSの良し悪しなんてPC使う目的次第だろ

>>629
両方使える人からみても「Windowsしか知らない人」は馬鹿確定で良いんだよ
「Linuxしか知らない人」は全く居ない訳じゃないけど母数が少ないので微妙

>>625
> 差分をまとめて見ればいい話。

まとめてみることしか出来ないじゃないかｗ

小さくコミットをまとめるというのは、
要するに大きな機能でも、小さなコミットにまとめられるということ。

なぜ小さなコミットにまとめるのかというと
小さなコミットのほうがコードがわかりやすいから。

その小さなコミットを、全部まとめて大きなコミットにしたら
小さく分ける意味が無いだろｗ

またゴミコミットがあるのも、当然小さく分ける意味をなくしている。

>>629
> それぞれ大事にしてるものが違うし、

俺が大切にしているのは、
このソフトはどういう修正をして
バージョンを積み重ねてきたかという結果だよ。
リリースもしていないものの作業なんか必要ない。

でもなぜか結果じゃなくて過程を残そうとするやつがいる。
ソースコードに修正履歴を残すのと同じ種類の人間だろうね。
あとから見ても必要にならないものまで残そうとする。

>>631>>633>>635
>お互いを改宗させることに努力するより、
>同じ宗派の人同士が有意義なGitライフを送れるように情報交換でもしたらどう？

という意見についてはどう思うんだ?

平和ボケのパンプキン野郎を相手にするつもりはない

>>636
改宗させようなんて思っちゃいないｗ
ここを見たその他の人が洗脳されないようにしているだけだ。

>>638
どんな人が洗脳されるというんだろ。
グループで協力してソフトウェアをつくっている人ならこうするのが当然、
ってお互いに言い合っているように見えるんだけど。

>>639
バージョン管理ソフトなんだからバージョンを管理するのに
必要な情報のみを入れましょうといってる俺と、
なぜか過去の作業報告書を兼ねて、必要ない修正まで記録して
バージョンごとの違いを見難くしましょうと言ってる人の違い。

作業報告書なら別に管理しろよ。
それがgithubでいうならば、Issueやプルリクなんだが。

第一コードの履歴だけじゃ作業報告にもならりゃしない。
Issueやプルリクなら日本語で書かれた経緯が記録される。

バージョンを管理するのはタグの仕事
人が作業した内容をコミットの仕事
タグだけをみりゃあいい
何も全部のコミットをみなくていいだろ

> バージョンを管理するのはタグの仕事
またおまえかｗ

タグは特定のコミットに名前をつけるだけだぞｗ

そのタグの履歴を見たら、
まー、ごみだらけで、何やってるか意味不明。
そんなコミット使い物にならねぇ。

なくすべきだね。
そして不要な情報のない正しいコミット履歴を
持ったものにタグをつける。
完璧♪

コミットを綺麗しないとこうなる。

★タグ 1.0
・ちょっと修正
・さっきの間違えた
・○機能仮実装
・リファクタリング
・○機能ミス修正
・おっと最初の修正のタイポ修正だ
・バグ修正
★タグ 1.1


ほらね。何をやってるのかさっぱりだｗ

>>640
「必要ない修正まで記録してバージョンごとの違いを見難くしましょうと言ってる人」に
洗脳される人が出ないように啓蒙活動をしているということか?

そんなので洗脳される人がいるとは思えないけど。

だんだん状況がはっきりしてきたね。^_^v
洗脳される人が出ないように必死に啓蒙活動している変な奴が少数いて
そいつが騒いで迷惑かけてるということか。やれやれ。

>>643
お前はそんな意味のわからないタグしかつけてないのか?

>>636
履歴をまとめる人は唯一神しか認めてない。
それ以外が良い場合もあるという人は、唯一神を含め八百万の神を認めている。
前者が変わらないとどうしようもない。

立ち見続出

>>646
> お前はそんな意味のわからないタグしかつけてないのか?

お前タグの付け方間違ってるんじゃね？
普通はリリースしたバージョンに対してつけるものだ。
gitだとこうだな。 https://github.com/git/git/tags


お前が言うタグはどういうものか
それと同じ使い方をしている例をgithubでもなんでもいいから
探してきてくれ。

おっとgit 2.3.1がでてるじゃないかｗ

>>648
それはリリースタグという、タグの一種でしかない。
お前がガラパゴスのイグアナだったな。

いいから、早く探してこいよｗ

>>643
ふむ。これをどんなふうに綺麗にするんだ？
作業途中の一時的なcommitのことかと思ってたけど、後から見つかったバグやタイポの
修正なんかもということになると話が違ってくるな。

みんなが自分と同じやり方じゃなきゃヤダー、とワガママ言ってる害虫が一匹消えれば済む話だな。

>>652
リリース前か、リリース後かだよ。

リリース前ならrebaseするべき。
リリース後ならできない。

ここでいう「リリース」の定義は、みんなで
共有しているブランチにマージされた時。

マージされてないならrebaseして、
マージした後の共有ブランチはみんなが見るのだから
見やすくするのがいい。

>>653
> みんなが自分と同じやり方じゃなきゃヤダー、とワガママ言ってる害虫が一匹消えれば済む話だな。

というか、一般的なやり方を見習えばいいだけだよ。

他の人のやり方は、オープンソースプロジェクトを見ればいいんだから
参考にするべきものがないってことは無いはず。

ゴミコミットを残すと言ってる人は、
git bisectの問題をどうやって解決するわけ？

身内相手とかならともかく全く無関係な赤の他人のやり方に口を出すとか何のメリットがあるんだ？
身内に変なのがいたらそいつに直接オレオレルールを叩き込めばいいだけじゃねえの

まあそれも迷惑きわまりないけどなｗ

オレオレルールじゃなくて
一般的なルールだって言ってるだろｗ
gitの基本的な使い方だよ。

んな細かいことどうでもいいよ

>>659
> 一般的なルールだって言ってるだろｗ

お前にとっては
だろ？

> gitの基本的な使い方だよ。

勝手に決めるな、ボケ

んな細かいことどうでもいいよ

>>655
自分が見てるものだけを持ち出して一般的って何だよ。
その理論だと、やり方はひとつのみが正しいということにならないか。
まあ、お前がやってない一般的なやり方は屁理屈つけて、例外とされるんだろうけどな。

一般的な使い方とか正しい使い方とかどうでもいいよ
開発する上で都合の良い方法をその人たちで決めればいいことだろ
チームに変な奴がいるんならここでやらずにそいつを説得すべきだし、「俺の思う正しい使い方」を啓蒙したいんだったらQiitaにでも行ってくれ

>>654
うん、だから、リリース後のコミットが>>643のようにならないようにするために
どう「コミットを綺麗に」すると言っているんだろう？
まさか、すべてのバグを出し切るまでリリースすべきじゃないとか？

もうどっちでもいいよ。俺は俺のやり方でやるから。

>>666
そいつがオレのやり方

まっちさん乙

こいつと同じチームのメンバ大変なんだろうなぁ。
下っ端で聞いてもらえないから、ここて言ってるだけかもだけど。

チームメンバーを俺色に染め上げる

>>663
それで君が見ているものは何なんだ？

まさか、自社限定の井の中の蛙とか？

もっと広い世界を見ようぜ。
それが一般的というものなんだからさ。

例として、gitのやり方を見てみよう。
https://github.com/git/git/commits/master
どんな機能が追加されたのかわかりやすい。

Web とか、誰でも読めてレビューするようなモンなら
レビュー前提である程度まとめてコミットした方がいいし、
ゲームとか、レビューが現実的じゃないケースで
バグったら洒落にならんもんなら細かい方がいいんじゃないの。

レビューがあろうがなかろうが変更意図の最小単位でコミットするのがいいことに変わりはないでしょ
修正の修正はどっちのケースでもまとめてあった方が後から読みやすいと思うが
それを無駄・有害・有用のどれにとるかはPLの好み次第

gitにはpull requestって機能はないんですか？

>>674
git request-pull

>レビューがあろうがなかろうが変更意図の最小単位でコミットするのがいいことに変わりはないでしょ
複雑なシステムだと意図通り動くとは限らないよ

>>671
そうじゃないよ。
自分の見ているものが絶対と思っているかどうかの違いだ。

ホント救いようないな。

コミットログの先頭に記入漏れがあったので修正したいんですが20個もあるんです
git rebase -i HEAD~20でエディット画面になりますが
修正したいログのpickをeditに書き換えて保存して終了後、git commit --amendでまたエディット画面になるので修正してgit rebase --continueをするんですが
20個もやってられないので、最初のgit rebase -i HEAD~20ときに立ち上がるエディット画面のところでまとめてログを書き換える方法を教えてください

修正したいコミッログトのとこで別ブランチを作ってコミットログを書き換えてマージで統合

>>677
一般論はどうでもいいよｗ

自分が見ているもの＝さまざまなプロジェクトが
俺の言ってるとおりになっているんだが。

>>679
それだとブランチを変えてもコミットログを20個編集するために
commit --amend
rebase --continueを20回やるのには変わらないと思うんですが・・・

>>680
「俺の言ってるとおり」っていうのはどのレスのことなんだろう。
もしあんたが ID:s5JPbxDv ID:qn8r0NuB ならとりあえず>>665に答えてくれんか。

>>680
それしか見てないなら、他のを批評するのは何故か。
俺は他のパターンも見てるし、
そのやり方でコストが割に合ってないのも見てる。

>>678
エディット画面で
pick ハッシュ　メッセージ
exec git commit --amend -m'新しいメッセージ'
って言う風にexecを使えばまとめてできそう
http://qiita.com/yuku_t/items/fed530acb97385ecbeee

ちなみにコミットメッセージを書き換えるだけならeditよりrのほうが楽だよ

source treeを使っているんですが、
履歴を削除したいです。

1,2,3,4,5があったとして、
5だけ残したいです。

やり方を教えていただけないでしょうか？

>>678
20個前のコミットのメッセージを1個書き換えるだけじゃなくて20個全部書き変えたいってことでいい？

git commit は-Fでエディタを立ち上げずにコミットメッセージを書いたファイルを指定できるから予め20個編集済みのファイルを用意しとくか、
既存のメッセージを機械的に書き換えられるなら git showのオプションを調整してログメッセージだけ表示させたやつを
perlなりsedなりで書き換えた後git commit -F - --amend にパイプで食わせるようにするとかで一気に行けそうだが。

手間を考えると >>684 の書いてるようにTODOリストで r (reword) 使うのが一番楽だな

>>683
検証できるもので語ろうよｗ

検証できない事だと嘘付いても調べようがないからね。
それを利用して、さも自分が知っている秘密の世界（笑）では
自分の都合のいいことが起きているという。

でも科学の世界では第三者が検証できなければ意見としてみなされない。
だから検証できるものを出すのが重要。

俺は出した。git本家のリポジトリだ。
君はなにか出したかね？ 信用される行動を取りましょう。

なるほど
一理ある

>>688
では、それが一般的というのを立証してください。

>>690
立証方法は数でいいかな？

より多くのプロジェクトでやっているやり方が
より一般的である。

この定義は問題ないだろう。


今のところgitという例がひとつ出た。
反対意見のプロジェクトは0だから
今の所一般的なのはgit風である。

反対プロジェクトが出たら、また一つ探してくることにするよ。。

>>691
いくら数を挙げようと母集団の数が不明なので一般的かどうかわからない。
そんなの語るなよ。
ということになる。

相手より多かったら一般的とか、どんだけ狭い世界で生きてるんだろう。

>>692
じゃあ、検証可能でもっといい方法があったら
それに変更することにするよ。

それまでは、より多くのプロジェクト（誰でも検証可能なものに限る）で
使われている方が一般的という定義にしておくね。

あ、仮だから、仮。

文句ばかり言って、何もだいたい手段を言わない人を
黙らせるための仮の定義だからね〜。

ニセ科学は、数だけなら多いんだyo

>>691
「ほら、gitも俺の主張するやり方してるだろ？」と言われても、その「俺の主張するやり方」が
よくわからないんだが。
>>643と>>671の決定的な違いと考えている点は何？
commit直後に修正入れるようなみっともないことしないよう、ちゃんとデバッグしろということ？

アホすぎる

それぞれの環境に合ったやり方があると言っているのに、
より多くのプロジェクトで使われてるやり方がいいとか。

>>696
> commit直後に修正入れるようなみっともないことしないよう、ちゃんとデバッグしろということ？

コミットはこまめにやるべきだから、ちゃんとデバッグしなくてもいいというか
事実上できないよ。

その代わり、ちゃんとデバッグしてからmasterなり
他人に公開しているブランチにマージする。

こまめにやったコミットをデバッグして、
問題があったらもちろんrebaseして、
きれいなコミットにしてからマージする。

それがgitなどの多くのプロジェクトで極普通に行われている方法。

>>698
それぞれの環境にあったやり方はあるだろう。

例えば、ソースコード管理をせずに
ソースコードに修正履歴のコメントを書く
という環境もあるだろう。

そういう環境があることを否定しているのではなく、
より良い環境とは何か？というのを
多くのプロジェクトをみて学びなさいということ。

>>700
より良いって何だよ。オマエの自己満足だけだろ。

>>700
オマエの言う方法が絶対的に良いのなら、何故他の方法を取れるような実装になっているのだと思う?

>>699
あぁ、もちろん、commitというのは公開するcommitのつもりで書いた。
>>699の内容はおおむね理解できる。結局のところ>>643と>>671の違いは、共有する
branchにマージする前にちゃんとデバッグしたかどうか、ということでいいんだね？

発端は開発効率が上がるからより良いって話だったが、こいつとは別のやつなのかな。

586 デフォルトの名無しさん sage 2015/02/25(水) 00:05:08.53 ID:Wo4XdcUv
>>584
結局のところは、最終的に履歴がキレイに見えればいいわけで。
自分が会社でSVNを使ってた時は、

1. 自分の修正の途中経過を保存しておけるローカルのSVNのリポジトリで作業して、
2. ちゃんと動くようになったら、他人に見せれるキレイなコードに直して、
3. キレイなコードを会社のSVNにコミットしてた。

Gitはそれが一連の流れとしてできるわけでしょ？
なぜGitの良さを殺して開発効率が悪くなる方向に向かうのかが分からない。

とりあえず俺は初心者だからどっちの意見が正しいのかわかんないのでおしえて

まずコミットをまとめる派の意見
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"
このあと何をしてコミットをまとめるのかおしえてくれ

このスレも明後日で終わりか

プログラムなんて完成させりゃいいのに、
より完璧にバージョン管理する方法とか、手続きにとらわれすぎて可哀想。

>>685
スカッシュしようｚ

Git本家のやり方は良いよね。
俺もあの考え方をベースに単純化して運用してる。

>>705
その例じゃわかりづらいだろｗ

まず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 (バグがある新クラス）

この例はまだ機能がまだ少ないからいいけど、例えば、2つのファイル修正。
2つのファイル作成で成り立つ機能を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の拡張）※この時点ではバグあり

new_featureブランチ（全部履歴残す版）をみて
他人が結局何をしたのか？なんて把握できるわけがないし、

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してからマージ

有名なプロジェクトをみても途中の作業履歴が残っていないので
それが一般的であるとうことがわかる。

>>707

> プログラムなんて完成させりゃいいのに、
> より完璧にバージョン管理する方法とか、手続きにとらわれすぎて可哀想。

その考えもわかるけど、それだとsquashするほうがまだましだだから
どちらにしろ履歴は残さないよ。

>>710
まって、俺初心者だからそのあとのコミットのまとめかたをおしえて
実際に打って確認しないとどっち派がいいのか判断できない
態度がでかい初心者で申し訳ないが重用なのでたのむ

>>712 解説乙。
bisectについて補足する。

「new_featureブランチ（全部履歴残す版）」だと
bisectが止まったコミットが本当にmasterのHEADに影響してるか信頼できない。
(bisectが止まったコミットを調べて原因発見したと思っても、
後の修正コミットで何度も試行錯誤されて変更されたりしてると、
最終的にHEADで問題を引き起こしてる原因とは違ってたなんてことがおこる)

逆にトピックブランチのコミットを全部ひとつにスカッシュしてしまうと
bisectで止まったときに見ないと行けない変更量が必要以上にでかくて調べるのが面倒。

「new_featureブランチ（rebase版）」くらいの
ひとつひとつは意味のある単位で、かつできるだけ小さい粒度の複数のコミット
にまとめるのが妥当な落とし所って感じ。

もちろんbisect以外に「あのトピックでどうなってたっけ？」みたいに見直すだけの時も、
そのトピックの成立がわかりやすいストーリーになってるほうが読み解くのに効率が良い。
(むしろこっちのほうがシチュエーションとしてはよくある)

>>714
まとめること自体は、rebaseだよ。
git rebase -i （編集を開始したいコミット）
ってやればエディタが表示される。

そこで順番を並び替えたり
まとめたりするものを選ぶだけ。

ただ、ここでコンフリクト起きたりすると
それを解消するのに時間がかかって本末転倒になるから、
コミットはほんとうに小さく分けてこまめに整理しながらやること。

あと大きな機能は小さな機能に分割してリリースすることだね。
ただしちゃんとした設計ができてないと、あとから大幅に変更することになって
最悪コードやレビューがムダになりかねないから、
小さな機能でもリリース（master等の共有ブランチにマージ）するなら
しっかり作りこまないといけない。

基本は小さく作ることだよ。そうすればコミットをまとめるのも楽になる。

１チン毛セットにつき１コミットだ

　　　　　　　　　　　　　　　　　　彡 ⌒ ミ
　 　　彡ﾊヽヽミ　　　 　　　　　 （｀・ω・´ ）　ブゥーチッブゥーチッ♪
　　　（　´・ω・｀）　　　　　 　 .／ >‐　、-ヽ　　　ペーペケッペッペペーペーペペ♪
　　　/　　　　　ヽ　　　　　　/丶ﾉ､_。.ﾉ ._｡）　ブゥーチッブゥーチッ♪
　　 / /　　　　ヽ|　　→　　〈 、〈Y　,ーiｰ〈ト　　　ペーペケッペッペペーペーペペ♪
　　（_二つ　　　 ）　　　　 　.＼_ξ ~~~~~~Y
　　 |　　　　　 イ　　　　　　　　 |＿＿/＿_|
　　 |　　l⌒ヽ 　ヽ 　　　　　　　 |、,ﾉ | ､_ﾉ
　　
　　　　　　結　果　に　コ　ミ　ッ　ト　す　る　　　ラ　イ　ザ　ッ　プ
　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿　　＿＿
　　　　　　　　┃ライザップ 　　　　　　　 　　　　|　|検索|←をｸﾘｯｸ!!

まだ主観をルール化しようとしてる奴がいるのか。
企業なんかではうまく行かない。

という主観でした（笑）

>>712
> 有名なプロジェクトをみても途中の作業履歴が残っていないので
> それが一般的であるとうことがわかる。
オープンソースとか参考にしている時点で、レベル低すぎて話にならん

>>719
> まだ主観をルール化しようとしてる奴がいるのか。
> 企業なんかではうまく行かない。
それがわからない、一本道真理教がキコキコ三輪車漕いでるっぽい

>>721
一本道真理教だとか、キコキコ三輪車だとかが、必ずしも悪いわけじゃないんだけどね
プロジェクトにいる技術者のレベルが低い場所では、そういうやり方の方がうまく行く場合がよくある

>>721
> オープンソースとか参考にしている時点で、レベル低すぎて話にならん

gitを作ってるgit本家もオープンソースですよ（笑）

何を勘違いしているのか。

むしろ参考にするべきものだ。

社内のオレオレルールを一般的と勘違いしているのかね？
それともうちは馬鹿ばかりだからgitを使うことで精一杯。
正しい使い方ができるレベルにないって話かね？

オープンソース開発と、社内チーム開発じゃ性質が全然違うってことだろ。
どっちが上とかそういう問題ではなく。

社内チーム開発じゃ性質が違うという主張をするのはいいが、
その理由が全く述べられてないのが問題。
だから説得力が全くない。

>>724
それならそもそもgitを使わないほうがいいんじゃないですかね？ｗ

ここまでの流れまとめ

馬鹿「社内の開発はオープンソースとは違う！」
みんな「それで？」

馬鹿「え？」
みんな「え？じゃなくて、何が違うの？」

馬鹿「オープンソースとは違う」
みんな「いや、違うのは分かったから、何が違うの？」

馬鹿「・・・」
みんな「違うは違うだろうけど、それがどうgitの使い方に影響を与えるの？」

馬鹿「・・・」
みんな「社内の開発は、オープンソースとは違うから、こうするべきだっていいたいんだよね？」

馬鹿「・・・」
みんな「なにか言おうよ？明確な理由があるんでしょ？」

馬鹿「り、履歴は全部残すべき」
みんな「だからさぁ。その理由を言えって」

馬鹿「社内はオープンソースとは違う。」
みんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」

馬鹿「違うから、残すべき！」
みんな「だからその理由は？」

馬鹿「オープンソースを参考にしている時点でレベルが低い！」
みんな「だめだこいつ。話にならない。」

>>726
あなたが、gitをオープンソース開発の手法専用にしか使えないのならそうだろう。
まあ、いくつも使い方があると混乱してしまう人も居るから、手法ごとにツールを変えるのもひとつの手だよね。

>>728

>>727の続きですか？

馬鹿「gitはオープンソース開発の手法専用ではない！」
みんな「うん、で、どんな手法で使っているから、履歴は残すべきってなるの？」


いつもの手だね。否定するだけしてじゃあどうするのか？の答えが全くない
言われたことに「それは違う」というだけの簡単なお仕事ｗ

>>725
あなたがわからないなら説明してもいいが、両方経験したことある人は大抵わかるんじゃないかな。

例えばある日、開発を行ってたAさんが交通事故にあった。Bさんが引き継ぐことになったが、やりかけのチケットが意味のあるコミットになってないからと共有されてなかった。
オープンソースなら、なかったものかそもそも気付かれずに、他の人がやるだろう。
社内ならそれには社のリソースを使っていたのだから、共有されているべきだ。
ストレージを共有するとか他の手段もあるが、gitで共有するのもひとつの手段だ。

>>728

なんか、ファイルコピーを利用した履歴保存テクニックとか
エクセルで作る仕様書講座。みたいな臭いがするなｗ

専用に作られたものを使わずに、今の俺が知ってるのがこれだけだからという
消極的な理由で、適していない道具を使って無理やりやろうとする。

より良い方法を調べて改善していこうよ。それともそれをしないのが
（あんたの）社内の伝統なのかな？
必死で主張しているあなたの"社内"が透けて見えるね。

>>729
その話じゃないよ。馬鹿乙。

>>731
会うこともない数万人が見るものと、
席を隣にしてる数人が見るものを、
同じ方法でコストも含め同じく良い結果が得られるの?

>>730
> 例えばある日、開発を行ってたAさんが交通事故にあった。Bさんが引き継ぐことになったが、やりかけのチケットが意味のあるコミットになってないからと共有されてなかった。

それはプッシュすればいいだけの話だが？
git使ってるならコミットは毎日よりも短いタイミングで行ってる。

もしかしてコミット＝プッシュと勘違いしている？

コミットを共有リポジトリにプッシュすればいいだけの話で、
過去の意味のない履歴を残す理由にはなってないよ。

プッシュした後も、そのブランチが個人のものならrebaseできるし
してもいいってわかってるかな？

リモートの誰からも見える個人の情報をプッシュするのと
（リモートにある）共有されたブランチにマージするのは別の話。

交通事故〜の話なら、個人のリモートブランチ（またはリポジトリ）にプッシュすれば十分。
そしてこれは履歴を残す話とは全く関係ない。

わかってるのかな？

>>733
違うと主張したいのなら
「違う」と言うだけではなく、
その理由を書くように

>>730を見てると、subversionの根本的な設計ミスによる悪しき習慣と
「どんな場合でもpushしたものはrebaseしたらいけない。」という
gitを中途半端に学習した初心者の間違った理解っていうものを
ひしひしと感じるね。

>>734
オープンソース開発で個人のブランチを共有するの?

そういや、交通事故の話、subversionの方が悪影響あってね。

subversionはコミット＝プッシュだから、
「作りかけだからプッシュしない」と考えるようになる。

gitだと作りかけでプッシュしても、後から直せるから
どのタイミングでもプッシュっ出来るんだよ。

>>735
わからないのに知りたいなら、
教えてください、お願いします。だろが。
なんで馬鹿様基準で書くと思ってるんだ。

>>737
オープンソースとか関係なく、他人に見せるべき情報なら共有するが？

githubの例で言えば、オリジナルのリポジトリを
個人がフォーク（これは共有される）して
ブランチを作ってプルリクエストを送る。

もちろんしたくないなら、ローカルで作業しても構わないが、
少なくともプルリクの段階では、個人リポジトリに作った
個人のブランチを共有することになる。

>>739
いえ、知りたくありません。
だって反論はここにない方が
私にとっては都合がいいですから（笑）

>>741
うん、経験のある多くのやつはわかってると思うから、わからない奴は黙ってればいいよ。

>>740
見せたい、見せたくないに関わらず、社のリソースを使ってやってることだから見せるってこと。

>>742
そのセリフはみんなから「あぁ、言い返せないんだ」って思われるだけですよｗ

「反論意見はない」

あなたも私も両方が満足する答えでだからこれでいいと思います。



>>743
はい、見せればいいと思いますが？

ちなみに世の中にはこんな人がいるかもしれませんね。

「赤ペンで添削された報告書をそのまま出す人」

いわく。修正した過程が重要なんです！

>>744
わかってる人からは、なんでそんな馬鹿な質問してるんだろうと思われてるよ。

>>744
作業量を評価する時に試行錯誤を評価する場合がある。
コミット量のグラフとか見たことないか?

>>745
だといいですねｗｗｗ

思っていることは想像

事実をだけを見れば「反論理由はない」

あなたも私も満足する結論ですｗ

>>7466
> コミット量のグラフとか見たことないか?

githubにあるやつですね。gitlabにも最近つきました。

で、それがどうかしたんですか？

あーわかった。rebaseすると、コミット量が減ると思っってるんですね。
それはマヌケです。

fix typo
fix typo
fix typo
fix typo

というコミット数の水増しで
評価を水増しできる会社で働きたいですｗ

こういう風にツリーをごちゃまぜにする奴が居るから、消したりして読みやすくしなきゃなんないのかw

途中の説明も結論には必要ないのでコミット同様消しますw

> 750
説明が必要なものなら、コミットログ
（場合によってはソースコード）に書けば？

fix typo
fix typo
fix typo
fix typo

のようなコミットに説明が必要だから残さないといけないと
いう考えがわからない。


全部残す or 全く残さない
の二元論になってるね。

考えているようで全く何も考えてないよね。
必要か必要でないかを考えないで
全部残しておくなら、馬鹿でもできるもの。

報告で結論だけ言ったら、説明を求められたので、
間違って直したものも含めてやったこと全てを
報告したら怒られました。何が行けないんでしょうか？


みたいなレベルで仕事している人いるのかなぁ？＿

報告は必要な物を簡潔にでしょ？

人を使う立場に立つと、こういうバカがいることも考えて、やり方を決めなきゃいけない。

「社内チーム開発」とやらががそんなにすごいなら利用できるかもと思って期待してたんだけど、
「おーしおまえら、帰宅前は作業中の状態でもいいからコミットしてリポジトリにプッシュしとけよ。
でもマージ依頼するときはちゃんとコミット整理してからな」
で終わる話だった。

>>751
それ、残さないとしたらどうやるの？

WIPコミットでもブランチ切って触るなアピールしとけば履歴気にする必要もないし

>>755
公式ドキュメントのチュートリアルとrebaseのman(特に -i 関連)を10回くらい読んでから
>>710 からの流れを10回くらい読め

そういう話じゃなくて。
その関係あるかないかわかんないfixを全部ひとつのcommitにまとめちゃうの？

タイポのコミット同士をまとめるんじゃなくて
タイポした元のコミットとまとめて、機能変更の履歴としては不要なタイポしたというログをなくす

その機能変更がまだローカルだったらそれでいいけど、bugやtypoって
たいがい後から見つかるものじゃない？
その場合は>>761のままでいいってこと？

>>760
テストしてリリース（レビューも終わって共有しているブランチにマージ）して
しまったものは仕方ないよ。 その歴史は改ざんできない。

だけど、バグやタイポっていうのは確かに後から見つかるが、
ずっとあとではなく、より近い未来の方が見つかる。
修正した所にバグが発生するのだからね。

だからリリースよりも前に見つかる物の方がより多い。
その多い問題を直すことが出来るし、直した方がいいという話をしている。

ちなみに、
> その機能変更がまだローカルだったらそれでいいけど

共有と公開は違う。

1. ローカルは非公開
2. 公開は他の人が参照できるリモートリポジトリやブランチにプッシュすること
3. 共有とは、他の人も修正を加えるブランチにマージすること


ローカルでない = 共有 ではない。
共有する前に公開して、そこにレビューが行われてから、共有される。

情報共有みたいな言葉があるから勘違いするかもしれないけど
公開したからって直ちにそれが共有されるわけじゃない。

ちなみに、masterは共有ブランチと誰もがはっきりわかるだろうが、
その他のブランチは共有されたものなのか、個人のものなのかわかりづらいだろう。
そこは名前つけルールなどで解決できるが、個人的には
「公開された個人専用のリモートリポジトリ」を用意することをおすすめする。

githubであるプロジェクトをフォークして、自分専用の
公開されたリポジトリを作るのと同じようなもの。

俺が社内用として勧めるgitlabでも標準的な機能として採用されている。

個人のリポジトリは、gitlabにおける個人のネームスペース以下に
作られるから、それが共有されたものなのか、
単に公開されたものなのかはっきりわかる。

オープンソースと社内プロジェクトじゃ
履歴を利用する人も目的も違いから必要な粒度も違うっしょ

>>763

それは>>727にまとめてあるから言わなくていいよｗ

ここまでの流れまとめ

馬鹿「社内の開発はオープンソースとは違う！」
みんな「それで？」

馬鹿「え？」
みんな「え？じゃなくて、何が違うの？」

馬鹿「オープンソースとは違う」
みんな「いや、違うのは分かったから、何が違うの？」

馬鹿「・・・」
みんな「違うは違うだろうけど、それがどうgitの使い方に影響を与えるの？」

馬鹿「・・・」
みんな「社内の開発は、オープンソースとは違うから、こうするべきだっていいたいんだよね？」
馬鹿「・・・」
みんな「なにか言おうよ？明確な理由があるんでしょ？」
馬鹿「り、履歴は全部残すべき」
みんな「だからさぁ。その理由を言えって」
馬鹿「社内はオープンソースとは違う。」
みんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」
馬鹿「違うから、残すべき！」
みんな「だからその理由は？」
馬鹿「オープンソースを参考にしている時点でレベルが低い！」
みんな「だめだこいつ。話にならない。」

オープンソースでのソースは見せるためのものであり
履歴もその中に含まれるからだろ

社内開発はそうじゃない
１に生活ぶ、２に納期、３４がなくて５に責任

それが履歴残すことで、解決できるのかよｗ

>>766
お前日本語理解出来ないのな…

そうか？ 誰か本人以外に理解できた人いる？
アレを理解できる人がいるのなら、説明して見せてよ。
本人以外がｗ

馬鹿「社内はオープンソースとは違う。」
みんな「違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」

馬鹿「社内開発は１に生活ぶ、２に納期、３４がなくて５に責任 」
みんな「だから違うのは分かったから、どこがどういうふうに違って、だから履歴を残すべきって結論になるのさ？」

履歴の潔癖さにかまけてる暇などないって事いいたいんじゃないの？

なんか勘違いしてそうだから念の為に言っておくけど、
gitはリリースされたものを改ざんすることは難しいよ。

なぜなら、リリースされたものの複製を
みんなが持っているから。

>>770
それをいうのなら、忙しすぎて他人が何やったか
誰もコードをレビューをしてないって言うべきじゃないの？

誰かにレビューを依頼する時、その依頼をされた人は
そのコードを見ないといけない。当たり前だけど。
その時大量の修正をいきなり渡しても、
その修正が妥当か判断することは出来ない。

書いた本人は、何をやったかわかっているのだから
書いた本人が、綺麗にしてからレビューを依頼するほうが効率的だよね？

コードを他人に見てもらおうと考えてないし、見ることを全く考慮しないコード
何を修正するにも、影響が範囲がわかりません、どこで問題が起きたのかわかりません
解析に時間がかかります。というのが忙しい原因の一つだろうね。

某傾いてる電気系メーカ（いっぱいありすぎるかｗ）のプロジェクトで
ソース出せって言っても出さない朝鮮人の下請けが居たよ
コミッターだったらしいけどまあ微妙で赤字になった

だからさっさとコミットしろって意味じゃねーの？

>>766
>>765はオプソは履歴を残すが社内開発はそうじゃない(残さない)と書いてある

その是非は置いといて、それ以前にその日本語が理解出来てないって馬鹿にしてたんだが
それすら分からんのな…

>>773
それだと、ソース出したくないなら、コミットしないから意味無いでしょ？
内部でちゃんと保存していますといって終わり。

コミットしろという言葉が通用するなら、
プッシュしろっていう言葉も通用するわけで、
それは人の問題。

>>774
> その是非は置いといて、それ以前にその日本語が理解出来てないって馬鹿にしてたんだが

日本が理解できてないってどこの部分が？

あんたこそ日本語が理解できてないんじゃないの？ｗ

後で変更できないからコミット自体をためらうという弊害はあるな

>>765の会社って、きっと何の資料も残してないよ。
議事録とかもなさそうだね。
社内開発の内容を残さない会社なのだから。

>>777
> 後で変更できないからコミット自体をためらうという弊害はあるな

そうそう。それがsubversionで実際に起きていた問題の一つなんだよ。

作りかけでもいいから、とりあえず提出しろ、もし問題があればすぐに指摘できるから。
問題があればそれを直せばいいだけ。完成してから出すんじゃない。
その時に問題がわかっても既に手遅れになっている。

これが最近俺が言っている事。
最低でも一日に一回は作りかけのものをプッシュするようにって
言っているよ。ミスはあとで変更すればいいだけだからね。
git使ってるならプッシュしない理由がない。

作業途中も見れるから、完成したときには問題のないコードになっていることもある。

>>776
>>765
オプソは見せる為のもので履歴も含まれる
↓
社内開発はそうじゃない(残さない、他に優先すべき事がある)
↓
>>766
> それが履歴残すことで、解決できるのかよｗ
↑
ぷっ

>>780
あー本当にわかってなかったのかｗ

>>765
オプソは見せる為のもので履歴も含まれる
↓
社内開発はそうじゃない(残さない、他に優先すべき事がある)
（他に優先するべきもののために、履歴は全部そのままとっておくほうがいい）
↓
>>766
> それが履歴残すことで、解決できるのかよｗ


こういう流れだよ？
最初から、履歴を整理する？ or 履歴を全部残すか？
って話だっただろ。

>>781
あっそ
結局全部残すのが前提で糞みたいな議論を延々続けてんのかよ

>>782
分かったならいちいち勘違いで噛み付くなよ。
せっかく履歴はあとで見やすいように整理するべきって
結論になってたんだから。

> オープンソースプロジェクトみろよ。

○○ちゃんはこうやってるから

> みんな「違うのは分かったから、

自分=みんな

これは…典型的な小学生だな

勝手に自分一人で結論づけといて、さも総意であるかのように言うところもか。
結局印象操作によるゴリ押ししかできないと。

まず双方どんなプロジェクトを想定しているのか
はっきりさせようか。

>>786
それ1つで、どんなプロジェクトにも対応できるという主張と、
プロジェクトごとに、それぞれ違う手法が最適という主張だから、
後者は想定がないんじゃ。

このスレのアスペどもはどうでもいい議論をいつまで続ける気なの

例えばgithubで複数人で開発していく時にさ
コミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん
そしたらそれを修正するためのコストがかかるんだよ
だからコミットを何でもかんでもまとめるべきではない
まとめるときはまとめるという行動を必要最低限にするべき
プッシュスルまでにこまめにまとめると自爆するんだよ

github登録したけど何を上げたらいいのかわからない・・・
そこまででっかいもの作ってないし、何を上げていいのかサッパリだ

売名していくならgithub
誰にも見せたくないならbitbucket

>>789
> コミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん

コマンドの使い方が適切ならそんな間違いは大抵防げると思うけど。
例えばどんなシチュエーション？

git rebase -i HEAD~n
nの打ち間違えとか

>>761
うーん、わかったようなわからんような。
要はレビュー等でリリース前にバグを潰せればfixの履歴を残す必要がない、と。
それはそれでいいけど、gitの運用ポリシーとかそういうのとは関係ない話のような。

共有リポジトリを上書きしようとしても蹴られるだけだから間違えて困るのは自分だけ

>>793
nが小さい分には無害だから大きく指定してしまうってことだよな？
それをよくやってしまうようなら 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 を見ればいいわけだし。

git rebase -i `git merge-base master HEAD` でもいいかもしれん。

>>782-783
自分一人でやってるなら、自分が好きなように履歴をまとめていいと思う。

ただし技術レベルが低い他の人が入ってくると、
・typoとかう○こしに行ったとか、どうでもいいコミットをリモートリポジトリに入れまくって場を荒らす
・まとめちゃいけない履歴をまとめてしまって、とんでもない状態になる

という、2つのリスクが生じる。
それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
Git運用ルールができたとしても、短絡的ではあるが分からなくはない

>>792
> コミットをまとめるっていっても、すでにgithubにあがっているコミットまで間違えてまとめてしまうリスクもあるじゃん

ありえないなｗ

自由にまとめられるのはローカルにあるもの、もしくは
自分専用リポジトリにあるものだけ。

ローカルにあるmasterの過去の履歴を変えてpushしたら他人に影響出るけど
過去の履歴を変えているならば、いつもどおりにpushはできずにエラーになる。
push --forceしなければ変えられない。

その上、みんなが共有しているものはgit push出来ないようにしている。
（gitlabならウェブ管理画面から設定するだけ。githubはしらないがpre-commitに仕込めば良さそうだ）

つまり共有しているものに対しては、pushは許されずに、マージのみ可能にしているから
すでにgithubに上がっているコミットを間違えて修正することはない。

いい加減やめろマジで

ん？長文だけど違う人か
サーセン

>>798
> ただし技術レベルが低い他の人が入ってくると、
> ・typoとかう○こしに行ったとか、どうでもいいコミットをリモートリポジトリに入れまくって場を荒らす
> ・まとめちゃいけない履歴をまとめてしまって、とんでもない状態になる
そういうのはsubversionでも同じでしょ？

そういうのを防ぐために、githubやgitlabといったものがあるんだよ。

さっきも書いたように、masterや特定の共有ブランチには誰もpush --forceできない。
そして技術レベルが低い人には、masterへのマージ権限もなくしてしまう。

そうすると履歴を荒らすなんてことは不可能になる。
もちろんローカルは自由になんでもできるが、
それを共有するためには、正しい履歴で技術レベルが低い人は
レビューを通さないとマージされない。

運用ルールを決めるのではなく、まずツールを導入して正しく理解して使うことが重要。

よく日本はパッケージを買って、そのパッケージに業務を合わせようとするのではなく
パッケージのほうを業務にあわせてカスタマイズしようとするから、無駄が多いって言われるね。

>>798

> それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
> Git運用ルールができたとしても、短絡的ではあるが分からなくはない

そういうルールができたら、
「機能がひと通り完成して全体が出来るまでプッシュしない」
ってなってしまうと思うけど？

マージする段階では綺麗になっていないといけないが、
それよりか前の段階では、自由にrebaseしていいならば、
小さくコミットしていけるわけだが。

ま、git使ってるならばローカルで何やっても自由で他人にはわからないんだがねｗ

共有 と 共有していない 状態で、ルールが違うってことを認識しないとね。

gitみんな好きになる

>>802
あなたが言ってるのはツールの使い方であり、他人の使い方ではない

同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
チームがこじれることって多い

日本はパッケージのほうを業務にあわせてカスタマイズしようとする・・・としたら、
それはおそらく文化的な側面によるものだろう

ログを整理したいならコミット台帳を別個に作ってそこで清書しろ
履歴を改ざんリスクに晒す必要などない
権限ユーザがいないと共有リポジトリの更新が止まるならより悪化してるじゃないか

履歴の書き換えぐらいで何のリスクになるん？
大げさに言い過ぎじゃね？

もはやVCS一般のどうでもいい話をする糞スレに成り下がったな

自分の意見のゴリ押しばかりでソース管理以上にチームの意思あわせ大変そうだな

てｓ

.gitconfigに
[alias]
a=add .
ac=!git a&&git commit
って書いてあったんですが、エイリアスの中からエイリアスを書いたら不具合でませんか？
あと!ってなんですか？

>>805
> 同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
> チームがこじれることって多い

意味がわからん（苦笑）

じゃあ両方に権限与えればいいんじゃね？

この際だからさ、git以外も含めて全部権限与えろよ？
それで混乱したって、チームがこじれるよりマシだだから
お前はそれを選択するんだろう？

git関係ないじゃん。

>>807
> 履歴の書き換えぐらいで何のリスクになるん？
> 大げさに言い過ぎじゃね？

全くその通り。

共有されてない所でやるのだから、
単に最初から間違えなかった形にしてから
提出するだけの話。

なんのリスクなのかさっぱりわからんよね。

間違いは直せばいい。
共有するコードに要求される品質レベルはプロジェクト次第なんだから
ルールだって違って当たり前。

>>812
＞じゃあ両方に権限与えればいいんじゃね？
＞この際だからさ、git以外も含めて全部権限与えろよ？
＞それで混乱したって、チームがこじれるよりマシだだから
＞お前はそれを選択するんだろう？

いや、自分ならこっちを取るな
　『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
　Git運用ルールができたとしても、短絡的ではあるが分からなくはない』


＞git関係ないじゃん。

「rebase禁止」も「rebaseオッケー」も、Gitの機能とは関係ない、Gitの運用ルールの話だよ

>>815
> 　『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう

え？ なんの関係があるの？ 権限の話でしょ？

そのコードをマージするのは誰？
メインブランチにマージするのは誰？
マージするのは入社何年目の人？

入社何年目かの同じ年次の人は
全員、同じ権限を与えるっていうのが
あんたのやり方なんでしょ？

ならどんなにダメな人でも、マージする権限持ってるわけだよね。

手をつないでみんなでゴールしましょう的な
ゆとりの発想。

>>814
＞共有するコードに要求される品質レベルはプロジェクト次第なんだから
＞ルールだって違って当たり前。

自分もそう思う
違う点があるとすれば、自分は「Gitの運用ルールを決めるのは、要求される品質レベルじゃなく、
プロジェクトに集まった人の技術レベルじゃないか」と思ってるところだ

つまりは馬鹿向けのやり方ってことかｗ

正しいやり方っと言うのはある。
それは当然高い技術を持った人のやり方。


そして技術が低いものがやる
初心者向けのやり方。
それは、正しいやり方よりも劣っているが仕方ない。
初心者なのだから。

>>816
＞ならどんなにダメな人でも、マージする権限持ってるわけだよね。

いや、自分なら逆の方向をとる。

どんな良い人でも○○の職階を持っていない人、または自分以外は
マージする権限を与えない、って方に倒す。

> どんな良い人でも○○の職階を持っていない人、または自分以外は
> マージする権限を与えない、って方に倒す。

同じ年次の、Aさんに権限を与えてBさんに権限を与えない、とかを安易にやると、
チームがこじれることって多い

↑これお前が言った言葉。

年次が同じなら同じ権限を与えるんでしょう（笑）

>>818
＞つまりは馬鹿向けのやり方ってことかｗ

その通り。
例えプロジェクトリーダーでも、プロジェクトに集まったバカをクビにする権限は持たないしね。

だから、まさにこの言葉の通りだ
　『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
　Git運用ルールができたとしても、短絡的ではあるが分からなくはない』

>>820
＞年次が同じなら同じ権限を与えるんでしょう（笑）

そう。
だから、両方に権限を与えない方に倒す。

>>821
それじゃ意味がわかりにくいから
ちゃんと正確に言おうよ。

※↓正しいやり方が出来ない人のための馬鹿向けのやり方です
　『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
　Git運用ルールができたとしても、短絡的ではあるが分からなくはない』
※↑正しいやり方が出来ない人のための馬鹿向けのやり方です

>>822

じゃあ誰もマージする権限を持てないってことになるなｗ

>>823
元の文章より長くなっただけで分かりにくい。

>>824
そう。自分以外は。

>>825
正しいやり方、普通の人のやり方ではないということが
一番重要な点だから、これは省略してはいけない。

※↓正しいやり方が出来ない人のための馬鹿向けのやり方です

　『それに対して、「1コミットで意味を成すようにしろ、typoも許さん」「rebaseは絶対にするな」っていう
　Git運用ルールができたとしても、短絡的ではあるが分からなくはない』

※↑正しいやり方が出来ない人のための馬鹿向けのやり方です

>>826
勝手にルールかえんなよｗ

お前と同じ年次であれば全員同じ権限だ。

お前が言ったことだろドアホｗ

まさにゆとりの発想ｗ
同じ年なら、権限も一緒♪

連日チャットみたいな勢いだなー

>>827
もとの文章の>>798の方が分かりやすい。

だれか〜

>>828
そこは>>828に書いてある通りだ

＞どんな良い人でも○○の職階を持っていない人、または自分以外は
＞マージする権限を与えない、って方に倒す。

自分だけはプロジェクトリーダーだから特別なんだ。

ごめん、>>821でした。

ごめん、>>819だ。

>>832
> 自分だけはプロジェクトリーダーだから特別なんだ。

関係ないよ。
同じ年次であれば、同じ権限を持たせないと
チームがこじれる。

俺だけは特別だって言ってるならなおさら。

むしろ同じ年次であれば、一人がプロジェクトリーダーなら
他の人もプロジェクトリーダーにするべきだな。

なあgit使いってバカばっかりだろ
このスレ見て分かるように
年中揉めてるよな君ら
なんか構造的な欠陥があんじゃねえの

自演にしか見えない

バカでも手出しちゃうくらい普及しちゃったってことでひとつ

なるほど
一理ある

>>839
納得

馬鹿が使うのはいいんだが、馬鹿が管理者もどきみたいなものになって
gitをぶち壊すような使い方を押し付けるのだけはやめてほしいね。

別に馬鹿が管理者でも、運用しながら意見出してきゃいーやん。gitという仕組みに収まるようになってんだから。

馬鹿を侮ってはイクない
馬鹿を舐めてはイクない
馬鹿を相手にしてはイクない

物を知らない馬鹿なweb屋が吠えてるなあ

>>842
gitをぶち壊すような運用にはならないと思う
gitのコンセプトが活きない運用には、なるかもしれないけど

>>837
git使ってるやつらがgitなんだから、しゃーない
だけど、開発者が自虐でgit（バカ）って付けたつもりが、
ユーザは本当にバカの集まりだったんだから、開発者も愕然としたろうな

>>846
まあ確かに。個人のPCの中まで覗いてあれこれ言う訳もないのだから
rebaseし放題ではあるなｗ

レビューによる細かい修正が入ったら、別のブランチに変更すればOKだろう。
（見える所で）rebaseはしてない。ただ綺麗にしたブランチに仕切り直ししただけ。
意味をわかってないのにルールを作ろうとする人には、この程度の技で乗りきれるだろうｗ

２．３．２

複数人で開発するなら
add
commit
merge
rebase
status
log
branch
reflog
checkout
これしか使いませんよね、他にもありますか？
これ以上何か覚えるのは無駄な気がします

cloneとpushとfetchとpullも追加します
initは一回しか使わないので除外しました

>>850
remoteがなければ、他人のブランチ追加できないし、
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

remoteってcloneした時点で設定されてるので入りますかね？

git helpだけ覚えればあとは何も覚える必要はない

開発ブランチでコミットを何回かしてmasterにチェックアウトしてプッシュ、そしてまた開発ブランチにチェックアウトしてコミットして・・・の繰り返しでリポジトリって壊れますか？

なんか壊れてしまって、最後にコミットした内容がなくなってるんですがどうやって復活できますか？
reflogで最後にコミットしたのにチェックアウトしても内容が空でした

git のバージョンは2.3.0です

reflogでコミットって何？
壊れたってのはローカルリポジトリ？
かなりの確率で「壊れた」じゃなくて「壊した」だと思うけど

reflogに頼らざるを得ない状況で
最後の1コミットを試行錯誤で復元するくらいなら
書き直した方が早いんじゃね

ああ接続助詞「のに」じゃなくて最後にコミットした「状態」にってことか

結論は変わらないが

コミット時にaddし忘れてたとか間違ってaddしたとか
IDEが同期できてないとかいうオチじゃないの

diffはなんて言ってるの？

気持ちの悪い擬人法だなぁ

？

sourcetreeで今実行したgitコマンドを確認する方法を教えて

>>860
858の最後の、「コマンドが喋った！」的なところだろう

git pushはユーザがpushしているという解釈ができなくもないが
git showはどう考えてもgitにshowさせている

そういう文化で気持ち悪がられても強くなれ！としか

>>863
こちらは、diffたんは何て言ってるの？ってことを指したつもりだ

＞そういう文化で気持ち悪がられても強くなれ！としか
ちなみに、この返しも相当気持ち悪い

>>863
> git showはどう考えてもgitにshowさせている
無意識だろうけど、擬人法になってる
コンピューターをこういう理解の仕方してる事が気持ち悪い

コマンドという言葉も命令という擬人化が気持ち悪い？

>>865
良し悪しは別にして、OOP の説明とかでよく見ると思うが

単なる使役動詞だろ。

今日プッシュしたコミット一覧を調べる方法ない？

開発ブランチをマージしたらいったんその開発ブランチを削除して作りなおしたほうがいい？

これだけじゃ足りないな。

revertがない、stashがない

>>863自体の気持ち悪さが半端ない

開発・テスト用リポジトリ・・・DBパスワード等はテスト鯖用あるいはダミー

運用リポジトリ・・・開発・テスト用リポジトリから最新のバージョンをフェッチしマージして使う、DBパスワード等は当然実際のもの

こんな感じでおｋ？

> DBパスワード等は当然実際のもの
そういう運用がありえないとは言わんが
少なくとも当然ではないだろう

この人たちいったいどこから流れてきてるんだろう

sourcetreeで今実行したコマンドを確認する方法教えて

linuxで定番のGUIってなんですか？

XWindowSystem

>>873
一般的にはデータベースのパスワードはリポジトリに入れない。
リポジトリに入れない設定ファイルとして分離しする。
そのリポジトリをオープンにしたら？って考えればわかるでしょ？

パスワード関連の設定はアプリのデプロイに関連する話
そういうデプロイのシステムがなければ、
単にサーバーに設定ファイルを置く。

あと開発・テスト・運用リポジトリなんて分け方はしないしブランチにもしない。
すべて同一のリポジトリの同一のブランチを使う。
でないとそれぞれが本当に同じものなのか分からないし、
同期をとる作業が面倒になる。