トップページ⇒tech
984コメント273KB

Git 6

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2013/05/21(火) 11:26:36.94
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - 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/
0175デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
>>174
ドックフードを食べるという訳じゃないが、チュートリアルプロジェクトみたいので
回すのは結構いいかもね。 頭の中身をテキストに落としただけで実際に机上で
すら回したことのないライブラリ管理を押し付けるのは止めてくださいという
プロジェクトは多いからね。
0176デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
難しいと言ってる香具師は選ばれたんだよ
あきらめろ
0177デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
底辺web土方が一番使ってる気がする。
全般的に頭が悪いので高度な機能？は使わないから
こんなにわかりやすくて便利なものはない
0178デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
Gitみたいな分散型VCSを使わないのは
高機能エディタやIDEを使わずにメモ帳でプログラムするみたいなもんだ
0179デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
ちょっと視点を変えると、分散型のVCSを使っていなかった時代はファイルの更新履歴の
管理はIDE等が持つUndoやローカル編集履歴機能に頼る比率がより大きかった気がする。
そういうのは更新内容のコメントが残らないしチームで共有もされない。

コミットの相手はローカルだしブランチを切るのも手軽なのでとにかくコミットが気軽。
記録に残るコメント付きコミットの頻度がサーバー上のtrunkをみんなで突っつくよりも
格段に向上するだけでも分散VCSを使う価値はあると思う。
0180デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
コマンドでたいていのことはできるんだけど
履歴みたり差分みたりするのはツールがないと不便
なんか中途半端なんだよな
0181デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
馬鹿には無理
0182デフォルトの名無しさん2013/08/03(土) NY:AN:NY.AN
馬鹿にもソース管理できるようにするツールだろ
0183デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
cui派だけどtigはあった方がいい
0184デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
正直、Winしか使って無い人にLinuxCUIを教えるくらい難しい。そこがネック。
0185デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
svnの時はコミットするのに慎重になっていたが、gitだとバシバシできて良い。
0186デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
Gif　ジフ
Git　ギット

(´Д｀)？
0187デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
Gimp　ギ・・・ジン・・・ギンプ（小声）
0188デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
>>184
コピペもできないのか。
0189デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
コピペ失敗したときに不安のストレス与えて可哀想だろ
0190デフォルトの名無しさん2013/08/04(日) NY:AN:NY.AN
cogito ergo sum
コギト！
0191デフォルトの名無しさん2013/08/05(月) NY:AN:NY.AN
>>189
コピペしてもエンターする前に見直せるけど、ミスクリックは見直せないね。
0192デフォルトの名無しさん2013/08/08(木) NY:AN:NY.AN
githubが無くても、git使ってた？

サービスたち上げること考えたら、割と他のVCSの方が使いやすくパッケージングされてるように感じた。
0193デフォルトの名無しさん2013/08/09(金) NY:AN:NY.AN
特定のディレクトリ以下のファイルを自動でリポジトリに追加することってできませんか？
0194デフォルトの名無しさん2013/08/09(金) NY:AN:NY.AN
シェルスクリプトを定期的に動かせばいいんじゃないの？
0195デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>193
pre-commt フックとか
0196デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
gitのメリットがいまいちわかりません。
一人でテストケース書かない俺でも使うメリットありますでしょうか。
コードはPHP。

今はdropboxを使って、古いコードに戻してます。

教えてください。
0197デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
メリット:
将来集団での開発に参加したときに恥をかかない。昔svnは今はgitも一般教養。

DropBoxはファイル単位での履歴しか持っていないけれども、gitというか一般論と
してバージョン管理システムはプロジェクト全体のスナップショットの履歴を持つ。
プロジェクト全体を何週間前に動いた状態とかにコマンド一発で巻き戻せる。
(もちろん個別ファイルの巻き戻しも可能)
便利かどうかは別としてVCSを使ったバージョン管理というのはそういうものだから
慣れていて損はない。

単にファイルを巻き戻すだけではなく古いファイルと内容を比較するといった操作
が用意されている。DropBoxだとこれは面倒臭いでしょ。

git的な事情としてブランチベースの開発がし易い。何か新しい機能追加をする場合
はブランチという派生バージョンを作って、そちらを書き換えて、上手く動いたら
メインブランチに変更内容をマージして書き戻すというサイクルを細かく繰り返す。
個人利用であっても複数の開発トピックが同時進行する場合は便利。
そしてブランチベースの開発も一般教養になりつつあるから知らないと恥ずかしい。
0198デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
たかがGit位、知らない奴がいたら教えてやれば済むことだと思うんだけど
Git知らなきゃ恥って思ってる人たちはメディアで饒舌な人たちに
踊らされ過ぎなんじゃ無いだろうかと．．．
Git知ってるからといってそれにいかほどの価値があるというのだろうか
0199デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>198
なんかトラウマあったんだろうな...
0200デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
「（他のを使っているから）Gitを知らない」ならともかくとして

「プログラマーなのにバージョン管理の利点自体を知らない」レベルだと普通に恥ずかしいし、知らない事が恥に値する程の価値は十分有るでしょ
0201デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
どうだろう、例えば独学で凄い3Dグラフィックエンジン作ってた様な人が
仮にバージョン管理システムの存在をこれまで知らなかったとしても
いくらもその人の価値を落とすようなことは無いと思うんだよね
業務でプログラムしてました、これまでバージョン管理とか使ったことありません
みたいな事を想定して恥だと言ってるんだと思うんだけど
個人的に思うのは、世の中で知る価値のある技術的なトピックというのは
ひとりの人間が一生かけても取得出来ない数があるのは明らかで
こう言うなんというか、自分の知ってる10のうちから謎々を出してしか
人の価値を計れないと、自分より優れた人の価値は絶対に計れないだろうなぁと
0202デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
Gitを知っている事に価値があるかはともかく、Gitの類を使った開発に参加する際に
Gitの使い方を知らなければその人は当面無価値だよね。参加できないのだから。

受け入れる側が懇切丁寧親切に教えてくれるラッキーなケースもあるだろうけど、
そういう受け入れる側にしても新しいメンバーに予め期待する予備知識は年と共に
どんどん変化するわけで。

知らんことが出てきたら人に教えてもらう一方で裏では恥ずかしいと危機感持って
自分で学んでキャッチアップするぐらいでないと色々大変だと思う。
0203デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
俺なら git 知ってるとどや顔してる奴より、git のマニュアル渡したら人に聞きながらでも、それなりに使える奴を選ぶわ。
0204デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
どうしてもgitを理解できなくて悔しいんだろうな
有用なプログラムを作れるようなレベルの人はgit程度簡単に使いこなせる
0205デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
> どうしてもgitを理解できなくて悔しいんだろうな

誰のことだろう...
仮想敵作って、一人相撲が趣味なのか？
0206デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
ドヤ顔していようが素直な顔していようが関係無いけどね。
ドヤ顔していたところで抜けている事柄に関しては必ずボロが出るし。

ただボロが出た後で抜けをどう埋めるかの姿勢の差はでかいと思うけど。
自学するドヤ顔と指示待ち素直、どちらを選ぶ?
0207デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
おまえらそんなに他人に教えるのイヤか？ｗ
使い方くらい教えてやれよ、性格悪いな。
0208デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>197
ありがとうございます！
0209デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
ここにいるみなさんはテストケースも書かれてるんでしょうか？

皆さんきっちりしてそう。
0210デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
まあ、VCSの知識は運転免許証みたいなものだ。

みんなが車を走らせる公道に出てくる際は必ず持ち合わせるべきもの。
そしてとるのも難しくない、教習所でちゃんと学べば基本的に誰でもとれる。
ただ最近は道交法の改正で分散型という仕組みが出来たので多少混乱はあるらしい。

就職してからの免許証取得も可能だろうけれども出来れば就職前の取得が望ましい。
運転免許証を持っていてもペーパーだと仕事で必要になった時に困るよね。
0211デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
VCS の知識ぐらい持ってて当たり前だが、会社によって使ってる VCS 違うんだから、就職前に取得とか言われてもなぁ。

そもそも ClearCase なんて個人じゃ買えないしな (w
0212デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
それは就職後にどんな車を仕事用に割り振りられるか解らないから、就職前に免許を取って
適当な車を乗り回すのは無駄だと言う程度には不思議な理屈だなぁ。

応用が利かないので車を乗り換える度にイチから運転方法を覚え直す人ならともかく、普通は
別の車であっても運転経験があれば新しい車もあまり時間をかけずに乗りこなせると思うけど。
仮に仕事の現場で特殊車両に乗る人でも関連作業で普通の車を運転する機会も多いでしょ。
0213デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
っていうかバージョン管理ってそんなに難しいか？
いやGitの機能が奥深いのは分かるけど、普通に使うのに十分なレベルなら
自習でも一週間もかからないだろうし、業務なら簡単なチュートリアル
読んで貰うくらいで十分だろ？間違ってる？
知ってるとか知らないって事が、そんなに問題になるとは思えないんだけど
0214デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
とかいいながら1ヶ月かかっても使えない>>213なのであった
0215デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>212
事前に特定の車両の免許を取れと言ってる奴に言ってやれよ

> Gitの類を使った開発に参加する際にGitの使い方を知らなければその人は当面無価値だよね。

>>213
何か嫌なことでもあったんだろ。
0216デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>215
べつにそれは特定の車両を使っている現場ではその車両を運転できないと無価値だと
言っているだけであって、別にだからその特定の車両の免許を事前に取れと言って
いる訳では無いでしょ。

gitでもhgでもsvnでも、何でも良いから事前にVCSを使った開発経験を持っていれば
仮に他所で他のVCSを使っていても教える方も教わる方も双方共に楽が出来る。

そしてその中から何を選ぶかと問われれば、昔svn今ならgitはリーズナブルな選択
だと思うけれどもね。現場で使う頻度云々もあるけれども、今は公開リポジトリを
利用するのにもこの二つは広く使われるなど応用も広いと思うのだけど。
0217デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
バージョン管理システム自体は簡単でもバージョン管理そのものはプロジェクト管理と
関連するから単純な作業じゃないよね。
0218デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>216
>その特定の車両の免許を事前に取れと言っている訳では無いでしょ。

>> Gitの使い方を知らなければその人は当面無価値だよね。

君は、Git の前に日本語覚えるべき
0219デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>218
日本語以前の問題で、理屈をちゃんと踏まえる習慣をつけないとプログラミングの
世界では不味いと思うよ。

「無価値だよね」から「特定の車両の免許を取れ」と勝手読みするのに至るまで
いくつの理屈をすっ飛ばしたのかな。
0220デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>210
例えがうまいな

ただ、自転車で十分！！とかいって道路走って信号無視してる奴が迷惑なんだよ！！w
0221デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>220
あと基本的な運転技術自体は座学や教習所内の運転コースで学べるのだけれども、実際に
公道で周囲の車の流れにのって運転するには隣に指導員が乗った路上講習や免許取得後に
実際に他の車の集団が走っている中を運転して場数を踏まないことには如何ともし難い
のもどことなく似ている。
0222デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>196
行ごとにいつ、どうして変更したかわかるようになるよ。
>>198
今まで教えてすぐ使いこなせた奴はいなかったな。やはり習熟が必要。
0223デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>219
　　　　　　git の知識が無いのは無価値 ⇔ 無免許
　　　　　　　　　↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
特定の VCS (git) について知識を得とけ ⇔ 特定の免許を取っとけ

引っ込みつかなくなっているだけならまだしも、マジでこれぐらいの論理が組み立てられないと、この業界だと辛くないか？ (w
0224デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>223
横方向のアナロジーは解らないでもないし、一生懸命視覚化しようとした努力は
買うけど。

> git の知識が無いのは無価値 -> 特定の VCS (git) について知識を得とけ

誰も書いていないじゃん。「Gitの類を使った開発に参加する際にGitの使い方を
知らなければ」という自分で引用した仮定すらすっ飛ばしているし。

0点。
0225デフォルトの名無しさん2013/08/10(土) NY:AN:NY.AN
>>224
そんなレスしてて楽しいの？

傍から見ると、可哀想にしか見えないんだけど。
0226デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
>>192
> サービスたち上げること考えたら、割と他のVCSの方が使いやすくパッケージングされてるように感じた。

ネット越しでも共有フォルダ使うならなんもいらないし、
httpでもapacheにgit-http-backendのリンクを食わせるだけで
超お手軽だろ?
0227デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
Githubのスレが見当たらないんですけど、Githubの質問はスレ違いなんでしょうか。

あるプロジェクトを自分のリポジトリにフォークして、自分のフォークリポジトリに少しずつチマチマとコメントつけてコミットしてるんですが、
それを元のリポジトリに、毎回のコメントごとコミットってできるんでしょうか？


つまり、
コミット "初回"
コミット "2回目。○○を直しました。"
コミット "3回目。■■を直しました。"


とフォークしたリポジトリにコミットしたのを元のリポジトリに

コミット　"フォークからのコミットです"

とまとめてコミットではなくて

コミット "フォークからのコミットです。初回"
コミット "フォークからのコミットです。2回目。○○を直しました。"
コミット "フォークからのコミットです。3回目。■■を直しました。"



としたいんですが
0228デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
Githubの質問じゃないし
0229デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
gitって有料ばかりだけど皆有料プラン使ってるの？
フリーでコードを公開ってのもあれだけど、有料プランの出費もいたいなぁ。
0230デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
>>229
gitは基本無料ですよ
0231デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
>>230
ありがとうございます。
無料だとコードを晒さないといけませんよね？
俺の作ったコードなんて誰も触らないでしょうけど。
0232デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
俺もコード晒さずにただで使ってるよ。git。
0233デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
>>231
まず、git とgithubは異なるものね
で、github について言えば、無料なら晒さなければならないのはその通り
それが嫌なのであれば、git+dropbox とか、bitbucket とか代替案はいろいろとあるよ
0234デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
gitとgithubを勘違いしてないか
0235デフォルトの名無しさん2013/08/11(日) NY:AN:NY.AN
232,233,234
ありがとうございます。
同じものだと思ってました。
ググってみます！
0236デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>どうだろう、例えば独学で凄い3Dグラフィックエンジン作ってた様な人が
>仮にバージョン管理システムの存在をこれまで知らなかったとしても
>いくらもその人の価値を落とすようなことは無いと思うんだよね

言ってることは理解出来るが
一緒に仕事したくないタイプ
0237デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>236
俺は、お前を排除するね
0238デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>237
俺は、おまえを虐めるね
0239デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
>>238
もっと〜もっと〜
0240デフォルトの名無しさん2013/08/12(月) NY:AN:NY.AN
どうぞどうぞ
0241デフォルトの名無しさん2013/08/13(火) NY:AN:NY.AN
lolcommitsって真面目に使っている人っているのかなw
http://mroth.github.io/lolcommits/
0242デフォルトの名無しさん2013/08/13(火) NY:AN:NY.AN
lolcommits
約 3,370 件 （0.23 秒）

使ってないでいいんじゃね？
わざわざこれがなにか調べる気も
しないけど
0243デフォルトの名無しさん2013/08/18(日) NY:AN:NY.AN
せっかく来たのに
まだ決定打的なGUI出来てないの
また明日こよ
0244デフォルトの名無しさん2013/08/19(月) NY:AN:NY.AN
>>243
頑張ってください！
応援してます！
0245デフォルトの名無しさん2013/08/20(火) NY:AN:NY.AN
永遠に明日を待ち続けるのであった
0246デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
無いなら俺が作ると考えない奴に明日はかおない
0247デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
かおないパワー！
0248デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
gitconfigでaliasに
log = log --date〜
みたいな感じで書いたんですが
デフォルトのlogで表示されます

l = log --date〜
って書くと反映されました

aliasでlogが反映されないのはなぜですか？
0249デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
>>248
仕様です
> To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored.
0250デフォルトの名無しさん2013/08/29(木) NY:AN:NY.AN
そうだったんですか！
わかりました！
0251デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
間違えてIDとパスワードを含んだコードを間違えてあげてしまったので、
至急ローカルでコードからIDとパスワードを削除して
git add -A
git commit -m "IDとパスワードを消した"
git push origin master
ってしたんですが
githubの履歴にはIDとパスワードが入ってるコードが閲覧できてしまいますよね
こういう場合はどうしたらいいでしょうか？

やり方がわからずリポジトリごと消してるので一応被害はありません
0252デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
testブランチを切り替えるのを忘れてしまい、masterブランチでコードを編集してしまったのですが
この場合、.
編集したファイルを別のディレクトリにバックアップ
↓
git checkout -fで元に戻す
↓
git checkout -b testでtestブランチに切り替える
↓
バックアップしたファイルで元のファイルを上書き
という流れで解決はしたのですが、ものすごい面倒くさいです

以下の3つの状態それぞれのケースでもっとよい方法がございましたらどうか伝授してください
１．git addする前
２．git addした後
３．git commitした後
0253デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
commit --amend
push --force
0254デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
commit 前なら git stash save; git checkout xxx; git stash pop で大体おｋ。
commit してしまったら git reset HEAD^ でひとつ戻ってから同様にやればいい・・・と思う。 たぶん。 きっと。 おそらく。
0255デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
1.2. stash -> checkout test -> stash pop
0256デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
githubで自分のリポジトリでpull requestを送る練習をしてるんですが
branchはmasterじゃないほうがいいということなんですが
branch名は他の人とかぶらない様なネーミングをつけておいたほうがいいですか？
もし他の人とbranch名がかぶったらコンフリクトになっちゃいますよね？
0257デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
ブランチ名はリポジトリローカルなので、被ってもOK
自分のリモートとローカルでも別の名前使えるよ
ただ自動で生成されるコミットメッセージに出てきて紛らわしいので、意味のある名前が推奨されてる
0258デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
>>256
自分のリポジトリにpushして自分にpull requestするならブランチ名は重なってちゃまずいと思うけど
forkしたリポジトリにpushしてオリジナルのリポジトリにpull requestするなら、
ブランチ名の重複は考えなくていいんじゃないの？
02592512013/08/30(金) NY:AN:NY.AN
>>253
>>254
>>255
これのうちぼくへの暖かい回答はどれですか
0260デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
自分で判断したまえ
0261デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
まあ、問題のない世代からブランチを作り直してmasterを別のものにするしかないと思う。
編集履歴なくってしまったら、バージョン管理にならなしね。
pullしている人には事前の連絡を忘れずに
0262デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
おいおい。消す方法あるぞ。ちょっと待ってろ。
0263デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
stashという便利なコマンドがあるんですね！勉強になりました
0264デフォルトの名無しさん2013/08/30(金) NY:AN:NY.AN
>>251

Gitポケットリファレンス
http://www.amazon.co.jp/dp/477415184X

の71ページに書いてある。
まさにコミットしてはいけないパスワードファイルをコミット
してしまった場合の対応。

git filter-branchコマンドを利用するらしい。
更にその後reflogも消すためにgit gcを行う。

細かいやり方は書くだけでも面倒くさいので
本を見るか、ぐぐってくれ。
0265デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
>>251
こういうのってどうやって管理するのがいいの？
gitでコミットするファイル内では別ファイルを読み込む形にして、その別ファイルは.gitignoreに追加するのとかいいかなと思うんやけど。。
oauthライブラリ作ってて同じことやったことある
0266デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
>>262
これかぁ。
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88

知らなかったや。
結果的には、同じになりそうだけれど、filter-btanchだと、他のブランチにも影響してくれるみたいだね。

>>265
本物のデータファイルを管理下に配置するのが間違いだと思う。
あと、個人的には、addのとき手抜きしないとかかなぁ
GUIだと難しそうだけど。。。。

#久しぶりに規制とれたさて、いつまで持つやら
0267デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
password.yml はリポジトリに入れない。
間違ってコミットしないように、.gitignoreに指定しておく。
代わりにpassword.yml.sample をリポジトリに入れる。
0268デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
>>264
宣伝成功！！！！！
0269デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
コミットをするタイミングがわかりません
やっぱり仕事でやるならコミットもきれいにしないといけないのでしょうか？
ちょっと更新したらコミットとかやめるべきですか？
0270デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
>>269
細かい更新でコミットするのは問題ない
むしろやった方がいい。

コミットは単なるファイルセーブじゃないんで、
コミット＝アプリが正しく動く状態にしないといけない。

でかい機能追加であっても、正しく動く状態を保ちつつ
小さい修正を繰り返して開発できるはず。
その小さい修正ごとにコミットする。

リモートリポジトリに送信しない限り
歴史は自由に書き換え可能なのだから
最終的にバグやミスがないコミットの連続になる。

これを開発用のブランチで行う。
最終的にmasterにマージするときに
一つのコミットにまとめるかどうかは方針次第。
0271デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
俺は動かない状態でも一時的な作業用のブランチ作ってコミットするのはよくやる (workとか、それとわかりやすい名前がいい)
動く状態になったらちゃんとしたブランチに merge --squash して作業ブランチ削除、みたいな感じ
0272デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
履歴に残さない一時的なコミットなら
どうでもいいよ。
0273デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
全プッシュ！
全プッシュ！
0274デフォルトの名無しさん2013/08/31(土) NY:AN:NY.AN
へ？git push 以外になんか引数必要だっけ？へ？
■ このスレッドは過去ログ倉庫に格納されています