- 1 名前：デフォルトの名無しさん mailto:ageteoff [2015/03/23(月) 13:35:13.83 ID:aBYp+bVs.net]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
git-scm.com/book/ja
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 11
peace.2ch.net/test/read.cgi/tech/1416195050/
- 809 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 13:07:53.62 ID:VxoBFrok.net]
- >>802
運用のことを考え出したら初心者じゃない。
コマンドなんてあとから覚えりゃいいんだよ。
運用があって、それに必要なものを作ったのが
gitなんだから。
- 810 名前：デフォルトの名無しさん [2015/07/14(火) 13:20:00.15 ID:G0PBqp91.net]
- 初心者はコマンドを先に覚えた方が良い。
でないと、話が通じない。
ある程度使って、具体的に困ったところが出てきたら、運用スレで聞けば良い。
ただしあっちは関係無い話に脱線しがちだから、良いとこ取りした方が良いよ。
- 811 名前：デフォルトの名無しさん [2015/07/15(水) 23:09:43.18 ID:a+rEGmf6.net]
- すいませんgitでコミットするときにこのファイルは何で更新したのか思い出せません。
なので、これから更新する内容は「○○機能を実装」ってことでそれをプロジェクトルートのテキストファイルにメモ書きしてました。
しかし、コミットするときに毎回メモを見るのを忘れてしまいます。
再帰にコミットログを書いとくとかなんかtodoみたいなコマンドってありませんか？
- 812 名前：デフォルトの名無しさん [2015/07/15(水) 23:10:19.62 ID:a+rEGmf6.net]
- 訂正
☓再帰にコミットログ
○先にコミットログ
- 813 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:21:39.17 ID:YpeXwOwK.net]
- >>805
> それをプロジェクトルートのテキストファイルにメモ書きしてました。
いますぐそのようなアホなことを辞めましょう。
- 814 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:22:13.29 ID:VsrdjrWK.net]
- 前回との差分見ながらコミットログ書けばいい
あらかじめ用意しておくから忘れるんだ
- 815 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:44:52.69 ID:DsRhlYqB.net]
- 自分が今なにをしてきたか忘れるのか、
よっぽどコミットを溜めるのか、
コミットのコメントが適当すぎるのか
もうバージョン管理以前の問題な気が
アナログだけど付箋にメモしてディスプレイに貼れば？
左がこれからやること、上部が今やってる事、右が終わった事、
いや右は要らんかな？
- 816 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 00:52:26.73 ID:Ye9E1FJD.net]
- >>805
自分が差分を見て理解できないコードをコミットしちゃダメだよ
- 817 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 02:04:46.85 ID:C5QhjRoF.net]
- git notes とかはどうかな？
- 818 名前：デフォルトの名無しさん [2015/07/16(木) 04:35:55.01 ID:MREKRM2C.net]
- >>810
差分ってたまに直観的じゃない出力することが良くある
- 819 名前：デフォルトの名無しさん [2015/07/16(木) 07:52:03.14 ID:SnFgv9L8.net]
- git diffの表示範囲を広げるオプションは？
- 820 名前：デフォルトの名無しさん [2015/07/16(木) 08:04:35.28 ID:SnFgv9L8.net]
- >>805
githubとかRedmineとかticket/issue管理ツールと併用するのが一番だけど、1人で使うのだと構築するのが大変かもね。
メモをgit管理されていれば、メモの差分もgit diffで出るよね。なので、commitする前に必ずgit diffしていればメモを見るのを忘れることはないはず。
このやり方をする/しないにかかわらず、commitする前にgit diffをするのは大事だから習慣付けるべきだよ。
- 821 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 09:31:42.39 ID:NYNU6iM6.net]
- 変更するたびにコミットしといてpushやmerge前にamendなりrebaseで整形すればよくない？
- 822 名前：デフォルトの名無しさん [2015/07/16(木) 12:26:35.31 ID:WO54leEH.net]
- >変更するたびにコミット
コンパイル出来ないものをコミットするメリットは？
- 823 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 12:32:11.52 ID:DSiPnBiQ.net]
- コンバイル云々より下のレイヤーの使い方をしてるだけだろ。
ビルド管理の目的以外でバージョンコントロールしてはいけないという理由はない。
- 824 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 13:02:02.47 ID:Q/SdAAm+.net]
- してはいけないのではない。
ソフトウェアのバージョンを管理する以外につかっても
意味が無いということだ。
- 825 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 13:39:11.99 ID:Ye9E1FJD.net]
- ぜんぜん使いこなせてないな
そんなんじゃgitを使う意味が無い
- 826 名前：デフォルトの名無しさん [2015/07/16(木) 14:56:22.79 ID:SnFgv9L8.net]
- ここは初心者向けだそうなので、gitの使い方に自信がある人はこちらへどうぞ。
Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
peace.2ch.net/test/read.cgi/tech/1433650988/
- 827 名前：デフォルトの名無しさん [2015/07/16(木) 15:16:59.28 ID:FDPV8gUS.net]
- >>810
ある機能を実装するのに、差分の出し方としての段階があると思うけどそういう単位でやるの？
面倒じゃない？
- 828 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 15:29:22.25 ID:cQ0wrBTO.net]
- >>816
何をやってたか忘れない
別途メモ管理不要
revertできる
- 829 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 16:59:52.48 ID:XEPlidkJ.net]
- revertは悪
- 830 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:11:52.83 ID:BQ1LfMZh.net]
- >>805
> 先に再帰にコミットログを書いとく
どうしてもと言うなら
git commit --allow-empty -m "○○する予定"
touch a; git add a;
git commit --amend -m "○○してやったぜ"
- 831 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:13:56.91 ID:sUV1QtUU.net]
- プログラムしてからコミットコメントを練る習慣を逆にすることを勧める。
コミットコメントの内容は、コーディングする前に決めておく。
つまり、これから何をプログラムするのかをまず決める。
その後、コメント通りにプラグラムできたら完了、コミットする。
下記のページの Write preemptive comments でも推賞されている。
https://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/
こうすれば、何で更新したのか、と悩むことはなくなる。
- 832 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:24:57.63 ID:sUV1QtUU.net]
- >>805
「○○機能を実装」というのがデカすぎるから、
メモを見なきゃ把握できなくなるんだよ。
で、メモを見るのを忘れて困ったことになる。
これを改善しないと、git に君が望む機能（ツール）があったとしても、
全く役に立たなくなる。
更新内容の粒度はもっともっと小さくしなきゃだめだ。
10分かそこらでプログラムできる程度の大きさにしてみな。
そうすれば、メモを見る必要すらなくなる。
- 833 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 20:38:56.88 ID:IhY29Rvn.net]
- VCSがない時代の人
1.あれやこれや編集して、時々変更が失なわれないようにファイルに保存
2.目的の変更が完了したところで、バックアップを作成しておく
VCSの時代の人
1. 以前と同じ
2. リポジトリにコミット
DVCSの時代の人
1.編集中の変更は基本自動保存。昔のファイル保存するような感覚でローカルリポジトリにコミット。
2.目的の変更が完了したところで、履歴をまとめてリモートリポジトリにプッシュ。
この運用方法のポイントは
ファイルは自動保存すること。
ローカルコミットにはまとまった意味など不要。
単に編集量や、経過時間のチェックポイントとしてコミットする。
このコミットコメントは、いい加減なメモや、あるいはコメントなしでもよい。
- 834 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 00:55:21.98 ID:6Y2ZhytJ.net]
- Android studioというかIntelliJ IDEAでGitと連動させたソースの編集がまさに>>827のDVCSの時代の人のやりかたができて便利
ファイルへの保存についてはまったく気にする必要がない
ソースの編集画面でHEAD内容と差分のある行の左端に常に印がつく
その印をクリックすると編集前の内容がポップアップで表示されて、行を編集前の状態に戻すとかこのポップアップから操作できる
ソースの編集画面からファイル単位のコミットとかできるし、--amend指定なんかもワンタッチ
HEADと差分あるファイルの一覧を表示してる窓からまとめて全部コミットとかもできる
これで行単位のコミットとかできたら完璧なんだけどそれは無いみたい
IDEを起動したままコマンドラインでgit add -pしてcommitしてもIDE側でほぼ完璧に追従してくれるのでまあなんとかなってる
- 835 名前：デフォルトの名無しさん [2015/07/17(金) 04:20:41.08 ID:OfiHmkDl.net]
- >>826
差分を1つ1つみなきゃいけないゴミコード打つなよ
- 836 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 05:57:36.41 ID:JRoNxi4V.net]
- パーツごとにブランチを分けて開発し、各パーツを統合する開発ブランチにマージして開発をする
or
パーツごとにリポジトリを分けて開発し、全てのパーツをサブモジュールとしてリポジトリ内に持つリポジトリで開発をする
どっちがいい
- 837 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 13:27:11.26 ID:2DUlvwkL.net]
- パーツごとにブランチ？
そんなことをやってるプロジェクトがありますか？って話だ。
- 838 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 20:25:59.09 ID:zMQ3zlsL.net]
- よっぽどの規模じゃないとあんまり細かくサブモジュール化しても面倒なだけだと思う
- 839 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 20:45:24.33 ID:3x9AOrGu.net]
- index.php
calendar.php
この２つのファイルを編集してまだaddをしてない状態なんですが
index.phpだけ編集しなかったことにして前回のコミットした時の内容のままにして、
calendar.phpだけコミットしたいんですが
どうやってindex.phpを更新してなかったことに出来ますか？
- 840 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 22:56:30.48 ID:muZ+fGR1.net]
- >>833
Indexの変更を手元に残しておきたければcalenderだけaddしてcommit
- 841 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 17:46:21.84 ID:GcYCq0Aw.net]
- iOSアプリ開発をsource treeで管理している初心者です。
今回チャット機能つきのアプリを制作しているのですが、ネイティブコード、サーバーサイド(php)、データベース(MySQL)を同時に管理するのは無理(もしくはかなり難しい)ですよね？
ネイティブコードとサーバーサイドはsource treeで管理するとして、
データベースの情報はコミット毎になんらかの方法で全テーブル情報をログ出力して、それをメモ代わりに置いておく…ということくらいしか思いつかないんですけど、どうでしょうか。
サーバー連携が必要なアプリって、みなさんどうやってGitで管理してるんでしょうか…
- 842 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 20:15:32.34 ID:5OYZKZ4e.net]
- 普通、バージョン管理の対象にするのはDDL、初期データ、設定ファイルくらいだろ。
コミットごとのテーブル情報って、何を管理しようとしてるんだか。
- 843 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 21:05:27.99 ID:Xl228nsE.net]
- 俺もデータ内容まで保存しようというのはかなり冗長な気がする。
スキーマ更新のSQLのみバージョン管理、
DBのバックアップは別にダンプしてアーカイブだろうな。
- 844 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 06:20:36.38 ID:KkAp073H.net]
- >>835
データの中身は管理対象外、データベースのバックアップの問題
ソフトが対応するデータベースのインターフェースと言う意味では
クエリー処理のプロシージャをDB側で組んでおくのが一番簡単だけど
どうしてもというならDBをゼロから構築するスクリプトなりバッチなりを書いて
それをGitで管理せておく
なんにしろデータベースとアクセスアプリは分離しておくのが大切
- 845 名前：デフォルトの名無しさん [2015/07/19(日) 06:48:36.12 ID:EU0ROg42.net]
- 特定のデータの混入がバグの原因になる場合
git bisect で特定したければ
DB のバックアップも git 管理に入れる必要がある
- 846 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 07:28:28.07 ID:KkAp073H.net]
- >>839
なるほどそういう考え方もあるか
- 847 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 09:06:48.58 ID:wG1rbxp8.net]
- バグはデータじゃなくてコードの側に存在するものだろ。
bisectするにしても、バグを再現できる同じデータを使わなければ見つかるもんも見つからなくなると思うが。
- 848 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 09:12:53.24 ID:I0iNBGYL.net]
- 確かにその場合単体テストを増やすべきな気がするな
- 849 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:04:49.68 ID:Npxm1YBj.net]
- >bisectするにしても、バグを再現できる同じデータを使わなければ
そのためにコミットごとにデータもダンプするんじゃないのか？
再現ももちろんデータ書き換えでテスト実行
- 850 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:48:59.20 ID:wG1rbxp8.net]
- bisectは基本的に、新たに判明したバグについて過去にさかのぼって原因箇所を特定する
ためのものだと思っていたが。
テストデータもcommit時点のものを使うとすればその時点で既にbadだったということになるが、
そういう運用していたらbisect役に立たないんじゃね？
もちろん、bisectを使うつもりがなければビルドが通らないcommitするのも自由だと思うんで
それは別の話として。
- 851 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:59:24.27 ID:3NrA4A7J.net]
- >>843
> そのためにコミットごとにデータもダンプするんじゃないのか？
データは0の状態から、テストコードを書くんだよ。
テストコードの中でデータをリストアする
普通はフィクスチャっていうけどな。
当たり前だが実データまるまるダンプしてリストアなんてしない。
そんなことをやったら効率よくテストがかけない。
テスト全体が一つのデータに依存してしまうからね。
正しいテストとは、テスト対象（ファイル単位等）の
テストに必要なデータだけを入れてテストする。
だからテスト実行前にはデータを全て削除する。
データベース全体をダンプするなんてことはしない。
- 852 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 13:06:34.44 ID:I0iNBGYL.net]
- テスト用ＤＢの他にモック、リポジトリパターンも使われるな
- 853 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 14:22:36.05 ID:4suFbVBW.net]
- データもgitで管理するって新しいなｗ
- 854 名前：デフォルトの名無しさん [2015/07/22(水) 10:52:31.65 ID:phbUY/16.net]
- git checkout develop
git branch -b my_topic_branch
とした後でいくつかcommit後、「my_topic_branch作成直後〜さっきのcommitまで」をrebaseしたいとき、
git rebase -i ***
の***には、何と指定すればいいですか？
- 855 名前：デフォルトの名無しさん [2015/07/22(水) 12:19:49.68 ID:EiNSX7P4.net]
- 何も指定しない
- 856 名前：デフォルトの名無しさん [2015/07/22(水) 13:10:35.36 ID:phbUY/16.net]
- 何も指定しないと怒られます。
$ git rebase -i
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
or: git-rebase [-i] (--continue | --abort | --skip)
ちなみに、今はcommitの数を数えて、HEAD~~~~~~とかしてます。
- 857 名前：デフォルトの名無しさん [2015/07/22(水) 13:17:41.56 ID:EiNSX7P4.net]
- じゃあ、git rebase -i develop
- 858 名前：デフォルトの名無しさん [2015/07/22(水) 13:54:39.00 ID:phbUY/16.net]
- >>851
おお、それでいけました。
ありがとう。
- 859 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 16:41:20.44 ID:zBOMfGM9.net]
- >>851はgit checkout developの後にdevelopへ何かコミットされた場合、
たぶん>>848が期待してる動作にはならんぞ
- 860 名前：デフォルトの名無しさん [2015/07/22(水) 17:25:54.55 ID:EiNSX7P4.net]
- そういや、そうだね。
じゃあ、
git rebase -i `git merge-base develop HEAD`
ってのが、あったけど、素直にgit logして分岐点のcommit idを調べた方がはやいかもね。
別のブランチとの分岐点を起点に rebase -i する git エイリアス
qiita.com/uasi/items/70d4358c3c70c64f4261
- 861 名前：デフォルトの名無しさん [2015/07/22(水) 18:24:49.47 ID:phbUY/16.net]
- >>853
なるほど、topic branchを複数作って作業するときまずいわけですね。
>>854
merge-baseのこと知らなかったので、もう少し調べてみます。
- 862 名前：デフォルトの名無しさん [2015/07/27(月) 15:06:20.98 ID:+ejnTFZv.net]
- 質問させてください
公開版のHTMLと公開を控えたHTMLがあって、これをgitで管理しようかと考えているのですが
公開版（Master）、確認用（Blanch）とした場合、Blanchは確認環境（HTTPアクセス）として機能させることはできるのでしょうか
- 863 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 15:24:49.11 ID:aZg91AP9.net]
- >>856
何をどうしたいのかもうちっと具体的に説明しないと
ツッコミようがないぞ？
- 864 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 15:45:36.34 ID:biNPOZMH.net]
- >>856
masterブランチはどうやって確認環境として機能させるつもりなの？
- 865 名前：デフォルトの名無しさん [2015/07/27(月) 15:47:39.18 ID:+ejnTFZv.net]
- >>857
説明不足ですみません！
たとえば
example.com/public/
この「public」内のコンテンツをgitで管理するとして
「public150727」という名前で「public」のブランチの更新版を作ったときに、ブランチ「public150727」の内容を確認環境としてブラウザで閲覧する方法はないものかと思いまして質問しました。
もっと砕いた言い方をしますと、gitと使えない環境の人にブランチ「public150727」の内容をブラウザで見てもらうことはできるのでしょうか。
- 866 名前：デフォルトの名無しさん [2015/07/27(月) 15:50:15.95 ID:+ejnTFZv.net]
- >>858
そうですね、勝手な思い込みで公開版をマスターという前提で書いていました
特に公開中のバージョンがマスターであるこだわりはありません
失礼しました！
- 867 名前：デフォルトの名無しさん [2015/07/27(月) 15:56:55.58 ID:T5zoWN7L.net]
- masterブランチをexample.com/public/でアクセスできるようにする手順と同じ手順でできる
- 868 名前：デフォルトの名無しさん [2015/07/27(月) 16:03:28.50 ID:+ejnTFZv.net]
- >>861
「public150727」をpushするということですね！
- 869 名前：デフォルトの名無しさん [2015/07/27(月) 16:16:20.09 ID:T5zoWN7L.net]
- >>862
> 「public150727」をpushするということですね！
違う。そういうレイヤーの話じゃない。
「更新されたmasterブランチ」を「example.com/public/でアクセスできるようにする手順」だ。
- 870 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 16:23:58.54 ID:ybeDhwD5.net]
- >>859
ローカルサーバーで見るではだめなの？
りぽじとりを２つ分けて
それぞれ別々でステージングサーバーにでぷろい環境にするとか
- 871 名前：デフォルトの名無しさん [2015/07/27(月) 16:50:45.48 ID:+ejnTFZv.net]
- >>863
理解が浅くてすみません
自分の知識ですとブランチごとにURLを割り当てるように読み取れるのですが、おそらくそういうお話ではなさそうなのでもっと勉強します！
>>864
やっぱりステージングサーバーで確認→本番環境にPUSHするのが安心ですね
皆さんありがとうございました！
- 872 名前：デフォルトの名無しさん [2015/07/27(月) 16:52:44.86 ID:T5zoWN7L.net]
- まぁ、本人がこれで解決したと思うんならそれでいいか・・・。
- 873 名前：デフォルトの名無しさん [2015/07/27(月) 17:03:36.01 ID:+ejnTFZv.net]
- >>866
よかったら>>863に書いていただいた手順の概要、もしくは参考のURLを教えていただけませんでしょうか
- 874 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:17:59.43 ID:T5zoWN7L.net]
- >>867
> よかったら>>863に書いていただいた手順
いやいや、それは俺らにはわからんよ。
その手順がわかりさえすれば、それと同じ手順でできるだろってこと。
ローカルのmasterを変更して、それをサーバにpushしたら、example.com/public/の内容が更新されるんだろ？
その仕組みは一体誰が構築したんだ？
- 875 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:18:41.69 ID:aippD/Jn.net]
- .gitをWebサーバーで公開していないか心配になるな
- 876 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:21:38.69 ID:T5zoWN7L.net]
- >>869
うわ、その発想はなかったわ。
- 877 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:27:25.72 ID:JJPg7kwZ.net]
- 業務使うコマンドを全部教えてください
来月からアルバイトなんですけど
clone,log,reflog,reset,branch,push checkout,commit,add,rm,mvはしってます
- 878 名前：デフォルトの名無しさん [2015/07/27(月) 18:21:27.18 ID:bJ8mI018.net]
- >>871
git --help
- 879 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 21:16:18.54 ID:v7fIr+eP.net]
- >>869
Push to deploy の改善 2.3.0 で入ってるし .git を不可視にしとけば個人サイトくらいなら問題ないんじゃない？
- 880 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 22:46:51.50 ID:aZg91AP9.net]
- >>859
やつぱりまだわからないや
やりたいのは次のどっち？
1)
公開webページとかのhtmlその他諸々をgitで管理して
どっかのブランチにコミットすると自動的に公開webページになるようにしたい
さらに、公開前の事前確認用のページも用意したい
2)
なんかプログラム開発中のソースコードとかをgitで管理しておいて
みんなにレビューしてもらうためにwebページで閲覧できるようにしたい
- 881 名前：デフォルトの名無しさん [2015/07/27(月) 22:48:07.44 ID:u9s58J+y.net]
- A:ある手順を踏めばできるぞ
B:プッシュすればいいんですね
A:そういうレイヤーの問題じゃない
B:ではどういう手順で？
A:それはわからん、プッシュすればできるだろ
なんとなくこのスレの闇を垣間見たような気がするぜ
- 882 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 23:00:40.37 ID:aZg91AP9.net]
- あ、よく見たら1)の方だね。
俺だったらポストフックスクリプト書こうとするな
特定のブランチにコミットされたら対応するディレクトリにexportするようなやつ
gitに付属のフックスクリプトのサンプルに似たようなことやるのがあったと思うから調べてみ
手抜きバージョンなら
事前確認用のディレクトリにクローンしておいて
1分おきとかでpullかけるようにcronをセットしちゃう
こんなあたりでいかが？
- 883 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 13:25:37.42 ID:3O5DcyiA.net]
- Jenkins とかの Pull Request Builder とかでいいんじゃないかと
あとは heroku なにかに push して確認すればいいんじゃない?
- 884 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 16:06:24.66 ID:iS6umbvt.net]
- 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
- 885 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 23:54:34.28 ID:Z/s3EayV.net]
- 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%って何を表してるんですか？
- 886 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 00:17:46.73 ID:j0BJwxBz.net]
- ファイルの一致率。ファイルの修正と移動を同時にしたんだね。
gitは移動を記録していないので、ファイルの一致率から移動を推測している。
- 887 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 09:32:05.34 ID:bPiFDPfp.net]
- >>859
よそ様の記事だがこんな感じだよ、hook script
< qiita.com/fnobi/items/98bd5d1c83c010842733 >
ぜひバルスしてくれたまえ
- 888 名前：デフォルトの名無しさん [2015/07/29(水) 15:20:03.83 ID:YsMaiv/S.net]
- あるフォルダの中のあるフォルダ・ファイル以外を無視したいんだけど
.gitignoreをどう書いたらいいかわからない
hoge/piyo ←無視しない
hoge/fuga/ ←無視する
hoge/foo/ ←無視する
hoge/bar ←無視する
たとえばこんな感じで、今は fuga,foo,bar を毎度列挙してるけど
今後フォルダがどんどこ増えるとするとちょっと嫌な気分になる
- 889 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 16:33:49.47 ID:bPiFDPfp.net]
- >>859
- 890 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 16:38:56.52 ID:bPiFDPfp.net]
- >>859
How to rebuild from update hook
で検索してみ
kernel.orgでのドキュメント自動公開用のフックスクリプトが解説付きで買いてあるよ
あなたの場合はこれよりは簡単なはず
- 891 名前：デフォルトの名無しさん [2015/07/29(水) 17:01:12.31 ID:1zEW+9y+.net]
- hoge/!piyo
- 892 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 19:54:41.79 ID:syqOZkA4.net]
- >>878
「Git 2.5」がリリース
osdn.jp/magazine/15/07/30/044700
- 893 名前：デフォルトの名無しさん mailto:sage [2015/07/30(木) 01:34:27.13 ID:6b1uCZJv.net]
- おお、ついにPerforceまで取り込む気か！
- 894 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 08:21:08.61 ID:Uyj1+FiM.net]
- 指定したディレクトリ以下のファイルをスキャンして
編集してから1週間以上コミットせずに放置してあるファイルを
一覧で出力するようなスクリプトかツールあったら教えて下さい
雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
そのまま忘れて半年放置のようなファイルを検出したいのですが
- 895 名前：デフォルトの名無しさん [2015/07/31(金) 08:36:32.35 ID:709JoO30.net]
- git diff
- 896 名前： HEAD []
- [ここ壊れてます]
- 897 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 09:00:48.29 ID:u6UInjxJ.net]
- >>888
> 雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
svnじゃないんだから、コミットしろよｗ
svnと違ってコミット＝サーバーに送信 ではない。
そこがsvnのだめなところであり、gitの優れたところなんだよね。
gitなら安定しなくてもコミットできる。
もしバグが見つかれば修正してrebaseしてまとめてしまえばいい。
だから意味がある単位でコミットしていって、
あとでまとめて安定したと思ったらサーバー（共有リポジトリ）にpushすればいい。
（work in progress的なやりかたなら、作りかけでもpushするのもあり）
そこからレビューをうけてOKになったらmasterにマージする。
「安定したらコミット」という発想をやめないといけない
その発想だとどうしても一回のマージのコードが多くなりすぎる。
小さく機能毎にコミット、gitではそれができる。
- 898 名前：デフォルトの名無しさん [2015/07/31(金) 09:30:41.27 ID:709JoO30.net]
- コンパイルできないものもコミットしていいですか？
- 899 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 09:51:16.96 ID:02j0y00V.net]
- いいよ
- 900 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 10:08:59.48 ID:VSZ3MRZU.net]
- >>891
そもそもスクリプトはコンパイラしないし
- 901 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 10:23:03.17 ID:5Be3R/21.net]
- 「意味がある単位」でコンパイルできないものという発想が良くわからない。
- 902 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 12:30:24.06 ID:Q/Fv6mzV.net]
- 毎朝コミットで良いよ
- 903 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 12:32:31.44 ID:02j0y00V.net]
- svnのコミットに近いのは、masterへのpushじゃないかね
- 904 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 13:05:45.97 ID:5Be3R/21.net]
- >>888
ひょっとして、etckeeperが求めるものだったりする？
- 905 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 14:59:02.99 ID:Pi4vilvw.net]
- https://git-scm.com/book/ja/v2/使い始める-Gitのインストール
ここの一番最後に
＞次からはGitを使ってGitそのものをアップデートできます：
って書いてあるんですが
これってmakeとかしなくてもgit pullしただけで新しいバージョンのGitが使えるようになるってことですか？
- 906 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 15:49:47.76 ID:5Be3R/21.net]
- >>898
ならない。
- 907 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 15:51:07.09 ID:R58DjZqg.net]
- >>898
インストールしたGitを使ってGitのソースをアップデートできるって意味だな
当然ソースをアップデートしたあとmakeは自分でやる
- 908 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 05:22:16.40 ID:fbUoNrmE.net]
- >>891
> コンパイルできないものもコミットしていいですか？
他人に渡さないならば何の問題もない。
svnとか使ってると、この自分だけが触れる
コミットという概念がわからんのだろうな。
- 909 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 05:24:32.97 ID:fbUoNrmE.net]
- >>895
> 毎朝コミットで良いよ
なんで1日の区切りでコミットしてるんだよｗ
作業の区切りでコミットしろよ。
大抵の場合、1日に数回コミットするもんだ
|
 |
