トップページ⇒tech
1001コメント321KB

Git 10

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2014/06/22(日) 17:40:25.81ID:mgZTcG6H
ソースコード管理を行う分散型バージョン管理システム、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/
0083デフォルトの名無しさん2014/07/05(土) 14:29:48.66ID:oA33QTWa
>>82
msysgit のインストールに失敗してるんだろ
0084デフォルトの名無しさん2014/07/05(土) 14:45:31.43ID:oc6wEiev
あれ？もしかしてmsysgitインストールしたらmsysgitってフォルダ作られる？
C:\Program Files (x86)\Git
とは別に？
0085デフォルトの名無しさん2014/07/05(土) 14:57:24.31ID:Q/k3+41v
win7にmsysgitをインストールしたら↓のディレクトリにインスト―ルされたけど、Git Bashもこの中だし

C:\Users\Hiroshi\AppData\Local\Programs\Git
0086デフォルトの名無しさん2014/07/05(土) 15:03:51.27ID:oc6wEiev
そうか…やっぱ失敗してんのかな
500から403に変わってGoogle Codeからは相変わらずダウソ出来ないし
もう少し探してみるか…
ありがとなヒロシ
0087デフォルトの名無しさん2014/07/05(土) 15:16:53.89ID:oA33QTWa
>>86
しばらく前から動かないって言ってるひとか？
インストールに失敗してるんじゃなくて、アンインストールに失敗してるんじゃないか？
ゴミが残ってて新しくインストールしたmsysgitがうまく動かないみたいな感じ
0088デフォルトの名無しさん2014/07/05(土) 15:51:10.99ID:oc6wEiev
うーん
つってもとりあえず『アンインストールとまたは変更』から削除したんだけど
それじゃ足りないのかな？
ゴミがどこに残り得るのかすらわからんのだけど
0089デフォルトの名無しさん2014/07/05(土) 15:59:32.61ID:oA33QTWa
そういうのは地味に調べるか、できなきゃOS再インスコかね
自分もWindowsはよくわからんから、Winでこの手のツールをインストールしまくるのは嫌だね
なので、構成を自分でだいたい把握できてるcygwin版を使ってる
0090デフォルトの名無しさん2014/07/05(土) 20:52:23.99ID:oc6wEiev
なんなのこれ…
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)
0091デフォルトの名無しさん2014/07/05(土) 21:02:46.99ID:Q/k3+41v
お前のwindowsが単にぶっこわれてるだけなんじゃね
0092デフォルトの名無しさん2014/07/05(土) 21:03:11.07ID:oA33QTWa
>>90
それは STATUS_ACCESS_VIOLATION でググルと対策らしいのが出てくるぞ
TEMPフォルダ絡みらしい
0093デフォルトの名無しさん2014/07/05(土) 21:08:28.81ID:oA33QTWa
中途半端にGitのコードにユニコード対応とか入れた影響なんだろうなあ
日本語Win環境なんかじゃ試して無いだろうし
オリジナルのGitがほぼそのまま動くCygwinがやっぱええわ
0094デフォルトの名無しさん2014/07/05(土) 21:20:01.50ID:oc6wEiev
>>92
おぉ、ほんとだありがとう
キャッシュ自体1.5Gもあったしちょうどよかった…
0095デフォルトの名無しさん2014/07/05(土) 21:35:39.83ID:DUJJhZn/
>>93
なんかユニコードがらみで問題でもあったの？
0096デフォルトの名無しさん2014/07/05(土) 21:58:23.52ID:oA33QTWa
>>95
TEMPフォルダにゴミがあると>>90みたいに落ちるらしい
特に日本語ファイル名のファイルとかあるとダメ
Unicode対応前のバージョンなら問題無いとか
0097デフォルトの名無しさん2014/07/06(日) 01:52:41.07ID:2At6bBxp
やっと使えるようになったよ
ありがとう

コミットの概念が、SVNとちょっと違うのかなぁ
また混乱したら聞きにくるよ
繰り返しになるけどありがとね
0098デフォルトの名無しさん2014/07/06(日) 02:22:08.53ID:hcqFkKqd
なんで頑なにPro Gitとかを読もうってしないんだ連中は
0099デフォルトの名無しさん2014/07/06(日) 12:57:28.08ID:IqnhNmsn
ここの先輩って一つのフォルダにどのくらいプロジェクトを詰め込んでるのか教えてください
0100デフォルトの名無しさん2014/07/06(日) 15:24:57.69ID:f2dQpJou
自分も興味ある＞どのくらい詰め込んでるのか

今はSubversionで10くらいのシステムを1システム1リポジトリで管理。
1システム(1リポジトリ)の中で document/client/server/moduleA/moduleB/... と複数ディレクトリを作って管理してる
Gitの場合、systemA-server/systemA-client という単位でリポジトリ作った方がいい？
0101デフォルトの名無しさん2014/07/06(日) 16:16:31.85ID:aXyTuyHi
>>100
ケースバイケースとしか言いようがないけど、Subversionに比べてGitではリポジトリを分けることが多くなった。
っていうか、「フォルダ」と「プロジェクト」って、「リポジトリ」とどういう関係があるのか説明してくれないと上手いこと答えられないかも。

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

Subversionと違って、独立したものをなんでもかんでもリポジトリに突っ込むと別々に開発したときにマージが発生しまくってめんどくさいし、
Subversionでいうところのupdateをかけるフォルダの単位でリポジトリを分けたほうが面倒がないよ。Gitはリポジトリの一部だけを最新にするってことができないから。
0102デフォルトの名無しさん2014/07/06(日) 18:40:54.69ID:8H24GUT0
systemA-serverとsystemA-clientにリポジトリを分けた時なんだけど、
両方で使えるライブラリがあったとする。

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

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

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

まったくgitはよく考えて作られてるよ。
0103デフォルトの名無しさん2014/07/06(日) 18:45:43.21ID:8H24GUT0
それからorphanブランチっていうのも忘れちゃいけないね。

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

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

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

systemA-serverとsystemA-clientに別のリポジトリに分けなくても、
別のリポジトリにわかれているかのように使うことだって出来る。
0104デフォルトの名無しさん2014/07/06(日) 18:50:04.07ID:J6LM3Iar
MavenとかRubyGemみたいな仕組みが利用できる言語なら、
ライブラリをsubmoduleで取り込む必要は無いね
まあでもそういうのが常に使えるわけじゃないからsubmoduleの仕組みを作ったんだと思うけど
0105デフォルトの名無しさん2014/07/06(日) 23:12:18.37ID:5OIsyZ4O
コードを修正するたびにコミットログにupdateって書いてすぐにpushするんですけど
pushってどのタイミングでやってますか？
0106デフォルトの名無しさん2014/07/06(日) 23:23:33.10ID:HJxqGFZE
>>105
テスト合格したらプッシュ
01071002014/07/06(日) 23:58:38.68ID:Jh/5AOzt
>>101-104
ありがとうございます。
知らないこと・未経験なことばかりで勉強になりますm(_ _)m
0108デフォルトの名無しさん2014/07/07(月) 06:17:17.82ID:JBDMezlo
updateなんて意味のないメッセージのコミットは、pushする前に分かりやすくメッセージを書き換えたりsquashしたりした方がいいよ
0109デフォルトの名無しさん2014/07/07(月) 08:35:06.30ID:dSawaSg/
commit はこまめに
完全に動かない時は動かない理由も書いて commit
push は動作確認出来たものを push
どうしても動作テスト通っていないものを push したいときは branch で
0110デフォルトの名無しさん2014/07/07(月) 08:36:37.14ID:iqLntt6B
何回か前の commit のメッセージにスペルミスがあったのに気付きました
恥ずかしいので治しておきたいのですが過去の commit のコメントを治せますか？
0111デフォルトの名無しさん2014/07/07(月) 09:33:06.41ID:sxx7xYnm
俺もそれ知りたいです
そういうときはいつもgit initからやり直してたので
0112デフォルトの名無しさん2014/07/07(月) 09:49:15.90ID:TkAvh2GT
git rebase rewordでググれ
0113デフォルトの名無しさん2014/07/07(月) 11:22:17.68ID:qZJT4lFx
git rebase -i commit~1
って感じ
0114デフォルトの名無しさん2014/07/07(月) 16:51:47.32ID:KZfau/wE
スペルミスにより別の存在する単語になって文全体の意味が違うくなるってなら直す必要もあるかもだが
そうでなく本来のスペルを予測可能な範囲なら大抵はいちいち直さんやろ
0115デフォルトの名無しさん2014/07/07(月) 21:00:46.13ID:rOGGoQLa
subversionもそうだけど、なんでコメントって
気軽に直せないんだろう？

git rebaseでもコメント修正したら
コミットID変わっちゃうし。
0116デフォルトの名無しさん2014/07/07(月) 21:09:20.24ID:eRMueaNX
バージョン管理に関しては気軽に修正できるっていうのは必ずしも良いことではない
Gitは気軽に修正できる代わりにハッシュが必ず変わって修正が明白になるようにした
0117デフォルトの名無しさん2014/07/07(月) 22:03:17.69ID:rOGGoQLa
いや、今の話はソースコードじゃなくて
コミットログの話だから。
さすがにソースコードを気軽に編集できればなんて話はしてない。

気軽に編集できる git notes をなぜ作ったのか？
コミットログを修正できればよかったのではないかって話。
0118デフォルトの名無しさん2014/07/07(月) 22:16:10.15ID:eRMueaNX
コメントの修正も基本的には問題あるよ？
同じバージョンやハッシュでコメントの違うコミットがOKなVCSがあるとして
それらのコミットを先祖に持つ二つのブランチをマージするときどっちのコメントが引き継がれるべきだと思う？

notesはこういうときどんな扱いしてるんだろ
0119デフォルトの名無しさん2014/07/07(月) 22:39:39.79ID:GtUCyZaI
タイポを修正したコミットのメッセージがタイポしてたら死んでも直したくなるだろ
0120デフォルトの名無しさん2014/07/07(月) 22:53:15.16ID:4tIz5IJL
subversionは、コミットログを編集できるよ
0121デフォルトの名無しさん2014/07/07(月) 23:00:28.64ID:eRMueaNX
それはまあ、非分散型だから問題にならないのかな？
分散型の場合にはコメントの編集がコミットを特定するIDとかに反映されないようだと困る
0122デフォルトの名無しさん2014/07/07(月) 23:03:08.44ID:rnTCx4k1
コミットの私物化
0123デフォルトの名無しさん2014/07/07(月) 23:23:04.44ID:YLk007Ty
>>115
> subversionもそうだけど、なんでコメントって気軽に直せないんだろう？

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

git は難しいと思うよ。
A さんと B さんで違う内容に編集したらどうするかとかから決めないとダメだろうし。
0124デフォルトの名無しさん2014/07/07(月) 23:40:30.30ID:aVaaFMZ2
gitはコマンドや引数が複雑化しすぎている
今後登場するバージョン管理システムでこれを克服しなければならない
例えばlogとreflogならgit logとgit log -ref
0125デフォルトの名無しさん2014/07/07(月) 23:41:56.88ID:aVaaFMZ2
統一できるコマンドは統一するのが大事
reflogはlogに吸収させてしまえばいい
そしてコマンドに対する引数もなるべく少なくすること
0126デフォルトの名無しさん2014/07/07(月) 23:42:42.69ID:aVaaFMZ2
gitはphpみたいに汚い
0127デフォルトの名無しさん2014/07/07(月) 23:58:44.89ID:KZfau/wE
BazaarやMercurialとかの他の分散型はgitほと汚くないの？
0128デフォルトの名無しさん2014/07/08(火) 00:04:03.61ID:TkAvh2GT
reword >>126
squash >>125
squash >>124

# The first commit's message is:
汚いレスを圧縮
0129デフォルトの名無しさん2014/07/08(火) 00:18:25.88ID:u9V+tSfl
よくも悪くも Linux なんだなぁと思う。
個人的には FreeBSD + Subversion の方が肌に合う。
0130デフォルトの名無しさん2014/07/08(火) 01:36:57.96ID:hxSm+BQN
コミットログなんて、探すときのヒントなだけで、結局はChangeLogやdiffで確認するだろ。あとはtagとか。
0131デフォルトの名無しさん2014/07/08(火) 01:52:11.38ID:iPzcgb4Q
リポジトリに対するログと、
作業スペースの履歴のログで意味が違うだろ
0132デフォルトの名無しさん2014/07/08(火) 02:06:34.79ID:aM3L01D8
まさに意味が違うという話をしてたんじゃないの？
0133デフォルトの名無しさん2014/07/09(水) 10:21:12.64ID:7mAKqlSH
>>114
fileId を fieId と書いてしまって
field って言う別の存在する単語と見間違えます
どうしたら治せますか？

>>121
コミットのコメントのログをバージョン管理に入れてしまえば良い
0134デフォルトの名無しさん2014/07/11(金) 00:22:31.17ID:sjma/frv
git push -uの-uってなんですか？
毎回-u付けないといけないんですか？
0135デフォルトの名無しさん2014/07/11(金) 00:41:29.05ID:YU+Bm/Jy
>>134
ヘルプくらい嫁
http://git-scm.com/docs/git-push
0136デフォルトの名無しさん2014/07/11(金) 06:25:33.53ID:jWWrmOK/
必要なときは付けろとgitに言われる
0137デフォルトの名無しさん2014/07/16(水) 01:04:59.81ID:1BA7HWeq
PJはSVN使ってるんだけど、諸事情あって今俺が書いてるソースはリリース直前までコミットできない
さすがに不安なんで、git-svnでローカルにだけでもgitとしてコミットしようとしてるんだけど、
git-svnって、TortoiseGitでもできるん？
git自体触ったこともないので、GUIなくてコマンド覚えるのに時間かかるようだったら諦める
0138デフォルトの名無しさん2014/07/16(水) 09:01:10.65ID:7fshRLGV
>>137
TortoiseGitでも出来るが、gitを使ったことがないとちょっと解りにくいかも。
0139デフォルトの名無しさん2014/07/16(水) 09:51:25.74ID:YAHvhD3g
最初TortoiseGitだとできるように見えなかったのが、コマンドでgit-svn使い始めたら
あちこちちゃんと対応してることにきがついたｗ
0140デフォルトの名無しさん2014/07/16(水) 11:03:35.86ID:nVCK3WYF
initial commitってどのタイミングでコミットしたらいいのか教えてください
作るものは掲示板でお考えください
まずファイル構成を決めて空のファイルを作ってコミットするのか
何もファイルが存在しない状態でコミットするのか
ある程度動くものができたらコミットするのか
本当にわかりません
0141デフォルトの名無しさん2014/07/16(水) 11:48:22.12ID:qYDy3YV9
特にセオリーは決まってなかったと思う
わからないなら空commitでおｋかと
0142デフォルトの名無しさん2014/07/16(水) 13:12:44.48ID:dtGU31iT
initial なら 空っぽの RADME.md だけ作って commit てる
とりあえず何か commmit しとかないと diff がエラーになる
0143デフォルトの名無しさん2014/07/16(水) 13:30:32.92ID:Sd4M1rY0
リリースバージョンで1.0と2.3とかつける時のコミットログはなんて書きますか？
git commit -m "Release: 1.0"みたいな感じ？
0144デフォルトの名無しさん2014/07/16(水) 13:45:29.77ID:G80bT3bq
最近はREADMEをマークダウンで書いたりするのか。
0145デフォルトの名無しさん2014/07/16(水) 13:46:33.57ID:G80bT3bq
>>143
tagつけるので、コミットメッセージは気にしない。
0146デフォルトの名無しさん2014/07/16(水) 13:47:41.27ID:YAHvhD3g
GitHub使うとそれがデフォだったりするからな
0147デフォルトの名無しさん2014/07/16(水) 14:05:10.01ID:Hxrp0ywP
GitHubだとリポジトリのリンク開いたときにトップディレクトリのREADME.mdをHTMLに変換して表示してくれるからね
トップディレクトリの一覧の下にそれを表示するんで、トップディレクトリ自体にはあまりファイルとかたくさん置かないようにしとくと更に見やすくて良い
0148デフォルトの名無しさん2014/07/16(水) 14:15:16.78ID:Hxrp0ywP
>>142
一番最初に--allow-emptyで完全空っぽのコミット作ったりすると問題ある？
0149デフォルトの名無しさん2014/07/16(水) 14:19:26.07ID:G80bT3bq
>>146
>>147
なるほろ。githubか。
0150デフォルトの名無しさん2014/07/17(木) 18:11:47.91ID:FWioQIqe
プッシュし終わった跡に間違いに気づいてコミットしなおした
git commit -m "update"
git push
git add -A
git commit --amend -m "update"
ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？
0151デフォルトの名無しさん2014/07/17(木) 18:23:12.64ID:FWioQIqe
なんか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の跡にどうするのが一番良かったのか教えて下さい
0152デフォルトの名無しさん2014/07/17(木) 18:37:46.64ID:5+M8kOpG
>>150-151
そもそも>>150をやってはいけない
pushしたコミットを--amendで直してはいけない

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

push -fをしてもいいのは、push先のリポジトリを自分しか見てないような場合とか、
自分以外の人が見てる場合にはその自分以外の人全員にpush -fする旨の許可を貰えるような場合
0153デフォルトの名無しさん2014/07/17(木) 18:40:00.40ID:FWioQIqe
なるほどそうでしたか
これからはやらないことにします
こういうときって２回目のコミットログはfixとかって書いとけばいいですかね？
0154デフォルトの名無しさん2014/07/17(木) 19:54:07.75ID:5+M8kOpG
>>153
コミットメッセージは何をfixしたとかupdateしたとかまで書いておいたほうがいいと思うけどね
0155デフォルトの名無しさん2014/07/17(木) 21:16:30.65ID:0NORU4KM
チケット駆動とGitの組み合わせで開発するときに
何かするたびにチケット切って、それにあわせたブランチをGitで切って作業する運用って
プロジェクト中盤以降なら修正とか改善の粒度も小さいからしっくりくるんだけど
プロジェクトの何もない最初のほうは、１つの大きな機能の実装に2週間とかかかって、
それのせいでブランチ閉じられずにマージコミットやコンフリクトがあふれてなんかしっくりこない。

チケット駆動してる人は最初からチケット駆動してる？
それとも落ち着くまではmasterに直接コミット突っ込んだりしてる？
0156デフォルトの名無しさん2014/07/17(木) 21:21:35.53ID:iWQxEqkT
>>153-154
--autosquash用のフォーマットの"fixup! 修正先のコミットID"、でいいよ
元々何をしたかったかは直前のコミットメッセージにあるわけだし
0157デフォルトの名無しさん2014/07/17(木) 21:36:45.43ID:OTputfOO
コミットごとにpushするのはやめたほうがいい？
0158デフォルトの名無しさん2014/07/17(木) 21:48:15.42ID:f9EwQ7K8
fixed #1223とかrefs #4643とかだな。
コメントだけではそれが安定か不安定かくらいしか見てない。
ローカルだとadhocとかno testとかもある。
0159デフォルトの名無しさん2014/07/18(金) 00:19:24.35ID:9lilrWED
個人的なリポジトリなら自分が見やすいよう好きにすればいいし
共同のリポジトリなら仲間同士でルール決めてやるほうがよい
git flowやgithub flowあたりのメジャーなやりかたを採用するのもよい
コミットごとのpushがリポジトリを見づらくしてるよう思うのなら仲間と相談してしないようにルールを決めればよい
0160デフォルトの名無しさん2014/07/18(金) 01:07:16.29ID:97CjBc8L
内容書くと、どこまで書くかという程度がそれぞれなので、文句が出る。
0161デフォルトの名無しさん2014/07/18(金) 01:23:55.70ID:fn9HMHhn
>>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になったらメインのリポジトリにマージする。
0162デフォルトの名無しさん2014/07/18(金) 06:26:27.67ID:P4uOsCCD
>>151

>>150 をやってしまったのなら pull してコンフリクトを治して add して commit して push するのが一番良い
0163デフォルトの名無しさん2014/07/18(金) 07:43:45.67ID:NmG7h+bv
>>161
>>151 が聞いているのは
>>150 の状況にならないためにはどうすれば良いのか？ではなくて
>>150 の状況になってしまった場合どうすれば良かったのか？だから
その回答は今回の場合は適切じゃない

あ
でも
>>150 へのレスだからいいのかな
0164デフォルトの名無しさん2014/07/18(金) 08:06:52.12ID:Vkkmxlwy
上書きしないですぐに修正コミット追加するかrevertしてじっくり修正
誰もrevert使ってないのは縛りプレイなの？
0165デフォルトの名無しさん2014/07/18(金) 09:10:39.82ID:fn9HMHhn
>>164
通常のコミットと、マージコミットと二つあるんだよね。

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

とかいう、通常のコミットだけの履歴を作りたいのかと。
こういうのは、機能毎にマージコミットであるべき。
0166デフォルトの名無しさん2014/07/18(金) 19:58:00.50ID:kcaMBvas
SGitってアンドロイドアプリ使ってみたことある人いる？便利なのかな
0167デフォルトの名無しさん2014/07/18(金) 20:58:14.38ID:wFp38Dl6
2.0.2
0168デフォルトの名無しさん2014/07/20(日) 12:13:18.06ID:6LE+xCsK
コミットてどのタイミングでやるべきか教えてください
例えば設定ファイルで設定を書いたらそこで1コミット
0169デフォルトの名無しさん2014/07/20(日) 18:25:37.05ID:k6VJN0Us
はい
0170デフォルトの名無しさん2014/07/20(日) 18:45:06.24ID:OS5ZzYFf
>>168
そんなのローカルルール。
特に分散型は同一プロジェクト内でも、リポジトリごとに違うことも。
0171デフォルトの名無しさん2014/07/20(日) 18:47:28.99ID:llZw+pKm
>>168
後でいくらでも直せるんだから
ローカルでコミットするタイミングは
バックアップとっておきたいと思ったタイミングだな。

一箇所修正したらコミットとかやるときもある。
コンパイルできなくてもやるときもある。

そのあとpushする前に意味がある単位でコミットを作り直すな。
意味がある単位とは言い換えると、コミット一個だけ取り消したいと思う単位とか
誰かにコードを説明する時に「まず○○に関する修正ですが・・・」の単位とか。

意味が無いことはしない。意味があることをする。と考えれば
コミットに分けておくと、何かあった時に便利だなってことに
コミットすればいいんだよ。
0172デフォルトの名無しさん2014/07/20(日) 20:52:14.88ID:zKSe34gp
1〜3回目のコミットをまとめる方法をおしえて
いま10回目のコミットまでしてある
0173デフォルトの名無しさん2014/07/20(日) 22:04:48.48ID:zKSe34gp
mkdir a
touch t.txt
git init
git add -A
git commit -m "ic"
mkdir b
git checkout -f←bディレクトリが残ったままとなる。なぜですか？
0174デフォルトの名無しさん2014/07/20(日) 23:31:18.41ID:667cWtBA
checkout は、リポジトリに登録している物に対して作用する
b は、リポジトリの管理外だから無視する
0175デフォルトの名無しさん2014/07/20(日) 23:36:41.49ID:tRUHKzxS
ってことはいちいちrm -rf * *.*ってやらないとだめそうですね
めんどくせえ
0176デフォルトの名無しさん2014/07/20(日) 23:37:11.83ID:PtZju0so
何のために？
0177デフォルトの名無しさん2014/07/20(日) 23:53:43.91ID:Veyq7Blc
いちからか？
0178デフォルトの名無しさん2014/07/20(日) 23:54:29.30ID:tRUHKzxS
ファイルとかディレクトリを作った後にやりなおしたいんですよ
0179デフォルトの名無しさん2014/07/21(月) 00:21:33.87ID:jb5Wh/p0
追跡されてないファイルやディレクトリを消すコマンドがあるかもね！？
0180デフォルトの名無しさん2014/07/21(月) 00:40:34.84ID:bGaWqmfa
そ、その、、コマンドをどうかおしえてください・・・ガクッ
0181デフォルトの名無しさん2014/07/21(月) 02:42:51.85ID:Udsw+XFD
git clean
0182デフォルトの名無しさん2014/07/21(月) 04:21:43.81ID:DpfIQ25M
ファイルが無い空のディレクトリをpushしたいのですが
addしてもcommitしてもpush出来ません＞＜
■ このスレッドは過去ログ倉庫に格納されています