Git 10

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

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

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

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

ｲﾁｵﾂ

Gitを使うと早漏になるの？だったら嫌だなあ、使うの控えるべきかしら？

ｱｰｲｷｿ

　∧＿∧　　　　　　 SVN？ ぎっとぎとにしてやんよ
　(　･ω･)＝つ≡つ
　(っ　≡つ＝つ
　/　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　( /￣∪

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

◆関連スレ
バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ〜 Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://peace.2ch.net/test/read.cgi/tech/1326806859/
【分散型バージョン管理】 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/

◆関連書籍
Pro Git 日本語版電子書籍公開サイト
http://progit-ja.github.io/

開発効率をUPする Git逆引き入門 2014/04 著:松下雅和 船ヶ山慶 平木聡 土橋林太郎 三上丈晴
http://www.c-r.com/book/detail/970

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

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

実用Git 2010/02 著:Jon Loeliger オライリー本
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8

入門Git 2009/9 著:濱野純
http://www.shuwasystem.co.jp/products/7980html/2380.html

入門git 2009/08 著:Travis Swicegood 監訳:でびあんぐる
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

スレ立てて書き込み少な目で放置しとくと落ちるのは自動なのか？このスレは大丈夫なのかね？

入門Git以外は手に取ってみる価値もない
でFA?

GoogleAppsScriptで書いたソースをgitでリポジトリ管理するにはどうすればいい？

>>11
import/exportができるみたいだからそれ使えばいいんじゃないの？
http://qiita.com/soundTricker/items/e75ee1f2a7d89fa60a60

単に特殊なデプロイが必要になるってだけ。

import/export を自動化するスクリプトを GoogleAppsScript で書けないかな

>>10
どっちの？

念のためにこっちにも
Git 2.0.1 リリース
https://github.com/git/git/releases/tag/v2.0.1

>>14 君には入門Gitが入門gitに見えるのかね

スレ番も数字じゃなくハッシュ値で

さ　あ　、　も　り　あ　が　っ
　　　　　　　　　　　　　　　　　　て
　　　　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　　　　　　　　い
　　　　　　　　　　　　　　　　　　　　　　　　 り
　　　　　　　　　　　　　　　　　　　　　　　　　 ま
　　　　　　　　　　　　　　　　　　　　　　　　　　 し
　　　　　　　　　　　　 　　　　　　　　　　　　　　た

兆戦の皿が白ばっかりなのは
土器みたいに茶色いままだと
うんこが付いてても気付かないから

日本の器に黒っぽいのが有るのはうんこが付いてても気にせず食べるから？

皿にうんこが付く状況ってどんなんだよ

器にうんこが付くという発想がないから

トンスルランドでは台所に便所紙捨てるところがあるんだっけ

日本に観光に来てる連中は
ホテルのトイレでも紙をゴミ箱に入れるので
従業員を困らせている

日本も戦前は同じだったそうだよ

ここまで Git の話なし

今日のうんこスレはここですか

一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。

こんな注意書きが必要な連中なので

敗戦直前の日本の雑誌に、汚れたバケツに貯まった雨水を飲み水に使うことの美徳が書かれていたって話を思い出すな

それはともかく、Gitのブランチ管理はややこしいよなー
未だに解説読みながらやってる

gitのブランチ管理じゃなく
git flowもしくはgithub flowのブランチ管理がややこしいのでは

$ git clone https://github.com/username/repo.git ← 自分のリポジトリ(SSHキーは登録済み)

色々作業してローカルでコミットした

$ git push
fatal: could not read Username for 'https://github.com': No such file or directory
↑
なんでなん…
その後こうしたらpush出来た
↓
$ git remote rm origin
$ git remote add origin '[email protected]:username/repo.git'

originを変更しないと駄目な理由を分かりやすく教えてください

>>31

http://git-scm.com/book/ja/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

> HTTP 越しの Git のプッシュを行うことも可能ですが、あまり使われていません。
> また、これには複雑な WebDAV の設定が必要です。めったに使われることがないので、本書では取り扱いません。
> HTTP でのプッシュに興味があるかたのために、それ用のリポジトリを準備する方法が
> http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt で公開されています。

>>32
おお！素早いご指摘どうもです
よく理解できました
これからはそのドキュメントを良く読むようにします

っていうかGitHubってhttpsでのpushに対応してたっけ？

httpsのアドレス宛にいつもpushしてるが

>>31
単にpushする先を指定してないだけだろ。

URL指定でcloneしているから、
originと紐付いてないだろうし。

ローカルリポジトリのブランチhogeにコミットしました

ここでリモートリポジトリのhogeにコミットするはずが、リモートのmasterにコミットしてしまいました。

取り消すにはどうすればいいのでしょうか？

パルプンテを唱える。

もしくはメガンテ

git remote -v
origin https://hoge.com/fuga.git (fetch)
origin https://hoge.com/piyo.git (push)

git add . --all
git commit -m "hoge"

git push origin master

to https://hoge.com/fuga.git
master -> master

git branch -a したら

remotes/origin/HEAD -> origin/master

と出てきたんですが、これはhttps://hoge.com/fuga.gitのmasterにコミットされたということですよね？

用語が変なのはgit使いでなくsvn使いとかか

>>37
リモートリポジトリの管理者にごめんなさいして、どう処理するか相談する

リモートリポジトリをcloneしてmasterブランチのlog見たらコミット履歴にありませんでしたが・・・
どこにコミットされたのでしょうか・・・

>>41
その通りです

用語がめちゃくちゃで何を言ってるのか何をやりたいのかさっぱり分からん

>>40
その一番最初の git remote -vの結果が正しければ、
そのリポジトリで普通にpushすると https://hoge.com/piyo.git に反映されるはず

それなのに https://hoge.com/fuga.git にpushされたというログになってるのはオカシイ
＞git push origin master
＞to https://hoge.com/fuga.git
＞master -> master
写し間違えた？

>>43でcloneして確認したリポジトリは https://hoge.com/piyo.git か https://hoge.com/fuga.git のどっち？

質問が不明瞭、かつ書き間違いなどがあり申し訳ありませんでした。
もう一度できるだけ詳しく正確に書くように致します。

git remote -v
　　origin https://hoge.com/fuga.git (fetch)
　　origin https://hoge.com/fuga.git (push)
　　upstream https://foo.com/fuga.git (fetch)
　　upstream https://foo.com/fuga.git (push)
※「https://hoge.com/fuga.git」は「https://foo.com/fuga.git」をcloneしたもの

　　　　　　↓

git branch -a
　　branchA
　* branchB
　　master
　　remotes/origin/HEAD -> origin/master

　　　　　　↓

cd c:\users\nullpo\desktop\repo\test\
git add x.cpp
git commit -m "save!"
　　1 file changed, 2 insertions(+), 2 deletions(-)

　　　　　　↓

git push origin master
To https://hoge.com/fuga.git
　　　　dvcx245..9frr0bf master -> master
※ここで「git push origin branchB」とするはずが間違えて「master」にコミットしてしまいました。


ログから判別すると、現状は、https://hoge.com/fuga.gitのmasterブランチにコミットしてしまってると見るべきですよね？
ところがhttps://hoge.com/fuga.gitのmasterをcloneしてログを確認してもさっきのコミットが残っておらず、実際変更したはずのファイル(x.cpp)を見ても変わってないんです…。

>>47
それは、ローカルのmasterブランチをhttps://hoge.com/fuga.gitのmasterブランチにpushしただけだね
https://hoge.com/fuga.gitのmasterブランチの最新が9frr0bfに更新されてるはずだよ

>>48
ありがとうございました。
しかし、幾ら試してもhttps://hoge.com/fuga.gitのmasterのコミットログにないんです・・・。

恐らくこのまま放置することにします。
長々と書き込んでしまいすいませんでした。

>>49
いやだから、書き込みを良く見てくれ
「ローカルのbranchBじゃなくて、ローカルのmasterを、リモートのmasterへpusuしてる」
したがって、ローカルのbranchBにコミットしたx.cppファイルがhttps://hoge.com/fuga.gitのmasterに無いのは当然

それて、pushが成功したかどうかはファイルの有無じゃなくてハッシュで確認しろ
git branch -av で各ブランチと対応するハッシュを確認できる

pusu

>>50-51
おう、pusuはpushのタイポな

example.なんとか使えつって教わらなかったのか

VisualStudioのExpressでバージョン管理したいからGit入れたいんだけど
GUIで楽にローカルリポジトリ作る方法ってある？

はい、tortoisegitさんお呼びですよ

亀ってリポジトリ作れるの？

もちろん

単独で作れるのか
ありがとう

Visual Studioに組み込めるプラグインもあるかも知れんけど
わかんね。msdnでも覗いてみれ。

VSに組み込めるプラグインがあるとしても、Expressは拡張機能サポートしてないからどのみちダメじゃないか？

VS2013ならMSが公式でGitのプラグインを出してなかったか

Azure専用

Windowsが7以降ならSourceTreeもあるな

2013はExpressでもIDEからgit使えるけど、どうもわかりにくい
ankhsvnくらいに手軽だといいのだが、、、よって亀とコマンドライン併用
Xcodeの内蔵はかなり使いやすいと思った。

msysgitダウンロード出来ねぇ…
500ってなんだ…

サーバの内部エラー

https://github.com/msysgit/msysgit/releases/
行けた

ありがと！いけた

gitは正常に終了しませんでした (終了コード 128)

とか言われた…
なんだこれ…

あ〜、俺もそれなった。64bit Windows7
余計な物が入るのがいやなんだろうけど
msysgit諦めて
http://git-scm.com/
から丸々落としたら問題なくインストールできた

…え？
git-scmからmsysgitじゃないWindows用gitが入手できたの？

>>70
おｋ入れてみる

…の前にアンインスコしとこっと

msysgitのアンインスコがそもそも出来なくねえか？
ネットにはコントロールパネルからアンインスコしろと書いてあったが
インスコの途中でエラッたからかどうか分からんが、そんなものはなかった

とりあえず、面倒くさいのでインスコされたフォルダごと削除してやったけど
とりあえず、今のところ、その後、上記をインスコして問題ない

ところで、
インストールの時に聞かれる設定で
Checkout as-is, commit as-is
について、改行コードの勝手な変換は百害あって一利なしって言い切ってるサイトもあれば
なんか、それだとソフトウェア的に不具合が出る場合があるんで他の設定にした方がいいってサイトもあるんだが
実際にはどうなの？

個人的には、改行コードを勝手に変換されるなんて害以外の何物でもないと思うので
問題ないなら、何も変換させたくないのだが

>>73
いろいろな環境でやるならlfだけにしておいて、各環境でチェックアウト時にcr,crlf,lfで使うのが楽じゃない？
ソースじゃなくてなんか特殊なファイルとか管理するならきめうちのほうがいいかもだし、
自分ひとり開発とかチームで環境が変わる要素がないならそのままでもよい

企業でgit使う場合ってリポジトリは暗号化して使うものですか？そのへん詳しい人教えてください

>>75
基本的に、暗号化してからadd,commitするよ

>>75
詳しくはないけど。
鍵やデータはバージョン管理しないんじゃない。暗号化するようなファイルシステムなら、されちゃうかもだけど。

ん？Git-scmってのはmsysgitの代わりに使うって認識で良いの？

msysGitというプロジェクトでWindows用のGitが開発されていて
その成果は(Linux版やMac版も含めた)Gitの総合サイトであるgit-scmでも
やはりWindows用Gitとして配布されている…？

>>70 はつまり落とすサイトの話をしていて
開発版でなく安定版落としました、みたいな話なのかな

…俺もWindows版はよく知らんので、誰かツッコミ頼む

git-scm.comのDownload for Windowsで落ちてくるのは
https://github.com/msysgit/msysgit/releases/ のGit-1.9.4-preview20140611.exeじゃない？

>>70がうまく行かなかったのは同じ場所
https://github.com/msysgit/msysgit/releases/ のmsysGit-netinstall-1.9.4-preview20140611.exe
の方じゃないかな？

前者はバイナリだけの配布で、
後者はネットワーク経由インストールでコンパイル環境なんかも含めたすべてを落とせる？

そこで、cygwin で git ですよ。
オレオレビルドで、新しいリリースがすぐ使える

http://tracpath.com/bootcamp/learning_tortoisegit.html
これ見ながらやろうと思っても、Git Bash起動するとすぐ画面閉じるんだけど
Git bashってどうやって使うの

>>82
msysgit のインストールに失敗してるんだろ

あれ？もしかしてmsysgitインストールしたらmsysgitってフォルダ作られる？
C:\Program Files (x86)\Git
とは別に？

win7にmsysgitをインストールしたら↓のディレクトリにインスト―ルされたけど、Git Bashもこの中だし

C:\Users\Hiroshi\AppData\Local\Programs\Git

そうか…やっぱ失敗してんのかな
500から403に変わってGoogle Codeからは相変わらずダウソ出来ないし
もう少し探してみるか…
ありがとなヒロシ

>>86
しばらく前から動かないって言ってるひとか？
インストールに失敗してるんじゃなくて、アンインストールに失敗してるんじゃないか？
ゴミが残ってて新しくインストールしたmsysgitがうまく動かないみたいな感じ

うーん
つってもとりあえず『アンインストールとまたは変更』から削除したんだけど
それじゃ足りないのかな？
ゴミがどこに残り得るのかすらわからんのだけど

そういうのは地味に調べるか、できなきゃOS再インスコかね
自分もWindowsはよくわからんから、Winでこの手のツールをインストールしまくるのは嫌だね
なので、構成を自分でだいたい把握できてるcygwin版を使ってる

なんなのこれ…
Stack trace:
Frame Function Args
688100 [main] sh.exe" 8060 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
724705 [main] sh.exe" 8060 handle_exceptions: Error while dumping state (probably corrupted stack)

お前のwindowsが単にぶっこわれてるだけなんじゃね

>>90
それは STATUS_ACCESS_VIOLATION でググルと対策らしいのが出てくるぞ
TEMPフォルダ絡みらしい

中途半端にGitのコードにユニコード対応とか入れた影響なんだろうなあ
日本語Win環境なんかじゃ試して無いだろうし
オリジナルのGitがほぼそのまま動くCygwinがやっぱええわ

>>92
おぉ、ほんとだありがとう
キャッシュ自体1.5Gもあったしちょうどよかった…

>>93
なんかユニコードがらみで問題でもあったの？

>>95
TEMPフォルダにゴミがあると>>90みたいに落ちるらしい
特に日本語ファイル名のファイルとかあるとダメ
Unicode対応前のバージョンなら問題無いとか

やっと使えるようになったよ
ありがとう

コミットの概念が、SVNとちょっと違うのかなぁ
また混乱したら聞きにくるよ
繰り返しになるけどありがとね

なんで頑なにPro Gitとかを読もうってしないんだ連中は

ここの先輩って一つのフォルダにどのくらいプロジェクトを詰め込んでるのか教えてください

自分も興味ある＞どのくらい詰め込んでるのか

今はSubversionで10くらいのシステムを1システム1リポジトリで管理。
1システム(1リポジトリ)の中で document/client/server/moduleA/moduleB/... と複数ディレクトリを作って管理してる
Gitの場合、systemA-server/systemA-client という単位でリポジトリ作った方がいい？

>>100
ケースバイケースとしか言いようがないけど、Subversionに比べてGitではリポジトリを分けることが多くなった。
っていうか、「フォルダ」と「プロジェクト」って、「リポジトリ」とどういう関係があるのか説明してくれないと上手いこと答えられないかも。

systemA-serverとsystemA-clientが割と個別に開発できるなら(つまり、サーバーは新しいけどクライアントは古いみたいなのがOKかどうか)
リポジトリは分けるし、サーバーとクライアントで同調して開発しなくちゃいけないならリポジトリは分けないほうがいいように感じる。
言語が別で共有コードがほとんどないような場合も分けることがあるかもしれない。

Subversionと違って、独立したものをなんでもかんでもリポジトリに突っ込むと別々に開発したときにマージが発生しまくってめんどくさいし、
Subversionでいうところのupdateをかけるフォルダの単位でリポジトリを分けたほうが面倒がないよ。Gitはリポジトリの一部だけを最新にするってことができないから。

systemA-serverとsystemA-clientにリポジトリを分けた時なんだけど、
両方で使えるライブラリがあったとする。

そういう場合は、汎用的なライブラリとして別リポジトリを作り
submoduleで登録すればいいんだよね。

この汎用ライブラリにバージョン1.0というのがあったとして、
systemA-serverからバージョン1.0のライブラリをsubmoduleで登録する
systemA-clientからも、通常は同じバージョンを使うだろうけど、
一時的に1.1を使う。なんてこともできる。

つまりsystemA-server、systemA-clientからは両方同じ外部リポジトリを
参照していながら、都合のいいバージョンを使うことが出来るんだよ。

まったくgitはよく考えて作られてるよ。

それからorphanブランチっていうのも忘れちゃいけないね。

systemA-serverとsystemA-clientで別のリポジトリに分ける。
これもありだけど、別の案として
同じリポジトリ内に、独立したブランチを複数作ることが出来る。

リポジトリは最初のコミットから、ずっと歴史を成長させていくものだと思っているかもしれないが、
実は、一つのリポジトリに、「最初のコミット」を複数作れる。

一リポジトリ＝一歴史 じゃないんだよね。

systemA-serverとsystemA-clientに別のリポジトリに分けなくても、
別のリポジトリにわかれているかのように使うことだって出来る。

MavenとかRubyGemみたいな仕組みが利用できる言語なら、
ライブラリをsubmoduleで取り込む必要は無いね
まあでもそういうのが常に使えるわけじゃないからsubmoduleの仕組みを作ったんだと思うけど

コードを修正するたびにコミットログにupdateって書いてすぐにpushするんですけど
pushってどのタイミングでやってますか？

>>105
テスト合格したらプッシュ

>>101-104
ありがとうございます。
知らないこと・未経験なことばかりで勉強になりますm(_ _)m

updateなんて意味のないメッセージのコミットは、pushする前に分かりやすくメッセージを書き換えたりsquashしたりした方がいいよ

commit はこまめに
完全に動かない時は動かない理由も書いて commit
push は動作確認出来たものを push
どうしても動作テスト通っていないものを push したいときは branch で

何回か前の commit のメッセージにスペルミスがあったのに気付きました
恥ずかしいので治しておきたいのですが過去の commit のコメントを治せますか？

俺もそれ知りたいです
そういうときはいつもgit initからやり直してたので

git rebase rewordでググれ

git rebase -i commit~1
って感じ

スペルミスにより別の存在する単語になって文全体の意味が違うくなるってなら直す必要もあるかもだが
そうでなく本来のスペルを予測可能な範囲なら大抵はいちいち直さんやろ

subversionもそうだけど、なんでコメントって
気軽に直せないんだろう？

git rebaseでもコメント修正したら
コミットID変わっちゃうし。

バージョン管理に関しては気軽に修正できるっていうのは必ずしも良いことではない
Gitは気軽に修正できる代わりにハッシュが必ず変わって修正が明白になるようにした

いや、今の話はソースコードじゃなくて
コミットログの話だから。
さすがにソースコードを気軽に編集できればなんて話はしてない。

気軽に編集できる git notes をなぜ作ったのか？
コミットログを修正できればよかったのではないかって話。

コメントの修正も基本的には問題あるよ？
同じバージョンやハッシュでコメントの違うコミットがOKなVCSがあるとして
それらのコミットを先祖に持つ二つのブランチをマージするときどっちのコメントが引き継がれるべきだと思う？

notesはこういうときどんな扱いしてるんだろ

タイポを修正したコミットのメッセージがタイポしてたら死んでも直したくなるだろ

subversionは、コミットログを編集できるよ

それはまあ、非分散型だから問題にならないのかな？
分散型の場合にはコメントの編集がコミットを特定するIDとかに反映されないようだと困る

コミットの私物化

>>115
> subversionもそうだけど、なんでコメントって気軽に直せないんだろう？

Subversion はフックを設定すれば修正できるようになるよ。
svn ログ 編集 辺りでググればやり方書いてある。

git は難しいと思うよ。
A さんと B さんで違う内容に編集したらどうするかとかから決めないとダメだろうし。

gitはコマンドや引数が複雑化しすぎている
今後登場するバージョン管理システムでこれを克服しなければならない
例えばlogとreflogならgit logとgit log -ref

統一できるコマンドは統一するのが大事
reflogはlogに吸収させてしまえばいい
そしてコマンドに対する引数もなるべく少なくすること

gitはphpみたいに汚い

BazaarやMercurialとかの他の分散型はgitほと汚くないの？

reword >>126
squash >>125
squash >>124

# The first commit's message is:
汚いレスを圧縮

よくも悪くも Linux なんだなぁと思う。
個人的には FreeBSD + Subversion の方が肌に合う。

コミットログなんて、探すときのヒントなだけで、結局はChangeLogやdiffで確認するだろ。あとはtagとか。

リポジトリに対するログと、
作業スペースの履歴のログで意味が違うだろ

まさに意味が違うという話をしてたんじゃないの？

>>114
fileId を fieId と書いてしまって
field って言う別の存在する単語と見間違えます
どうしたら治せますか？

>>121
コミットのコメントのログをバージョン管理に入れてしまえば良い

git push -uの-uってなんですか？
毎回-u付けないといけないんですか？

>>134
ヘルプくらい嫁
http://git-scm.com/docs/git-push

必要なときは付けろとgitに言われる

PJはSVN使ってるんだけど、諸事情あって今俺が書いてるソースはリリース直前までコミットできない
さすがに不安なんで、git-svnでローカルにだけでもgitとしてコミットしようとしてるんだけど、
git-svnって、TortoiseGitでもできるん？
git自体触ったこともないので、GUIなくてコマンド覚えるのに時間かかるようだったら諦める

>>137
TortoiseGitでも出来るが、gitを使ったことがないとちょっと解りにくいかも。

最初TortoiseGitだとできるように見えなかったのが、コマンドでgit-svn使い始めたら
あちこちちゃんと対応してることにきがついたｗ

initial commitってどのタイミングでコミットしたらいいのか教えてください
作るものは掲示板でお考えください
まずファイル構成を決めて空のファイルを作ってコミットするのか
何もファイルが存在しない状態でコミットするのか
ある程度動くものができたらコミットするのか
本当にわかりません

特にセオリーは決まってなかったと思う
わからないなら空commitでおｋかと

initial なら 空っぽの RADME.md だけ作って commit てる
とりあえず何か commmit しとかないと diff がエラーになる

リリースバージョンで1.0と2.3とかつける時のコミットログはなんて書きますか？
git commit -m "Release: 1.0"みたいな感じ？

最近はREADMEをマークダウンで書いたりするのか。

>>143
tagつけるので、コミットメッセージは気にしない。

GitHub使うとそれがデフォだったりするからな

GitHubだとリポジトリのリンク開いたときにトップディレクトリのREADME.mdをHTMLに変換して表示してくれるからね
トップディレクトリの一覧の下にそれを表示するんで、トップディレクトリ自体にはあまりファイルとかたくさん置かないようにしとくと更に見やすくて良い

>>142
一番最初に--allow-emptyで完全空っぽのコミット作ったりすると問題ある？

>>146
>>147
なるほろ。githubか。

プッシュし終わった跡に間違いに気づいてコミットしなおした
git commit -m "update"
git push
git add -A
git commit --amend -m "update"
ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？

なんかgit pushしたら
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git@*********:*********/*******.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
って出たのでgit pullしたら
Auto-merging server.php
CONFLICT (content): Merge conflict in server.php
Automatic merge failed; fix conflicts and then commit the result.
ってなったのでコンフリクトを直してaddしてcommitしてpushしました
>>150の跡にどうするのが一番良かったのか教えて下さい

>>150-151
そもそも>>150をやってはいけない
pushしたコミットを--amendで直してはいけない

ただし場合によってはどうしてもやりたいときもあるので、そのときは git push -f を使う
push先のリポジトリの設定でこの操作が禁止されている場合もある

push -fをしてもいいのは、push先のリポジトリを自分しか見てないような場合とか、
自分以外の人が見てる場合にはその自分以外の人全員にpush -fする旨の許可を貰えるような場合

なるほどそうでしたか
これからはやらないことにします
こういうときって２回目のコミットログはfixとかって書いとけばいいですかね？

>>153
コミットメッセージは何をfixしたとかupdateしたとかまで書いておいたほうがいいと思うけどね

チケット駆動とGitの組み合わせで開発するときに
何かするたびにチケット切って、それにあわせたブランチをGitで切って作業する運用って
プロジェクト中盤以降なら修正とか改善の粒度も小さいからしっくりくるんだけど
プロジェクトの何もない最初のほうは、１つの大きな機能の実装に2週間とかかかって、
それのせいでブランチ閉じられずにマージコミットやコンフリクトがあふれてなんかしっくりこない。

チケット駆動してる人は最初からチケット駆動してる？
それとも落ち着くまではmasterに直接コミット突っ込んだりしてる？

>>153-154
--autosquash用のフォーマットの"fixup! 修正先のコミットID"、でいいよ
元々何をしたかったかは直前のコミットメッセージにあるわけだし

コミットごとにpushするのはやめたほうがいい？

fixed #1223とかrefs #4643とかだな。
コメントだけではそれが安定か不安定かくらいしか見てない。
ローカルだとadhocとかno testとかもある。

個人的なリポジトリなら自分が見やすいよう好きにすればいいし
共同のリポジトリなら仲間同士でルール決めてやるほうがよい
git flowやgithub flowあたりのメジャーなやりかたを採用するのもよい
コミットごとのpushがリポジトリを見づらくしてるよう思うのなら仲間と相談してしないようにルールを決めればよい

内容書くと、どこまで書くかという程度がそれぞれなので、文句が出る。

>>150
> プッシュし終わった跡に間違いに気づいてコミットしなおした
> git commit -m "update"
> git push
> git add -A
> git commit --amend -m "update"
> ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？

単純にpushしたらだめという意見が多いが別にそんなことはない。
運用の仕方による。

gitlabを使った場合のやり方。
メインのリポジトリからforkした個人のリモートリポジトリを作る。
これはgitlabにforkって機能があるんでそれを使うだけ。

メインのリポジトリには直接pushしない。個人のリモートリポジトリにpushする。
個人のリモートリポジトリは個人のものだから--amendして直してpushしていい。

そしてこの状態で思う存分レビューしてもらってNGなら直して--amendして
pushしてOKになったらメインのリポジトリにマージする。

>>151

>>150 をやってしまったのなら pull してコンフリクトを治して add して commit して push するのが一番良い

>>161
>>151 が聞いているのは
>>150 の状況にならないためにはどうすれば良いのか？ではなくて
>>150 の状況になってしまった場合どうすれば良かったのか？だから
その回答は今回の場合は適切じゃない

あ
でも
>>150 へのレスだからいいのかな

上書きしないですぐに修正コミット追加するかrevertしてじっくり修正
誰もrevert使ってないのは縛りプレイなの？

>>164
通常のコミットと、マージコミットと二つあるんだよね。

* A機能のコミット
* B機能のコミット
* A機能の小さなバグ修正
* C機能のコミット
* B機能のrevert
* A機能の小さなバグ修正
* B機能の再コミット

とかいう、通常のコミットだけの履歴を作りたいのかと。
こういうのは、機能毎にマージコミットであるべき。