トップページ⇒tech
983コメント406KB

Git 12©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net2015/03/23(月) 13:35:13.83ID:aBYp+bVs
ソースコード管理を行う分散型バージョン管理システム、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 11
http://peace.2ch.net/test/read.cgi/tech/1416195050/
0797デフォルトの名無しさん2015/07/14(火) 13:07:53.62ID:VxoBFrok
>>796
運用のことを考え出したら初心者じゃない。
コマンドなんてあとから覚えりゃいいんだよ。

運用があって、それに必要なものを作ったのが
gitなんだから。
0798デフォルトの名無しさん2015/07/14(火) 13:20:00.15ID:G0PBqp91
初心者はコマンドを先に覚えた方が良い。
でないと、話が通じない。
ある程度使って、具体的に困ったところが出てきたら、運用スレで聞けば良い。
ただしあっちは関係無い話に脱線しがちだから、良いとこ取りした方が良いよ。
0799デフォルトの名無しさん2015/07/15(水) 23:09:43.18ID:a+rEGmf6
すいませんgitでコミットするときにこのファイルは何で更新したのか思い出せません。
なので、これから更新する内容は「○○機能を実装」ってことでそれをプロジェクトルートのテキストファイルにメモ書きしてました。
しかし、コミットするときに毎回メモを見るのを忘れてしまいます。
再帰にコミットログを書いとくとかなんかtodoみたいなコマンドってありませんか？
0800デフォルトの名無しさん2015/07/15(水) 23:10:19.62ID:a+rEGmf6
訂正
☓再帰にコミットログ
○先にコミットログ
0801デフォルトの名無しさん2015/07/15(水) 23:21:39.17ID:YpeXwOwK
>>799
> それをプロジェクトルートのテキストファイルにメモ書きしてました。
いますぐそのようなアホなことを辞めましょう。
0802デフォルトの名無しさん2015/07/15(水) 23:22:13.29ID:VsrdjrWK
前回との差分見ながらコミットログ書けばいい
あらかじめ用意しておくから忘れるんだ
0803デフォルトの名無しさん2015/07/15(水) 23:44:52.69ID:DsRhlYqB
自分が今なにをしてきたか忘れるのか、
よっぽどコミットを溜めるのか、
コミットのコメントが適当すぎるのか

もうバージョン管理以前の問題な気が
アナログだけど付箋にメモしてディスプレイに貼れば？

左がこれからやること、上部が今やってる事、右が終わった事、
いや右は要らんかな？
0804デフォルトの名無しさん2015/07/16(木) 00:52:26.73ID:Ye9E1FJD
>>799
自分が差分を見て理解できないコードをコミットしちゃダメだよ
0805デフォルトの名無しさん2015/07/16(木) 02:04:46.85ID:C5QhjRoF
git notes とかはどうかな？
0806デフォルトの名無しさん2015/07/16(木) 04:35:55.01ID:MREKRM2C
>>804
差分ってたまに直観的じゃない出力することが良くある
0807デフォルトの名無しさん2015/07/16(木) 07:52:03.14ID:SnFgv9L8
git diffの表示範囲を広げるオプションは？
0808デフォルトの名無しさん2015/07/16(木) 08:04:35.28ID:SnFgv9L8
>>799
githubとかRedmineとかticket/issue管理ツールと併用するのが一番だけど、1人で使うのだと構築するのが大変かもね。

メモをgit管理されていれば、メモの差分もgit diffで出るよね。なので、commitする前に必ずgit diffしていればメモを見るのを忘れることはないはず。
このやり方をする/しないにかかわらず、commitする前にgit diffをするのは大事だから習慣付けるべきだよ。
0809デフォルトの名無しさん2015/07/16(木) 09:31:42.39ID:NYNU6iM6
変更するたびにコミットしといてpushやmerge前にamendなりrebaseで整形すればよくない？
0810デフォルトの名無しさん2015/07/16(木) 12:26:35.31ID:WO54leEH
>変更するたびにコミット

コンパイル出来ないものをコミットするメリットは？
0811デフォルトの名無しさん2015/07/16(木) 12:32:11.52ID:DSiPnBiQ
コンバイル云々より下のレイヤーの使い方をしてるだけだろ。
ビルド管理の目的以外でバージョンコントロールしてはいけないという理由はない。
0812デフォルトの名無しさん2015/07/16(木) 13:02:02.47ID:Q/SdAAm+
してはいけないのではない。

ソフトウェアのバージョンを管理する以外につかっても
意味が無いということだ。
0813デフォルトの名無しさん2015/07/16(木) 13:39:11.99ID:Ye9E1FJD
ぜんぜん使いこなせてないな
そんなんじゃgitを使う意味が無い
0814デフォルトの名無しさん2015/07/16(木) 14:56:22.79ID:SnFgv9L8
ここは初心者向けだそうなので、gitの使い方に自信がある人はこちらへどうぞ。

Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
0815デフォルトの名無しさん2015/07/16(木) 15:16:59.28ID:FDPV8gUS
>>804
ある機能を実装するのに、差分の出し方としての段階があると思うけどそういう単位でやるの？
面倒じゃない？
0816デフォルトの名無しさん2015/07/16(木) 15:29:22.25ID:cQ0wrBTO
>>810
何をやってたか忘れない
別途メモ管理不要
revertできる
0817デフォルトの名無しさん2015/07/16(木) 16:59:52.48ID:XEPlidkJ
revertは悪
0818デフォルトの名無しさん2015/07/16(木) 19:11:52.83ID:BQ1LfMZh
>>799
> 先に再帰にコミットログを書いとく

どうしてもと言うなら

git commit --allow-empty -m "○○する予定"
touch a; git add a;
git commit --amend -m "○○してやったぜ"
0819デフォルトの名無しさん2015/07/16(木) 19:13:56.91ID:sUV1QtUU
プログラムしてからコミットコメントを練る習慣を逆にすることを勧める。

コミットコメントの内容は、コーディングする前に決めておく。
つまり、これから何をプログラムするのかをまず決める。
その後、コメント通りにプラグラムできたら完了、コミットする。

下記のページの Write preemptive comments でも推賞されている。
https://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/

こうすれば、何で更新したのか、と悩むことはなくなる。
0820デフォルトの名無しさん2015/07/16(木) 19:24:57.63ID:sUV1QtUU
>>799
「○○機能を実装」というのがデカすぎるから、
メモを見なきゃ把握できなくなるんだよ。
で、メモを見るのを忘れて困ったことになる。

これを改善しないと、git に君が望む機能（ツール）があったとしても、
全く役に立たなくなる。


更新内容の粒度はもっともっと小さくしなきゃだめだ。
10分かそこらでプログラムできる程度の大きさにしてみな。
そうすれば、メモを見る必要すらなくなる。
0821デフォルトの名無しさん2015/07/16(木) 20:38:56.88ID:IhY29Rvn
VCSがない時代の人
1.あれやこれや編集して、時々変更が失なわれないようにファイルに保存
2.目的の変更が完了したところで、バックアップを作成しておく

VCSの時代の人
1. 以前と同じ
2. リポジトリにコミット

DVCSの時代の人
1.編集中の変更は基本自動保存。昔のファイル保存するような感覚でローカルリポジトリにコミット。
2.目的の変更が完了したところで、履歴をまとめてリモートリポジトリにプッシュ。

この運用方法のポイントは
ファイルは自動保存すること。
ローカルコミットにはまとまった意味など不要。
単に編集量や、経過時間のチェックポイントとしてコミットする。
このコミットコメントは、いい加減なメモや、あるいはコメントなしでもよい。
0822デフォルトの名無しさん2015/07/17(金) 00:55:21.98ID:6Y2ZhytJ
Android studioというかIntelliJ IDEAでGitと連動させたソースの編集がまさに>>821のDVCSの時代の人のやりかたができて便利
ファイルへの保存についてはまったく気にする必要がない
ソースの編集画面でHEAD内容と差分のある行の左端に常に印がつく
その印をクリックすると編集前の内容がポップアップで表示されて、行を編集前の状態に戻すとかこのポップアップから操作できる
ソースの編集画面からファイル単位のコミットとかできるし、--amend指定なんかもワンタッチ
HEADと差分あるファイルの一覧を表示してる窓からまとめて全部コミットとかもできる

これで行単位のコミットとかできたら完璧なんだけどそれは無いみたい
IDEを起動したままコマンドラインでgit add -pしてcommitしてもIDE側でほぼ完璧に追従してくれるのでまあなんとかなってる
0823デフォルトの名無しさん2015/07/17(金) 04:20:41.08ID:OfiHmkDl
>>820
差分を1つ1つみなきゃいけないゴミコード打つなよ
0824デフォルトの名無しさん2015/07/17(金) 05:57:36.41ID:JRoNxi4V
パーツごとにブランチを分けて開発し、各パーツを統合する開発ブランチにマージして開発をする
or
パーツごとにリポジトリを分けて開発し、全てのパーツをサブモジュールとしてリポジトリ内に持つリポジトリで開発をする

どっちがいい
0825デフォルトの名無しさん2015/07/17(金) 13:27:11.26ID:2DUlvwkL
パーツごとにブランチ？
そんなことをやってるプロジェクトがありますか？って話だ。
0826デフォルトの名無しさん2015/07/17(金) 20:25:59.09ID:zMQ3zlsL
よっぽどの規模じゃないとあんまり細かくサブモジュール化しても面倒なだけだと思う
0827デフォルトの名無しさん2015/07/17(金) 20:45:24.33ID:3x9AOrGu
index.php
calendar.php
この２つのファイルを編集してまだaddをしてない状態なんですが
index.phpだけ編集しなかったことにして前回のコミットした時の内容のままにして、
calendar.phpだけコミットしたいんですが
どうやってindex.phpを更新してなかったことに出来ますか？
0828デフォルトの名無しさん2015/07/17(金) 22:56:30.48ID:muZ+fGR1
>>827
Indexの変更を手元に残しておきたければcalenderだけaddしてcommit
0829デフォルトの名無しさん2015/07/18(土) 17:46:21.84ID:GcYCq0Aw
iOSアプリ開発をsource treeで管理している初心者です。

今回チャット機能つきのアプリを制作しているのですが、ネイティブコード、サーバーサイド(php)、データベース(MySQL)を同時に管理するのは無理(もしくはかなり難しい)ですよね？

ネイティブコードとサーバーサイドはsource treeで管理するとして、
データベースの情報はコミット毎になんらかの方法で全テーブル情報をログ出力して、それをメモ代わりに置いておく…ということくらいしか思いつかないんですけど、どうでしょうか。

サーバー連携が必要なアプリって、みなさんどうやってGitで管理してるんでしょうか…
0830デフォルトの名無しさん2015/07/18(土) 20:15:32.34ID:5OYZKZ4e
普通、バージョン管理の対象にするのはDDL、初期データ、設定ファイルくらいだろ。
コミットごとのテーブル情報って、何を管理しようとしてるんだか。
0831デフォルトの名無しさん2015/07/18(土) 21:05:27.99ID:Xl228nsE
俺もデータ内容まで保存しようというのはかなり冗長な気がする。
スキーマ更新のSQLのみバージョン管理、
DBのバックアップは別にダンプしてアーカイブだろうな。
0832デフォルトの名無しさん2015/07/19(日) 06:20:36.38ID:KkAp073H
>>829
データの中身は管理対象外、データベースのバックアップの問題

ソフトが対応するデータベースのインターフェースと言う意味では
クエリー処理のプロシージャをDB側で組んでおくのが一番簡単だけど
どうしてもというならDBをゼロから構築するスクリプトなりバッチなりを書いて
それをGitで管理せておく

なんにしろデータベースとアクセスアプリは分離しておくのが大切
0833デフォルトの名無しさん2015/07/19(日) 06:48:36.12ID:EU0ROg42
特定のデータの混入がバグの原因になる場合
git bisect で特定したければ
DB のバックアップも git 管理に入れる必要がある
0834デフォルトの名無しさん2015/07/19(日) 07:28:28.07ID:KkAp073H
>>833
なるほどそういう考え方もあるか
0835デフォルトの名無しさん2015/07/19(日) 09:06:48.58ID:wG1rbxp8
バグはデータじゃなくてコードの側に存在するものだろ。
bisectするにしても、バグを再現できる同じデータを使わなければ見つかるもんも見つからなくなると思うが。
0836デフォルトの名無しさん2015/07/19(日) 09:12:53.24ID:I0iNBGYL
確かにその場合単体テストを増やすべきな気がするな
0837デフォルトの名無しさん2015/07/19(日) 12:04:49.68ID:Npxm1YBj
>bisectするにしても、バグを再現できる同じデータを使わなければ

そのためにコミットごとにデータもダンプするんじゃないのか？
再現ももちろんデータ書き換えでテスト実行
0838デフォルトの名無しさん2015/07/19(日) 12:48:59.20ID:wG1rbxp8
bisectは基本的に、新たに判明したバグについて過去にさかのぼって原因箇所を特定する
ためのものだと思っていたが。
テストデータもcommit時点のものを使うとすればその時点で既にbadだったということになるが、
そういう運用していたらbisect役に立たないんじゃね？

もちろん、bisectを使うつもりがなければビルドが通らないcommitするのも自由だと思うんで
それは別の話として。
0839デフォルトの名無しさん2015/07/19(日) 12:59:24.27ID:3NrA4A7J
>>837
> そのためにコミットごとにデータもダンプするんじゃないのか？

データは0の状態から、テストコードを書くんだよ。

テストコードの中でデータをリストアする
普通はフィクスチャっていうけどな。

当たり前だが実データまるまるダンプしてリストアなんてしない。
そんなことをやったら効率よくテストがかけない。
テスト全体が一つのデータに依存してしまうからね。


正しいテストとは、テスト対象（ファイル単位等）の
テストに必要なデータだけを入れてテストする。
だからテスト実行前にはデータを全て削除する。

データベース全体をダンプするなんてことはしない。
0840デフォルトの名無しさん2015/07/19(日) 13:06:34.44ID:I0iNBGYL
テスト用ＤＢの他にモック、リポジトリパターンも使われるな
0841デフォルトの名無しさん2015/07/19(日) 14:22:36.05ID:4suFbVBW
データもgitで管理するって新しいなｗ
0842デフォルトの名無しさん2015/07/22(水) 10:52:31.65ID:phbUY/16
git checkout develop
git branch -b my_topic_branch
とした後でいくつかcommit後、「my_topic_branch作成直後〜さっきのcommitまで」をrebaseしたいとき、
git rebase -i ***
の***には、何と指定すればいいですか？
0843デフォルトの名無しさん2015/07/22(水) 12:19:49.68ID:EiNSX7P4
何も指定しない
0844デフォルトの名無しさん2015/07/22(水) 13:10:35.36ID:phbUY/16
何も指定しないと怒られます。

$ git rebase -i
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
or: git-rebase [-i] (--continue | --abort | --skip)

ちなみに、今はcommitの数を数えて、HEAD~~~~~~とかしてます。
0845デフォルトの名無しさん2015/07/22(水) 13:17:41.56ID:EiNSX7P4
じゃあ、git rebase -i develop
0846デフォルトの名無しさん2015/07/22(水) 13:54:39.00ID:phbUY/16
>>845
おお、それでいけました。
ありがとう。
0847デフォルトの名無しさん2015/07/22(水) 16:41:20.44ID:zBOMfGM9
>>845はgit checkout developの後にdevelopへ何かコミットされた場合、
たぶん>>842が期待してる動作にはならんぞ
0848デフォルトの名無しさん2015/07/22(水) 17:25:54.55ID:EiNSX7P4
そういや、そうだね。

じゃあ、
git rebase -i `git merge-base develop HEAD`
ってのが、あったけど、素直にgit logして分岐点のcommit idを調べた方がはやいかもね。

別のブランチとの分岐点を起点に rebase -i する git エイリアス
http://qiita.com/uasi/items/70d4358c3c70c64f4261
0849デフォルトの名無しさん2015/07/22(水) 18:24:49.47ID:phbUY/16
>>847
なるほど、topic branchを複数作って作業するときまずいわけですね。

>>848
merge-baseのこと知らなかったので、もう少し調べてみます。
0850デフォルトの名無しさん2015/07/27(月) 15:06:20.98ID:+ejnTFZv
質問させてください
公開版のHTMLと公開を控えたHTMLがあって、これをgitで管理しようかと考えているのですが
公開版（Master）、確認用（Blanch）とした場合、Blanchは確認環境（HTTPアクセス）として機能させることはできるのでしょうか
0851デフォルトの名無しさん2015/07/27(月) 15:24:49.11ID:aZg91AP9
>>850
何をどうしたいのかもうちっと具体的に説明しないと
ツッコミようがないぞ？
0852デフォルトの名無しさん2015/07/27(月) 15:45:36.34ID:biNPOZMH
>>850
masterブランチはどうやって確認環境として機能させるつもりなの？
0853デフォルトの名無しさん2015/07/27(月) 15:47:39.18ID:+ejnTFZv
>>851
説明不足ですみません！

たとえば
http://example.com/public/
この「public」内のコンテンツをgitで管理するとして
「public150727」という名前で「public」のブランチの更新版を作ったときに、ブランチ「public150727」の内容を確認環境としてブラウザで閲覧する方法はないものかと思いまして質問しました。

もっと砕いた言い方をしますと、gitと使えない環境の人にブランチ「public150727」の内容をブラウザで見てもらうことはできるのでしょうか。
0854デフォルトの名無しさん2015/07/27(月) 15:50:15.95ID:+ejnTFZv
>>852
そうですね、勝手な思い込みで公開版をマスターという前提で書いていました
特に公開中のバージョンがマスターであるこだわりはありません
失礼しました！
0855デフォルトの名無しさん2015/07/27(月) 15:56:55.58ID:T5zoWN7L
masterブランチをhttp://example.com/public/でアクセスできるようにする手順と同じ手順でできる
0856デフォルトの名無しさん2015/07/27(月) 16:03:28.50ID:+ejnTFZv
>>855
「public150727」をpushするということですね！
0857デフォルトの名無しさん2015/07/27(月) 16:16:20.09ID:T5zoWN7L
>>856
> 「public150727」をpushするということですね！
違う。そういうレイヤーの話じゃない。
「更新されたmasterブランチ」を「http://example.com/public/でアクセスできるようにする手順」だ。
0858デフォルトの名無しさん2015/07/27(月) 16:23:58.54ID:ybeDhwD5
>>853
ローカルサーバーで見るではだめなの？
りぽじとりを２つ分けて
それぞれ別々でステージングサーバーにでぷろい環境にするとか
0859デフォルトの名無しさん2015/07/27(月) 16:50:45.48ID:+ejnTFZv
>>857
理解が浅くてすみません
自分の知識ですとブランチごとにURLを割り当てるように読み取れるのですが、おそらくそういうお話ではなさそうなのでもっと勉強します！

>>858
やっぱりステージングサーバーで確認→本番環境にPUSHするのが安心ですね


皆さんありがとうございました！
0860デフォルトの名無しさん2015/07/27(月) 16:52:44.86ID:T5zoWN7L
まぁ、本人がこれで解決したと思うんならそれでいいか・・・。
0861デフォルトの名無しさん2015/07/27(月) 17:03:36.01ID:+ejnTFZv
>>860
よかったら>>857に書いていただいた手順の概要、もしくは参考のURLを教えていただけませんでしょうか
0862デフォルトの名無しさん2015/07/27(月) 17:17:59.43ID:T5zoWN7L
>>861
> よかったら>>857に書いていただいた手順
いやいや、それは俺らにはわからんよ。
その手順がわかりさえすれば、それと同じ手順でできるだろってこと。

ローカルのmasterを変更して、それをサーバにpushしたら、http://example.com/public/の内容が更新されるんだろ？
その仕組みは一体誰が構築したんだ？
0863デフォルトの名無しさん2015/07/27(月) 17:18:41.69ID:aippD/Jn
.gitをWebサーバーで公開していないか心配になるな
0864デフォルトの名無しさん2015/07/27(月) 17:21:38.69ID:T5zoWN7L
>>863
うわ、その発想はなかったわ。
0865デフォルトの名無しさん2015/07/27(月) 17:27:25.72ID:JJPg7kwZ
業務使うコマンドを全部教えてください
来月からアルバイトなんですけど
clone,log,reflog,reset,branch,push checkout,commit,add,rm,mvはしってます
0866デフォルトの名無しさん2015/07/27(月) 18:21:27.18ID:bJ8mI018
>>865
git --help
0867デフォルトの名無しさん2015/07/27(月) 21:16:18.54ID:v7fIr+eP
>>863
Push to deploy の改善 2.3.0 で入ってるし .git を不可視にしとけば個人サイトくらいなら問題ないんじゃない？
0868デフォルトの名無しさん2015/07/27(月) 22:46:51.50ID:aZg91AP9
>>853
やつぱりまだわからないや

やりたいのは次のどっち？

1)
公開webページとかのhtmlその他諸々をgitで管理して
どっかのブランチにコミットすると自動的に公開webページになるようにしたい
さらに、公開前の事前確認用のページも用意したい

2)
なんかプログラム開発中のソースコードとかをgitで管理しておいて
みんなにレビューしてもらうためにwebページで閲覧できるようにしたい
0869デフォルトの名無しさん2015/07/27(月) 22:48:07.44ID:u9s58J+y
A:ある手順を踏めばできるぞ
B:プッシュすればいいんですね
A:そういうレイヤーの問題じゃない
B:ではどういう手順で？
A:それはわからん、プッシュすればできるだろ

なんとなくこのスレの闇を垣間見たような気がするぜ
0870デフォルトの名無しさん2015/07/27(月) 23:00:40.37ID:aZg91AP9
あ、よく見たら1)の方だね。

俺だったらポストフックスクリプト書こうとするな
特定のブランチにコミットされたら対応するディレクトリにexportするようなやつ

gitに付属のフックスクリプトのサンプルに似たようなことやるのがあったと思うから調べてみ


手抜きバージョンなら
事前確認用のディレクトリにクローンしておいて
1分おきとかでpullかけるようにcronをセットしちゃう

こんなあたりでいかが？
0871デフォルトの名無しさん2015/07/28(火) 13:25:37.42ID:3O5DcyiA
Jenkins とかの Pull Request Builder とかでいいんじゃないかと
あとは heroku なにかに push して確認すればいいんじゃない?
0872デフォルトの名無しさん2015/07/28(火) 16:06:24.66ID:iS6umbvt
2.4.7 と 2.5.0 がリリースされたね。
https://github.com/git/git/releases/tag/v2.4.7
https://github.com/git/git/releases/tag/v2.5.0
0873デフォルトの名無しさん2015/07/28(火) 23:54:34.28ID:Z/s3EayV
git v2.4.3

mv index.php sub/list.php
git add .
git commit -m "backup"

コミットした後に
rename index.php => sub/list.php (74%)
って表示されたんですがこれってindex.phpをgit mvで移動したのと同じことですか？
ato
74%って何を表してるんですか？
0874デフォルトの名無しさん2015/07/29(水) 00:17:46.73ID:j0BJwxBz
ファイルの一致率。ファイルの修正と移動を同時にしたんだね。
gitは移動を記録していないので、ファイルの一致率から移動を推測している。
0875デフォルトの名無しさん2015/07/29(水) 09:32:05.34ID:bPiFDPfp
>>853
よそ様の記事だがこんな感じだよ、hook script

< http://qiita.com/fnobi/items/98bd5d1c83c010842733 >

ぜひバルスしてくれたまえ
0876デフォルトの名無しさん2015/07/29(水) 15:20:03.83ID:YsMaiv/S
あるフォルダの中のあるフォルダ・ファイル以外を無視したいんだけど
.gitignoreをどう書いたらいいかわからない

hoge/piyo　　←無視しない
hoge/fuga/　←無視する
hoge/foo/　　←無視する
hoge/bar 　　←無視する

たとえばこんな感じで、今は fuga,foo,bar を毎度列挙してるけど
今後フォルダがどんどこ増えるとするとちょっと嫌な気分になる
0877デフォルトの名無しさん2015/07/29(水) 16:33:49.47ID:bPiFDPfp
>>853
0878デフォルトの名無しさん2015/07/29(水) 16:38:56.52ID:bPiFDPfp
>>853

How to rebuild from update hook

で検索してみ

kernel.orgでのドキュメント自動公開用のフックスクリプトが解説付きで買いてあるよ

あなたの場合はこれよりは簡単なはず
0879デフォルトの名無しさん2015/07/29(水) 17:01:12.31ID:1zEW+9y+
hoge/!piyo
0880デフォルトの名無しさん2015/07/29(水) 19:54:41.79ID:syqOZkA4
>>872
「Git 2.5」がリリース
http://osdn.jp/magazine/15/07/30/044700
0881デフォルトの名無しさん2015/07/30(木) 01:34:27.13ID:6b1uCZJv
おお、ついにPerforceまで取り込む気か！
0882デフォルトの名無しさん2015/07/31(金) 08:21:08.61ID:Uyj1+FiM
指定したディレクトリ以下のファイルをスキャンして
編集してから1週間以上コミットせずに放置してあるファイルを
一覧で出力するようなスクリプトかツールあったら教えて下さい

雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
そのまま忘れて半年放置のようなファイルを検出したいのですが
0883デフォルトの名無しさん2015/07/31(金) 08:36:32.35ID:709JoO30
git diff HEAD
0884デフォルトの名無しさん2015/07/31(金) 09:00:48.29ID:u6UInjxJ
>>882
> 雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
svnじゃないんだから、コミットしろよｗ

svnと違ってコミット＝サーバーに送信 ではない。

そこがsvnのだめなところであり、gitの優れたところなんだよね。
gitなら安定しなくてもコミットできる。
もしバグが見つかれば修正してrebaseしてまとめてしまえばいい。

だから意味がある単位でコミットしていって、
あとでまとめて安定したと思ったらサーバー（共有リポジトリ）にpushすればいい。
（work in progress的なやりかたなら、作りかけでもpushするのもあり）

そこからレビューをうけてOKになったらmasterにマージする。

「安定したらコミット」という発想をやめないといけない
その発想だとどうしても一回のマージのコードが多くなりすぎる。
小さく機能毎にコミット、gitではそれができる。
0885デフォルトの名無しさん2015/07/31(金) 09:30:41.27ID:709JoO30
コンパイルできないものもコミットしていいですか？
0886デフォルトの名無しさん2015/07/31(金) 09:51:16.96ID:02j0y00V
いいよ
0887デフォルトの名無しさん2015/07/31(金) 10:08:59.48ID:VSZ3MRZU
>>885
そもそもスクリプトはコンパイラしないし
0888デフォルトの名無しさん2015/07/31(金) 10:23:03.17ID:5Be3R/21
「意味がある単位」でコンパイルできないものという発想が良くわからない。
0889デフォルトの名無しさん2015/07/31(金) 12:30:24.06ID:Q/Fv6mzV
毎朝コミットで良いよ
0890デフォルトの名無しさん2015/07/31(金) 12:32:31.44ID:02j0y00V
svnのコミットに近いのは、masterへのpushじゃないかね
0891デフォルトの名無しさん2015/07/31(金) 13:05:45.97ID:5Be3R/21
>>882
ひょっとして、etckeeperが求めるものだったりする？
0892デフォルトの名無しさん2015/07/31(金) 14:59:02.99ID:Pi4vilvw
https://git-scm.com/book/ja/v2/使い始める-Gitのインストール
ここの一番最後に
＞次からはGitを使ってGitそのものをアップデートできます：
って書いてあるんですが
これってmakeとかしなくてもgit pullしただけで新しいバージョンのGitが使えるようになるってことですか？
0893デフォルトの名無しさん2015/07/31(金) 15:49:47.76ID:5Be3R/21
>>892
ならない。
0894デフォルトの名無しさん2015/07/31(金) 15:51:07.09ID:R58DjZqg
>>892
インストールしたGitを使ってGitのソースをアップデートできるって意味だな
当然ソースをアップデートしたあとmakeは自分でやる
0895デフォルトの名無しさん2015/08/01(土) 05:22:16.40ID:fbUoNrmE
>>885
> コンパイルできないものもコミットしていいですか？

他人に渡さないならば何の問題もない。

svnとか使ってると、この自分だけが触れる
コミットという概念がわからんのだろうな。
0896デフォルトの名無しさん2015/08/01(土) 05:24:32.97ID:fbUoNrmE
>>889
> 毎朝コミットで良いよ
なんで1日の区切りでコミットしてるんだよｗ

作業の区切りでコミットしろよ。
大抵の場合、1日に数回コミットするもんだ
■ このスレッドは過去ログ倉庫に格納されています