Git 5

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/

◆前スレ
Git 4
http://toro.2ch.net/test/read.cgi/tech/1329234309/

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

◆過去スレ
Git 3
http://toro.2ch.net/test/read.cgi/tech/1310403238/
Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連スレ
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
CVS導入スレ〜 Rev.3
http://toro.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://toro.2ch.net/test/read.cgi/tech/1326806859/
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 3
http://toro.2ch.net/test/read.cgi/tech/1297704483/

◆関連スレ 別板
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/

◆関連書籍
Ｇｉｔによるバージョン管理
2011/10
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Ｇｉｔ
2010/02
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8

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

入門ｇｉｔ
2009/08
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

make 使ったこと無い子が暴れてるのか

まったくこれだからRubyっ子は（断定）

タイムスタンプを巻き戻すメリットって何？
デメリットがあるのは分かる > make

rakeでもtimestamp見るんじゃなかった。

>>6
タイムスタンプを見るだけで何時修正したファイルなのかを判断できるｗ

タイムスタンプしか見ない人に対して、修正してないフリが出来る

Windowsがタイムスタンプ信者を増やしてる気がするな。
Sambaでコピーして、makeがおかしい毎回cleanしなきゃ
ってのもいる。

Gitはチェックアウト時のファイルのタイムスタンプをコミット時間にしないウンコ

>>11
だから、そうするメリットは何？

チェックアウトより、git archiveのファイルのタイムスタンプをコミット時間にしてくれ

一方 mac binary には check sum があるので一目瞭然なのであった

>>11
コミット時間にされたらソッチの方が迷惑だボケ
コミットした時のファイルのタイムスタンプを維持しろ

>>13には同意できる

>>12
電気代節約

>>17
馬鹿？

>>13
だからコミット時間じゃ意味が半減するだろ

ファイル毎にタイムスタンプ保持しろと？
面倒なやつだな

タイムスタンプを維持するってことは、中身が変わってなくても変分ありになるってことだよな
マージする度にどちらの時刻を使うか選ばされるのか
分散開発には使えないな

ファイルをいつ修正したか見たいんだったら
logを見ろよ

ログ見れない低能だから

>>21
＞中身が変わってなくても変分あり
中身が変わってなければ日付も変わらないだろ
何を言っているんだ

>>24
touch

>>25
それは意図的に変えてるだろ
混同するなアホか

ぷwww

> 中身が変わってなければ日付も変わらないだろ

この状況がありえないと思ってたんだろ？
なのに論破されて顔真っ赤wwww

だからそんな機能要らないってｗｗｗｗ

svnがファイルの更新をタイムスタンプで見る仕様だったから
元(?)svn信者はタイムスタンプの保持に拘る傾向があるな
gitでは全く意味ないけど

えっ？
gitってタイムスタンプじゃないの？
じゃあ、チェックイン時刻？

スレ立てたばかりで書き込み無いと落ちるんだってね
容量増やし職人ご苦労さん

更新日時→ファイルサイズ→ハッシュ？

　//／／／／／／,　””　 　 ヽﾐ川川
　|//／／／／,　’”　　　　　　　’,川川
　川/////,　’”,,,,,,,,,,,,,,,,　　　　r””‘,川||
　川f 川f´　　　　　　　　　　 ,ィ::ﾗ’,川　　うわっ…私のgit、タイムスタンプ…？
　川ﾍ　 |　　 　弋て::>　　　　￣ 　’,ﾘ
　 川 ﾍ.__　　　　　　　　　　 ヽ　／７!　　（２９歳 Aさんの場合）
　　川川 ﾍ　　　　 _,.　’-‐””´y’　 //
　　 川川ﾘﾍ　,　’´　　　__,,,／　 / /
　 　川川川|/　　　’”´　　　,　’´ /||
　　 川川川|　　　　　　　　　　 /川

md5sumのフリーの良いライブラリってなに？

>>29
makeの仕様だろ

ファイルのタイムスタンプが重要なんだったらDVCS使わない方が良いんじゃないの？

>>36
http://toro.2ch.net/test/read.cgi/tech/1295493964/
946 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 19:25:52.78
TortoiseHGを最近使いだして、その使い勝手に感激しています。
そこで質問なんですが、ファイルの更新日時も管理対象にすることはできないのでしょうか？

特定のリビジョンへ更新した際に、更新日時もそのときのものに変更されれば
最高なんですが。


947 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 19:40:30.94
>>946
タイムスタンプ更新是非については総合スレの話題として、
それらしき拡張はあるようだ。
http://mercurial.selenic.com/wiki/UsingExtensions
http://mercurial.selenic.com/wiki/TimestampExtension
http://mercurial.selenic.com/wiki/TimestampModExtension


948 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 21:58:54.77
>>947
TimestampModExtension
これ使ってみました。
手間いらずでバッチリ希望通りの動きをしているようです。
どうもありがとうございました。

git 用の TimestampModExtension 作れ
そしたらネ申になれるぞ

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

enpelさん必死っすね
gitについて語り合う時点で低脳なんです
ゲームプログラミングしてるやつって低脳がおおいですね

えんちゃん ?@enpel
@fumilin 皆でgithub開発しよう。慣れればgitの方が融通は聞く気がする。アセットサーバーの昨日を知らなすぎるだけかもしれないけど

チェックアウトするたびにmake clean; make
素晴らしく電気代の無駄だな

>>41
makeを使っていることが人生の無駄

いまどきはEclipseなどのIDEを使ってコンパイルする
Makefileなんて書きたくても書けない雑魚ばっかりですよ

>>43
gitってMakefile手書きなの？そりゃウンコだ。
https://github.com/git/git/blob/master/Makefile

>>41
中身が変更されてない(正確にはハッシュが変わらない)ファイルはタイムスタンプも変わらないからmakeはそのままで動くけど？

今のgitはそうだね
タイムスタンプを巻き戻せと言ってるアホに合わせたら
動かなくなるけど

まあ普通に問題になるのは、ファイルを旧バージョンに戻したときのタイムスタンプだな

gitの動作は現状のとおりでいいとして、
チェックアウトでコミット時刻に戻したいならそういうスクリプト書けばいいし、
コミット時の変更時刻に戻したいならコミットのフックにそういう記録付けさせればよい
これで万事解決だと思うのだが

# 遅ればせながらスレ立て乙>>1

>>48
何も解決していない。コミット時にファイルのタイムスタンプを保存してチェックアウト時にそれにするという需要があって、
Mercurialではそれがある。Gitには無い。

つまりスクリプトすら書けない無能には
解決になってないってことだね

無能の自分のために誰かスクリプト書けよコラってことだね

>>49
じゃあMercurial使えばいいじゃん

馬鹿には無理

>>49
時系列順に
(A)ファイル変更→(B)ステージ→(C)ファイル変更(if any)→(D)コミット→(E)チェックアウト
チェックアウトの時点では普通(E)の時刻になるわけだが、(A)〜(D)のどれになるべきなんだ？

バカチョンMakefileで喜んでるところが...

>>50
gitとmakeのためにスクリプトを書かないとダメなのか。gitは馬鹿じゃないと無理だ。

タイムスタンプを巻き戻すメリットを説明して、
自分はスクリプト書けない程の想像を絶する低能なので
誰か書いてください、と言えば書いてもらえるかもね

あと、gitでログも見れない程の低能です、も付け加えると可能性が上がるかもよ

>>57
gitのログって読むものなんですか？ウンコなログしか無いんですけど。

ログの見方も分からない低能です、と

gitってmergeなんたらかんたらってコミットログに勝手に付けるウンコソフトですよね？

昨日からgitほとんど使ったこと無いやつが紛れてないか？
checkoutの件もそうだったし、logもなんか勘違いしてる気がする
書き込みに癖があるからたぶんずっと同じ奴なんだと思うけど

> 昨日からgitほとんど使ったこと無いやつが紛れてないか？

Windows+svn信者の可能性が濃厚

>>37
本家の機能でもなくてただの拡張スクリプトじゃないか。

>>30の時点で明らか

いまさらgithubに語り合ってる低脳が集まってるスレはここですか！？
おおおおおおおおお！！！

中学生レベルのトーク内容ですよ！

いまさらっすか

enpel見てるとゴミクズだよなあ
あいつ２０代後半~３０代くらいだろ？

っであの知識量だろ？
いまさらgithubとかわめいてる低脳だろお！！！！！！！！ｗ

Ruby最強中学生コミッタsora_hとLL最終決戦させたら
一瞬で敗退するだろうなあいつは

ここまで誰一人としてgithubなんて話題にしてねーよwww

>>43
Eclipseもタイムスタンプ見てると思うが

つか、みんながみんな同じタイムゾーンで開発してるわけじゃないやろ

>>69
だからgithubは変なタイムゾーンなのですね？

>>58
それはお前がウンコなログ書いてるからだろ…

>>66
https://github.com/treeboa
消したのか、つまんねー奴ｗ

にゃ〜

>>53
あとマージするときも考えなきゃね。
マージ元の時刻とマージ先の時刻とマージした時刻のどれを採用するか？
もちろんファイルの中身は同一なんだけどね。

タイムスタンプも自分のシステムとリモートと同期が取れてるとは限らないから、feachした時に時刻差分を記録して補正する必要もあるかもね。

>>74
マージした時刻でいいだろ
ファイルに変更があればタイムスタンプを更新すべきだ

つまりPULLする度にほとんどのファイルのタイムスタンプがPULLした時刻になると。
そのタイムスタンプに何の意味があるのかわからないけどね

そもそもタイムスタンプに何の意味も持たせないのがgit

gitはエンタープライズで使えないという結論でOK？

>>78がGitを使えないというのはOK

>>79
タイムスタンプの他にディレクトリ・ファイルのリネームを扱えないという点でGitは使っていないから。ありがとう。

ファイルのリネームは情報としては保持しないけど、実用上は問題なく判定してくれるんじゃなかったっけ？
git mvしてgit statusするとrenamedと出る

rename を git 通さず os レベルでやると時々死ねる

同一コミットにしておけばいいだけじゃなく？

すごい初歩的な質問なんですが、gitにおいてローカルレポジトリとマスターレポジトリって区別はあるんですか？
例えば二人で共同開発するとして、よく例に出てくるのはマスターレポジトリの置いてあるサーバと、
それぞれの人間のPCっていう構造ですけど、例えばマスターレポジトリがなくて、
二人がそれぞれ個人サーバ上で開発して、相手のサーバにpushしあうというような構造でもいいのですか？

>>81
ローカルで変更したファイルがリモートでリネームされていても
pullした時にリネーム先のファイルに自動的にマージされるね。
svnだとコンフリクト出るだけで訳わからなくなっていたから
gitに乗り換えて楽になったよ。

>>82
.gitignoreをちゃんと設定してあればgit add -Aで済ませる事も出来るよ。

>>84
マスターかどうかの区別は無いけどbareかどうかの区別はある

ワーキングツリーのある作業用リポジトリとは別に
個人サーバーにbareリポジトリを置くのならpushしあえるし、
そうじゃなければpullしあうのはOKだがpushしあうのはややこしい

>>86
なるほど、とりあえずどっかにbareレポジトリってのがあったほうがいいのですね
bareレポジトリについて勉強します
ありがとうございます

>>84
--sharedにしてないとpushした時に、権限で怒られないっけ。どんなシステムとアカウントでやってるか知らないけど。
pullなら書き込むのは自分だからいいんじゃない。

>>87
git init --bare --share
のことだと思うよ。

各人が自分用のbareリポジトリを置いてそこにpushして、
相手のbareリポジトリからpullしあうのが簡単だと思うけどどうなのかね

チームメンバーが好きにbareリポジトリ作れるサーバーが一つあると便利よね。

>>91
つ bitbucket

>>58
差分を読むんだよ

>>93
差分はどうやって読むのですか？TortoiseGitがウンコなんですけど。

>>92
フリーソフトならいいけど、業務用のファイルを入れるのは無理だなぁ

>>94
GUIしか使えない低能はsvn使ってるべき
マジで

GitHubにてprivateレポジトリを使って、
4人でコードを書く予定です。

この場合、プランは4人ともMicroなんでしょうか？
それとも一人だけMicroを契約しておけばよいのでしょうか？

すみませんが、教えていただけると助かります。

>>94
書いてあるのが読めんのにやってるんかい？
ログはピンきりだからね、読めなくても、何とかなるんだよ

ターミナルでプロジェクトのgitいじってる時に、
現在地/...../...../目的ファイル
なんかをいじりたい時って、効率良くいじれる方法ないですか？
vi 現在地/...../....../目的ファイル 　ってするのは結構面倒なんです

>>99
cd 現在地/...../...../

目的のファイルの位置毎にターミナル開いてみたら

viが面倒ならemacsを使えばいいじゃない

馬鹿には無理

find . -name hoge|xargs editor
emacs開きっぱなしだから、最初以外は近くのバッファから辿るけど。

>>99
~/.gitconfig に

[alias]
vi = "!f() { vi "$(git ls-files "\\*$1\\*" | head -10)"; }; f"

って書いて
$ git vi 目的ファイル

>>105
目的ファイルのファイル名全部入力するの面倒じゃんｗ

zsh辺りなら、リポジトリ内の目的ファイルの頭何文字か入力すれば、
リポジトリ全体から探して途中のディレクトリを補間してくれるとかできないのかね？
まあ俺はemacsのdiredに頼りっぱなしだから使わないがｗ

>>106
$ git lv 的ファイ
でもいけるよ

>>107
s/lv/vi/

>>107-108
どこまで入力したら目的のファイルを一発で開けるかわかりにくいじゃないｗ
まあでも、全部入力しても同じファイル名が複数ある可能性もあるのか
viならいっぱい開いてから:nとかで選べばいいしね

>>105
おお、これは面白いな！自分のにも入れとこう。

だからそれがめんどいんだって
current/1/2/object1
current/1/3/object2
current/4/5/object3
とかなってたらややこいだろ

あすまん 100までしかみてなかったわ

>>106
Vimのctrlp.vimなら…おっと、スレチなのでこの辺で。
ttp://toro.2ch.net/test/read.cgi/unix/1342368545/

>>111
その場合だと>>105の使うならばそれぞれ、
git vi 2/o
git vi 3/o
git vi 5/o
で開けるなｗ

>>97
ひとりだけ契約して、あとはcontributerとして登録すればよいです。

リファクタリングに対するコミットってどうやってますか？

一般的にリファクタリングはミスが起きないように
一歩づつ変更すると思います。

fooをbarに変更、
barのメソッドをスーパークラスに移動
引数の順番を変更。
引数をオブジェクトに変更
etc

この一連のリファクタリング作業を一回のコミットで行うと、
変更点が多すぎてレビューが大変になると思います。
しかし一つづつのコミットに分けるのも多すぎな気がします。

できれば、一連の操作を1つのコミットの中で
動画のように再生可能な形でコミットできればと思うのですが。

一つづつコミットしておいて、
レビューが終わったらrebaseしたらいいじゃん

一つづつのコミットが多すぎ？なぜ？
各変更点はなるべく小さいほうが、Regressionが見つけやすいんじゃね

rebaseってそういうときに使うのか？違うだろ？

rebaseはいろんなことに使える
自分のコミットをFast-forward状態にするためのrebaseはもちろん便利だけど、
ベースを変更しないrebaseでのコミットの整理も便利だよ
コミットをまとめたり逆にコミットをばらしたりさらにはコミットの順番を入れ替えたりとか

>>116
リファクタリング用にブランチ切って最終的にmerge --no-ff

うちはレビューのためにわざわざ分割する事はないけど、
レビュー後 merge --squash か rebase -i は使うな。
レビュー反映のコミットも追加されるしね。

レビューはredmineでやってる。

リファクタリングの度合いにもよるけど、リファクタリングと言いながらも
バグを作り込むことはありがちだから、後でbisectしやすいように、
rebase -iでのsquashはしない方がいいと思うんだがなあ

testしろよ。

gitってcloneしか使ってないわ

馬鹿には無理

>>121でいいだろ

>>128
よくない

べつにいいだろ

入門Git p63 でhttp://members.cox.net/juniko/Gitusers.gif から
本文の流れで使っている、仮のHPのgif画像をwgetで入手することになっているが
そのHPにアクセスできず悔しい。本を読み進めるには問題ないのだが、濱野氏が
どんな画像を用意していたのかが知りたい。

ぱんだなのか

>>129
お前には聞いてない

>>133
　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

　　　　 ／￣＼
　　　　| 　＾o＾　|　＜なんとなく 命に　かかわる　パンチを　しますよ
　　　　 ＼＿／
　　　 　/　　 ヽ
　　　　|　ヽ　　|　　　＿　＿，.’；.／￣＼
　　　　ヽ　_￣＝−＿− ＿.＿）)|　　　　|
　 　　　 | 　　　　　　￣　；’，.∴;＼＿／
　　　　　|　 i　|　　　　　　 　/　　　ヽ
　　 　　 .|　 |｜　　　　　　 / /|　　　|
　　　 　｜ ﾉ ﾉ　　　　　　/ /　|　　 　|
　　　　　.| .| （　　　　　　/ /　 |　　　 :|
　　　　　/|＼.＼　　　　し　　 |　　　 |
　　　　　し' 　￣

| ∧ 　 　　　　　　∧
|/　ヽ 　 　 　　　./ .∧
|　　 ｀､　　　　　/ 　 ∧
|　　 　 ￣￣￣　　　　ヽ
|￣￣￣月曜日￣￣￣）
|￣￣￣￣￣￣￣￣￣.＼
|ヽ-=・=-′　ヽ-=・=-　　/ 　　やあ
|:: 　 　＼＿＿_／　　　　/
|:::::::　　　 ＼／　　　　　/

すまん。
何か変なのに触ってしまったようだ…

　　 >┴<　　　⊂⊃
　-（ ﾟ∀ﾟ.）-　　　　　 　 　 　　⊂⊃　　　　
　　 >┬<　
　　　　　　　　　　　　　　　.人
　　　　　　　　　　　　　　 （＿_）　　
　　　　　　　　　　　 　　 （＿＿） 　ｳﾝｺｰ
　　　　　　　　　　　　　 （,,・∀・)
　　　　　　　　　　　　 　(　O┬O　　ｷｺｷｺ　　　　
　　　　　　 　 _＿≡ ◎-ヽJ┴◎ 　 　　　
;;⌒::.;;.⌒⌒/ 　 /|￣￣￣￣￣/ ￣/::. :; ;⌒⌒:.:⌒:;⌒;;⌒
..　　,::.;　　/ 　 /|￣￣￣￣￣/ 　 /..,　,;　.:　　　,,｡,.（◯）　　 ::
　 :　:::.,　/ 　 /|￣￣￣￣￣/ 　 /,,;　　（◯）　　:::　ヽ|〃　　;;:
.　　,:.;　/ 　 /|￣￣￣￣￣/ 　 /..,　,;　:ヽ|〃　　,,｡,　　　 ::;;,

clone厨は(・∀・)ｶｴﾚ!!

GUIによるGitリポジトリ管理機能を提供するWebアプリケーション「GitLab 3.0」
http://sourceforge.jp/magazine/12/10/25/0437230

コミットログの文字エンコーディングを表示する方法って、
Gitで提供されてませんかね？

日本語でログ書いてる俺が悪いんだけど、、、

git config --get i18n.logoutputencoding のこと?

いえ、違います。情報不足で申し訳ないです。。。

自分の.gitconfig設定自体は
[i18n]
comitencoding=euc-jp
logoutputencoding=utf-8
となっています。
(git diffなどはtextconvにnkf -wを指定しています)
また、シェルの環境変数LANGは、
ja_JP.UTF-8
です。

↑のようにしている背景は以下です。

1.普段の環境はUTF-8
2.いま関わっているリポジトリのルールとして、
コミットログはEUC-JPと決まっている

、、、このような背景がありまして、.gitconfig設定の意図としては、
以下のつもりで、設定しています。

comitencoding=euc-jp
→コミットログはEUC-JPで書く
logoutputencoding=utf-8
→コミットログはUTF-8でシェルに表示したい

、、、なのですが、結局、コミットログを入力するときに立ち上がるエディタは
環境変数LANG設定に基づいて最初はUTF-8になってます。★★★
また、コミットログの表示も、textconvでnkfを挟まないと、
結局コミットログを書いた人の文字エンコーディングのままみたいですが、、、

長々と書いてしまいましたが、
上記★★★箇所の関係で、
うっかり自分がEUC-JP以外でログを書いてしまうことがあります。
これをあとからチェック（および修正）するのが非常に面倒でして、、、
現状、このためだけに
git rebaseで自分のコミットをr指定することで
ログだけ全部エディタで開き直しています。
そしてエディタに表示されるエンコーディングがeucでなかったら、eucに直して保存し直したりしてます。。。

これがどうにかならないかと、質問させていただきました。
ひとつひとつのコミットのログが、
どの文字エンコーディングで記録されているかを知る方法か、
ログ入力時に強制的にeucに変換する処理を挟む方法などがあれば、
教えていただけないでしょうか？

commit-msgフックかな

>>144
役に立つかわからないけど
うちはemacsのデフォルトをcp932にしてたんで
こんな感じにしてたよ。

[core]
editor = emacs --eval \"(prefer-coding-system 'utf-8-unix)\"

純粋に質問なんだけど、いまどきUTF-8以外でコミットログを書く意味ってあるの？

ないけど
ルールなら仕方ない

シフトJIS最強

>>141です。
情報くださったかた、ありがとうございました。
明日試してみます！

ローカルとリモートをプロジェクトによって使い分けつつ開発する場合、github導入して、
・ローカルで開発したいプロジェクトはアップしない
・リモートで開発したいプロジェクトはアップする
って使い分けでおk？
使用環境はWindowsで、GUIとそれなりの将来性からgithubに目をつけたのですが。

>>147
合わせられるならソースのエンコーディングと合っている方が都合がいい
理由は忘れた

>>152
コミットログの表示は--encodingで変更出来るから
システムのロケールに合わせたほうがいいと思うよ。

リモートでも公開したくない奴の場合、
有料プランが嫌だったらbitbucketにしたほうがよかったりとか

>>151
gitとgithubの違いがわかってないのかな。

リモートで開発するって意味がよくわからない

コンパイルサーバーだのリモートデバッガだの色々あるだろう


gitとは関係ないが

最近だとテスト環境へのデプロイをgit pushでやるとかあるじゃないｗ

まあたぶん関係無いがｗ

開発メンバーが地理的に離れてる場合もあろう。
関係ないけどｗｗ

>153
Windowsだけどunicode対応のmsysGit使ってみたら
ソースもコメントも全部utf-8で統一出来たわ
本当にありがとうございました

>>158
最近は wiki を github に push するのが日課になってる
関係なくてスマソ

gitってclone --depth 1でブランチを全部落として来なくなった？
それとも今までブランチがいろいろ切り替えられた状態になってたのがおかしかったのかわからない。

大変困ってます。

Windows 7 で TortoiseGit を使っていて、
msysgit を最新版にしたら、
日本語ファイル名を含むレポジトリが文字化け
するようになってしまいました。

.git/index を秀丸で開いてみると shift-jis にすると
ファイル名が正しく表示されることから、レポジトリは
shift-jis になっているようです。

msysgit は最新版は utf-8 だそうですが、あたらしい msysgit で
このレポジトリを使えるようにする方法があれば教えてください。

むり
やり直し

せめて前後のバージョンナンバーが欲しいな。
ちなみに最新のTortoiseGitなら、日本語ファイル名も日本語パス名もUTF8化して格納してくれる。

>>165

レスありがとうございます。

後から入れたのは Git-1.8.0-preview20121022.exe です。
前は確か 1.7.0 くらいだと思います。うろ覚えですが・・・。

最新のTortoiseGitなら、日本語ファイル名も日本語パス名もUTF8化して格納してくれるが、
古いのはだめ。混ぜたらアウト。
http://tmurakam.org/git/git-encodings.jpg
http://tmurakam.org/git/old.html

> .git/index を秀丸で開いてみると shift-jis にすると
> ファイル名が正しく表示されることから、レポジトリは
> shift-jis になっているようです。
表示の問題で、格納先はUTF-8で管理されてるとか

質問させてください
ブランチを分けて開発して、masterへマージする段階で、
どのコミットがmasterへマージされるか事前にマージ対象コミットを一覧にしてみたいのですが、
コマンド叩いてみたい場合、どのようにすれば見れるでしょうか？

現在は、git diff --name-only -b master -b commit1 のようにして、
変更ファイル一覧を見てはいますが・・・
これだと双方向での変更ファイル一覧が出てしまい、
masterのバージョンが進んでいると、どれがマージされるファイルなのか分かりにくいのです・・・

>>166
WindowsのGitがUTF8に対応したのは1.7.10からなので、>>167　の言うように混ぜたら危険状態なんだろうね
古いレポジトリをコンバートする方法とかあるのかな？

むり
やり直し

こういうことがあるからGitは使いたくねーんだよな
使うとしても5年後かな

>>169
リベースすればいいんじゃないの？

>>173
それは、一度実際にマージして、
何がマージされたか確認後にリベースでリセットするって事ですか？

>>174
マージする前にリベースすれば、
自分が何に何をマージしようとしてるのかがはっきりするよね？

経験的には、masterからマージ用に別ブランチ作ってマージして見るのが一番早い

>>169
マージテスト用のブランチ作って
git merge --squash するとエディタに一覧が出てきて分かりやすいよ
ブランチ作らなくてもreset --hard HEAD^ で戻るけどね。

>>175
リベースでログが見れるのかと調べてみましたが、
ちょっとわかりませんでした・・・

>>176
>>177
簡単で分かりやすいですね。
テストマージ用のブランチ分けて結果を見て判断する事にします。
masterのリセットは何か気分的に最終手段というか、
いけない事をしている気がして気軽にリセットするのに不思議とためらいがあります


レスくれた方々、ありがとうございました。

>>178
リベースすることで、masterのバージョンがすすんでる分を自分のブランチに取り込むことができて、
自分のブランチがmasterの最新バージョンから生えた差分に作り直される
この状態なら git diff --name-only master するだけで望みの情報がとれることになるわけだけど、
まあファイル名の確認だけでいいのならリベースする必要はないのかもしれない

使うとしても5年後かな(ｷﾘｯ

何が安定するのに5年もかかるんだろう…

日本語環境とGUIだろｗ

馬鹿には無理

MSがさっさとMBCSをUTF8にしてくれればいいのに

>>170
古いmsysgitでformat-patchで全部パッチ化して、新しい方でamしたらある程度行けそうな気がするがどうだろう

>>169
git diff master...topic
git log master..topic
git cherry -v master topic
あたりを場合によって使い分けてる。一番よく使うのはcherry

>>170-171
最悪 filter-branch で iconv まわすシェルスクリプト書けばいけるんじゃね？

俺もgit-filter-branchでconvmvとかどうよ？と考えた
まだ試してないけど…

gitでコミットすると、/.gitへデータが登録されるんですか？

馬鹿には無理

>>188
そんな感じ

いや/.gitなんて妙な場所じゃないぞ、./.gitだ

>>190-191
あざーす

Gitのインストール後、Git Bashの起動で詰まったので質問させてください。
OSはWindows7 64bit
インストールは全てデフォルトで行いました。
Git Bashを起動したところ画像のようなメッセージを表示してすぐBashが消えてしまうのですが、何が原因なのでしょうか。
同じような事例でアドバイスがいただけると幸いです、よろしくお願いします。
ttp://www.dotup.org/uploda/www.dotup.org3638336.png

Windows7の64bitでGit使ってるけどうちでは問題出てない
Git-1.7.8-preview20111229-unicode.exe
インストールするときに管理者権限で実行したことくらい

>>194
すみません、言葉が不足していました、バージョンは最新版のGit-1.8.0-preview20121022.exeを使用しています。
最新版ならばunicodeもサポートしていたと思うのですが、うむむなぜだろう。

別に謝らないといけないようなことじゃないよ
うちじゃ動いてるし

馬鹿には無理

先輩どうかたすけてください
git for windows 1.8.0です
git reflogってやったら
482fd25 HEAD@{0}: reset: moving to HEAD~1
299598a HEAD@{1}: checkout: moving from master to 299598a4a56412482b2492eebe0a7b
44b9f0b HEAD@{2}: commit: ３回目のコミット
299598a HEAD@{3}: commit: ２回目のコミット
482fd25 HEAD@{4}: commit (initial): 初めてのコミット
(END)

こうなってctrl+cとかctrl+zを押しても(END)が消えなくて次のコマンドとか打てません
これはどうやって抜けるのでしょうか？
とりあえずgit reflogを打ったらコマンドプロンプトを閉じてまた起動させています

lessが起動してるだけだろ

うちの環境なら出力行数が端末の出力範囲内に収まるときにはページャは起動しないんだけど、
コマンドプロンプトで動かすgit for winが糞なのか

>>198
lessを抜けるのは q を押す

>>200
それは普通の動作じゃない
less -F するとそうなる

-Fなんて自分で設定してないんだけど、
gitがcore.pagerがlessの場合に自動で-FRSXをつけてくれるみたいだな
git for winはなんでこれが無効になってるんだ？

馬鹿には無理

どうもありがとうございますqを押したら直りました。これで自信を持ってgit reflogできるようになりました。いまこういう状態なんですが、一番上のHEAD@{1}からHEAD@{2}までの記録を消す方法はありますか？
7006fb0 HEAD@{0}: reset: moving to HEAD@{1}
282878c HEAD@{1}: reset: moving to HEAD@{2}
7006fb0 HEAD@{2}: commit: 5回目のコミット
555af26 HEAD@{3}: commit: 4回目のコミット
282878c HEAD@{4}: commit: 3回目のコミット
fd505a7 HEAD@{5}: commit: 2回目のコミット
eae391e HEAD@{6}: commit (initial): 1回目のコミット
上を下のように消して修正したいんです
7006fb0 HEAD@{0}: commit: 5回目のコミット
（略）
eae391e HEAD@{4}: commit (initial): 1回目のコミット

>>204
何のためにそんなことをするんだ？
reflogの記録なんてローカルにしか残らないぞ
それも時間がたてばgit gcで消えるし

>>204
git reflog --helpくらいみろよ。

馬鹿には無理

無理には馬鹿

馬鹿には馬鹿

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

テキストの色と背景色をRGBで設定したいのですが、どのように書くのでしょうか？
require "curses"
Curses.init_screen
Curses.start_color
Curses.init_pair 1, Curses::COLOR_BLACK, Curses::COLOR_WHITE
begin
Curses.attrset(Curses.color_pair(1))
Curses.addstr("Hello World!")
Curses.refresh
Curses.getch
ensure
Curses.close_screen
end

int init_color(short color, short r, short g, short b);
init_color ルーチンは色の定義を変更します。 次の 4 つの引数を取ります。
変更する色の番号の後に 3 つの RGB 値が続いたものです (赤、緑、青の各コンポーネントの量についてです)。
最初の引数の値は、0 と COLORS の間である必要があります
(デフォルトのカラーインデックスについては、 Colors のセクションを参照してください)。
最後の 3 つの引数はそれぞれ 0 と 1000 の値の間にある必要があります。
init_color を使用するとき、 画面上にその色が発生したところはすべてただちに新しい定義に変化します。

すいません、書き込むスレを間違いました
>>212さんありがとうございます

githubが日本語化しない・・・

UTF-8対応だけで充分だよ
日本語普通に通るからな
日本語ファイルも問題ない

>>215
>>214 はgitじゃなくてgithub.comの話だと思うが。

昔は数言語のインターフェイスがあったんだけどなくなっちゃったね。

Githubも日本語が通りさえすればインターフェイスは英語のままでいいよ。
という話だと思う。

>217
そのとおりです

レスありがとう

初心者向けのブログ記事に
日本語にできるって書いてあったけど
実際は無理だったのね

在日のお仕事
ネットの情報工作
日本の技術の中韓への輸出
沖縄県民になりすました米軍基地の反対デモ
パチンコ運営
暴力団事務所の運営
生活保護の不正受給
神仏を盗難して海外へ売却

>>217
utf-8で日本語使えるじゃん。

だからもう今の状態で十分ってことだろｗ

日本語不自由な香具師がいるな

みんなが使ってるって理由でGitを使ってる連中はこの程度

>>214 が英語出来ないんだと思ってたが
日本語もまともじゃなかったというオチ

コミットAからBまでのログを見る
Aより前までのログを見る
Aより後のログを見る方法ってどうやって指定するんでしたっけ

馬鹿には無理

b*k*には無理

プロジェクトのディレクトリツリーの一部にレポジトリ作ってもよいんですか？
最終的にルートに作ったらどうなるんですか

マージが大変になるんじゃないかな

subproject煮汁

>>226
A..B
A
A..

>>229
サブプロジェクトとかモジュールという考えはよくある。でも同じファイルを2つのリポジトリには属させないな。

submoduleいいお

ああ、そういうことかぁ
ようやくわかってきました

日々gitに遊ばれてるんですが・・・
gitでリポジトリをcloneせずにサーバーのファイル一覧を表示させるには
どうしたらいいのでしょう？

つまり、Subversionの svn ls svn+ssh：//user@host/path/to/repo のような
ことをするにはどうしたらいいのでしょう・・・か？

http://weble.org/2011/03/10/git-ls-files
http://transitive.info/article/git/command/ls-files/
http://iyukki.blog56.fc2.com/blog-entry-119.html
http://d.hatena.ne.jp/happybirthday/20091103/1257230865

>>237
で、cloneしないでサーバーを指定するのはどのあたりに載っているのでしょう？
cloneしてあればgit ls-filesやgit ls-treeでいい、というのは分かるのですが。
不勉強で申し訳ありません。

馬鹿には無理

コマンドラインは知らんが、GUIならリポジトリブラウザを使えば見れるな

>>238
中央リポジトリをサーバーだと思ってる時点で間違ってる。subversionの概念は捨てるんだ！

馬鹿には無理

自己紹介乙

git-daemonにはファイル一覧を取得するようなプロトコルは無いんじゃないの？
リポジトリにssh経由でアクセスしてるならsshでgit ls-treeしてそのまま取得できるだろう
サーバ側にリポジトリブラウザをインストールするのもいい
リポジトリを置いてるサーバ側に何か用意しないとだめだってことだ
まあ普通はsshが簡単

>>244 ありがとー。
無理やり1行でやるなら、
ssh user@host "cd path/to/repo; git ls-tree master"
みたいな感じになるということか。
--bareなリポジトリだとls-filesは動かないのかな。

BtoEのシステムで、◯◯会社向け、△△会社向けのように、導入先ごとに設定ファイルが異なる場合
どのような構成で管理すれば良いでしょうか？
設定ファイルは異なる会社に見せてはならないため、ローカライズで用いられるような構成にはできません。
/resource/language/◯◯社.conf
/resource/language/△△社.conf

似たような事例を紹介しているサイトなどありませんか？

>>246
branch切るか、設定ファイルをひとところにまとめてsubmoduleはどう？

>>246
リポジトリを導入先に直接見せるかどうかだな
見せるのであればブランチでも駄目だし、見せないのであれば全部突っ込んどいてもデプロイしなきゃいいだけじゃね？

>>246
Mercurialの場合、MQのリポジトリ管理
http://cointoss.hatenablog.com/entry/2012/12/04/202114

>>246
Mercurial Queue の適用事例
固有修正を継続的に保守したい
http://d.hatena.ne.jp/flying-foozy/20120608/1339223976#localpatch

>>249-250
んなもんでいいなら、gitでもリポジトリを導入先毎に分けて定期的にマージすればいいだけだろう

馬鹿には無理

ブリーフケースみたいにgit使いたいんだけど
そういう使い方を紹介してるページ教えて

ブリーフケース？
勘違いかもしれんが、Dropboxでも使ったほうがよくね？

俺はトランクス派

>>254
NAS上のフォルダと自分のPCのフォルダを差分管理する

>>255
トランクケースな

儂はビキニ派

Gitで一人で開発する場合って、アプリ開発のソースフォルダと別にローカルリポジトリを作り、
そこにひたすらコミットしていく感じですか？

馬鹿には無理

馬鹿には無理派

>>259
各プロジェクトの最上位フォルダでgit initするとそこに.gitができて、そこにひたすらコミットしてる。

>>259
ファイルサーバにpushしてる。ストレージが壊れたら困るし。
USBメモリとかSDカードでもいいと思うけど。

一人gitだと、リポジトリまるごとをバックアップし続ける程度かな。
日付順に増えていくから、3日前に戻るとか簡単w

>>262-264
ありがとうございます。
バックアップ目的もありますが、何よりちょくちょく個人開発のアプリだと書きなおしたりするので、
履歴とか見れると助かるんです

>>265
履歴を見るだけなら作業しているディレクトリにあるリポジトリだけでいいだろ。というかgitで管理しているなら、そのリポジトリは必須になるはず。

お前荒らしだろ
荒らしにレスするのも荒らし

単にsvnしか使ったこと無い人でしょ

gitってsvnを使いこなせなかった奴が集まってよね

>>269
お前を筆頭にな

最初に触ったSCMがgitなんで、svnさっぱりわからんです、はい

svnは使ってはいたけど使いこなせてなかったな
無くてもまあ何とかなると思ってた
gitは無いと困る

svn出る前からcvs引っ張ってたからなぁ。あまりsvn使い込む前にgitにしてしまった。
>>269みたいな初心者だとsvnが初めてってことになるのか。

cvsはまったく理解できんかった。
その後 長らく
cvsに囚われたプロジェクトリーダのもとで、
svn使ってた。
コミットという概念が無いかのような管理方法だった↓

1.
ソースコードに
『ここからここまで◯◯の件で修正』
とコメントを付けること
2.
コミットの単位は問わない。
・複数の変更がひとつのコミットでもOK
・なぜかひとつひとつのファイル単位で
コミット分けてたりする人が、、、
3.
適当にコミットしたら、
『自分の名前＋日付け』の
タグを打つこと
4.
上記タグを作ったことを
自分でメーリングリストに投げること

思い出しても笑ってしまうな

まだそんな所もあるんだぜ
ウチだ

cvsやsvnと関係ないじゃん。

コミットしないで帰るとすごく怒る上司がいた

>>277
それをやりすぎると
/*きょうはここまで。まだ動きませんww*/
みたいなのが出てこない？

>>276
git使っても「修正部分にコメントで修正履歴残せ」って言うだろうしな、そういうとこは。
cvs使いやsvn使いが悪いと思い込んでるのもタチが悪いな。

branch

>>276
>>274みたいなルールができあがるのって
CVSとは関係あると思ってたんだけど。
CVSはファイル単位でしか管理できない（らしい）けど、
それで無理矢理SVNのリビジョンを再現しようと思ったら、
コメントで囲ったりコミット前後の状態をまるごとコピーする（＝タグをうつ）
ってことになるのかと。

で、CVSの感覚を引きずったままだと、
SubversionだろうがGitだろうが、
ツールに関係なくクソみたいなルールになる。

>>281
cvs使ったこと無いのか。
そんなことにはならないよ。どうしてそうしなきゃいけないと思うのかも分からん。

無駄なコメントとかコメントで囲ったらdiffが酷いことになるのは
同じだし(もちろん最終的な成果物としても最悪!)、1つの修正を別々に
commitされたり複数の変更を1つのcommit入れられたりしたときも同様。

複数ファイルcommit時のアトミック性が保証できないというのはcvsの
問題らしいけど、コメントにしてもタグを打っても解決しないよね。

>>274ルールはバージョン管理ツールを使わないときの約束事に見えるｗ

>>277
作業用のブランチに毎日コミットは意外と良いぞ。
管理上も機械的に進捗見えるし、自分が後で見直した時に修正の意味がすぐ分かる。

>>277
もう一つ大きなメリット。担当者に事故が起きた時のリカバリーが容易。

>>274
cvsは、変更履歴とか残してくれるキーワード展開がそのまま使えて、なかなか便利。有名なドキュメントにも$idとかたまに見かけるな。

>>283
擬似的にアトミック性保持するためにタグ打って
タグとタグをdiff見るんじゃないの

>>285,>>287
昔、全体の管理はsvnなのに、
パートごとの作業用ブランチをcvsで運用、、、ということがあったのを思い出した、、、

そのパートの人による全体の管理用svnへのコミットを見ると、
$Idとかの自動展開部分だけの変更だけがあったりして、
ちょっとうざかった。。。

>>288
複数commitが同時に入った場合、ファイルによって順序が逆になったり
するけど、tag打っても解決しないよね。
逆にtagとtagのdiffが確実に取れる状況なら、cvsは何の問題もないよ。

元の話題のsvnのrevisionと同様という話だと、cvsはtagと時刻しか
無いという問題もあるね。cvsのtagなんて気楽に打てるんだから
バンバン作ればよいと思うが。

>>269
このレスへの過剰半のワロタ
何人かは図星だったんだろうな

>>291
そのレスがあまりにもバカだっただけだろう。

>>290
たぶん複数人による同時コミットがないように、
コミット予約表とかファイルのロックをしてから〜とか
そういうルールもあるんだろう。
それでタグ同士でアトミック性を確保する。

svnになったらそんなことする必要ないのに、頭がcvsで止まってると、ルールだけ引きずっちゃうっていうね・・・

コミット予約表ってのあったな。
同じファイルを同じ日に変更するひとがいると
コンフリクトしてチェックイン作業に時間がかかり、
予定通りリリースできなくなると困るからだって言われてた。

コミットログは適当でいいから、
別管理しているreleasenote.txtに変更内容を書けとか言われたこともある。謎。

>>293
いや、だからtag打っても変わらないって。
どこかのプロジェクトリーダーの頭が悪いのはcvsのせいじゃない。

うちはGitだけど変なルールあるよ。
日本人しかいないけど、コミットログは英語。理由は、文字化けするから、だって。
んで、英語だと変更内容の説明が簡易になりがちだからという理由で、別途日本語で変更内容をテキストファイルに記載しなきゃなんない。

>>296
うちはredmineへの参照しか書かないな。

VSSしか使ったことのない俺はSVNはなんとか理解できたがGITは全然わからん

redmineじゃなくてバグジラだなー。うちは。なぜか顧客直通のバグジラしかなくて、そこに本当のバグの原因とか書くと顧客がうるさいから、ろくに情報が集まらないけど。
顧客から見えるバグ登録システムがあってもいいけど、それとは別に内部開発用のバグジラも置かんとダメだろとは思ってるけど、リーダーさんとかインフラ担当さんとかにあまり技術がないせいで、いつまでたってもゴミみたいな環境から変わらんわ。

要望の段階からチケット切ってる。

今日の大喜利スレはここですね

>>301
違います。こちらです。
http://toro.2ch.net/test/read.cgi/tech/1356521407/

>>284
会社なんかだと上の方はバージョン管理ツールを使えないのがデフォだったり
するからそれ絡みなんでしょ。ツールがやってくれることを人間がいちいちやる
ことないのに、勉強しないし教えても無駄だしで続くことになる。

以前、変更点を出せって言うからdiffで出したら怒られたでござる。プログラム読めない人はコメントだけ読んでくれたら良いのになぁ。
patch使わないでファイル単位で置き換えしている運用も失業すればいいのに。

>>304
＞patch使わないでファイル単位で置き換えしている運用も失業すればいいのに。

うちもなぜか、
顧客へのリリース担当の人が、
そういう方法使ってるっぽいな。
「特定の修正だけをリリースする」
みたいなタイミングがちょくちょくあるみたいなんだけど、
なぜかまず
「その修正に関わるファイルを最新版に置き換える」
という方法でうまくいかないか試そうとしてる節がある。
「このファイルだけ置き換えたらうまくいきますよね？」とかいちいち聞いてくんなよ、、、

削除済みアカウントのコミット履歴でメールアドレスが晒され続けるのってどうにかならないの？
削除後だとどうにもならないのかな

filter-branch --commit-filter でできるんじゃないの？

pushの仕様変更は先送りかよ

>>305
というか、差分更新がファイル単位の変更で済むようなファイル構成
を目指せよ。 なんでも巨大なファイルにする癖をまずなんとかしろ。

>>309
何言ってんだお前。

ﾜﾛﾀ

馬鹿には無理

git-svnは、gitに慣れれば慣れるほど
subversionの使いづらさが気になるのが弱点だなぁ

gitは、gitに慣れれば慣れるほど
gitの使いづらさが気になるのが弱点だなぁ

>>314
何と比較して?
単に使い辛いだけならスキル不足なだけだと思うよ。

>>315
bzr

>>316
bzr使いたいのに、移行するスキルがないんだね。git慣れるまで使い込んで。かわいそうに。
ん? でも使いにくいってことは、まだ慣れれないってことか。bzrに移行しても今度はmercuryがとか言うだけだ。

共有リポジトリはsvn、ローカルはgitってのが便利だなぁ。

>>317
https://yukar.in/note/ckFkxs

>>318
同意
バイナリを扱い始めるとgitだけじゃきつくなる
プログラマー以外が多い職場だと尚更

>>315
cvsより管理がめんどう

>>321
一生cvs使ってろ。

>>322
なに怒ってんだよ 仲良くしようゼ

いまどきcvs使ってる人とはちょっと＾＾

gitとcvsを比べたらそりゃcvsの方が簡単だからな

cvs<svn<git
素人の俺様に、一番簡単なのはgitw
cvsはguiツールでもわからんかったwww

一番簡単なのはhgじゃね？

>>327
bzr

>>318
mergeinfoって真面目に編集してる？
うちも中央はsvnなんだけどmergeが辛い…

>>323
おこってねーよ。
cvsはモジュール取得とかキーワード展開とか個別管理があって便利だよ。
ただしスレチ。

今頃それを言うかｗ

なんで喧嘩ごしなのかわからん

職場のルールや
身内の使いやすいの使えばええやん

お前らがGitやsvn開発したわけでもないだろうに

github上でフォークした自分用のリモート(ローカルも)リポジトリを本家に追随させるのにはどうしたらいい?

ttp://d.hatena.ne.jp/haru-s/20110405/1302006637
↓のようにやってるけど、
$ git pull --rebase github master
$ git pull origin master
$ git push origin master

↓のようではダメ?
$ git pull github master
$ git push origin master

>>333
> $ git pull --rebase github master
> $ git pull origin master
> $ git push origin master
これってrebaseした上でmergeしてない？おかしくね？
> $ git pull github master
> $ git push origin master
これだと単にmergeするだけだからダメではない

自前の変更をmasterに加えるなら、本家に追従させるブランチを別に作っておいて
そっちでpull(常にffになる)、masterで別途そのブランチをmerge、がいいかも

>>335
別に作らなくても
$ git fetch github
$ git merge github/master
でいいんじゃね。という事は
$ git pull github master
でいいんじゃね

馬鹿には無理

git svnでsvn switch --relocateみたいなのはどうすればいいんだろうか
既にgit svnで変換したリポジトリはあるけれども、svnでディレクトリ構造が変わった時に何もしなかったので、
履歴は途切れてしまっている。
ぐぐってみるとあちこちにスクリプトがあるけど・・・何処のを使ってもいいのか？

あ

git initってプロジェクト毎にしたほうがいいでしょうか？

もちろん。

バックアップ目的で
git commit
でデータを保存し続けてますが
これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？

>>342
普通はレポジトリができてからの歴史は全部保存される
VCSはそういうものですよ

ありがとうございます
データが消えたりしたらどうしようとおもってgit commitを控えてました
これからはたくさん指定校と思います

>>344
gitは消えることがあるから注意した方がいいよ
バックアップは忘れずに

>>345
お前よほど無茶な使い方してたんだな…

revertしたら負け

>>345
おいｗｗｗｗｗｗ

>>348
gcを知らない馬鹿？

>>346
ブランチ作って消せば普通に消えるが、
消えない使い方のほうが無茶では？

>>342
>343 で「普通」とあるけどgitは「普通」じゃないから、
そういうことが心配ならgitは使わない方が良いよ。

>>349
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？
＞これってcommitしすぎると古いデータは消えていったり、一定期間立ったデータは消えたりするものですか？

>>349さんのおっしゃるとおり、Gitはちょっとしたうっかりでレポジトリ内のデータが消失し、全ユーザに迷惑をかけます。
Gitリポジトリは慎重に慎重を重ねて扱い、みだりなコミットはやめましょう。

>>350
gcを知らない馬鹿？

>>345
gitそのものをgiｔで管理してるんでしょ

>>349
名前の知られたソフトウェアの中央リポジトリでごっそりコミットが消えたって事件が起こったなら
あんたの主張を認めるよ

ホスティングサービスのgitリポジトリにpushするのが俺のバックアップ

reset --hardやブランチ削除をした後gcすれば、古いコミットの中で到達できないコミットは消されるが、
そもそもgcする前にreflogとかのコマンドでデータを取戻すだろうし、
他のリポジトリにpushしてバックアップしておけばその分は大丈夫だし、
他にも作業している人が居るならそこから取り戻せるし、
普通は誤操作でコミットが消えることはない。

githubとかのサービスのリポジトリはpush -fを使って既存のコミットを消せないようになっているね

>>354
> 名前の知られたソフトウェアの中央リポジトリでごっそりコミットが消えたって事件が起こったなら
> あんたの主張を認めるよ
https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57

>>355
> reset --hardやブランチ削除をした後gcすれば、古いコミットの中で到達できな?%

>>356
ありがとう
これから全社にGit使用厳禁、SVNへの切り替えを通達してくるわ

>>355
> reset --hardやブランチ削除をした後gcすれば、古いコミットの中で到達できないコミットは消されるが、
bareではreflogは残らない。

> githubとかのサービスのリポジトリはpush -fを使って既存のコミットを消せないようになっているね
githubはpush -fできるが？

>>356
railsは糞って話？
>>357
じえんおつ

前githubにforce付きでpushしたら拒絶された気がしたけど、別のサービスだったかも
githubのヘルプにはpush --forceは出来るが何をしようとしているか分かっていないならやるなと書いてある
enterprise版にはpush --forceを拒否するためのオプションが有る

強制pushは間違ってコミットを消す可能性があるのでpre-receiveフックで禁止すべきだ

Assemblaではデフォルトで禁止されているけど設定で有効にできる

>>360
sf.jpはそのオプション付いてた。

pushは次のバージョンで仕様が変わる

Windowsでgit1.8.1.1を使う方法ってありませんか？
http://git-scm.com/のDownload for Windowsをクリックしても何故か1.8.0がダウンロードされるので困ってます

>>364
The current source code release is version 1.8.1.1. If you want the newer version, you can build it from the source code.

つまりcygwinを入れてビルドするしか方法はないってことですか？

1.8.0がWindows向けの最新ビルドです
それより新しいバージョンが欲しかったらソースからビルドしてね。って書いてあるからそうなんじゃないのかね
Cygwinが必要かはわからんけど
http://git-scm.com/download/win

誰かビルドしてくれる優しいボランティアの人っていないものですかね
アフィリエイト張っとけば儲かると思いますよ

>>368
そんなにWin版の1.8.1がないと困る状況なのか…お察しします

gitは元々Windowsなんかどうでもいいんだよ
嫌ならhg使っとけ

出るまでじっと待ってろよ

ぎっとな

バージョンごとcabアーカイブで管理してろ

どうしてもジットって言ってしまう

ギト

ジットでもあってる

リーヌスの発音に合わせとけばいいんじゃね？

ギットじゃないの？

複数人で作業する環境でgitを使う場合
最低限必要なコマンドを教えてください
お願いします！
明日からお客の現場にいくので困ってます！
ていうか経験浅いのに（浅いってハッキリいったのに！）今日面接行って２時間の言語研修受けて明日からすぐ即戦力で働いてもらうってマジキチすぎる！

>>379
git

git 退職届
git commit

スキルシートに
PHP 1年
Java 6ヶ月
って書いたのに
PHP 6年
Java 3年
に書き換えられてるし
何これ
派遣会社ってどこもこんなのかよ

グチならよそに行け

git rebase -i 夢に満ちていたあの頃

git rebase イチロー

git init --bareで作ったのが共有リポジトリっていわれてますが
ここにみんながpushしていくところで合ってますか？
自分だけのはaddとcommitでみんなで共有するところはpushって認識で合ってますか？

>>386
お前がそう思うんならそうなんだろう
お前ん中ではな

では正しく教えて

>>386
--shareもつけてる。

SubversionからGitへの移行を考えています。
いまのプロジェクトでは一つのリポジトリの中に複数コンポーネントを別々で管理しています。
Subversionはリポジトリ内の任意のディレクトリからチェックアウトできるのですが、
Gitではできない（リポジトリの上位ディレクトリからしかチェックアウトできない）のでしょうか？

だとしたら、
http://d.hatena.ne.jp/wyukawa/20100506/1273142916
にある「2. 単一リポジトリ複数trunk型」で今は運用しているのですが、
これをGitに移行するとしたら、「3. 複数リポジトリ型」になるのでしょうか？

gitでcheckoutしたときに新しい内容と古い内容がこごちゃまぜになってよみがえる事があります
これはなぜですか？

そもそもgitはpartial checkoutができないので、
可能な限り小分けにして別リポジトリにするのが正しい
リポジトリ間の相互利用はsubmoduleやサブツリーマージを駆使してどうにかする

svnの相対パスexternalsは便利だったよなあ

>>392
ありがとうございます！やっぱりそうですか・・・
発想の転換が必要ですね。
そのあたりの運用みたいな話ってどこかに掲載あります？
一連のコマンド操作はよく出てくるのですが、リポジトリ構成の話とかはあまり無いので。。
Git book読めって話なのかもしれませんが。。。

リポジトリ分割で悩む必要はないんじゃないかな
結局チェックアウトしたい最小単位ごとにリポジトリを作るしか無い
trunk/branch/tagなんかは機能としてあるので、中身はtrunk相当分だけでいい

運用で大事なのはやっぱマージの指針を決めることじゃないかな
rebaseするのか、何度も取り込むのか、複数ブランチがお互いにマージし合うのを良しとするのか
特にサブツリーマージなんかを使い出すとrebaseが上手くいかなくなることもあってはまる

391お願いします

>>395
どうなるのか具体的に説明してくれ
>>391では何を言ってるかわからない

コミットされてない作業ファイルがあったとか？

自分もどうやってこうなったのかよく覚えてないんですが
ファイルをエディタで開くと最新の内容と古い内容がごちゃまぜになってるときがあるんですよ
こういうときいつも手動で書き換えてます

conflict 解決要求の警告無視して commit したろ

なんですかそれよく覚えてません

釣りじゃないならgitの出したメッセージをコピペしなさい。

今月gitを使い始めたばかりでメッセージは良く覚えていません
なったときのメッセージも保存してないのでよく覚えていません
git initとgit add .とgit commitとgit checkout .しか使ってません
これでたまにファイルの内容が壊れてるんです
どうしてこうなるのか原因がわかればそういう使い方をしないようにするのでなんとかお願いします

馬鹿には無理

>どうしてこうなるのか原因

メッセージを読まずに無視したからに決まってるだろ

>>402
今月もそろそろ終盤なんで、およそ1ヶ月使ってそれなら、あと1ヶ月ぐらい練習に費やすといいよ
実運用はそのあと。

gitつかったことないんだけど、conflict無視してコミットなんてやんちゃなことできちゃうの？
svnでいうところの、conflict解消してないのにresolved、 commitってステップを踏んだのかな

>そういう使い方をしないように

必ずメッセージを読みなさい。

とりあえずテンプレのPro Git読んでこい
話はそれからだ。

>>406
コンフリクトしたままではコミット出来ない。
手動で編集後、addでステージする必要がある。
commit時にincludeオプションで含めることも可能みたいだが使ったこと無い。

.gitディレクトリを別の場所にコピーして使っても大丈夫ですか？

　　　　　 /ノ"~::::::::::::::::::i::::､::::::::::::､::::::::::::::::::::::メ、　　　　＿　　　　　　　　　　　　　　　　　 .＿
　　　　　/....:::::::::::::;;:::::/::!:::::i;:::ヾ::::::＼:::::::::＼:::::::＼　 ┌┘└─┐　　　　/７　　　　　　┌┘└─┐
　　　　 /:/:::::::/:::/:::::ｲ:/ﾞ!:::::ﾍ::::i＼:::ヽ::::､:::::ﾞi;:::::ヽ,|.　└┐　r─┘　　　/ /　　　　　　 .└┐┌─┘
　　　　ﾚ/:::::::/::;ｲ::／|/　ヽ::::ﾞi＼ｌ,ンﾍﾄ＼ヽ::::i:::::::}　　 ／　　二,ﾞ''ヽ、　/ /─-､　　　　　　/　/ｌ二二ｌ
　　　　.｛:::;;::::|/ |/,'ﾞ~'''=-ヽ＼ヽ‐~イ,､i　ヽ_iヽ:ﾄ:::::〉　 | /~|　レ'／ヽ ﾞi / ／￣ヽヽ､┌┐ /　/「ｌ
　　　　 i:::;|:::::ｌ,　/　（o｝ﾞ　　　ﾞ ヽ　ゝ-- '" ∧,|ヽ/　　ヽ二､_／┌┘ﾉ|／　　　 ＼二_ノ∠_/　L二二ｌ
　　　　ヽ/|::::|ﾊ `'　-'''~　　<ｌ　　　　　　　 ハﾉ::ﾚ'　　　　　　　　 ￣
　　　　　| ヽｌ､(ﾍ　　　　　__,,,,,r‐-､　　　　.ハ'/　　　　　　　 ┌-､　　　　　　　　　　　　　　　　　　,-‐──-､
　　　　　　 ヽヾ∧　　　　i'‐''"""'‐i　　　 /::::ﾍ　　　　　　厂７＼ ＼□口　＿/￣/＿＿　 　　　　|　┌─┐ |
　　　　　　　　 |:::ヘ　　　!,　　　　ﾉ　　 ,ｲｌ::::::::i,　　　　　/　/　 ヽ　ヽ　　　L_　　＿＿　ﾞヽ　　　　ヽ＿ｌ　　|　|
　　　　　　　　 |::::ｌ:ｌ､ﾞヽ,､. ﾞ''‐-‐'"　 ,イ-''|;;:::::|:ｌ　　　　/　/　　　ﾍ　ヽ　　　/　/　　　|　　|　＿＿＿　　 ／／
　　　　　　_,,--メ‐‐.､￣ !ﾞ'-､,,,,,,...‐" i'　 ヽﾘ:::ﾚ'　　　/　/　　　　 ヽ　ヽ　 /　/　　　 |　　|　［＿___　」　　|＿|
　　　　／~　　｛　　　ヽ''"ｌ　　　　　　|'ヽ､ ヽｌ/"_,,,,,,∠_/　　　　　　ﾞi　　>/　/　　　 」　　|　　　＿//　　┌┐
　　　 /　　　　ﾞi　...:::: .ﾞi ﾞ'''‐-､,,_　　　　_,,ﾞ''‐''"~　　　~ﾞ"''ヽ.､　　　　￣　￣　　　　└─┘　　＼＼ 　　└┘
　　　 |.　　　　 ヽ::::::::::: ﾞﾄ､　　　 ﾞ　　‐"　　　　　　　　　　　　 ﾞ''-､,,_ 　　　　　　　　　　　　　　／／
　　　 ヽ　　　,-‐‐ヽ::::::::::: ヽ､　　　　　　　　　　　　　　　　　　　　 　ﾞ"'‐- 　　　　　　　　　　　

>>409
マジレスすると、そのフォルダを使っていないときにコピーするのは問題ない。
でも普通はやらない。
gitプロセスが動いているとロックされていて正常にコピー出来ないはず。
上書きコピーは多分リポジトリが壊れる。

clone、fetch、push、pullを使ったほうが確実で速い。

C:\jabacodeの中に.gitを作
C:\javacodeに変更したかったんです
一度C:\javacodeからcloneしてからC:\jabacodeのほうは消して使ってみます

>>412
はああああああああああああああああ！？？？
普通移動するだろそれは。gitが処理中でなければ良いんだから。
コピーはおすすめしない。

別にcloneでもいいんじゃない？
何も問題はない

>>414さんがそうおっしゃるのでもう.gitを移動はしないことにした
cloneして消す。これが唯一の正解

cloneするとclone元がupstreamになるだろ？
まあ設定し直すだけだけど若干めんどい

っていうか移動するにしても、普通は.gitだけを移動するんじゃなくて作業ツリーごとやる
>>412の例ならjabacodeディレクトリをリネームして終わりだろ？

すいません勘違いしてたらすいません
Windowsを再起動して立ち上がった直後にフォルダをコピーすることも検討してみます
あとcloneでやるのも両方やってみたいと思います
両方出来る事を確認して中級車の仲間入りに慣れたら良いなと思います

長文打ってる間に新規レスが・・・ｗおれはなんてタイピングが遅いんだ
明日返信しますすいません

>Windowsを再起動して立ち上がった直後にフォルダをコピーすることも検討してみます
何で再起動後やねん
何かのプロセスに使われていなければ普通にリネームも移動もコピーも出来るし

てかcloneなんかしても時間かかるだけだろ、コピーも同様
リネームや移動のほうが速い

もう遅いから俺も寝よう

windowsはどうだか知らないが、上のディレクトリを移動してもファイルの実体は変わらないから、ロックされてても関係ないんじゃないの。

ファイル名変えたら中身も変えないといけないファイルあるじゃん？
Javaみたいにクラス名=ファイル名とかで。

で、中身変えたら別ファイルと判定される場合(git log --followで追えなくなる場合)
ビルドできないのを承知でgit mvだけのコミットを作るべきなのか、履歴が途絶えても気にしないべきなのか
どうしてる？

履歴追えなくなる方が嫌だから、同じファイルとして認識されないなら、移動だけのコミットをする

Mercurialはこの辺問題無いのにね。

今までgit mvして編集してからコミットしてたけど、git mvして編集する前に一旦コミットしなきゃいけなかったのか…。

>>423
やっぱそうか…ありがとう

mvしてちょこっと編集してcommitして、別ファイル扱いにされるってよっぽどじゃないか？
名前書き直した程度なら追随してくれたはずだが

ここの上級者たちでも答えは出ないのか

>>426
基本そうだけど、元々の行数が極端に少なかったり名前をたくさん繰り返してたりすると引っかかる。
ファイルの先頭に定形コメントを入れてるようなとこだと、まずかからないとは思う。

一旦コミットして、追従してくれない時だけ戻してrenameだけのコミットを作るのは？

ぶっちゃけ、追従してくれないほど中身代わってるなら別ファイルでいいよ

過去にコミットしていったデータに戻せなくても良いので
最新のデータだけ別のフォルダに写してそこで新しくgitで管理するにはどうしたらいいのかだけ伝授してください

>>430
だよな

>>431
rm -f ./.git
git init
git add .

githubとgitが有名だからって理由でgitを使っているんですが（といってもaddとcommitだけ）
githubってgitでしかバージョン管理できないんですかね？
他のバージョン管理システムからってできないのでしょうか？

そりゃ"git"hubなんだからね

そうですよね
なんかこうgitより簡単なバージョン管理とかあったりしたら助かるのでいろいろ試してみたいなと思ってました
github使えないのでgitだけにします

MSのサービスとか、google codeとか使いなさい
githubのメリットってほとんど無いよ？

>>437
使いやすいから300万人も利用しているんでそ

>>438
それ、大半がSkyDriveみたいに倉庫として使ってるだけだからｗ

さすがにオンラインストレージの代わりにはならんわ
レンタルサーバの代わりとかならまだわかるが

ソースやデータ置き場として見れば
無料だしバージョン管理までしてくれるし
ついでに貧弱だけどWikiまであるから嬉しい

確かに有料でも良くて高速高容量なら
さくらでssh+gitってのもありだけど

っていうかprivateにするためだけに
有料でgithub使う理由が判らん

さくらは信頼できるの？

あなたが何をもって信頼に足ると判断するつもりなのか

githubはカス、sf.net勝ち組とか言ってるのこのスレ以外にないぞｗ

そんなことお前しか言ってない

>>439
無料だと公開状態だけど、大半の人が公開で倉庫に？
無理がある意見だなあ

>>445
ごめん、言ってたのVCSスレの連中だったわｗ

ttp://toro.2ch.net/test/read.cgi/tech/1334766732/
75 名前：デフォルトの名無しさん[sage] 投稿日：2012/08/23(木) 14:39:26.25
sf.netは10年たっても残ってそうだけど
githubが心配なんでsf.net使ってる

78 名前：デフォルトの名無しさん[sage] 投稿日：2012/08/26(日) 09:22:42.68
githubは、gitベースのソーシャルコーディングという
スタイルに特化してる分、
そのスタイルが廃れれば、githubは消えるだろう。
そのときでもsf.netは、時久の流行りのシステムを
取り込んで生き延びると思う。
svnとかgitとか、今までもそうだったろ

開発を委託した外部の人にリモートリポジトリにpushしてもらおうと思っているのですが、
その場合はsshのアカウント作らなきゃいけないのでしょうか？
svnみたくアカウント作れないのでしょうか？

>>448
これを読んでみたらどうか
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

4.4に一つのアカウントで複数のユーザにアクセスさせる方法の解説がある
4.8にGitoliteを使って管理する方法の解説がある

やっぱりソースコードって
言語別にディレクトリを分けてその中にプロジェクトを作るべきですか？

>>450
何の言語？

javaとかcとかrubyとかです

>>452
gitと関係無いだろ
プロジェクトを管理するツール次第じゃないか

>>449
ありがとうございます。
sshつかうなら後はLinuxのユーザー管理の問題か

コードを公開したくないんですけど
あと日本語で使いたいので国産のgithubみたいなサービス教えてください
できれば無料で
なければgithubより安い値段で

英語でも良いなら色々有るんだけど
日本語対応でプライベートリポジトリ持てるのって有る？

OSSホスティングサービスの比較 - Wikipedia
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83
Comparison of open source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

>>382
係数が判明したんだから
次からはあらかじめ係数で割っとけ

>>457
派遣先も同じ係数を使ってるから、素でいいよ。

どうせたいして信用してないしね

>>457
係数ってなんですか
結局ITとは関係ない工場の仕事してるけどさ

>>460
6

すまん、一部で秘密鍵やパスワードが検索されてしまう状況が話題になっているんだが、
自分のリポジトリがそういう状態になっていないことをどうやって確かめればいいんだ？

どうもうこうも、そういうファイルをリポジトリに入れてるなら
以前からずっと公開状態にあったのが見つかりやすくなっただけだし、そうじゃないなら関係ないだろ

今日githubのオフ行った人内容ｋｗｓｋ

そんなんあったの

>>465
ハブられたの？

京都でもあるで。懇親会はないらしいけど

>>466
わろすｗ

C#のソースコードをgitするときに除外するファイルってありますか？
また、除外はどうやってやるのでしょうか？

TFS / Visual Studio で Git をフルサポートへ
http://softwareengineeringplatform.com/articles/news-git-and-update2/

majika

MS、オープンソースのバージョン管理ツール「Git」をサポートへ
http://japan.cnet.com/news/service/35027623/

Windows Azure が git で deploy 出来るようになって久しい
http://toro.2ch.net/test/read.cgi/tech/1359450980/

Windows Azureがgitのデプロイを受け付けるのと、
Visual Studioがgitをフルサポートするのは全然意味が違うだろｗ

FTPからGITでwebサイトを作る時代って認識してますけどあってますか？
パーミッションの設定とかしなくて楽ですよね

GITとGIFと岐阜の発音を教えてください

ギット、ジフ、ギフ

node.js developer center
http://www.windowsazure.com/en-us/develop/nodejs/
  npm install azure
  git commit -m "My first Node app"
  git push azure master

「Visual Studio 2012 Update 2」CTP版が公開、TFS/VSが「Git」に対応
http://www.forest.impress.co.jp/docs/news/20130131_585929.html

このスレ読んで気づいたけど
Githubオフ登録だけして行くの忘れた

ポインタとハッシュの違いがよくわかりません

>>481 そもそも似てない

一般的にポインタって言ったら「指し示すもの」だし、ハッシュって言ったら、「なるべく衝突しない一意の識別子」を指すと思う。

両方とも、プログラム中で何かリソースを指すものに使えるけど、
何かgitと関係あるのか？

Gitはデータのハッシュをキーとしてデータを管理してるんですよね?
ドキュメントにブランチはツリーのポインタを持っていると書いてあり、混乱したので質問しました。
つまりGitでいうポインタとは、登録されている他のデータのハッシュ値のことという理解でいいのでしょうか。

gitをdropboxにおいた場合ってどうやって暗号化したらいいの？

>>485
http://git-scm.comの3章あたりを読んでるのか
Gitで管理されるブランチやコミットとかなんらかのオブジェクトを指し示す物(ポインタ)はハッシュで良いけど、
それを日本語の文章でポインタと呼ぶことはあまり無いな

>>486
gitのレポジトリを暗号化したままの状態で操作したいってこと？

>>486 ではないけれど
秘密鍵をgitで管理するいい方法はないかなぁと思う
hookを駆使すればうまいこと暗号化しつつgitリポジトリにつっこめないだろうか

秘密鍵を手元で暗号化/復号するんじゃだめなのか？

>>489
> hookを駆使すればうまいこと暗号化しつつgitリポジトリにつっこめないだろうか

当然その秘密鍵を hook で復号化してチェックアウトするんだよね？

その hook 見れる人は誰でも秘密鍵を復号化できるわけだけど、良いんだよね…

>>488
むずかしいことはよくわかんないけど
とにかくdropboxにおいてるときは暗号化して誰かに盗まれても使えないようにしたい

秘密鍵なんて滅多に変更しないんだからリポジトリに突っ込む必要ないじゃん
githubの記事読んで来たお上りさんか？

ちょうどいいのがあるじゃないか。
https://gist.github.com/873637

暗号化ZIPで固めて放り込んどけばいいだろ

ええええ

あの

githubでアカウントを複数使いたいんですが
みんなに公開用と匿名用（ニートがばれるので）
gitを使うときに名前とメールアドレスを設定するじゃないですか
あれってアカウントを切り替えるごとに自動的に切り替える方法ありませんか？

リポジトリごとなら .git/config で切り替えられるが。

おっけーですそれでいきます

難しく考えすぎてたみたい
>>495 で十分でした
回答してくれた方々サンクス

zipの暗号なんて簡単に解けるんじゃなかったっけ？

簡単に解けてたまるか

[A] 初期のソースコードをにコミットします
[B] 改変したのでコミットします
[C] 改変したのでコミットします
[D] Aの状態を戻して新しいコード書き、Cの次にコミットしたい


Dについてどうやるのか教えてください

git revertすりゃいいんじゃないかな

git revertしたらコミットしたやつがきえちゃうじゃないですか
AとBとCはのこしときたいんです

git resetと勘違いしてないか？

Aでブランチ作れば

Aの状態にも適用出来るパッチを作って、そのパッチを手元のリポジトリ上ではCの次に並べたいということだろう
git checkout AしてDの作業をして、stashしてgit checkout masterしてgit stash popでどうだ

・Aからブランチ切ってDの作業をコミット
・Cに戻って、さっきのブランチをマージ
が正当だと思う
まさしく>>504のまんまだけどね

>>495
その暗号化に使用した秘密鍵をまた暗号化して保存するのですね。

宝石箱の鍵が宝石箱に入ってる って言う状態になりそうな予感…

鍵をパスフレーズで秘匿するというのはふつうに使われていると思うが。

で、そのパスフレーズをまた暗号化して保存するのですね。

なんのためのパスフレーズだよｗ

生体認証最強()
ですねわかります

>>504
Aにそのまま適用可能なパッチを、Cの次にコミットしたいってどういう状況なの？
そのパッチがCにもそのまま適用出来るならAに戻す必要なさそうだし。
俺なら、Aの後にA'というコミットを作るけど、それと何が違うの？

数日前からTortoiseGit/msysgitを使い始めた新参なんだけど、
がんがんコミット/プッシュ作業してるとエクスプローラーの表示が
おかしくなる。再起動/explorer.exeの強制終了で対応してるんだけど、
何か根本的な対応策知っている人がいたら教えて
ttp://2ch.at/s/20mai00595982.png

>>518
根本的な解決方法は、windowsを捨てる。

>>516
生体認証は盗まれた時に変えることができないという欠点があるので、無効にできるよう他の認証方式との組み合わせが必要だと考えてる。

Overlayやめたら？

Windowsやめるか、shell拡張使わずか。
バグフィックスされるのを待つしかないのかな。

>>518
Overlayやめたら？

git commitって1万回やっても一番最初のコミットはちゃんと残りますか？
あと、残る場合、無駄に容量が増えるので、○番目以前のコミットは消してHDD節約する方法とかありませんか？

はい

>>523
コミット消すとか斬新だな

コミットってやっぱり消さないのが普通ですか？

>>517
rebase厨としてはよくあること

古いコミットをまとめるとかやろうと思わないけど、いざやるとなるとrebaseするしかないんだよね

コミット消しても、どれだけHDDの節約になるか・・・
よっぽど消さないと節約した〜とはならないでしょ
git gc すれば、綺麗に圧縮されて節約にはなるけど。

むしろ古い複数の変更を詰め込んだ雑然としたコミットを、ちゃんと変更内容ごとにばらしたいと思うことならよくある
実際にrebase -iって打った所で、当時のビルド環境を再現できずに諦めてresetする

>>529
今はSSDとかクラウド（）ストレージとか利用が少なからずあるから少しでも
節約したいって部分はあるでしょ。特にノートなんてストレージ容量増やすの
面倒だし。

>>523
rebaseしてgc

最近使い始めた。

githubで使ってるアカウントに、
人材派遣会社っぽいところから、
電話くださいってメールが届いた。
なんなのこれ？

そのクズな会社をさらしてくれよ

Google の人事からメールが来たけど無視した
Google Japan だったし

うそおつｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

つまらん

xxx様
 
はじめまして、○×△☆の※※でございます。
突然のメールで失礼致します。Githubを拝見させて頂いてメールさせて頂いております。
私どもは外資系ヘッドハンティングファームでございます。外資系ＩＴ企業、
コンサルティングファーム、国内ＩＴ企業のエンジニアポジションをご紹介しております。
現在私どもでは、クライアントの強いご希望でアプリケーションエンジニア、
ネットワーク系のエンジニア、ゲームエンジニアの方を探しておりまします。
エンジニア関連職にご興味ございましたら是非、１度お電話で構いませんので
お話させていただけないでしょうか？？
 
もし、お話させていただける場合は
 
○電話番号
○ご連絡ができるお時間
 
をご記載の上ご返信いただけますと幸いでございます。
 
xxx様とお話できることを楽しみにしております。
何卒、よろしくお願いします。

※※
Recruiter
○×△☆

どこのクライアントか特定してさらしちまえよ

プロジェクトの中身関係なく日本人に片っ端から送ってるんだろうな

支那から似たようなの結構来てる、台湾からは一度だけ来た
あとなぜか米軍の南ア？かよくわからんがそこからもきた。

おいおいこんなのgithubで管理していいのかpublicで
ttps://github.com/takashiogawa/GOAND/blob/master/%E3%82%AF%E3%82%99%E3%83%A9%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF/%E5%BA%83%E5%91%8A%E3%83%8F%E3%82%99%E3%83%8A%E3%83%BC.txt

githubのプライベートレポジトリって有料だから
まさか無名の自分のレポジトリ見にくる人はいないだろうと思って
ケッチってんのかな？

何がダメなの？パスはちゃんとgoogledocsに置かれてるじゃん？

見てないから知らないが、パスワードが書かれてる元データもコミットされたままなんじゃね？
問題があるとしたら、それを晒してる>>542の行動だと思うｗ

業務の進捗を公開しちゃってる時点で「信用できない企業」だよね。

>>545
2chには既に「公開情報なので拡散しても罪には問われない」という判例ができていてだな…

自分のID、Passを公開しても法律的には問題ないな

>>542 >>545
色んなものが見えてくるね
https://github.com/takashiogawa/GOAND/blob/master/.gitignore

違法コンテンツへのリンクだけでもアウトという判例は既に積み重ねられている。
「自分のパスワード」が過失で公開されてしまったものなら、それへのリンクは
不正アクセス禁止法に違反する行為と考える事も可能。
操作するかは警察の胸先三寸。

もし見つけてもヒントだけにしとくのが無難。
>>542 は論外。

客に通報してやるのもいいね。

記念にフォローしてみるか

フォークとか絶対するなよｗ

コミット履歴みると .gitignore 作る前のバージョンが・・・

googleで「githubページ 広告」でｇｇｒとトップにヒット

削除したものが残ってるとは思ってないみたいな。

git使いたいだけちゃうん

初めてgithubレポジトリ自分のフォローされた

それbotだよ

普通にメールも来たよ
使い方教えてくれって

最近のボットは手が込んでるんだな

なにその「最近のダッチワイフは」的な言い回しはｗ

そんなに手が込んでいるのか、最近のは。
また買ってみるか・・・？

>>499
これのやりかた詳しく

普通にgit configなんちゃらってすればリポジトリごとに設定できるって話でしょ

masterブランチのtest.txtの中身
a
b
c
testブランチを作ってのtest.txtを
d 100
e 200
f 300
にして
git add test.txt
git commit -m "testブランチのコミット"
git checkout master
git merge test

test.txtの内容がtestブランチの内容になってしまいました
masterブランチの内容とtestブランチの内容を足したいんですがどうしたらいいですか？
masterブランチに書いた内容が結構量があるのでやばい状況になってます

今
git checkout ハッシュってやったんですけど戻せません！助けてください

足すってなんだ？
git checkout ハッシュ --forceってやりゃいけるだろ

あなたは神ですそのコマンドで元に戻りました

すいませんちょっと気になったことがあるのですが

masterブランチで作業してコミットしました
testブランチを作ってファイルを編集しました。ここでコミットはしてません
masterブランチに切り替えたんですがファイルの内容がtestブランチのままです
マージするまでmasterブランチとtestブランチを切り替えながらやりたいので、ファイルの内容も切り替わってないと不便です
こういう場合はどうやるのが王道でしょうか？

コミットせずに保存しとくなら git stash かな
王道はしらんけども

了解しました

fork

ブランチを分けて作業をするときたとえば
index.html
test1.html
test2.html
test3.html
がるとして
master以外にa,b,cって分けるとするじゃないですか
aはtest1.html
bはtest2.html
cはtest3.html
を編集して、それ以外のファイルは編集しちゃいけないってことでしょうか？

>>575
異なるブランチで同じファイルを編集してもいいけど、
編集した場所によってはマージ処理を機械的に行うのが不可能になるので、
そうなった場合は人間が手作業でマージ処理をすることになる

という事は同じファイルを編集しないようにする方法ってありませんか？
こういうのってコミュニケーションでこれは編集しないでくださいって言うだけしかできないですかね？

>>577
ない

うは、困りましたねコミュ障なのでメンバーに話しかけるのがツライ

test1.html.編集前に読め.txt
を作って中に注意事項書く

例えばmasterブランチに空のtest.jsを作成して、異なるブランチに分けてメソッド書く場合
ブランチAはaメソッド、ブランチBはbメソッドのコードを書いて、それらをmasterブランチにマージするのはどうやるのでしょうか？
単純にgit merge a bってやると最後のbブランチの内容だけしか反映されません

こんな感じかな
git checkout master
git merge --no-ff A
git merge --no-ff B

ためしてみますありがとうございます

コミットしたあとにファイルを消して
git checkout masterってやってもファイルが復活しなくて
git checkout .　てやったらファイルが復活します
何故masterはだめなんですか？

馬鹿には無理

>>584
git checkout ブランチ名
git checkout ファイルとかディレクトリ
この2つは同じcheckoutコマンドなのに意味が全然違って、
前者はブランチの切り替えで後者はファイルの復活

勉強になりました

汎用ツールをいくつかの環境に導入しています。
それぞれの環境の違いはパラメータファイルだけなのですが
これはGitでは管理対象外にするのが良いのでしょうか？
上手い管理方法があれば教えて下さい。

設定ファイルは普通別リポジトリだろ

馬鹿には無理

漏れには無理

gitプロトコルを動かしきらずにあきらめてsshのみの運用。だめだ俺も馬鹿

Windowsでgitする場合、msysgitを使うのとcygwinからgitを入れて使うの
どっちがおすすめですか

>>593
Windowsを捨てる

Windows環境でgitを使おうとしてる奴はハゲ

msysgit+tortoisegit

>>593
どちらも一長一短って感じだから両方入れとけばいい

以下は個人的な感想
- cygwin
GUI がXサーバ必須になって面倒かつイマイチ (使っていないから現在どうなっているかよく知らない)
- msysgit
一部機能が未対応
周辺ツールのサポートがないことがままある

>>581
これって本当にそうなる？
こっちではちゃんとコンフリクトになるんだけど

git merge A Bなんだろうけど、
うちでもAブランチをFast-forwardでマージしたあとBのマージでコンフリクトするな

あれまじすか
あとで使ってるバージョンとファイルの内容と実行したコマンドをgit initから書いて見ます

C:\をカレントフォルダに指定しておく
mkdir test
cd test
git init
type nul > test.js
git add .
git commit -m "1"

git checkout -b a
echo function a(){} > test.js
git add .
git commit -m "a"

git checkout -b b
echo function b(){} > test.js
git add .
git commit -m "b"

git checkout master
git merge a b

test.jsの内容
function b(){}

git config --listの内容

core.symlinks=false
core.autocrlf=input
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
core.quotepath=off
core.editor=C:/Hidemaru/Hidemaru.exe
user.email=個人情報なので非公開
user.name=個人情報なので非公開
push.default=simple
gui.recentrepo=D:/source/ruby/update
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly

ブランチBがブランチAからの分岐になってるからそれで正しい
ブランチBをmasterから分岐してみ

バージョン1.8.0.msysgit.0

以上、コンフリクトになりません！

ああああああ一回masterに戻ってbブランチを作ったらちゃんとコンフリクトできました
ブランチってブランチを作ったところから分岐するんですね、勉強になりました！

お、おう

すいませんgithubってpublicだと他人のリポジトリに勝手にコミットとか出来ちゃうんですよね？
お金がないのでプライベートに出来ないんですけど、自分だけコミットしたデータだけ取得する方法ってありませんか？

お好きな方法をどうぞ

githubを使わずにローカルだけでレポジトリ管理
見つからないことを祈りながらgithubにpush
ほかのサーバーを立てるか借りて使う

>>607
他人が勝手に自分のリポジトリの内容を変えたりはできないよ

>>607
アンタ馬鹿？

>>608

bitbucketがgit対応でプライベートリポジトリが無制限だったはず

>>607
コミットはアクセス権のあるひと(SSH秘密鍵を登録したメンバー)しか出来ない
自分以外にコミッターを追加することはもちろん可能

見られるのも嫌なんだと思うのだが。

>>614
だから何だよ！
金無くてプライベートリポジトリにしたいなら
github以外にしとけよ

>>614
>>607 の質問ではそういう心配はしていない。

bitbucketの方が使い勝手いいと思うんだが
gitもhgも対応してるし

bitbucket止まりすぎだろ
分散バージョン管理ならあまり問題にならないだろうけど

githubとbitbucketのちがいを詳しくおしえてください

>>619
wikipediaのホスティングサービス一覧見ろ

azure いいよね

やったWindowsに新しいバージョンがダウンロードできるようになった！！
しばらく1.8.0だったけど今日1.8.1.2を入れる事ができました

>>622
それutf8の香具師？
cmd.exeでも動く？

あの、作ったブランチで編集したファイルをコミットしないでmasterブランチに戻ってまたさっきのブランチにもどったら編集してた内容が消えてました

masterブランチに戻るときに作業結果消えるけどいいのか？って聞かれただろ

移動元と移動先のブランチで同じ内容のファイルなら
編集中の状態を持ったまま移動できるんだっけ

>>588
探せばレスキューできるんじゃなかった。
俺はstashしてからcheckoutするけど。

>>623
日本語ファイル使ったことないのでわかりません！
cmd.exeで使ってますがgit logで表示される日本語は文字化けしませんでした！

linuxでリモートリポジトリって何処に作ってます？
ユーザーホーム直下とか？

>>629
/var/repository/name

HFSだと/shareとかもアリって聞いたけど、どうなんだろ。

/var/mycodes/php
/var/mycodes/hsp
/var/mycodes/c

/var/git/hoge

>>629
github

ありがとう

>>593 亀レスだけど。

今はどうか知らないけど、自分がインストールしたときは
Cygwinのgitはバイナリマウントしてないとcloneがうまく動かなかった。
デフォルトでテキストマウントしてるようなら注意した方がいい。

msysgitはCygwinとも共存できるので、msysgitの方がお勧め、だと思う。
インストール時に改行コードをどうするか、パスをどこに通すか選べたはず。

あんまり関係ないけど、Cygwinシェルからだとgitk.cmd ってやらないと
msysgitのgitkが立ち上がらない。コマンドプロンプトからならgitkで立ち上がる。

Windowsでgithubを複数アカウントで使う場合
.sshってホームフォルダにできるじゃないですか
なのでユーザーを切り替えてから新しいgithubアカウントを作って.sshを作成したら複数アカウントで運用できますよね？

>>636
githubでの複数アカウントの使い分けかた — KaoriYa
ttp://www.kaoriya.net/blog/2012/07/13

herokuにgitでファイルを簡単に上げられますけど
パーミッションの設定とかしなくても大丈夫なんですか？

今日に限って帰るの遅いとか・・・
ログイン制限になったら泣けるな

git で、ブランチが指しているコミットIDを変更するにはどうしたらいい？
やりたいことは
echo 新しいコミットID > .git/refs/heads/ブランチ名
と同じことです。
git rebase -p feature_xxx
したら、feature_xxxに含まれる子ブランチがうまく移動してくれなかったので。

>>640
git reset --hard コミットID

コンフリクトになる条件ってこれ以外にあったらおしえてください

・masterブランチからtestブランチをつくって、同じファイルをどっちのブランチでも編集したとき

>>642
前提条件を絞らないといっぱいありすぎるぞ

>>641
ありがとうございました。

一人でgithubを利用する範囲でお願いします

>>645
たくさんありすぎて無理

馬鹿には無理

add
commit
log
status
branch
checkout
これしか使わない場合でもいっぱいありますあｋ？

>>648
なんでコンフリクトが起こるのかを考えたほうがいいよ

gitで中央の履歴を絶対に消せないようにする方法を教えて

gitに中央なんてものはないので無理です
真面目に

誰も巻き戻せない絶対的な中央がほしいんだけど
どうしたらいいのかね

pushでブランチを巻き戻したり上書きしたり消したりを不可能にしたいならこんな感じか
git config --system receive.denyNonFastforwards true
git config --system receive.denyDeletes true
当然のことだがレポジトリを直接操作できるなら意味は無い

>>653
ちょっと参考にさしてもらうわ

レポジトリを直接いじって死ぬ分には覚悟するけど
gitコマンド経由では絶対に死なないようにしたい

githubのmasterブランチと僕のおうちのパソコンのmasterブランチの内容ってまったく同じでしょうか？

ちゃんとpushしてれば同じのはずです

なるほど、ちょっといまいちgitは難しいですね
同じであれば問題なさそうです

うふふ

質問です
masterといくつかのbranchをgithubにpushしました
その後github上で不要になったbranchを数件(普通のブラウザで)削除しました
手元にはそのbranchは残っているのですが
ローカルでそのbranchを消そうとすると
github側のbranchが見えない(先に消したので)と言われて消せません
github側にあるかないか無視して消すにはどうすればいいですか？

企業ではソースコードの管理はやっぱりgithubにお金払ってプライベートにしてるものですか？

解決
git branch -r -D origin/ほげほげ
で出来ました

企業によるだろｗ

企業だけど、お金払えないので public にしてますよ。

プライベートにしたいなら ssh 鯖立てれば良いだけじゃね？
なんでわざわざ github にお金払うの？

単にssh鯖でgitが使えるだけじゃgithubと同等にはならんからなあ
アカウント管理とかコードレビューのためのツールとかいろいろ自前で環境整えるのがメンドイなら
github使うのもありだろ

>>659 >>661
リモートで削除されているリモートトラッキングブランチを掃除するコマンドとして
git remote prune origin
というのもある

>>666
ありがとう

git使い始めて、その性能にものっそい驚いてます。

checkout --SOFT
みたいな、ファイルを変えずにブランチを切り替えることはできないですか？

>>668
そこはresetでしょ

C:\test\aにgitリポジトリを作って
そのあとにaフォルダをC:\sample\dir1\aに移動しました
そして、.git以外のファイルとフォルダを消してgit checkout .　ってやったら最新のコミットの内容と古いコミットの内容でaフォルダ内がごちゃごちゃしました
フォルダを移動したい場合ってどうしたらいいでしょうか？

>>670
＞最新のコミットの内容と古いコミットの内容でaフォルダ内がごちゃごちゃしました
具体的にどうなったの？

git mvせずに普通に移動しただけでしょ
後からgit rm & addでも可

.gitのあるフォルダの場所を移動したって話でしょ
べつに問題無く移動できるよね？

おう誤読してた
でも.gitごと移動したなら問題ないはずだよな

>>670
最新のコミットが実際にはされてなかったってオチじゃないの。
移動しとききたい時は、元の残しといたままgit cloneしてる。

オフトピックが続いてあれだけど、

　- 重複が起こらないことが保証されていること

　- 重複が起こる確率が小さいこと

この2つは意味的にまったく違うってことが分からない奴多いんだね。
やっぱり今時のプログラマってFランとか専門学校卒が多いのかな。

その間に「重複が起こる確率が実用上無視できるほど小さい」って言うのがあるだけだろ。

あと、学歴になんかトラウマでもあるの？

>>676
突然どうしたｗ
Linusに喧嘩売ってる？ｗ

最後にコミットした内容と、最後に編集した内容（コミットしたか覚えてない）のファイルが混じってるんです

>>679
>>670の方法で移動するとすべてのファイルが最後にコミットした状態になる
コミットしたか覚えてないファイルがある状態じゃ、正しく移動できたかどうかの判断できないだろ

>>670
> そして、.git以外のファイルとフォルダを消して
そもそも何の目的でこれをしたの？移動したいだけなら必要ないと思うけど。

そうですよね、最後にコミットしたか覚えてないのが問題かもしれません
うまく移動できたか確認したかったのでいったんファイルとフォルダを削除してgit checkout .で復活できるか確認したかったんです

逆に移動元で最後にcheckoutとかresetしてたら、どっかに含まれてて漁れば復元できたかもな。移動と関係ないか。

git blame でどの行がどのコミットのものかわかるから調べてみたら？

>>682
確認する目的で取り返しがきかないことするなよ
しかも確認しようがない方法でさ

それ、その場で消してcheckoutじゃなくて、
他の場所にcloneすれば確認できるんじゃ？
移動する前でも、移動した後でもさ。

>>676
お前初めてかここは、力抜けよ

どんな意図があってVisualStudioスレからコピペしたんだろうね

A.新規で何が作りたいプログラムがあるとします
B.フォルダを作ります
C.空のファイルを作成します
D.空のファイルにコードを書きます

どの部分でgit initをはじめてgit add . とgit commitをしたらいいですか？
いままでgitは使ったことなくていままで作ったプログラムはgitで管理してないんですけど、
これから作るプログラムからgitの練習を兼ねたいと思っているのですが、
どの時点でgitのリポジトリを作ればいいのかわかりあｍせん

ある程度動いてからでいいよそんなもん。

完成してからgitしたらいいってことですね
わかりました

A.新規で何が作りたいプログラムがあるとします
 → 名前が決まったら github で create a new repository
B.フォルダを作ります
 → ローカルフォルダで create repository here (つまり git init)
C.空のファイルを作成します
 → まず README.md を作って git add . と git commit (first commit)
 → A の github を origin にして push
D.空のファイルにコードを書きます
 → 出来れば master 以外に開発用 branch 作ってからコードを書き始める

プログラム書いてる間に＾「あー、編集ミスった。さっきの処理残しておけばよかった」って後悔することない？
俺はそういうときでも復元できるようにビルド通らないのもコミットしてる
仕事だとビルドできないのはコミットするな！っていうのもあるけど、個人だったらそんなこときにしなくてもいいしなｗ

そういう処理は消さない

ビルド通らないのもコミットするときは
後でそこだけ消せるようにしとけばいいじゃん

書き直すのが手間になるくらいの処理を削るときは、一旦コメントアウトして
新しく書いた方のテストが通ってから消すのが普通だよな。

何のためにバージョン管理してんだ？

俺もよくやるよ、古いコードコメントにしてコミット。戻すの楽だもん。
自分のリポジトリなら何コミットしても自由じゃん。

コンパイル通らないまま保存しときたい時はstashに入れてるな

commit -m "[tmp]ほげ" とかやる気のないコメントでやっといて
後で整理ついたらrebaseで潰してる

> 仕事だとビルドできないのはコミットするな！っていうのもあるけど

分散リビジョン管理なんだからローカルで好きなだけブランチに
コミットしちゃえばいい。

commit -m "ああああ"

ああああの部分について適当に書いてるんですけど、定石な書き方とかってありますか？

普通に変更点を書くよ

適当なら問題ないだろう
適当ならな

バージョン管理ってプログラミングの技術とは無関係のソース管理術だろ
板違いじゃね？

-m "何々の変更"
これは無意味だから書くべきではない。変更点はdiffでわかる。

-m "何々の為の修正"
こちらの方が重要

>>702
動詞現在形で始めて78文字以内、ピリオド無し、が一応ルールらしい
が、git自身のリポジトリを見ても全く守られてない

ので、まあ後で自分が検索しやすければなんでもいいと思う

1行目はいろんなツールが要約的な意味で使うので、必要十分なサマリーに。
それさえ守ればあとはフリーダム。

1行で500文字くらい書いてるわ

それは凄いな
よほど文才ないと1コミットにそこまで書けないだろ
まぁ同僚にいたら迷惑な気がするが

>>702
redmine使ってると、"refs #12345 @2.5h"とか書いとくとチケット12345にリンクしてくれるし、2時間半かかったと記録してくれる。
あとは直してるのか、追加してるのか書いてる。そうするとどこが安定してるかわかりやすいので、戻ってみるとき便利。

>>702
定石というかわからないけど

-m "はやく帰りたい"
-m "終電やばい"
-m "もう無理"
-m "さがさないで下さい"

githubで興味のあるリポジトリ？をフォローするとそのリポジトリが更新？されたときに登録したメールアドレスにメールが届くんですけど、
メールはいらないけどそのリポジトリ？その人のアカウント？のフォローだけする方法を教えてください
毎日メールがわんさか来てどうしたらいいか困り果ててます

まず退会ボタンを押します

ポチっとな

>>713
フォローするのはアカウントに対してだよね
リポジトリに興味があって印をつけておきたいだけならStarを使えばいい

>>705
どの板なら良い？

バージョン管理板だな

どこが適切なのか
こっちで思う存分語ってきてくれ
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

これが移転したら考えよう

>>2見りゃわかるが、この板にはかなりたくさんのバージョン管理システムのスレがある

適当にファイルを作る
git init
git add .
git commit -m "セーブ1"
適当にファイルを更新する
git add.
git commit -m "セーブ2"
ここで1番目のファイルに戻って確認したい事があるから git checkout セーブ1のハッシュでもどる
git log するとセーブ2のコミットがなくなっている！
git reflogで見たら残っている

２番目にコミットしたとき、１番目のコミットのファイルの内容を確認したいので戻って、確認終わったら２番目に終わるときはどういうコマンド操作をするのが王道でしょうか？

ミス
×確認終わったら２番目に終わるときは
○確認終わったら２番目に戻るときは

diff

1に戻ろうとしてるのはなんで？

diffってコマンドがあったんすか。。。。これで確認できたんですね
1に戻りたかったのはそこにしか書いてないコードがあったためです

えっ

言ってることはそのとおりだけど、
入門者、初心者スレとしてはあまりこだわらないほうが良いよね。
知識として知っておいて、いずれはそうするべきだってのを知っていればいい。
変に考えすぎて失敗して完成しないパターンに入る気がする。

reflogを知ってるのにdiffを知らんとか偏ってるなｗ
showコマンドで特定のコミットの内容表示もできるぞ

>>722の操作は普通やらないけど、やっちゃいけないってわけでもない
戻るときはcheckoutで元のブランチを指定すればいい
カレントブランチがブランチで無い？という感じのちょっと特殊な状況に
なるので戻るまで操作に気をつける必要がある

なるほど、
これからはこういうことはやらないようにします

>>713
star

ハッシュを指定する場合でのcheckoutとresetの違いって何？

checkoutは.get/HEADが指す先を変更する
resetは.get/refs/heads/*が指す先も変更する

git初心者です
リモートのリポジトリはローカルのコマンドラインからinitできないの？
サーバー側で作成してあげないとダメなんですか

>>734
まずはリポジトリとは何なのかを勉強するべき

なんかgitって新しいバージョンから仕様が変わるんでしたっけ？

>>734
Mercurialだと
hg clone . ssh://foo/bar
でリモートに新しく作れるんだけどね。Gitはそういうの無理みたい

そういうのいらない
期待してないし

初心者モードとか実装してほしい

日付変わるのなんとかならんかな
チェックアウトした日時とかコミットした日時とかじゃなくて
コミットした時点のそのファイルのタイムスタンプに復元してくれたら嬉しい

>>737
分かりました
ありがとうございます

>>740
gitはそういう目的のツールじゃないんで

>>740
禿しく概出

★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


↑マスコミや、在日カルトのネット工作員がやっていること

TVなどが、偏った思想や考え方に染まった人間をよく使ったり、左翼を装った人間にキチガイなフリをさせるのは、視聴者に、自分と違う考え方をする人間が世の中には大勢いるんだなと思わせる効果がある。
..

>>740
makeが失敗する原因がわからずに悩むがいい。

エディタなんかもタイムスタンプが新しくなってるのを見て
ファイルとバッファの内容の食い違いがあるのを検出したりするからね

趣味、日曜PGなんですが、Gitって勉強しとくばきですか？Webアプリをデプロイするときなんかでも使いますよね？

しとくばきですか→しておくべきですか

失礼しました

しばくぞ

趣味プログラムでも、何かしらツール使ってソース管理しといた方が楽だと思う

スレ的にはgitだけど、zipでも十分＞趣味

何故ZIPで管理しないでgitを使うのか
このあたりの解説をお願いできますか

簡単に差分見れたり
簡単に過去に戻れるから

github に push して zip でダウンロードしてる漏れは勝ち組

最近ほんと2chのレベル下がったな
低年齢化が原因かな

>>755
そう思ったら卒業しろよ
いつまで2chに張り付いてんだ

他に遊んでもらえる場所が無いんだろ
察してやれよ。

>>747
webアプリと環境によると思うけど、そのまま上げるならrsyncが楽と思う。それはそれとして履歴管理はしておいた方がいい。

>>758
ありがとうございます。何らかの履歴管理は検討すべきですね

>>758
> webアプリと環境によると思うけど、そのまま上げるならrsyncが楽と思う。

節子、それデプロイじゃなくて単なるアップロードや

gitはpushされたときに自動で何かするプログラムを簡単にリポジトリに仕込めるんだよね

>>760
デプロイって配置って意味でしょ。例えばJavaServletならmavenからパッケージングするし、Railsならrakeからとかでそっちのが便利なのでwebアプリによってと言った。webアプリによっては何もすることないのだから、アップロードのみがデプロイ。

>>762
いや、別に君がそう考えてるならそうでもいいけど、世間とずれてる
ことぐらいは自覚した方がいいかと…

>>763
そうだね。君の所属している狭い世間とは違うかもね。

Web アプリ デプロイ あたりでぐぐればいいのに…

ちょっと可哀想な人なんだろうな。

Web アプリ デプロイでぐぐるとほとんどJava関係なんだなｗ
これはこれで激しく片寄ってる気がｗ

>>747
結論を言うと、デプロイのためにgitが必要と思うならやめておけ。その言語や環境のスレで必要なツールを聞け。

logしたときに出るコミットのログは、
溜まってきても消さない方がいい感じですか？

>>768
ブランチの最新のコミットはその溜まってるすべてのコミットに依存してるので、
ブランチの最新のコミットをそのままに過去のコミットを切り捨てることはできない
切り捨てるとすれば、最新のコミットまですべてリベースすることになる
リベースするとハッシュが変わる
みんなで共有してるコミットは基本的にはリベースするべきでは無い

複数人で作業する前提で利用するコマンドって
commit
add
branch
checkout
status
log
reset
こんぐらいですよね？他につかえたほうがいいコマンドありますか？

>>770
あります。たくさんあります

diff/show を過去のコミットを見るのに使う
push/pull は複数人での作業なら当然使うよね
fetch/merge/clone/show-branch あたりも使えたほうがいいかも
stash は簡単で便利で是非覚えておくべき
reflog は何か変な状態になったのを調べるために
rebase はいくつかの定石的な使い方だけでも覚えとくと失敗を簡単に修正できる
cherry-pick で簡単に済んでしまう仕事は結構多い

>>766
て言うか、あいつらぐらいしかデプロイなんて言わないから。
日本語でも、ソフトウェアを配置するなんていう奴はちょっと変な奴だろ。

んなことないw
Railsでもよく使うよ

VisualStudioじゃInstallSheildのあるカテゴリは「セットアップと配置」だし、デブロイにしてもたまに見かけるから気にならないな。
判りにくい単語を使い出す奴も頭悪いけど、それに執拗に絡んでるのも頭悪いだろ

GAEもdeployだったでごじゃるよ

7
7
7

>>772
宇和こんなにあるんですね、今から覚えます

>>774-776
ほら、言ってるそばから変な奴が現れたし (w

むしろデプロイという単語と無縁のWebエンジニアだと、
PHPとなFTPとか使ってそう

git checkout -- index.html と
git checkout index.htmlの違いってなんですか？
--は何を表しているんでしょうか？

此処から先はファイルネームしか出て来ません
ということを表しているのです
例えば--helpというファイルがあったら
git diff --help じゃヘルプが出ちゃうけど、
git diff -- --help こう書いたらOK
・・・のはずです

-- から後はブランチ名じゃなくてファイルのパスだよ、という明示。
ファイル名と同じブランチがあった場合にちがう。
git help checkout の EXAMPLE で説明されてる。

>>782
ありがとう

実際に現場ではどのようなミスでトラブルになることがありますか？

趣味ですが今日からgitで管理して以降と思って初めてgitしたんですが
コード書くときにブランチ分け忘れました
やっぱりブランチってわけたほうがいいでしょうか？

>>786
masterというブランチにコミットしたのでは無いのですか？

そのとおりmasterにコミットしました
もしかしてやっちゃまずかったですかね？

あーあ

一回.git消してもう一回やることにします

あ〜〜

masterしか使ったことないや。

そういう場合、ブランチ作ってチェリーピックであってる？

reset --hard でいいやん

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

--force

>>790
それは本当はする必要ないけど、慣れる近道は使い倒す事だから何回でも最初からやり直すと良いよ
ブランチも切りまくれ、マージしまくれ、コンフリクトしまくれ

涙の分だけ強くなれるよ

GUIでの3Wayマージに良いツールってなに？
DiffにはWinMergeを使っているけど
3Wayマージ用のTortoiseMergeがあまり使い勝手良くない
TortoiseGit付属のはコンフリクトあるのに表示してくれなかったりするバグもあるし

p4merge

* githubにsubmoduleとして使いたいソースがある
* 自分は権限がないので、そこへはcommitできない
* submoduleとして使う場合、特定のrevisionを使いたい
* 自身のプロジェクトはbitbucketにある。

この場合、アプローチとしては以下が正しいでしょうか？

* submoduleとなるソースをgithubからbitbucketへリポジトリをcopy(forkはできないので・・・)
* bitbuket上に特定のrevisionのbranchを作る
* 自身のプロジェクトのsubmoduleとして、そのbranchを参照する

>>801
Git submodule の基礎 #git #AdventCalendar - Qiita
http://qiita.com/items/0d525e568a6088f6f6bb

>>802
この場合、githubにあるbranchを追っていく形になると思うんですよね。
自分が困っているのは、githubのmasterの特定のrevisionで固定したいんです。それはsubmoduleのディレクトリで
git checkout -b hoge {固定したいrevision}
すれば可能ですが、他のユーザーがcloneしたとき、submoduleは上記で固定したrevisionを指していますが、detach head状態になります・・・これがどうにも気持ちが悪い。
かといってsubmoduleがあるgithubにはbranch作る権限がない。
どうするのがスマートでしょうか。

fork

submoduleとして使っているブランチがリモート先で更新されたら
detach状態になるのは仕方がないことなのかな・・・

>>804
githubはgithub以外へはforkができないですよね。bitbucketとか。
>>801みたいにコピるしかないのかなと。

githubでforkすりゃいいだろ馬鹿

サーセンwww
そうかbitbucket無理に使わんでもいいか（笑）

branch作ったところでdetached HEADは回避出来んよな
forkってcloneしてpushと同じことだろ？

ちなみにbitbucketからgithubのリポジトリをインポートすることもできました。
ごめんなさい。

>>809
detach避けるためにそれ以上更新しないbranchを作るという意図でした
main projectからは、そのbranchをsubmoduleとして参照

GitHub点呼スレ

GitHub
http://toro.2ch.net/test/read.cgi/tech/1363238105/

GitHub連呼スレに空目した

叩いてるのが一人しかいないって？
お気楽でいいね〜

幹は普段いじらず改造は全部枝でやって、納得できたら幹に反映する

みたいなやり方をしてるんだけど、このやり方ってなんか名前とかある？

>>815
砂遊び作戦

>>815
むすこいじり

お前アンカもまともに打てないのか？
初期のyahoo掲示板かよｗ
「トピずれだぞアンチは出てけ」
ってかｗｗｗｗｗ


やっぱ糞スレは保守するのに必死だな。sageる余裕もないのか。

あ？

い？

ち？

ゃん大勝利！

BDD

windowsにgitをインストールするときに改行が何とかって3種類選ぶやつがありました
\r\nにするとか\nにするとか改行を自動変換しないとかそんなやつ
それで、言語によってソースコードは\nだったり\r\nだったりするのですが、改行は自動変換させないほうがいいでしょうか？
rubyとかjavascriptとかは\nで書いてるんですが、VC#だと改行が\r\nになるのでこのあたりはどうしたらいいのか教えてください

改行にかぎらずこの手の自動変換は全部切っとけ
バイナリファイルへの誤爆が怖いし

そうします自動変換はやめときます

こんな風に


いつのまにか


ソースが2行づつ


改行されてたでござるよ

Git初心者です

/.../foodirを、
git init --separate-git-dir=/sepadirで別のとこにリポジトリ情報保存していました。

ずっと前に気にせずにfoodirをpuyodirに変更したらしく、gitのコマンドが
fatal: Could not switch to '/.../foodir': No such file or directory
と出て使えなくなりました。

git configですら使えなくなり、どうやってディレクトリ名変更をgitに伝えればいいかわかりません。
/sepadir内のconfigファイルに　worktree = /.../foodir　とあったのですが、これを直接書き換えても大丈夫なんでしょうか･･･

どうかよろしくお願いします。

>>828
大丈夫

それは良かった

〜(゜▽゜)〜

お前らの油ぎっとぎと

>>829
ほんとですか？
信じます！

嘘を嘘と（ｒ

おっぱい

本と空気読めない奴だな、だから気違いの多い春の2chって嫌いなんだよ。

>>836
お前の母ちゃんよりマシだろ・・・

また github 経由で変なメール来た。この手のメールの共通点は、
「あなたのプロフィールを拝見し、大変興味をもち」
と書いてある割には肝心な感想の文章はなく、彼らの宣伝だけが以下に続く。

馬鹿発見

>>838
卒業大学や特許まで調べられてきたことがあった
マジ怖い

gitってほんと難しいね・・・

馬鹿には無理

各社毎の設定を切り分けるためにブランチをきることにしました。
dev　・・・・・機能追加用ブランチ
dev/ooo　・・・ooo社用ブランチ（機能追加用ブランチをマージ）
dev/xxx　・・・xxx社用ブランチ（機能追加用ブランチをマージ）
これでうまくいくと思ったのですが
mergeする度に必ず設定ファイルがconflictします。
これはしょうがないのでしょうか？

ttp://i.imgur.com/hTifBya.jpg

http://sns.atgames.jp/cache/img/jpg/w415_h415/a_1584613_f2ab4c70635b37d2c9a0233fe752134e2ada75d1_jpg.jpg

 　 ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　 |　 　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　 　/.:oヽヽ: :|: | :|
　　　 　{　{o:::::::}　　 　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　 　ヾ:::ｿ /|: : |
　！？ ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　 ＞
::∧: : :|: |J　　 ＼　　 ／　　 ／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　 ヽ: |::|＼　　　 ￣/ /|　　|: : :|: |

>>843
最近のapacheとかでは、ディレクトリ内の設定をすべて読み込むとか、シンボリックリンクを貼ることで設定が有効になるとか、影響なく追加しやすいようになってるよね。

>>843
そもそも各ブランチで勝手に書き換えられる設定ファイルを
別のブランチでmergeすることは必要なの？

ひな形はgitで管理するけど実際に使う設定ファイルはgitで管理しない方が良いように思うけど、
設定の項目名の他に設定値まで他のブランチでも流用したりするのかな。

>>847,848
返信ありがとうございます。

設定ファイルには各社毎に異なるシステム名や機能の有効無効フラグを持っています。
最初はGitの管理対象外にしていたのですが
新たに機能を追加した時に別で管理しているファイルにも
同じ変更を加えないといけないのでもっといいやり方が無いかと思いまして・・・

Gitでやるべきこととそうではないことをもう少し整理してみます。
ありがとうございました。

rebase

そもそも自分とこ以外の会社にはどうやって提供してんだろ？
gitリポジトリにアクセスしてるなら
自分で勝手にやってくれって気がするし
archiveかなんかでexportしてるなら
export用のスクリプト書けばいいだけな気がするが

いずれにしろ設定ファイルはもうちょい改良の余地がありそうではあるけど

>>851
そんなことぐらい自分で判断しやがれ
ここで聞いても答えはでんだろ
他の人の意見を聞くならまだしも
お前が信じるかどうかなんて知ったことじゃねえ

Gitの話題なので貼っておこうか…
ttp://cpplover.blogspot.jp/2013/03/kde_26.html

GJ

>>852
何を信じてなさそうに見えるの？

すいません助けてください本当お願いします！
コミットしてから結構大量にコードの修正をしたんですけど、
その状態でコミットしないでgit checkout . ってしてしまいました！
これを取り消す方法ないでしょうか？

ない

うはああああああああああああないんですかああああああああああああああああああああああああああああああああああ

ある

ない

ある

>>856
コミットせずにチェックアウトとか削除とかしたらあばばばばばばばば

一度 add していたら dangling object として残ってるかもね

同じリポジトリ間で、サブツリーマージ？ を行いたい
具体的には
repo/prjA/libA
repo/prjB/libB

があり、libAとlibBの中身をLinkさせたい。Historyも共有したい

一応 GUIでSourceTree使ってるけど CUIでも良いです
知ってたら教えて下さい

Linkってなに

msysgitを入れるとguiのソフトもついてるじゃないですか
そのguiの使い方がさっぱり分からないんです
コマンドプロンプトからaddとcommitとlogとstatusとcheckoutしか使ってないんですが
やっぱり業務でgitするならguiも使えないと厳しいでしょうか？

>>865
リンクです

怒らないで聞いてほしいんだけど、何でこんな時間に書き込み出来るわけ？？
普通の人は学校や会社があるはずなんだけど・・・・・・
このこと知った親は悲しむぞ？？
現実見ようぜｗｗｗ

プンプン

ポッポー

>>866
厳しいって何?
GUIじゃサーバで使えなくて業務が達成できないとかならわかるが。

あの付属のgui使ってる人なんているの？

業務なら人に教えることもあるだろうから、使う使わないは別として知っておいた方がいいだろ

業務なら教えたりマニュアル読んだりするのにCUIの方がいいだろ。

C:\library\の中に
C:\library\sql_no_backup\*.pl sqlのバックアップ
C:\library\make_format_text\*.pl フォーマットされたファイルの作成
など小物スクリプトをlibraryフォルダの中にフォルダ別に分けて管理してます
それぞ大規模なコードは書いてないですが、結構頻繁にlibraryフォルダに追加されていきます
こういう場合って親フォルダのlibraryでgit管理中するのか、それとも各小物スクリプトのフォルダの中でgit管理するべきか
どっちがいいか教えてください
githubにプライベートリポジトリであげます

>>875
配置はインストールスクリプトで決める。

>sql_no_backup sqlのバックアップ
ここまでひどい名前は久々に見た

バックアップしないのかと思うよな

「フォーマットされた」ならformatは過去分詞形にしないとダメだろ
× make_format_text
○ make_formatted_text

>>879
いや、lose_formatted_textだろう。

コマンドを覚えるのがたるいから、Git extensions ってクライアントを使ってるけど、
趣味で書いてるコードを金曜の夜にコミットしようとしたら、操作を間違えて、数日
分のコードが消えた。
土曜に半日かけてもとに戻して、さっきコミットしようとしたら、また今日の分の作業が
消えたわ。
ちょっとした操作で簡単に消えるのな。

Git extensions　は捨てて、コマンドを覚えることにするわ。
もう寝る。

GitExtention使ってるがコミットしようとして消えたことなんて一度もないぞ
どんな間違った操作をしたんだ

>>882
コミットしようとしたら「ブランチが選択されていません。このままだとウンヌン」みたいな
メッセージがでたんで、コミットのウインドウを閉じて、ブランチを選択して、またコミットしようと
したら、変更のファイルが表示されなくて、あれっと思ってファイルを確認したら、
全部選択したブランチの最新の状態になってたわ。
コミット前の今日の変更は消えてた。

TortoiseGitも細かいバグは多いな

>>883
メッセージは全文をそのまま貼るように

>>881 だけど、
http://qiita.com/items/e37c707938847aee671b
このページをみて、金曜に間違えた時点にもどせましたわ。
Git Extensionsのせいにしてごめんね。
でも、やっぱコマンドから勉強しなおすわ。

メッセージ貼らない人の言うことは怪しいということは分かった。

あほにかまうな

>>887
メッセージなんかいちいち取ってないわ。
捨てようって思ったからわざわざ再現とかしないし。

クライアントは日本語化されてないやつのほうがいいな。
トラブルがおきてネットの解説とか探しても、コマンドラインのどの操作が
クライアントのどの操作に対応してるかよく分からんかったわ。

bash-completeで補完してるからコマンドよく覚えてないな。

git svnってコミットメッセージ内のgit-svn-id（多分）からメタデータを再構築する方法あったんだね
知らなかった

てｓ

>>888
だからなんでそうなるのか理解不能状態
大体そう言うお前は学校行かないのかよ
見ろ、見事なカウンターで返した
調子に乗ってるからこうやって痛い目に遭う

＞見ろ、見事なカウンターで返した

ｗｗｗｗｗ

くやしいのぅ

くやしいのぅｗｗｗｗ

git commitしたあとに不要なファイルが存在していることに気が付きました
ファイルを消してgit add . してgit commitしたんですが
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: lib/codebird.php
#
no changes added to commit (use "git add" and/or "git commit -a")
って出てgit logみてもコミットされてないようでした

こういう後から気づいた場合はどうするのがいいのでしょうか？

>>898
git add . では消したファイルをステージできないので、git rmでステージしてからコミットする
修正を前のコミットに含めたい場合は git commit --amend
addやcommitをする前に、どのファイルが操作対象になるのかをgit statusで確認するべき

つかえねー

確かに馬鹿には使えない

Windowsにmsysgitを入れてgitを使い始めました。
文字コードがShift_JISのテキストファイルを編集しては、
何度かコミットしてみているのですが、
msysgitのgitkでバージョン間のdiffを見ると、gitkの左下のdiffが
文字化けします。(コミットログは文字化けしない)

とりあえず .gitattributes に以下のように書けば化けないようになりましたが、
Shift_jisのファイル全部を列挙していくのも面倒です。
hoge.xt encoding=shiftjis

これはそういうものなのでしょうか？

GitExtentionを入れるといい

utf8版の方が良い

Windowsでの使用は諦めた方がいい

Ruby の話なら同意

なんでや！Python関係ないやろ！！

>>907
つまらん　お前の話はつまらん！

つまるところつまらん

ゲリピー！

消化早まってるな
そろそろ次スレ立てとくか

はえーよｗｗ

はたらけど はたらけどわが生活楽にならざり
Git ソースを見る

gitで他人のソースを自分のPCにコピーして、
カスタマイズを行い、
自分のレポジトリにpushとかってできるんですか？

その場合。注意点とかありますか？
（マスターからブランチにするとか？）

初心者的質問ですいません。

>>914
できるし、自分だけでやるのと特に違いは無い
pullreqやパッチ送りあうならプロジェクトごとに流儀はある

>>914
他人のソースがgitのレポジトリで管理されてるの？
自分のレポジトリは誰が何処に用意するの？

自分のPCにコピーしてカスタマイズしたいなら、
自分のPCにgitをインストールして自分のPCにレポジトリを作る必要がある

自分のレポジトリが自分のPCのレポジトリとは別のとこにあるなら、
自分のPCのレポジトリから自分のレポジトリへカスタマイズ結果をpushする必要がある

>915,916
回答ありがとうございました。

質問です。
ソースの変更履歴(v1.1, v1.2, v1,3,v1.4)がある状態で、
(1)現在のソースをv1.2に戻す(と同じにする)ことはできるのでしょうか？
(2)可能な場合、v1.3〜戻す直前のソースがなくなるのでしょうか？
　それとも戻す直前のソースがv1.5として残り、最新のソースがv1.2と同じものになるのでしょうか？

１　できます
２　なくなりません

>>918
v1.1〜v1.4がコミットされていて、さらにv1.4から修正したコミットされていないソースがある状態？

まずコミットされていないものをv1.5としてコミットして、
そのあとgit revertでv1.2と同じ内容のv1.6を作るのが普通じゃないのかね
この方法なら何も失われない

v1.2のファイルをcheckoutしてv1.5としてコミットしたいだけの話ならresetでよくない？

あーresetすると履歴消えちゃうか

>>919-922
レスありがとうございます。

まだv1.5を作りたくない時はstashがある。

resetしてもreset ORIG_HEADで戻れる
怖いから別のbranchを作ってそこでresetする方が無難

git config color.ui true
ってすればカラー表示できるようになりますが、なぜかamazonEC2上だけできません
git log --color
とすればちゃんとカラー表示されるのでcore.pagerとかその他の問題じゃないと思うのだけど、、、
なぜだか分かる人、もしくはamazonEC2上（OSはamazonオリジナル）でカラー表示できてるよって人いますか？

>>816-817
検索したけど出て来ませんでしたよ

>>927
もあぱわー

GitExtensionsを入れたら Git BashでcommitするときもGUIのエディタが立ち上がって
激しくウザいんだが、止めるにはどこで設定すればいいんだろう？

.gitconfig辺りを適当に

あぁ、そっか。ありがとう。

あるサーバをメインとして、佐藤さんと田中さんが開発してるとき
出張先でVPNが張れないので佐藤さんのPCを一時的に
メインサーバ扱いにしたいんだけど どうしたらいい？

佐藤さんの脳にLANケーブルを挿す

メインサーバってどういう役割なんだ？

佐藤さんと田中さんが二人とも出張に行くのだろうか

>>932
田中「佐藤、あと全部よろしく」
でいいんじゃね？
そんなコミュニケーションもとれないなんてどんだけコミュ障なんだよ。

>>932
決まったルールは存在しないから
あなたの会社の好きにすればいいかと

てか、その二人はお互いをfetchしてないのか？
gitつかってるならメインサーバーなんて空気だろ

>>938
お互いにフェッチって、 フェ○して○ッチするみたいでいやらしい。


メインサーバにpushしてそれをfetchするようにしてるんだけど
お互いにfetchするのってどうやるの？

gitはそれぞれに対してpushとかできる
単にある場所しかpushしない、とルールで決めてそれをサーバにしてるんだろうから
一時的にルール変えてもいいんじゃない？

ふたりフェッチ（0点）

>>940
そう、一時的に運用ルールを変えたかった

つまり俺が知りたいのは佐藤さんのPCからfetchしたり
佐藤のPCにpushしたりする方法なのか

sshd動いてればいけるだろ
WindowsだとCygwin無いとダメ？

簡単にいうと、
準備
二人とも公開用にリポジトリをcloneする
git remoteで相手の公開用リポジトリを追加する

運用
相手の公開用リポジトリからpullする
自分の修正分を公開用リポジトリへpushする
二人の修正がおわったところで中央へpush

>>939
一時的にメインサーバーのリポジトリをclone作る手もあるか。
わかっていると思うけどfast-forwardになるように注意しないとマージのログが残る

やったことないけどpatchにしてメールすればいいんじゃないかな。

二人が同じ場所にいるならUSBメモリでも使うのが楽じゃね？

田中を解雇してお前が全部作る

githubで公開されてるパッケージを自分なりにカスタマイズしたものを、自分のレポジトリにアップしても問題ないんですかね？
本家にpull requestしないの？って話ですが
本家のポリシーと異なる方向性になってしまっている＆本家の反応がないので、
forkしたものをレポジトリごとrenameしておいておくべきなのか、
それとも、もう名前もかえて別パッケージにして、自分のレポジトリに新規に追加すべきなのか悩んでいます。
ライセンス的にはGPLv3です。copyrightに本家いれておけばいいんでしょうか・・？
本家に連絡は？ここら辺疎いのでさっぱりわかりません。
アドバイスください。

ライセンスさえ守れば好きにすりゃええ

細かいことを言えば、gitレポジトリ自体の設定ファイル類にはGPLは及ばないんじゃないかな
中身の流用はGPLの範囲で好きにすればいいが

.gitignoreとかは、誰が書いても同じになる的な意味で著作権の争点にならない=ライセンス気にしなくていいと思う

あるプロジェクトをフォークしたものに例えばdevというbrunchを切ってそこに適宜patchを当てていくとします
master <- フォークしたオリジナル
dev <- masterにpatchを当てたもの
masterがある程度更新されるとdevにmergeします。この時自分で当てているpatchはその都度git rebase -i dev~X
でdevの先頭から当てなおしていくとします。
そうすると devのある時点でtagをつけるとgit rebase -i dev~X した際にこのtagはgit rebase -i dev~Xの影響を受けるのでしょうか？

>>948
forkして自分とこにpushするのはgithub利用規約的に問題なし。

>>932
git remote add で佐藤さんとこ追加すればいいんじゃね？

gitで、親ブランチ名を調べる方法ってありますか。
たとえば
git checkout master
git checkout -b newfeature1
git commit
git commit
git commit
# ここで現在のブランチがどのブランチから分岐したのか知りたい

目視で構わなければ
git log --graph --format="%h:%d %s"
を適当なaliasにしとく

gitconfigにprettyのデフォルト設定できるよ。

ちなみに、俺はログの後ろに色変えてブランチ名入れてる。
タグとブランチ名で違う色にしたいけど設定なさそうなんだよなぁ。

あとは、tigだっけ？tuiのソフトもある。
ほとんど使ったことはないけどgitkみたいな感じ。

今日初めてタグを付けようと思うんだけど
タグをつけたらpushするの？
それともcvsみたく自動で全員に適用されるの？

AサーバとBサーバで同時に開発していて
Aで修正してcommit、pushした内容を
Bで現在修正中のソースと差分取ってみたいんだけど
どうしたらいい？

git fetch してから git diff FETCH_HEAD すれば差分が見れるけど
fetchせずに見る方法はないの？

git fetch
とだけ打ったとき、なにをfetchしているの？

$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
これの各行の意味がわからない
HEAD -> の行は何を意味しているの？

fetchしたとき、 git branch -a で FETCH_HEAD が
見えるかと思ったけど見えない
FETCH_HEADはどこにあるものなの？

とりあえず、gitは基本すべてローカル作業だとおもえばいい。
だから、pushやfetchの類をしていなければ他のリポジトリと連携はできない。

あとは、濱野氏の入門Gitあたりよんでかから出直してこい。

>>963
ありがとう
でびあんぐるの入門gitは捨ててくるわ

>>964
あとは、git公式にあるドキュメントもあわて読むとより実用的。

/en/のところ、/ja/にすると日本語版がでてくる。
多少内容は違いそうだけど。。。

>>964
一冊の本しか参考にしないってのも良くないぞ
わざわざそういうこと言ってくるのを見ると心配になる

AndroidStudioでgitが使えるということで導入してみたのですがpushの時に
Can't push, because no remotes are defined
とでてpushされません何が原因でしょうか？
git.exeはgithubについてきたものを指定しています

>>967
コマンドのgitの場合で話します。
git cloneでプロジェクトを始めた場合は、clone元がremoteとして自動的に登録されるが、git initで始めたから登録されてないってことじゃないかな。その場合は、git remoteで登録(configに追加)が必要。または、git push時にどのremoteにpushするか選択が必要。

>>968
git initで作っていたようです
一旦全部消してクローンからやってみます

>>969
既存プロジェクトの変更ならcloneだし新規のプロジェクトだとinitなんで
間違えようがないと思うが。

initで作ったのを消さないで、そこからcloneしてみるとか。
そもそもpushする目的が明かされてないが、練習なら上記でいいと思う。
非分散から来た人だったら、pushしなくても履歴管理できていることを理解すべき。

cloneというよりもfetchだろうね
いずれにしても、remoteの使い方は覚えておかないとgit使う意味あんまりないかも。

pushするだけなら都度、相手のリポジトリを直接指定という荒技も無いわけでもない。

既存コードをフォークしてGoogleコードで使った時、初期コミットしなきゃリモートブランチが作成されないから
PUSH+remote+force
とかで強制的にリモートのHEADを書き換えてつかった
コマンドは忘れたすまん

これあんまり語ることないよな

5スレ目の974でいうのもなんだけど

まあ、このまま、質問受付スレでもいいんじゃないかと。
網に掛かった質問を肴に話をふくらませようぜ(笑

なんでfetchしないとリモートとの差分が取れないの？

そりゃどのコミットとの差分かわからないからだろう

Git使い始めてわからないことだらけだから、そのうち質問するので待っててください

>>977
diffとるときにちょくせつリモート指定するんじゃ駄目なの？

次スレ試してくんよ

Git 6
http://toro.2ch.net/test/read.cgi/tech/1369103196/

整ったんで適当に埋めてくんさい

Git

>>979
diffとって確認したあとマージしたいとかの場合を考えると
fetchするまでリモートのブランチのHEADが変わらない方が楽だろ

>>983
なんか、手順おかしくね？
fetchする前のソースにマージなんかしたらあかんだろ。
自分のところに取り込むのは最後の一回だけにするとしても、fetchは必要なだけ随時してもいいとおもうけどなぁ。

>>984
もちろん、fetchしたあとdiffとってマージする話だよ
そのdiffとマージの間に勝手にfetchが行われるとめんどくさいってこと

main lineとするbranchと自分が編集するbranchを分ければいいだけの話じゃね？

>>986
意味がよくわからない
それでお互いのコミットをpullしてくるような作業ができるの？

pushするブランチとfetchするブランチをわけるという話だと思うので変なことをいっているようには思えないけど。。。

>>988
もっと具体的に言ってくれないと、
その2つのブランチ(リモート？ローカル？)をどういう風に使うのかわからないってことさ

リモートのbranchであってもfetchするまでHEADのコミットが不変であるから、
そのリモートのbranch名を指定して問題無くいろいろできる
もし、リモートのbranchのHEADのコミットが常に最新の状態に合わせて変化していくなら、
branch名じゃなくてコミットIDを使う必要がでてくる
そんな面倒なことしたくないから、fetchする方式のままでいいよ

梅

星

>>989
gitの基本として、必要なければ最後までマージしないというのがあるじゃん？

だからリモートのやつは、基本ローカルの編集とは切り離しておいて、pushするときにrebase --ontoとかしてリモートリポジトリのfast-forwardになるようにしてからpushするとか？

そもそも、リポジトリを別に用意しておくとかそういことなのではないかなーと。

スレ埋めに相応しい話題をひとつ

GIF形式の開発者が、GIFの読み方は「ジフ」と断言。長年の論争に終止符
http://hayabusa3.2ch.net/test/read.cgi/news/1369208081/
GIFって「ジフ」って読むよね？まさか「ギフ」とか読んでないよね？
http://hayabusa3.2ch.net/test/read.cgi/news/1369215353/

俺が最初、gitをジットと読んでいた理由がわかったきがする！
gifって普通にジフと読んでいたからなぁ、きっとこのえいきょうだったに違いない。

ghoti←これなんて読むん？

大変おいしくいただきました。ゴチ。

南京虐殺は30万人(キリッ)

南京陥落前の人口は20万人

南京玉すだれ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。