Git 6
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/05/21(火) 11:26:36.94Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://progit.org/book/ja/
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/
0360デフォルトの名無しさん
2013/09/12(木) 21:25:25.46fetch? pullじゃなくて？
0361デフォルトの名無しさん
2013/09/12(木) 21:28:16.000362デフォルトの名無しさん
2013/09/12(木) 22:35:46.28svnを使い慣れた人間にgitを使わせる場合には、gitとしての使い方を教育せずに
gitを使わせるような奴はそいつが悪いってことになる。
0363デフォルトの名無しさん
2013/09/12(木) 22:50:22.66何で?
自分は満足なんだけど、誰も使ってないみたいだから大きな穴があるんじゃ
無いかと気になってる。
0364デフォルトの名無しさん
2013/09/12(木) 23:00:32.67それは単純にsvnだけ、gitだけを使うよりも難しい作業を強いられることになる。
gitのノウハウにもgit-svnを使った例は少ない。
github及び、githubクローンであるgitlabを使うときどうするのかよくわからない。
何をするにも、gitだけだとこうやるけど、そこにgit-svnがくると・・・などという話が
いつまでも付きまとってくる。
穴があるというよりも大変。
0365デフォルトの名無しさん
2013/09/12(木) 23:05:01.67自分も使ってるけど、今のところ運用で詰んだことはないな。
0366デフォルトの名無しさん
2013/09/12(木) 23:09:50.78開発では？
gitの特色である開発中にいくつもブランチ作って
幾つものブランチを切り替えて
歴史を修正しながら、小さな修正で
開発するってことが普通に出来るの？
0367デフォルトの名無しさん
2013/09/12(木) 23:15:25.90cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。
gitの場合、pushをcommit、pullをupdateに置き換えてかんがえれば、svnからの移行もしやすいんじゃないかな。
gitはあくまで、ローカル作業がより便利になっただけだよ。
0368デフォルトの名無しさん
2013/09/12(木) 23:22:43.70そうなんだよな。
ソースコードはサーバーで一元管理するもの。
逆に言えば、ローカルにあるものはソースコードの管理というよりも
開発そのもの。だからgitは開発がより便利になる。
ステージングとかいいよ。
開発してる時に、小さなミスを見つけて、それだけコミットしたいと思うだろう？
gitなら、git addでファイルの ”一部分” だけをステージング（ようはコミット予定リスト）し
あちこち修正途中のファイルがあったとしても、簡単にファイルの一部分だけをコミットすることができる。
svnだったら開発中によくある面倒なことを
gitであれば楽にこなしてしまう。
0369デフォルトの名無しさん
2013/09/13(金) 00:00:07.94エラーの出る状態から作り直して失敗したらどうするんだ。
svnでもブランチとか適切に運用できていればいいんだろうけど。
0370デフォルトの名無しさん
2013/09/13(金) 00:18:00.21gitでもエラーの出る状態で入れないでよ
0371デフォルトの名無しさん
2013/09/13(金) 00:19:09.17エラーが出る状態でもいいかな。
0372デフォルトの名無しさん
2013/09/13(金) 00:34:16.73作業途中でコミットするのが納得できんな
単に途中経過を保存したいならstashがあるし
途中経過を他の人に見てもらいたいならMLや掲示板とかの方がいいだろう
0373デフォルトの名無しさん
2013/09/13(金) 00:39:20.59stashはpopという引数があることからもわかるように
スタックという考え方が基礎になってるんだ。
作業途中の割り込み、の割り込み、の割り込み
といった用途で使うもの。
作業途中のコミットは、
いくつかの作業を並行して行っている場合に使う。
Aという作業をやっている途中で、
Bという作業をやってさらに
Cという作業に移ってAという作業に戻る。
と思ったら、Cという作業を進めなくてはならなくて
次はBみたいな。
0374デフォルトの名無しさん
2013/09/13(金) 00:54:59.34時間が経つとstashしておいた事実を(俺が)忘れてしまう
作業が割り込む場合は作業ブランチ切ってコミットしてる
0375デフォルトの名無しさん
2013/09/13(金) 00:59:35.14それはロックの本質をわかってない
0376デフォルトの名無しさん
2013/09/13(金) 01:16:04.64あとでそのエラーになった修正を使いたくなるかも知れないじゃないか。
それにチケットと関連付ける時にソースもあった方がわかりやすい。
公なとこにpushするなら、その前にまとめればいいだけだし。人のローカルリポジトリに口出しするとか、わけわからんわ。
0377デフォルトの名無しさん
2013/09/13(金) 01:16:57.330378デフォルトの名無しさん
2013/09/13(金) 01:24:20.08っ鏡
0379デフォルトの名無しさん
2013/09/13(金) 07:30:06.930380デフォルトの名無しさん
2013/09/13(金) 08:58:47.04手元でずいぶん変更したけど まだビルド通らない/テスト通らない/バグが直りきってない ときにコミット我慢するの？
途中まで実装したけどやってみると案外うまくいかないな。もう一つの案をで実装してみるか、ってときにその瞬間のコードをコミットしないの？
0381380
2013/09/13(金) 09:15:18.83svnと同じタイミング・粒度でしかコミットしないという使い方も否定されないとしても、厳しすぎる制約を自ら課しているんだというのは認識しといた方がいいよ
0382デフォルトの名無しさん
2013/09/13(金) 09:20:31.22作業途中ならstashで保存する
これがベストな方法とは言わないし
他人のローカルリポジトリに口出しする気もないが
少なくとも作業途中でコミットする必然性はない
0383380
2013/09/13(金) 09:24:23.050384デフォルトの名無しさん
2013/09/13(金) 09:24:56.57手元に巨大な変更を抱えてて作業コピーの日付バックアップを一生懸命とってるの
0385デフォルトの名無しさん
2013/09/13(金) 09:29:58.54git checkout master
git merge test
git add -A
git commit -m "ちょめちょめ"
git push
この流れで合ってますか？
0386デフォルトの名無しさん
2013/09/13(金) 09:55:25.36Gitでは「まだ完成してない」とか言ってpushしない奴ということになるわけですね
0387デフォルトの名無しさん
2013/09/13(金) 09:57:59.86自由ってのは便利だが、一定のルールで遵守させなければならないと。
0388デフォルトの名無しさん
2013/09/13(金) 10:07:57.29git add -A は何をやってるの？
0389デフォルトの名無しさん
2013/09/13(金) 10:21:23.57gitでも「まだ完成してない」と言ってコミットしないよ。きっと。
という今の流れ。
gitはそれこそstashみたいな、コミットしない自由も考慮されてるとは思うけど程度問題だな。
無闇にコミットを避けることはない
0390デフォルトの名無しさん
2013/09/13(金) 10:22:55.14あれなんですよ
git add .
ってやると、なんかたまにgit add -A使えってメッセージが出るのです
0391デフォルトの名無しさん
2013/09/13(金) 10:28:03.32git add . は何のためにするの？
＞testブランチでコード書いた後
これはtestブランチで書いたコードをtestブランチへコミット済みって意味？
0392デフォルトの名無しさん
2013/09/13(金) 10:28:38.23> cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。
アホすぎ (w
チームにこんな奴いたら大変だろうな
0393デフォルトの名無しさん
2013/09/13(金) 10:29:15.20masterブランチに移ってからaddします
0394デフォルトの名無しさん
2013/09/13(金) 10:33:52.76何のためにtestブランチを作ったの？
0395デフォルトの名無しさん
2013/09/13(金) 10:40:32.810396デフォルトの名無しさん
2013/09/13(金) 11:03:05.11gitってそういう思想じゃないから無理だよね・・・
どうしようかな
0397デフォルトの名無しさん
2013/09/13(金) 11:14:25.460398デフォルトの名無しさん
2013/09/13(金) 12:32:33.83>>366
できるよ。自分だけだけど。
0399デフォルトの名無しさん
2013/09/13(金) 12:50:29.91ファイナルちょめちょめの後でmasterへマージ
0400デフォルトの名無しさん
2013/09/13(金) 13:14:13.68たとえば、git commit ってしたらc:\my.logに日時を記録する感じの機能をgitに組み込むなど
0401デフォルトの名無しさん
2013/09/13(金) 14:11:16.050402デフォルトの名無しさん
2013/09/13(金) 19:15:58.040403デフォルトの名無しさん
2013/09/13(金) 20:56:48.98いまどきのIDEだとローカルの作業履歴位はとってくれてるんだけどね。
コミットコメントが有るわけじゃないから何をやってたか分からないけど
ローカルの作業履歴としては割りと機能する。 テキストエディタ以外は
認めないって人には分からないだろうけど。
0404デフォルトの名無しさん
2013/09/13(金) 21:39:01.300405デフォルトの名無しさん
2013/09/13(金) 21:52:13.00gitのコミットログを見ればいいだけじゃん？
なんでわざわざ別に出力すんの？
0406デフォルトの名無しさん
2013/09/13(金) 22:44:41.16エディタの編集履歴が便利なことは否定しないが、複数ファイルのスナップショットに名前をつけて保存できる機能とは区別しようぜ
0407デフォルトの名無しさん
2013/09/13(金) 22:55:30.79git-svnだとマージに非常に制限がかかる。
そうなるとコンフリクトを恐れるようになって、いちいち手が止まってしまいストレスになる。
0408デフォルトの名無しさん
2013/09/13(金) 22:59:55.68あるんだが、原因を調べるには何を調べればいいかな？
表示されるエラーメッセージはInvalid Argumentとかearly EOFとかだけなんで意味わからん。
0409デフォルトの名無しさん
2013/09/13(金) 23:20:49.680410デフォルトの名無しさん
2013/09/13(金) 23:21:47.67よく知らんのだけどrebaseじゃダメなの？
0411デフォルトの名無しさん
2013/09/14(土) 00:15:42.09分散型だと中央を通さずに変更を渡すことが簡単だから、一部にだけ変更を伝えるという方法もあるね。
分散型はまだまだ色々な使い方ができそう。まあ運用を決めてもらわないと何もできない人には制限された方がいいんだろうけど。
0412デフォルトの名無しさん
2013/09/14(土) 00:16:03.03dcommit時にコンフリクトするとどうなるの?
いつもrebaseしてからdcommitしてたから、意図せずマージになってたことは
ほとんど無くて、コンフリクトしたことがない。
0413デフォルトの名無しさん
2013/09/14(土) 00:40:38.03rebaseあんまり使わないから向いてないのかも。
他のブランチでは気にせずgitらしくマージを繰り返してそれを中央リポジトリで公開して、いざsvn用のブランチに取り込もうとしてrebaseではまることが多かった。
0414デフォルトの名無しさん
2013/09/14(土) 00:44:26.35それを上に持ってくんな ということを言っている。
0415デフォルトの名無しさん
2013/09/14(土) 00:48:55.250416デフォルトの名無しさん
2013/09/14(土) 00:57:23.13git config --global core.compression -1
でどうでしょう
0417408
2013/09/14(土) 07:24:34.77それが、付けてもなんもわからなくて。
せめて、何に渡した何というArgumentがどうInvalidなのかくらいわかればいいんだが。
>>416
よくわからんが、エラーが出た箇所からすると関係ありそうな気がするな。
環境は会社なんで週明けに試してみるわ。ありがとう。
0418デフォルトの名無しさん
2013/09/14(土) 09:18:19.06なんか自動化したいんだろ
0419デフォルトの名無しさん
2013/09/14(土) 10:29:28.80rebase しないと dcommit できないんじゃないか。
0420デフォルトの名無しさん
2013/09/14(土) 10:42:48.85dcommit時にマージされます。ローカルからはそう見える。
svn上では、update→commitに見えると思う。
0421デフォルトの名無しさん
2013/09/14(土) 14:16:33.20複数人へのgit教育用にコミットしているかをひとつのログに集めたいから
0422デフォルトの名無しさん
2013/09/14(土) 22:52:16.95㌧
自分が使ってた当時、怒られた記憶があったんだが。
0423デフォルトの名無しさん
2013/09/14(土) 23:55:50.48コンフリクトした場合という話の流れを見逃してた。
コンフリクトした場合はどうなるかやったことがありません。
しなければマージされます。
0424デフォルトの名無しさん
2013/09/15(日) 07:40:17.91svn rebaseはrebaseもしている
最新リビジョンの先にしかコミットできないのと
svnのコミットにハッシュ振る必要があるので
ここでコンフリクトした場合確か無名ブランチに飛ばされるはず
自分はdevブランチ上で解決するようにしてるからあまり見たことないけど
共有がgitでも共有リポジトリの歴史いじることは推奨されてない気がするから
運用は似たようなもんじゃないの
？
0425デフォルトの名無しさん
2013/09/15(日) 09:35:25.121.0まで作ったとします。コミットもプッシュもたくさんやってきました
そしてバージョンアップさせていき2.0になりました
そこで質問です
やっぱりバージョンが違う場合でも同じリポジトリにコミットとプッシュするほうがいいのでしょうか？
あとバージョンごとにブランチは分けたほうがいいでしょうか？
0426デフォルトの名無しさん
2013/09/15(日) 09:44:38.260427デフォルトの名無しさん
2013/09/16(月) 16:48:00.63git logで誰がいつcommitしたか残ってるけど？？？
0428デフォルトの名無しさん
2013/09/16(月) 18:34:00.170429デフォルトの名無しさん
2013/09/16(月) 18:38:41.35.git/hookでできるんじゃないの
拡張じゃなくて組み込まれてる機能だけど
0430デフォルトの名無しさん
2013/09/19(木) 23:11:39.01Cドライブでコードを書いて、Dドライブをgithubの代わりとしてここにpushしたいのですが
こういう場合って、Dドライブのほうでgit init --bareってやってから
Cドライブ側でgit clone ～ってやるべきでしょうか？
0431デフォルトの名無しさん
2013/09/19(木) 23:50:18.12既に存在するプロジェクトのフォルダに対して
git init
git add .
git commit -m "comment"
を実行した場合、.gitフォルダにこれまでのバージョンが記録されていって、
いざとなれば、巻き戻せたりするんですよね？
0432デフォルトの名無しさん
2013/09/20(金) 00:17:54.09目の前の箱で試してみろ
0433デフォルトの名無しさん
2013/09/20(金) 00:20:17.14試してますが自身がないんです
0434デフォルトの名無しさん
2013/09/20(金) 00:44:10.93ローカルリポジトリ無くても
使えるものなの？
0435デフォルトの名無しさん
2013/09/20(金) 00:58:24.60ただしいつもgit cloneしてから、add, commit, pushしています。
0436デフォルトの名無しさん
2013/09/20(金) 01:10:41.71あっそ。
0437デフォルトの名無しさん
2013/09/20(金) 22:25:18.510438デフォルトの名無しさん
2013/09/20(金) 22:27:49.100439デフォルトの名無しさん
2013/09/20(金) 22:31:10.14gitとgithubの違い分かってる？ チーズとチーズケーキくらい違うよ。
0440デフォルトの名無しさん
2013/09/20(金) 22:34:11.91テヘ
0441デフォルトの名無しさん
2013/09/20(金) 22:35:10.100442デフォルトの名無しさん
2013/09/20(金) 22:42:24.200443デフォルトの名無しさん
2013/09/20(金) 23:03:11.09gitがあればいいのによくわらないけど
0444デフォルトの名無しさん
2013/09/20(金) 23:15:24.16ケーキとケーキ屋くらい違うと思うな。
試しに作った初めてのケーキをケーキ屋に並べるとか、恥ずかしすぎる。
0445デフォルトの名無しさん
2013/09/20(金) 23:22:06.350446デフォルトの名無しさん
2013/09/20(金) 23:30:59.55男だけど
0447デフォルトの名無しさん
2013/09/20(金) 23:41:06.57GitHub側が禁止してんならともかく何でもうｐしてけ
0448デフォルトの名無しさん
2013/09/21(土) 00:33:50.50今HelloWorldのリポジトリを削除していってるよ
0449デフォルトの名無しさん
2013/09/21(土) 01:07:54.680450デフォルトの名無しさん
2013/09/21(土) 16:52:31.32ファイル編集
git add .
git commit -m "コミットします"
git push
でgithubにtestブランチができます
ここで「はっ！」と気づいたのですが、間違えてtestブランチにpushしてしまいました
testブランチじゃなくてmasterブランチにpushしたかったのですが、ここからどうしたらいいでしょうか？
0451デフォルトの名無しさん
2013/09/21(土) 16:54:50.560452デフォルトの名無しさん
2013/09/21(土) 16:55:42.260453デフォルトの名無しさん
2013/09/21(土) 16:57:38.23--graphで表示したものを逆順に表示する方法ありませんか？
0454デフォルトの名無しさん
2013/09/21(土) 17:00:32.88そのままmasterにマージしてpushすればいいんじゃね
0455デフォルトの名無しさん
2013/09/21(土) 17:08:11.83○バージョン管理システムなんだから間違った状態も保存される。
間違った状態そのものを完全に履歴から抹殺するのは非常手段。
0456デフォルトの名無しさん
2013/09/21(土) 17:10:59.62そのままpushしたら
To git@～.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'git@～.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
ってなりました
0457デフォルトの名無しさん
2013/09/21(土) 21:07:39.45Pull Requestが来たんですが、内容の一部だけ採用して、他の部分は今までの自分のでいきたい、
という場合はどう処理すればよいのでしょうか？
0458デフォルトの名無しさん
2013/09/21(土) 21:09:17.870459デフォルトの名無しさん
2013/09/21(土) 21:10:46.12コミット分けろボケって言っとけ
で、全部マージするんじゃなくて好きなやつだけcherry-pickするとか
■ このスレッドは過去ログ倉庫に格納されています