14/04/15 21:13:10.96 Td9RmRcX
初心者ですが、
Gitの説明でよくブランチの分岐が書いてあってそれでrebaseだcherry-pickだ等々
説明が書いてあるけど、
このブランチの構造自体は皆さんgitのログとかから頭の中でイメージしたり
できるんですか? 自分にはまずそこが問題w
37:デフォルトの名無しさん
14/04/15 21:44:05.28 z6touH+D
VPSを自分専用のgit鯖にしてる。
って、ssh開けるだけだから、鯖という言い方もおかしいか。
自宅鯖が安心最安だろうけど、1k円/月くらいあれば安いVPSあるんじゃないか。
38:デフォルトの名無しさん
14/04/15 21:45:31.32 z6touH+D
>>36
git graphっていう、よく出回ってるalias見て理解してる。つもり。
39:デフォルトの名無しさん
14/04/15 21:58:59.82 OKvn8yBf
git log --gragh --all
でツリー出てくるよ。
コミットログの書式短いのにした方が見やすいけど。
40:デフォルトの名無しさん
14/04/15 22:10:15.34 JExjPciB
とりあえずならこんな感じか
git log --graph --all --decorate --oneline
自分はこれだとちょっと表示が気に食わないので、
--decorate --onelineの代わりに--pretty=formatで表示を加工してる
41:デフォルトの名無しさん
14/04/15 23:55:03.38 4LopPBVb
俺はDropboxにbareリポジトリ置いてるだけだ。
壊れるのが怖いから時々zipに固めてるけど。
42:デフォルトの名無しさん
14/04/16 00:09:16.13 7KV1DqqH
>>34-35
ありがとうございます。
>>8を見ながらインストールしてみました。
取り合えずローカルで使う予定なのでコミットまで一通りやってみました。
ローカルで使うならリポジトリの共有以降は不要ですよね(Gitとしての恩赦も薄そうだけど)
皆さんはリモート使って他の人と共同で何かを作ってるんでしょうか？
仕事で使う以外はローカルでも不便しなさそうですが、勉強のため開発と平行して使い方を勉強していこうかな。
43:デフォルトの名無しさん
14/04/16 00:27:33.04 23qQxnbb
リモートリポジトリを使った共同作業が git の本領発揮するとこだから読んでおいたほうがいいと思うけどな
一人で使ってるんだとしても、作業用のローカルリポジトリとリモートの(別にリモートじゃなくてもいいが)マスターリポジトリが分かれてると
push/pull のタイミングでコミット纏めたりとか出来て都合がよかったりするし
自分は githubでプログラム書いたり設定ファイル載せたりしてる
基本的に自分ひとりで書いてるけど誰かが勝手にバグ直してパッチ送ってきてくれたりして楽しいよ
逆に公開されてるソフトなんかで気になる部分を修正してパッチ送ったりとかね
とりあえずアカウントでもとって練習用として色々遊んでみたらいいんじゃない
44:デフォルトの名無しさん
14/04/16 00:37:04.13 FwnwH35E
>>36
githubフローに近いやり方で開発している。
自分が開発しているブランチがどこから分岐したかとかは一応把握してる。
それでも忘れるけど忘れたらgit log --decorateで確認するだけ。
自分が作業中のブランチはそんなに多数に平行して
開発するわけじゃないので、数個にしかならない。
他人のブランチの状態や過去のブランチは何も考えていない。
知りたくなったら調べるけど、基本的に無監視。
気にしてるのは、masterが更新されたかどうか。
基本的に自分のブランチは「masterの最新からの開発」という形にしたいから
誰かがマージしてmasterが更新されたら、git rebase masterして
masterの最新からの開発に配置し直す。・・・ってのを定期的に行う。
あとは単純にmasterにリベースしづらい時とか、一時的に他の人のコミットを取りたいとか
なんかミスってコミットを整理し直したいとかイレギュラーな作業でcherry-pickを使う程度。
まあ分岐しまくってそれを把握しなきゃってことはまずないよ。過去は忘れて、自分の現在の作業分だけ。
45:片山博文MZバグロボ ◆T6xkBnTXz7B0
14/04/16 01:17:21.34 9W1Fzx+3
VS2013でgit使ってるか？
どうやるの？
46:デフォルトの名無しさん
14/04/16 01:21:41.21 xXOno5ZN
Use Visual Studio with Git
URLﾘﾝｸ(msdn.microsoft.com)
47:デフォルトの名無しさん
14/04/16 01:35:45.97 vWpEG2+U
>>36
初心者はgitk --allでビジュアルに状態を確認しながら
雰囲気をつかむと良いと思う。
あと、「開発・バグフィックスはすべてトピックブランチを作って作業する。」
「トピックは原則としてmasterから分岐する」などのルールを設けて、
確認しないといけないこと(分岐元がどこか、とか)を減らす。
統合ブランチは master またはmasterの先端に作った使い捨てブランチだけにして、
マージ状況は log --oneline --first-parentで俯瞰するなど
ワークフローを工夫すれば、正確なコミットグラフをイメージしなくても
だいたいの状況を把握できるようになる。
48:デフォルトの名無しさん
14/04/16 03:11:28.56 EGmRT2AB
たまーに他人のコミットとコンフリクトしまくったりマージのミスでバグが混入したりするから、そういうときにコミットツリーをよく確認したいときは、
SourceTreeとかGitHub/BitBucketとかのサービスで詳細に把握しようと思うことはあるかな。大抵はそこまで把握しなくてもトラブらないけど。
49:デフォルトの名無しさん
14/04/16 03:16:00.58 FwnwH35E
それってツリー見てなにかわかるん？
50:デフォルトの名無しさん
14/04/16 03:22:23.47 LjaPwUAW
というよりbisectだよね
51:デフォルトの名無しさん
14/04/16 03:24:09.57 O1uBrWmJ
自動ビルドテストしようず
GitHubでプルリクエストすればマージ前でも自動テストしてくれるみたいだからリモート環境だけでテストできるんじゃないの
やったことないしどうせ自動化のテストはローカルでしなきゃならんけど
52:デフォルトの名無しさん
14/04/16 03:40:07.18 FwnwH35E
そういやbisectで思い出したけど、
テストコードをしっかり書いているとする。
バグが何処かで混入されたとして、
それを見逃したということはテストコードがなかったということになる。
そこで新たにテストコードを追加する。
さて、このテストコードを使って、どこでバグが混入されたかを
bisectで調べるにはどうしたらいいだろう？
git bisectをするたびにコミットが変わるのはいいんだが、
そのコミットには当然追加されたテストコードは含まれていない。
やばい、酒ははいってて、何を書いているのかわからないｗｗｗｗ
53:デフォルトの名無しさん
14/04/16 03:40:53.57 FwnwH35E
おーい、ちゃんと文章なりたってるかー？ｗ
54:デフォルトの名無しさん
14/04/16 03:49:55.54 EGmRT2AB
>>49
上手いこと説明できないが、ツリーがないよりあったほうがマージのやり直しはしやすい気がする。たぶん自分が関わってるプロジェクトの特性上のものだと思う。
まあ、ツリーだけってよりは1個1個コミットを見ていってそのローカルブランチではなにをするつもりだったのかとかを解釈していくという方が重要なのだろうけど。
>>51
インタラクティブなアプリだと自動でのビルドテストがかなり難しいんだよね。
OpenGLとかメディア系ライブラリと各種センサを使ったアプリとかだと、描画が想定通り行われてるかとか、ムービーが正しく再生されてるかとか、
センサの値が正しく反映されてるかとか、そういうものをテストコード書くのが難しすぎる、というか結局人間が解釈しないとOKかNGか判断できないものが
多すぎてTDDしづらいんだよね。ゲームとか典型例なんじゃないかな？
55:デフォルトの名無しさん
14/04/16 04:03:18.65 O1uBrWmJ
>>54
そりゃ無理だな
UIが複雑なのはテストの維持がめんどすぎて割に合わない
56:デフォルトの名無しさん
14/04/16 12:51:47.35 LjaPwUAW
>>52
git bisectはコミットされてないdiffを各コミットに適用してくれるから、
テストコードを自動マージできるように書いて
それをコミットしないままbisectすればできるよ
57:デフォルトの名無しさん
14/04/16 14:21:34.93 zACk8w4U
漏れはソースを他人に見せたくて仕方がない
露出狂鴨試練
58:デフォルトの名無しさん
14/04/16 21:49:07.29 SSurM9Qy
git statusをgit sだったりgsにエイリアスを設定して短くするやり方ありますよね
これgitの開発人たちに公認公式のエイリアスの設定方法って公開してませんかね？
59:デフォルトの名無しさん
14/04/16 21:52:45.78 23qQxnbb
alias の設定の「仕方」なら公認公式もへったくれもなく今やってる方法が公式だろうと思うが
大抵の人が設定してるであろう、一般的な alias の一覧みたいなのないかってことかね
60:デフォルトの名無しさん
14/04/16 22:13:23.97 QCJjs0GG
git config alias.変更表示 diff
こんなのがあったところで使うかよｗ
そんなの自分の自由
61:デフォルトの名無しさん
14/04/16 22:59:29.71 HsjrRpyw
shellのalias使えば良いだけじゃね？
62:デフォルトの名無しさん
14/04/16 23:18:22.32 YDFUIFCV
git sとか一意に出来るところまであれば自動で補完して実行する機能をオンオフ出来れば良さそう
63:デフォルトの名無しさん
14/04/17 03:15:07.74 KNGPRiph
>>56
サンクス
コミットしないままbisectできたのか。
まあ確かに動き的にはcheckoutしているだけだもんな。
64:デフォルトの名無しさん
14/04/17 03:18:41.09 KNGPRiph
>>58
subversionを真似したら？
短いエイリアスがあるから。
gitのコマンドが長いのは、短縮は自分で好きなの
割り当る用だと思ったりもしてるんだけど
なんか理由あるのかな？
65:デフォルトの名無しさん
14/04/17 13:12:49.12 ns8t/lZO
設定してあるエイリアス晒してみる
st = status
ci = commit
co = checkout
br = branch
dif = diff
difc = diff --cached
lo = log --oneline
lf = log --first-parent
lof = log --oneline --first-parent
66:デフォルトの名無しさん
14/04/17 13:45:04.02 aPfzsLri
statusはsだろうが
commitはcだろうが
きめえよ
67:デフォルトの名無しさん
14/04/17 14:05:07.53 vWEx34Yo
一番良く使うstatusとかlogはシェル関数で置き換えちゃってるな
gst = git status -s -b
glo = git log --graph --branches --remotes --pretty=format:'%C(black white)%h%Creset%C(blue bold)%d%Creset %s'
68:デフォルトの名無しさん
14/04/17 16:24:56.84 xYf1zYlh
>br = branch
わかる
>dif = diff
まぁ、わかる
>ci = commit
どういうことなの
せめてcmでしょ
69:デフォルトの名無しさん
14/04/17 16:47:58.48 ns8t/lZO
>>68
俺はかつてCVSユーザだったんだが、
CVSのcommitはciというエイリアスを持ってたんだよ。
SVNもciはcommitのエイリアスになってるだろ？
といってもそもそも何でCVSのcommitがciなんだよ？って話だよな。
CVSは当初、その前に流行した単一ファイルバージョン管理用RCSにかぶせてつかう
ディレクトリツリー管理拡張のためのラッパースクリプトとして登場した。
RCSのコミットに相当する操作はcheck inと呼ばれ、コマンドはciだった。
CVS, SVNはそれを継承してるというわけだ。
現在でも主要なディストロはだいたいRCSのパッケージを持ってて、
インストールすればciコマンドを使えるぞ。
ちなみにRCSのcheckoutは当然coだから使い方はmanを見てくれ。
70:デフォルトの名無しさん
14/04/17 17:02:55.46 x5+myCPx
ci co は結構多いと思うぞ。
過去の VC の流れで。
71:デフォルトの名無しさん
14/04/17 17:04:57.52 7VV2HzZ+
checkinの略だったよね？
72:デフォルトの名無しさん
14/04/17 17:32:10.40 x5+myCPx
github で gitconfig alias で検索すると結構色々でてきて面白いな
URLﾘﾝｸ(github.com)
わりとみんな同じ感じなんだねえ
73:デフォルトの名無しさん
14/04/17 17:33:57.98 xYf1zYlh
そうなんか、知らんかった
調べたらmercurialもciなんだな
74:デフォルトの名無しさん
14/04/17 17:38:39.61 Fx1ijgIa
branchはbだろうが
diffはdだ！
75:デフォルトの名無しさん
14/04/17 17:44:29.46 x5+myCPx
一文字だと不安(?)なのか二文字が多いなgithubだと
76:デフォルトの名無しさん
14/04/17 18:39:15.48 ns8t/lZO
2文字派か1文字派か。主要コマンドは比較的統一してる人多いね
77:デフォルトの名無しさん
14/04/17 18:50:05.36 gzIoS/KQ
ｃがかぶりやすいからだなｗ
78:デフォルトの名無しさん
14/04/17 18:52:52.00 zmGYf3iT
おれはねエイリアスでgit revertをecho ""に設定している
危ないコマンドや初心者が過去を隠すために使うようなコマンドをあえて禁止している
79:デフォルトの名無しさん
14/04/17 18:56:43.52 vWEx34Yo
git revertは危なくもないし過去を隠すコマンドでもないだろ
80:デフォルトの名無しさん
14/04/17 20:34:51.97 ns8t/lZO
むしろイケてない過去のコミットを無かったことにできるのがgitの利点かと思うが
81:デフォルトの名無しさん
14/04/17 21:44:17.51 XZy5mn+7
revertを禁止にするならresetも禁止にするべき
前進あるのみ
82:デフォルトの名無しさん
14/04/17 21:47:12.93 KNGPRiph
え？ エイリアスの話？
俺は、
bisect bad に bisect-fixed を
bisect good に bisect-unfixed を
割り当ててる。
便利だよ。
83:デフォルトの名無しさん
14/04/17 22:05:50.07 i6eMI8h0
晒してみる。省略形は多用するとクセになるから避けてるなぁ
[alias]
serve = daemon --reuseaddr --base-path=. --export-all --verbose
stat = status --short --branch
exec = "!exec "
84:デフォルトの名無しさん
14/04/17 22:10:52.86 u3XqYAfL
>>36ですが皆さん（>>38-40 >>44 >>47 >>48）アドバイスをどうもありがとうございます。
いやーgitをよく知らないままgitで大勢でメンテしているプロジェクトに送り込まれて
しまいまして。
とりあえずgitkとかで表示してみました... うわっ、平行な線が沢山走っている部分が!
なんか宇宙戦艦ヤマトのワープの図を複雑にしたような（たとえが古いか）
線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
85:デフォルトの名無しさん
14/04/17 22:23:16.22 KNGPRiph
開発する人数やワークフローにもよるけど、平行な線は
沢山あるべきじゃないよ。マージしづらくなるからね。
86:デフォルトの名無しさん
14/04/18 02:04:45.06 G95hrNw/
>>84
> 線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
むしろそこは多量のブランチをマージしたところなのでものすごい速度が落ちてるとこじゃないかな
87:デフォルトの名無しさん
14/04/18 10:26:06.59 TiuM1iK+
初心者ですけどリポジトリを作ったフォルダの中が管理対象になるんですよね？
でそのリポジトリを削除するとソースファイルまで削除されるんですが
もちろんブックマークだけ（sourcetreeで)の削除はできるのですが
間違ってハードディスク上のリポジトリを削除してしまったら大変です。
何か対策はあるのでしょうか？それともこういうものなのでしょうか
88:デフォルトの名無しさん
14/04/18 10:28:30.25 V7HQhmWQ
そりゃそうだろう
リモートにあろうがローカルにしかなかろうがリポジトリ物理的に消したらなくなるわな
大事ならバックアップとっといたらいい
89:デフォルトの名無しさん
14/04/18 10:30:51.17 l4m/ooPn
bitbucketあたりにアカウントとってそっちにプッシュしておくとか
90:デフォルトの名無しさん
14/04/18 10:51:55.78 TiuM1iK+
ローカルのみで使おうと思ってたのですがリモートにも上げた方がよさそうですね
91:デフォルトの名無しさん
14/04/18 11:00:45.77 KSddQ8SJ
Dropboxにリポジトリを作るやり方はここの先輩方はやってますか？
92:デフォルトの名無しさん
14/04/18 11:01:59.07 V7HQhmWQ
>>41にそういう奴がいるな
93:デフォルトの名無しさん
14/04/19 12:55:58.24 7PgX0mPg
>>84
gitkはgit log(というかgit rev-list)と同じ範囲指定が可能だから、
--allで表示が多すぎるなら表示範囲を適切に限定してやればよい。
特定のtopic(ここではmasterから分岐したとする)とmasterにだけ注目すればいいんなら
gitk master..topic (masterから分岐後のtopicのコミットのみ表示)
gitk master...topic (masterから分岐後のtopicのコミットとmasterにマージされたブランチを表示)
とか。範囲指定は複数回可能なので関係する範囲を好きなだけ指定すればよい。
94:デフォルトの名無しさん
14/04/20 20:26:37.01 mILxVbg/
>>91
.zshrcとか.vimrcとかをつっこんだリポジトリはDropboxにbareで載せてる。
95:デフォルトの名無しさん
14/04/21 13:00:54.05 ZKyIOHr8
gitignoreで
/*
/.*
このふたつを指定しているのをたまに見かけますが
はじめに/*ですべてのファイルを除外しているので/.*を書く意味は無いと思うんですが何故書くのですか？
96:デフォルトの名無しさん
14/04/21 14:22:29.42 dtgq5rdV
ドットで始まるファイルは * のワイルドカードにひっかからない仕様になってる。
シェル由来だね。
97:デフォルトの名無しさん
14/04/21 16:06:02.61 mYIG7FH4
なにそれバグだろ
クソだなgitって
98:デフォルトの名無しさん
14/04/21 20:57:12.01 1sDt+ic8
無知発見
99:デフォルトの名無しさん
14/04/21 21:13:29.40 fKV6ATCG
餌を与えないでください
100:デフォルトの名無しさん
14/04/21 21:48:05.88 yaM3rCK5
gitは糞だからsubversionを使え
101:デフォルトの名無しさん
14/04/21 22:43:41.18 KhXBvEFh
やだGitじゃないと
VSS、これ最悪でした。
チェックアウトされたままコンパイル通らない状態で担当者休み。どーすんの？
でもMSじゃないと駄目、OSSなんか信用できないとかで泣く泣く使う現場多数。
それに比べるとSubVersionかなりマシだけどオフラインな状態でコミットできない。
ちょっと痛い。
102:デフォルトの名無しさん
14/04/21 23:08:04.07 /9iyZBJ2
バージョン管理はgitしか使ったことがない
SVNは何がなんやらサッパリわからないから使えない
103:デフォルトの名無しさん
14/04/21 23:28:39.44 wk0llTNx
>>101
× SubVersion
○ Subversion
104:デフォルトの名無しさん
14/04/21 23:37:15.06 vVBjDa2G
オフラインの状態でコミットできないとか言ってるけど
コミットしたところでローカルにあるだけだからオンラインで他の奴がお前のリポジトリに
アクセスできなきゃ何もかわらんだろアホか
105:デフォルトの名無しさん
14/04/21 23:51:33.94 KhXBvEFh
例えばあなたが飛行機で移動中に１０項目ぐらいの作業して
帰社してコミットする時にコメントに１０項目だらだら書くの？
やーだー
106:デフォルトの名無しさん
14/04/22 00:01:10.97 4JSOLbvH
移動中に仕事するようなワーカホリックになりたくないわ正直
107:デフォルトの名無しさん
14/04/22 00:05:36.52 DheOpfOv
一例として挙げただけなのに。想像力無いなあ。
108:デフォルトの名無しさん
14/04/22 00:32:53.01 ysn+k/fU
セキュリティ的なこと考えるとオフラインでソースにアクセスってあんまりないんだよね
109:デフォルトの名無しさん
14/04/22 00:48:34.17 9W1A4/eN
>>97
いわゆるシェルは.(ドット)で始まるファイルは隠しファイルとしている
隠しファイルは ls *.conf とかで表示されない (.hoge.conf とか)
そんな時に rm *.conf して普段表示されてないファイルが消えるのは困る
だから * だけでは隠しファイルにマッチしないようになっている
ちなみに git が内部でどう処理してんのかは知らん
110:デフォルトの名無しさん
14/04/22 13:52:48.51 +yEK9mtt
ふつーにfnmatchでは
111:デフォルトの名無しさん
14/04/23 05:15:19.40 7ZWtOh9Z
commit A
commit B
commit C
commit D
commit E
commit F
と順番に作業して
あとから B から D をまとめて
commit A
commit b(B-D)
commit E
commit F
としたいときはどうすれば・・・
112:デフォルトの名無しさん
14/04/23 05:24:18.61 kDpoyMyg
よう知らんけど
↓のsquashというやつで出来るんじゃないの？
Git - 歴史の書き換え
URLﾘﾝｸ(git-scm.com)コミットのまとめ
> # s, squash = use commit, but meld into previous commit
113:デフォルトの名無しさん
14/04/23 07:20:48.07 fIp3qZsI
>>111
rebase -i
114:デフォルトの名無しさん
14/04/23 09:40:59.20 T4x0zu0j
２．０って来月でる？
115:デフォルトの名無しさん
14/04/23 20:35:59.48 7vo5B08Z
>>111と反対に、一つのコミットであるbを
B-Dに分割したい時どうしてる？
俺はrebase -i
116:デフォルトの名無しさん
14/04/23 22:04:37.40 59LgjvrD
rebase -i はいろいろ便利だよな
ただ慣れないと指定にちょっと戸惑う
>>111みたいにB以下をいじりたい場合だと rebase -i A ってしなくちゃいけないんだよな
それと、まとめたり順番入れ替えるだけなら操作は簡単だけど、バラす場合はちょっと操作がややこしい
117:デフォルトの名無しさん
14/04/24 00:12:45.07 6IEmJN8m
git rebase -i のコミットの表示順とgit logの表示順が逆なのは何故なんだぜ？
逆に表示するオプションあるけどグラフ表示とは併用できませんし。
118:デフォルトの名無しさん
14/04/24 01:22:42.87 cdLHxk0K
logは新しい順に表示しないと不便だと思うし(見たいのは最新の辺のことが多いよね)
rebase -iの指示書は、前のコミットにまとめるとかの指定することを考えると古い順に並んでたほうがわかり易い気がする
まあ、自分は慣れてしまったからかもしれないが
119:デフォルトの名無しさん
14/04/24 01:29:19.68 SDYiDObT
>>116
rebase -i B^
120:デフォルトの名無しさん
14/04/24 05:27:42.49 6xlhO1bi
rebase -i ^_^b
121:デフォルトの名無しさん
14/04/24 13:18:49.88 QakcezKL
最新のコミットだけプッシュする方法と
最新のタグをつけたコミットだけプッシュする方法
２つおしえてください
122:デフォルトの名無しさん
14/04/24 13:19:34.50 QakcezKL
なぜかというとコミットログからニートがバレるのでコミットログを全部プッシュしたくないからです
123:デフォルトの名無しさん
14/04/24 13:22:26.51 V8z90YIW
>>121
sqush
124:デフォルトの名無しさん
14/04/24 13:47:51.32 JOpp0cve
githubのコミットログからニートを検索するツールはよ
125:デフォルトの名無しさん
14/04/24 19:02:31.15 yOTIc0ZO
その前に日本人を探すツールが必要だ
126:デフォルトの名無しさん
14/04/24 21:18:41.68 hPYav21o
>>122
git filter-branch --env-filter 'GIT_COMMITTER_DATE="Thu, 01 Jan 1970 09:00:00 +0900
"; GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE' --all
127:デフォルトの名無しさん
14/04/24 22:02:19.45 6xlhO1bi
コミットログに日時変えればいいだけじゃん。
128:デフォルトの名無しさん
14/04/24 22:18:20.71 0H30XzcZ
git init
git checkout -b test
>Switched to a new branch 'test'
git branch
>何も表示されない
git checkout test
>error: pathspec 'test' did not match any file(s) known to git.
なんもコミットされてないとこうなるんですがどうしてこうなるんですか？
129:デフォルトの名無しさん
14/04/24 22:21:42.53 hPYav21o
>>128
その状態だと、HEADはrefs/heads/test向けのsymbolic-refになっているが、
そもそも指すべきコミットがないのでrefs/heads/testは存在しない。
よってbranchも何も表示しないし、checkoutもできない。
130:デフォルトの名無しさん
14/04/24 22:23:42.17 0H30XzcZ
仕様なんですか
一番最初のコミットが汚れるのがいやですね
131:デフォルトの名無しさん
14/04/24 22:25:13.61 6xlhO1bi
rebaseすればいいじゃんｗ
俺は、とりあえず空コミットを作る。
かもしれないし、作らないかもしれない。
132:デフォルトの名無しさん
14/04/24 22:26:57.87 hPYav21o
>>130
つまりコミット無し状態でブランチを複数作りたいということ？
133:デフォルトの名無しさん
14/04/24 22:31:15.84 0H30XzcZ
漢がrebaseなんて許せないタチなんですよ
コミットなし状態からブランチを分けて開発したいんです
基本的にmasterは汚したくないのです
134:デフォルトの名無しさん
14/04/24 22:33:01.48 6xlhO1bi
subversionがだめな理由が
rebaseできないからなんだけど？
それぐらい、というかそれ以上に
よく使う機能だぞ。
汚くしないためにrebaseがある。
135:デフォルトの名無しさん
14/04/24 22:37:44.72 hPYav21o
>>133
129で言ったようにHEADが存在しないrefを参照していればgit initした状態と同じなのだから、
二個目のブランチを作るときにgit checkout -bではなく
git symbolic-ref HEAD refs/heads/branch_name してから開発を進めればいいじゃない
136:デフォルトの名無しさん
14/04/24 23:47:09.80 T/Y/fuz3
>>133
そこまで潔癖ならマージもしないだろうからブランチじゃなくてリポジトリを分けたら？
137:デフォルトの名無しさん
14/04/25 00:27:14.58 kupFdBxu
master汚したくないっていうのが出来たとして、
1つ目のcommitがあって、それがtestブランチだとする。
が、masterはこのcommitから辿れる親コミットも指してないし、どれも指していない。
fast forward mergeできない状態だけどいいの？
どうせmasterはなにかしらコミットした段階で一番汚されてなくたってそのコミットを指してしまうのだから、コミットしてからチェックアウトしてもいいじゃん。
138:デフォルトの名無しさん
14/04/25 03:08:01.24 XQM8U6nM
mergeする予定無いのにブランチ切りたいとか意味不明すぎる
139:デフォルトの名無しさん
14/04/25 04:07:01.58 zu0sgmwa
空コミットじゃあかんのか？
つか空の.gitignoreくらい作ってからでも汚れとは思わんぞ
140:デフォルトの名無しさん
14/04/25 04:20:32.33 jzYptMLV
気に入らない部分があってもgitを使わざるをえない人は大変だね
個人の趣味でやってるならVCSは好きなのを使えるのにね
141:デフォルトの名無しさん
14/04/25 04:23:50.66 4klH39dY
気に入らない部分が、git以外には多すぎる。
142:デフォルトの名無しさん
14/04/25 05:28:33.42 cdj1D6xv
だねー
俺はローカル全部svnだわ
143:デフォルトの名無しさん
14/04/25 08:52:14.28 xiFjVo8G
３つ前のコミットに戻ってブランチを分岐したい場合ってどうすればいいのでしょうか
３つ前に巻き戻してからブランチするのでしょうか
最後の２つのコミットも念のために残したいのでブランチにしたいのです
具体的には
最後の２つのコミットの変更が破棄になったけど
念のために残したい
という状況です
144:デフォルトの名無しさん
14/04/25 11:14:49.10 4klH39dY
三つ前のコミットIDから
ブランチ作ればいいじゃん。
145:デフォルトの名無しさん
14/04/26 02:05:43.27 pkQNyj+N
>>134
rebaseはブランチ取り込むときにontoと組み合わせて使うことの方がおおいなぁ。
コミットログの都合もあるから履歴整理にはほとんど使ってない人がここに。
146:デフォルトの名無しさん
14/04/26 02:08:06.72 /GEUo84h
なんでブランチ取り込む時にontoなんだ？
普通にマージかチェリーピックすればいいだろ。
そのための機能なんだから。
147:デフォルトの名無しさん
14/04/26 02:26:05.50 pkQNyj+N
やり方がわるいんかな？
複数のブランチ平行したときとかontoつかってカットする感じに履歴いじらないとFFになってくれないことが多かった。
148:デフォルトの名無しさん
14/04/26 02:39:25.28 7YL+swb1
>>147
だからなんでFFにするんだよ
149:デフォルトの名無しさん
14/04/26 02:41:39.49 /GEUo84h
onto使ったら必ずほぼ確実にFFできないだろ？
なんか無駄に複雑なことしている気がするな。
150:デフォルトの名無しさん
14/04/26 13:53:59.32 Vv5x70uz
ホームディレクトリ以下の設定ファイルだとか、個人で使ってる自作ツールはSubversionで管理してる
ブランチ分けるどころか、リポジトリも1つだけで全部まとめて入れてる
そういう使い方するとGitよりSubversionが使いやすい
151:デフォルトの名無しさん
14/04/26 13:58:18.76 /GEUo84h
>>150
いや、ディレクトリがわかれるだろ？
subvertionを使うと、
* ファイルがあるディレクトリ
* リポジトリ
と二つにディレクトリがわかれるだろ？
それだけで使いづらいじゃん。
152:デフォルトの名無しさん
14/04/26 14:05:48.63 Z8XCebgD
?
153:デフォルトの名無しさん
14/04/26 14:20:33.69 dMJ+hsKf
>>151
全くその通りなんだけど、svnしか使った事のない人には多分理解出来ないと思う。
154:デフォルトの名無しさん
14/04/26 14:56:15.48 1yS20LQ1
リポジトリを1つだけだとさ
じゃあ例えば
C:/php/.git
C:/php/bbs
C:/php/wiki
C:/php/cms
みたいなのがあって、C:/php/cmsの履歴だけ戻す場合とか苦労するぞ
155:デフォルトの名無しさん
14/04/26 15:03:43.34 /GEUo84h
なぜリポジトリを一つにまとめるのか？
リポジトリを作るのが面倒であるということである。
156:デフォルトの名無しさん
14/04/26 18:03:12.98 Vv5x70uz
リポジトリをたくさん作るとその数だけcheckoutしてpull/updateしてcommitしないといけない
自分一人で使うだけでそんな面倒なことしない
157:デフォルトの名無しさん
14/04/26 18:26:46.44 ztOmzoR+
subversionだと、このようにpullやupdateや
commitがすごく大変で間違えられない作業なので、
このように避けようと思うようになります。
gitだと気軽なのにね。
158:デフォルトの名無しさん
14/04/26 18:27:44.99 bHDNIx6I
cvs使ってた10年以上前は、私もひとつのリポジトリでやってたことがありました。(*ﾉωﾉ)
159:デフォルトの名無しさん
14/04/26 18:30:43.24 Vv5x70uz
一人でしか使わないんだからコンフリクトなんかしない
commit間違えたらもう一回commitするだけ
開発頻度の低いファイルの管理にgitは過剰
160:デフォルトの名無しさん
14/04/26 18:39:48.80 ztOmzoR+
>>159
コンフリクトかどうかは
重要じゃないよ。
gitが便利なのは過去を修正できるって所。
一人でやっていても、簡単なミスはするもの。
追加漏れのファイルを追加
スペルミスの修正
こんなマヌケなコミットを残さないで済む。
161:デフォルトの名無しさん
14/04/26 18:42:46.95 ztOmzoR+
subversionが残すのは"作業"履歴なんだろうね。
gitが残すとのは"修正"履歴
だからsubversionは、いろいろ作業したものが
そのまま残って、あとで、で結局何をしたかったの？って
わけがわからなくなる。
gitは修正履歴だからこのコミットで何を修正したかが
はっきりするから、ある修正を取り除こうとした時も簡単。
subversionだとある修正を取り除くとき
それに関する作業を洗い直さないといけないけど、
gitだとそのある修正に対するコミットがどれかはすぐに分かる。
162:デフォルトの名無しさん
14/04/26 18:47:04.31 ztOmzoR+
subversionだと作業履歴が残っちゃうから
ちょっと気軽にコミットしようということができない。
gitだとちょっと一旦ここでコミットしておいて
少し違う作業をとか、こまめにコミットしておいて
あとでまとめようとか、一つのファイルの修正のうち
一部分だけをコミットしておこうとか簡単にできるが
subversionだとこまめにコミットしたら
その内容がずっと残る。恥ずかしいから
こまめにコミットできない。
あとでまとめてやるからいろんな修正が混ざってしまう。
163:デフォルトの名無しさん
14/04/26 18:56:37.43 Vv5x70uz
.bashrcや.inputrcが数千行になったらgitの導入を考える
164:デフォルトの名無しさん
14/04/26 18:57:44.05 ztOmzoR+
HAHAHAHA、基準がおかしい奴がいる。
こういう奴がgitに反対しているわけさ。
165:デフォルトの名無しさん
14/04/26 19:04:14.03 a+LUSt4b
bareめんどくない?
166:デフォルトの名無しさん
14/04/26 19:10:57.12 Vv5x70uz
だいたい.screenrcに対する特定のコミットを取り消すとか、そんな必要性感じたこと一度もない
167:デフォルトの名無しさん
14/04/26 19:12:42.80 ztOmzoR+
面倒くさいなら作らなくていいよ。
bareは必須ではない。
gitを始めるのに必要なのはディレクトリで
git initするだけ。
これでもうすぐにブランチ切り替えも
タグの作成もできる。
某subversi○nみたいに
わざわざtrunk、branches、tagsディレクトリを作って
コミットなんて面倒なことしなくていい。
168:デフォルトの名無しさん
14/04/26 19:13:48.14 ztOmzoR+
>>166
君は.screenrcの管理とかしかしないんだねｗ
えぇ、subversionは面倒だからでしょうね。
気軽に始められないｗ
169:デフォルトの名無しさん
14/04/26 19:17:57.35 Vv5x70uz
いや、何の事かわからないが、subversionでもgitでもどういうブランチ構成にするかはその人次第だから
170:デフォルトの名無しさん
14/04/26 19:22:53.05 ztOmzoR+
subversionにおけるブランチの作り方
※ブランチ作るたびに、この長いURLをいちいち入力する必要があります。
svn cp URLﾘﾝｸ(www.example.com) \
URLﾘﾝｸ(www.example.com)
gitだとこれだけです。
git branch v1p2p3
さてブランチに切り替えてみましょう。
svn sw URLﾘﾝｸ(www.example.com)
ぷぷぷぷｗ
なんでsvnはそんな長いURLが必要なんですか？ｗｗｗｗ
あ、ブランチは、ただのコピーでしか無いから、どこにでもコピーできる＝コピー場所を指定しなければいけないんですね。
これを毎回毎回入力して切り替えるんですね。大変ですねぇｗｗｗｗ
git checkout v1p2p3
みじかい！
171:デフォルトの名無しさん
14/04/26 19:24:43.18 ztOmzoR+
>>169
gitではブランチはブランチという機能なんで
subversinoみたいに、ブランチディレクトリ（branches）なんてのを
作る必要はないんですよ。
だからgitではブランチ名だけで、作成や切り替えが可能です。
いちいちディレクトリ（branches）書く必要はありません。
こんなの、き・そ・！ です。
172:デフォルトの名無しさん
14/04/26 19:30:14.03 y+As8odQ
おっ、そうだな
173:デフォルトの名無しさん
14/04/26 19:30:26.82 Vv5x70uz
いや、初めからブランチ作らないって言ってるし、.my.cnfでも.pgsqlでもなんでもいいが、ブランチ切って修正を分ける必要性を全く感じない
174:デフォルトの名無しさん
14/04/26 19:32:08.93 ztOmzoR+
※>>173 は「俺は日付毎のディレクトリを作るだけで十分」と言ってるのと同じだと見てあげましょうｗｗｗ
175:デフォルトの名無しさん
14/04/26 19:33:56.04 Z8XCebgD
なんでこの人こんなに発狂してるの・・・
別に git はゴミ！とか貶してるわけじゃないのに
176:デフォルトの名無しさん
14/04/26 19:34:13.93 Vv5x70uz
世の中には.ssh/configをテストファーストで日々更新してる人もいるのかもしれない、そういう人にはリリースと開発でブランチを分けてるのかもしれない
俺はそんなことしてないけど
177:デフォルトの名無しさん
14/04/26 19:35:28.56 ztOmzoR+
subversion使っている人は、みんな
ブランチ作らないって言ってるんでしょうかね
みんなブランチ要らないと言っているのであれば
subversion使っているだけで、アホとみなして良さそうですね。
実はブランチ作れないの間違いでしょうかねｗ
面白いですねｗｗｗ
178:デフォルトの名無しさん
14/04/26 19:36:05.09 ztOmzoR+
subversion使っている人には、
ブランチの必要性から説明しないといけないのでしょうか？ｗｗｗ
179:デフォルトの名無しさん
14/04/26 19:39:59.70 iVzDEppp
>>173
お前がブランチ作らないとかどうでもいいわ。
バージョン管理システムにおいて
ブランチは重要な存在であり、
subversionがブランチの管理が面倒だという事実に
代わりはないんだから。
それともSubversionの一般的な使い方において
ブランチは使うべきではないと言うつもりかい？
180:デフォルトの名無しさん
14/04/26 19:44:23.08 Vv5x70uz
いや、ホームディレクトリ以下の設定ファイルという前提なんだけど
個人の.bashrcを開発ブランチとリリースブランチに分けて更新するのが一般的という認識はなかった
181:デフォルトの名無しさん
14/04/26 19:46:55.41 koYBfWi3
ホームディレクトリ以下をgitで管理しようと思うのならば、
git initするだけでもう使えるよ。
subversionはそれだけで面倒。
最初の一歩の時点でもう負けてるんだ。
182:デフォルトの名無しさん
14/04/26 19:51:45.97 Z8XCebgD
なんか話を一般化して叩いてるけどホームディレクトリ内のファイルの管理ぐらい好きにやらせたれや・・・
183:デフォルトの名無しさん
14/04/26 19:54:06.41 HaseiyYq
自由にやっていいよ。面倒な方法だって言っているだけだから
別に面倒な方法だってわかってやってるなら問題ない。
面倒じゃないどころか、Subversionの方が簡単だって言い出すから悪い。
gitはgit initですぐにgit管理が始められるのに、
それよりも手間がかかるsubversionが簡単なワケがない。
せめて反証を出せと。
184:デフォルトの名無しさん
14/04/26 19:54:51.87 Vv5x70uz
>>181
なんでリポジトリを別の場所に置いたらダメなの？
特にマシン間で設定フィルを共有する場合、中央リポジトリが必要になるのは同じなんだから
185:デフォルトの名無しさん
14/04/26 19:56:09.41 Z8XCebgD
まあそこら辺は git スレでわざわざ頑張る内容ではないだろな
186:デフォルトの名無しさん
14/04/26 19:56:42.73 HaseiyYq
>>184
> なんでリポジトリを別の場所に置いたらダメなの？
ダメなんて言ってないだろ。
面倒だって言ってるだけ。
gitでも当然のようにリポジトリを別の場所におけるわｗ
だけど、リポジトリを別の場所に置くのは面倒。
必須でない作業なのだから、オプションであるgitの方が簡単。
少なくともその意見はsubversionの方が簡単だという理由にはなっていない。
リポジトリを別の場所に置くしか無いという欠点しか言っていない。
187:デフォルトの名無しさん
14/04/26 19:59:08.48 Z8XCebgD
>そういう使い方するとGitよりSubversionが使いやすい
これは「俺にとっては」ってのが頭につくだけの話でしょ。
別に白黒付けるもんでもなかろうに。
188:デフォルトの名無しさん
14/04/26 20:01:00.30 HaseiyYq
>>187
じゃあ、俺は、
「多くの人にとっては」って頭につけることにするよ。
お前ん中ではそうなんだろうなｗ
お前ん中では、設定ファイルの管理にぐらいしか使わないんだろうな
189:デフォルトの名無しさん
14/04/26 20:14:52.93 7bCdF05U
まとめ
（俺にとっては）Subversionの方が簡単
俺にとってはって、君、Subversionを何に使ってるの？
設定ファイルの管理だけど？
ブランチは使わない！
でもブランチやタグを使うと面倒だよね？
だから、俺はブランチは使わない！
ふーん、そう、それで何が簡単なの？
git なら git initだけで初められるけど。
gitで別の場所にリポジトリを置いてみなさい。
subversionはそれと同等！
いや、同等って、それ簡単ということになってないじゃん。
190:デフォルトの名無しさん
14/04/26 20:38:24.09 knmAOh4a
ブランチ使わないって前提の話で、subversionはブランチ作るのが面倒とか的外れな反論しておかしくなった
ドットファイルをブランチに分ける事は基本ないわな
191:デフォルトの名無しさん
14/04/26 20:42:18.34 7YL+swb1
>>190
俺はブランチを切りまくって、そいつらをマージしたものをマシン毎につかってるな。
いつのまにか47もブランチできてたわ。
192:デフォルトの名無しさん
14/04/26 22:24:36.07 jBTvJ1OX
Unix系のツールの設定ファイルとか複数の環境で使いまわすことが普通だし
最終的にはどんな環境でも一つの設定ファイルで動くようにまとめることが多いけど、
一時的に特殊な環境用にカスタマイズとかブランチ切って編集してるね
暇なときにマージして統合
193:デフォルトの名無しさん
14/04/26 23:35:52.72 pkQNyj+N
>>148,149
たとえば
$ git log --color=never --all --graph --pretty="[%h] %d %s"
* [6a1c481] (HEAD, master) 2
* [523984e] (branch2) branch2-2
* [6554768] branch2-1
| * [05c389f] (branch1) branch1-2
| * [6b85c6d] branch1-1
|/
* [9d47912] 1
ここから、 branch1をFFなるように取り込もうとしたら
$ git rebase --onto master 3829497 branch1 として 分岐なくしてからマージしない？
それとも履歴にはこだわらず、 rebaseで1世代だけにしてからcherry-pickするのが普通？
194:デフォルトの名無しさん
14/04/26 23:37:58.13 pkQNyj+N
>>193
$ git rebase --onto master 9d47912 branch1
の間違い、 行数削ったときに直すのわすれてた
195:デフォルトの名無しさん
14/04/26 23:46:42.24 7YL+swb1
だからなんでFFに拘るんだよ
196:デフォルトの名無しさん
14/04/26 23:47:26.43 7YL+swb1
>>193
あと、普通は
git rebase master branch1
で済む。
197:デフォルトの名無しさん
14/04/26 23:49:50.02 DhTsVAJ/
FFはCoolだかｒ
198:デフォルトの名無しさん
14/04/27 01:10:15.13 TcUJdg0l
>>196
その通りだね。
やっぱり無駄なことしてるじゃんｗ
onto使う必要がない所でonto使ってた。
199:デフォルトの名無しさん
14/04/27 05:35:56.46 /n7QikUK
svnでわざわざtrunk、branches、tagsディレクトリを作ってコミットなんて面倒なこと
ただの一度もしたことねえわ
200:デフォルトの名無しさん
14/04/27 06:08:30.59 TcUJdg0l
まあ、そういう変な人もいる。
201:デフォルトの名無しさん
14/04/27 10:01:09.95 YIeV8hDm
>>198
なくても平気なのかー、単純にrebaseするだけじゃダメな時あったんだけどなぁ、まっいっか。
FFこだわるのは、FF縛りがあるから。
202:デフォルトの名無しさん
14/04/27 10:13:05.46 +jGSbN4U
俺は、FFT派
203:デフォルトの名無しさん
14/04/27 14:15:59.24 ijMC55vL
git覚えたての子が暴れてて凄いなこのスレ
204:デフォルトの名無しさん
14/04/27 16:48:41.84 /n7QikUK
git派は自分のやり方以外は認められない原理主義者が多いんだろ
205:デフォルトの名無しさん
14/04/27 16:52:16.11 s0HPULD5
>>201
リモートから取り込んだコミットを
ローカルで改変してたりしないか？
開発用の修正を間に挟んだりとか。
206:デフォルトの名無しさん
14/04/27 20:05:48.91 0q81XbwG
>>205
それでもFFにならないわけはない。
207:デフォルトの名無しさん
14/04/27 20:42:56.75 RalmXzvw
>>9
>GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
>大塚 弘記
>URLﾘﾝｸ(www.amazon.co.jp)
この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
やたらけなしている人がいたが本当のところはどうなのか確認してみるつもり。
読んだらまた感想書く。
208:デフォルトの名無しさん
14/04/27 20:56:58.74 37jfUrsD
Gitについてはさわり中のさわりしか書いてないからまともにGit使おうと思ったら別の入門書買い足すことになるってだけだよ
209:デフォルトの名無しさん
14/04/27 21:34:00.25 FuM1UcuM
>>207
> この本買ってみた。題名とは違うがGitそのものの入門的な解説もちゃんとあるな。
でもGitの入門的な解説としてはよろしくない印象。
diff --cached を書いてなかったり、不自然な reset の例を示してたり。
まぁそれが主題じゃないからいいんだけどさ。
210:デフォルトの名無しさん
14/04/27 21:39:02.03 FuM1UcuM
>>201
> FFこだわるのは、FF縛りがあるから。
何がなんでもrebase && FF派ってやっぱlogが一直線になるのが嬉しいのかね？
俺的にはlog --first-parentで要約できないほうが辛いんだが、
もし他にrebase && FFの利点を知ってれば教えてくれ。
211:デフォルトの名無しさん
14/04/27 21:46:21.84 0q81XbwG
まっさきに思いついたのは無能なPMに強制されてるという理由だったが
212:デフォルトの名無しさん
14/04/27 22:46:45.69 y1TCx0zf
もうそろそろ2.0リリースされそうだけど使ってる？
213:デフォルトの名無しさん
14/04/28 01:24:17.91 r745xiPh
2.0は5月の第三週あたり
214:デフォルトの名無しさん
14/04/28 05:49:30.90 G/O2/oE+
プロジェクトいくつも首突っ込んでればリポジトリなんてすぐ数十にはなるわけで
手作業でpullだupdateだとかいちいちやるかよ
そんなもんはスクリプトで一括でやるもんだ
215:デフォルトの名無しさん
14/04/28 06:17:16.50 SIdeIE1K
Gitはリポジトリ数十になってもpullとか手作業でいいと思うが？
216:デフォルトの名無しさん
14/04/28 09:59:35.16 ES7XWIWl
どのプロジェクトが何の言語で書いたのかわかんない
githubのリポジトリに言語名/プロジェクト名で名前を付けても
スラッシュがハイフンに変換されるか不便
217:デフォルトの名無しさん
14/04/28 12:04:38.80 UImZVLxS
どの言語かなんて気にする必要ないだろ。
言語は変わるかもしれないし、複数の言語で
作られているかもしれないんだから。
言語名を頭に入れるという考え自体がおかしい。
218:デフォルトの名無しさん
14/04/28 12:26:41.94 ES7XWIWl
Git 2.0になって.gitconfigも変わる？誰か調べてる人いる？
219:デフォルトの名無しさん
14/04/28 12:27:37.63 ES7XWIWl
Gitインストールするときにタグ指定し忘れて開発版の最新2.0をインストールしたんだけど特に不具合ないんだよね
220:デフォルトの名無しさん
14/04/28 13:13:07.74 DVYrPedv
リリースノート読む限り大きな変更はgit pushのデフォルトがsimpleになることくらい？
自分の場合は既にsimpleに設定してたし
git addでパス省略ってやらないし影響なさげ
でも暫くは移行しない
221:デフォルトの名無しさん
14/04/29 03:34:15.62 yOn60HCq
>>210
FFは、利点がーというよりも、うちはリリースの終わったbranch削除しちゃうので一直線にまとまっていないと、都合悪いだけかな？。
btanchは開発工程の作業場所としてわりきってる。
222:デフォルトの名無しさん
14/04/29 04:05:17.29 5g+Rsf3h
>>221
FFじゃない状態でブランチマージしてから、そのブランチを削除すると何が問題になるのですか？
もしかして削除したランチに属していたコミットが消えちゃうのですか？
223:デフォルトの名無しさん
14/04/29 04:10:14.41 jiz/CQ6q
>>221
どういうふうに都合わるいのか詳しく頼む。
mergeコミットが残ってたほうがブランチの情報が残るという認識なんだけど。
224:デフォルトの名無しさん
14/04/29 09:19:49.77 wf66nSBF
修正履歴を残したいのに履歴をいじるのはおかしい
rebaseなんてGOTOと同じくらいいらない
225:デフォルトの名無しさん
14/04/29 10:11:12.30 gWfSfq0v
はぁ？
226:デフォルトの名無しさん
14/04/29 10:21:10.13 fjfML7VO
わざわざログを壊してまで見やすくしようっていうのがいらねえんだよ
コミッターが何をしたのか把握できないだろう
227:デフォルトの名無しさん
14/04/29 10:22:25.29 fjfML7VO
そういうのはタグで管理するべき
rebaseを使うのは下手くそが使うコマンド
228:デフォルトの名無しさん
14/04/29 10:41:22.64 jiz/CQ6q
議論が変な方向に行くのがイヤなんで一応ハッキリさせときたいんだけど、
俺が気にしてるのは rebase && FF マージね。
master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
FF merge するってやり方のこと。これをやりたくなる意味がわからない。
他の目的のrebase自体は問題ないと思ってる。
229:デフォルトの名無しさん
14/04/29 10:50:31.16 2NEMUWta
masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
意味がないならrebaseしてからのほうがログが読みやすい
230:デフォルトの名無しさん
14/04/29 10:58:37.39 fjfML7VO
どこで作業を行ったかの記録も重要である
余計なことはするな
231:デフォルトの名無しさん
14/04/29 11:14:43.54 jiz/CQ6q
>>229
> masterにブランチをマージするときに、そのブランチのベースがどこだったかという情報に意味があるか
どういう場合にベースを意味がある(または意味がない)くわしくたのむ
俺にとって重要なのはブランチの目的とその目的に向かってコミットがどう積み重ねられたのかであって、
ベースがどこかは明示的にはあんまり気にしないんだが。
FFマージじゃなければ統合ブランチの履歴を log --first-parent で要約できるのと、
マージコミットのログなどに表示される親コミット2つ使って
git log deadbeaf..cafebabe
のようにトピックのログだけ簡単に取り出せるのが便利なのに。
後者は内部で merge-base 使ってるのでベースに意味があるのは確かだが、
だとすれば常に(俺にとっては)意味があると言える。
232:デフォルトの名無しさん
14/04/29 11:21:26.26 LqsKRBzG
コミッターが行った作業をありのままに記録するべき
はたして捏造された記録に意味があるのか
233:デフォルトの名無しさん
14/04/29 11:33:05.72 EYu9TTok
>>224
コミットログとしてほしいものは、
修正の履歴であって作業の履歴じゃない。
コミットして1分後に気づいたタイポの修正なんか
修正の履歴として残す価値はないはない。
レビューを誰かに依頼して見つかったバグの修正なんか
修正の履歴として残す必要はない。
このコミットで何を修正するのかを明確に記録するには
rebaseは必須の機能。rebaseの機能なしで同じことを
やろうとしたら大変すぎて断念するレベル。
反論できる？
234:デフォルトの名無しさん
14/04/29 11:38:42.10 LqsKRBzG
その修正の裏に気づかずに別の箇所を修正しているかもしれない
不具合がそこにあればそこのログをみなければならない
でもそれを消しちゃったら困るよね
235:デフォルトの名無しさん
14/04/29 11:40:07.95 LqsKRBzG
>>233
だからそういうのはタグで管理しろ
236:デフォルトの名無しさん
14/04/29 11:49:24.38 EYu9TTok
>>228
> master(統合ブランチ)にトピックの作業を取り込む際に rebase してから
> FF merge するってやり方のこと。これをやりたくなる意味がわからない。
rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
masterへのmergeで起きたコンフリクトをその場で修正すると
バグを入れる可能性が高くなる。
コンフリクトが起きなければ問題ないが、いざマージしようと思った時に
コンフリクトが起きたら、修正する必要がある。
masterへの追尾が遅れれば遅れるほど、コンフリクトが起きる可能性も高くなるし、
コンフリクトが起きた時の修正も大変になる。だからこまめにmasterへrebaseしておく。
その一環として、最後にrebaseしておくだけのこと。
そうすればレビューアーも安心してレビューを行える。
もしかして一人での開発しかしてないんじゃない？
作った人とは別の人がレビューするとき、最新のmasterにマージできない状態だと困るんだけど。
レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
237:デフォルトの名無しさん
14/04/29 11:51:08.54 EYu9TTok
>>235
どうタグを使うっていうんだ？
そもそもタグの使い方が間違っている。
タグはある状態に対してつけるもの。
タグがついたらコードフリーズした状態で
それ移行変更してはいけない。
238:デフォルトの名無しさん
14/04/29 11:54:15.32 EYu9TTok
>>234
gitはrebaseしてもコミットが消えてしまうことはない。
コミットIDさえわかればその時のコードは分かる。
コミットIDはreflogに記録され続けるのでコミットIDがわからなくなることはない。
あとはdiffをとれば何を修正したかがわかる。
239:デフォルトの名無しさん
14/04/29 11:57:18.99 jiz/CQ6q
俺としては歴史修正ツールとしてのrebaseの使用には賛成なんだが、
やはりそっちの議論にいってしまうか。
いや、本当に全てのrebaseが有害と言ってるヤツもいるのかもしれんけども。
・rebase && FFマージの話
・歴史修正ツールとしてのrebaseの良し悪し
これらは分けて議論したいんだがな。
俺は後者としてrebaseは絶対必要だが、前者の使い方に疑問がある。
240:デフォルトの名無しさん
14/04/29 11:59:42.78 EYu9TTok
>>239
じゃあピンポイントで聞くわ。
開発者と、masterへマージ（レビュー）する人が別々の人だとする。
masterへマージする時にコンフリクトが起きました。
この時どうしますか？
1. 開発者に修正（rebase）してもらう
2. 自分で適当に修正する。
241:デフォルトの名無しさん
14/04/29 12:25:05.93 jiz/CQ6q
>>236
おぉ、そういう主張か。 >>239 はとりあえず忘れてくれ。
> rebaseしないでmergeしようとするとコンフリクトが起きる可能性が高い。
> masterへのmergeで起きたコンフリクトをその場で修正すると
> バグを入れる可能性が高くなる。
主題から少しはなれるがここはおかしい。
masterにマージする人間とtopicを作ってる人間が別人ならその場で修正なんかせず、topic 作ってるやつに一旦 merge か rebase させるべき。
topic 側から master をマージした直後なら、その topic を master にマージするときはコンフリクトは起きない。このときは master 側からは no-ff でマージすべきだが、topic作ってくれたやつがmergeした方向による。
もちろん topic 作ってる人間は rebase してもいい。たぶん君が取ってる戦略はこっちなんだろう。
ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
もう一度言うが、俺が気にしてるのは rebase && FFマージだからね？
rebase後にno-ffでマージしてるなら大きな疑問はないよ。(topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
> レビューする人は自分で作ったわけじゃないから、コンフリクトをどう解消させればいいか判断できない。
やっぱ他人なんだよな。mergeする場合はコンフリクトの解消はmerge/rebaseで書いたやつにさせるように運用するのがお勧めだよ。
242:デフォルトの名無しさん
14/04/29 12:27:35.28 jiz/CQ6q
>>240
> 1. 開発者に修正（rebase）してもらう
> 2. 自分で適当に修正する。
どちらかで選ぶなら1だね。ただし、そこにはmergeという選択肢もある。
そしてより重要なことだが、俺が疑問視してるのはそこじゃない。
rebase修正してもらうのはいい。そのあとFFマージをするのはなんでだぜ？ってこと。
243:デフォルトの名無しさん
14/04/29 12:30:47.09 EYu9TTok
> ただし topic を rebase したなら master にマージする人間は no-ff マージすべき。
gitlabでmasterにマージするときは、
ウェブの管理画面からボタンを押すだけ
その時勝手にno-ffされる。
というか、ウェブの管理画面からはno-ffでしかマージできない。
> (topic作る側はめんどくさそうだなってだけ。コンフリクトしないのに不要なrebaseも強制するわけでしょ？)。
コンフリクト起きないならrebaseもすぐに終わる。1コマンド入力してあとは自動処理。
コンフリクトするなら、結局どこかで作業するのだから大差ない。
コンフリクトするのかな～？って考えるぐらいなら
さっさと1コマンド入力して終わらせるだけの話。
244:デフォルトの名無しさん
14/04/29 12:35:19.57 jiz/CQ6q
>>243
> というか、ウェブの管理画面からはno-ffでしかマージできない。
rebase && FF派じゃねーのかよ (´・ω・`)
245:デフォルトの名無しさん
14/04/29 12:38:23.48 EYu9TTok
rebase派だけど、FF派じゃねーよ？
rebaseのあとはどっちでもいい派。
rebaseすることに異議を唱えてるんじゃないの？
246:デフォルトの名無しさん
14/04/29 13:06:53.85 jiz/CQ6q
>>245
ちがうよ、rebaseはなくてはならない重要なツール。
俺が疑問に思ってるのは rebase && FF だよ。
理由はrebase && FF してしまうと
1 log --first-parent で要約をとれなくなる
2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
から。詳しくは上の方を見てくれ。
247:デフォルトの名無しさん
14/04/29 13:21:06.01 GKmjQvWP
別にどっちでもいいというか
プロジェクトの性質に合わせて運用するべきで
他人がどうこう言うもんじゃないと思うが
FF派にとっては1と2は大して重要じゃないんでしょ
どうせログなんて参考にしかならんのだから
コードを追うならFFの方が都合がいい場合もあろう
248:デフォルトの名無しさん
14/04/29 13:47:07.80 +oyspTjV
プロジェクトの性質にもよるし、そのブランチで音一連の変更がどの程度の変更量かだったり、変更の意味にもよるし、mergeやrebaseをする人の技量にもよるよな。
merge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
URLﾘﾝｸ(blog.layer8.sh) (ちょっと違う例だけど)
こういうのって、ケースバイケースでしかないのに、mergeは悪！rebaseは正義！みたいに思っていそうで、
しかもこういうのを読んでmergeやrebaseの利点欠点について理解してない人たちがまたmergeは悪！rebaseは正義！と思い込んでしまって、害しかないと思うんだよな。
pullしてマージが発生したら「これでは自分が持っていたコミットの方が正統としているようなものです。origin へ push したのは a と b の方が先なのに…。」とか意味不明もいいとこ。
249:デフォルトの名無しさん
14/04/29 14:26:17.37 jiz/CQ6q
>>247
> 別にどっちでもいいというか
> プロジェクトの性質に合わせて運用するべきで
> 他人がどうこう言うもんじゃないと思うが
rebase && FFすべきプロジェクトの性質ってなに？
> コードを追うならFFの方が都合がいい場合もあろう
それってどういう場合？
一応断っておくが煽りではないよ。
どっちも例でよいので示してみてくれないか。
「あぁ、そういうことならrebase && FFマージ戦略にすべきだよね」
「rebase && FFマージ戦略じゃないと困ったことになってしまうね。解決策としてはrebase && FFマージがベストだよね」
って感じのをたのむ。
ちなみにこれも勘違いされるとイヤなので書くが、rebaseが常に悪ではないのと同様、
俺はFFが常に悪と言っているわけではないぞ。
些細な変更(ドキュメントのtypo修正1コミットとか)なんかはFFでも気にしないし、
コンフリクトしたときtopic開発者がmergeした方向によってはそれをmasterにマージする際はFFすべき。
俺が疑問を持っているのは「何がなんでもrebase && FF」ってタイプの主張だ。
250:デフォルトの名無しさん
14/04/29 14:28:32.84 jobIXRFq
どうでもいい
251:デフォルトの名無しさん
14/04/29 14:30:18.99 GcKmP5Zr
このスレの先輩方の議論のまとめとか入門とかをwikiにまとめませんか？
252:デフォルトの名無しさん
14/04/29 14:58:20.39 jiz/CQ6q
俺も他人が管理してるプロジェクトであれば「うちではrebase && FFでやるから」って言われても
「フーンそうですか。(大変ですね)」くらいで済ますわけですよ。
だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
それが正義みたいになるのは避けたいのです。
# 今のところ rebase && FF は面倒なだけで、「わかりやすい」というのは幻想だという認識
もし rebase && FF がフィットするプロジェクトの性質とやらがあるなら自分の認識を変えるし、
そうでないなら「rebase && FFが許されるのは中学生までだよねー」的な雰囲気になってほしいの。
253:デフォルトの名無しさん
14/04/29 15:08:09.46 jiz/CQ6q
名指しして悪いんだけど例えばこれ
URLﾘﾝｸ(powerful-code.com)
mergeの「悪い点」は履歴を統合ブランチの--first-parentとtopic
ごとに分けて考えることを知ってれば悪い点にはなり得ない。
rebaseの「良い点」はこれまた--first-parentしらねーんじゃねーの的な。
254:デフォルトの名無しさん
14/04/29 15:16:46.84 jiz/CQ6q
巨大なプロジェクトでも--first-parentで見れば直線的だし、
かなり要約(圧縮)されるので把握しやすい。
これがもしrebase && FFされてたらと考えるとログ見るのイヤになるだろうね。
例えば Linux で v3.13 から v3.14 の間には
マージコミットを除くと全部で12311個のコミットがあるんだが、
gitk --first-parent v3.13..v3.14
ってやったときに出てくる履歴は12311個と比較するとわずか422個で見た目も"直線的"だ。
これが12311個のコミットを見ないといけないとしたら、
直線的に並んでようが把握するのは楽じゃない。
422個(+マージベースの422個)のタグを打ちたきゃ打ってもいいけど、リリース用のタグが埋もれるわな。
命名規則で回避する？頑張れって感じ。
255:デフォルトの名無しさん
14/04/29 15:25:33.99 GKmjQvWP
イマイチ何を問題としているのかが分からん
> 1 log --first-parent で要約をとれなくなる
> 2 マージコミットの親コミットの情報をもとにtopicのログを分離できなくなる
これらが必要になるようなブランチの切り方・コミットの仕方が
FF前提の運用方針と合致してない（=土俵が違う）気がするんだが
>>249にあるように些細な変更はFFでも気にしないんだろ？
些細な変更を積み重ねて全体を変えていくのがFFの考えの根底にあるんじゃないの
考え方の違うものを己の考え方基準で評価したら幻想にも見えるだろうよ
256:デフォルトの名無しさん
14/04/29 15:48:55.09 +oyspTjV
>>252
rebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
257:デフォルトの名無しさん
14/04/29 15:56:19.89 jiz/CQ6q
>>255
そういうことなの？
トピックブランチを用いる場合、そのトピックがあるひとつの目的を表していて、
その目的を達成するための変更が複数のコミットになったりはしょっちゅうあるんだが。
rebase && FFはトピックブランチ使わないってことなのかね。
258:デフォルトの名無しさん
14/04/29 16:01:07.06 jiz/CQ6q
>>256
なるほどなるほど。そういう意見を待ってた。
ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
first-parentを見てもマージコミットから単一のトピックが見えるわけじゃなく、
同一の目的であっても複数のマージコミットに情報が分散してしまう。
ならもういっそのこと rebase && FF でとにかく全体をいっぺんに見れるようにしよう、
って感じかな。
感謝感謝。
259:デフォルトの名無しさん
14/04/29 16:15:23.14 GKmjQvWP
なぜトピックブランチ使わないって結論に至るの？
FFをスムーズに実現するなら
トピックごとに細かくブランチを切る方が得策じゃないの
まあ黙るならそれでいいというか少なくとも俺はもう黙るよ
逃げてすまんね
260:デフォルトの名無しさん
14/04/29 16:17:02.13 EYu9TTok
さっきからrebase && FFが問題であるかのように言ってるが、
問題なのは「FF only の masterマージ」だろう？
rebaseはFF onlyにするのに、使うかもしれないってだけで、
別にrebaseしなくても、FFでmasterにマージできることもある。
さらに言えば、masterへのマージ以外には
当てはまらないだろう？
261:デフォルトの名無しさん
14/04/29 16:19:03.64 EYu9TTok
そしてFF only で masterマージ している（かのようなログをした）
有名なライブラリ例を上げておく。
URLﾘﾝｸ(github.com)
262:デフォルトの名無しさん
14/04/29 16:21:51.52 EYu9TTok
>>258
> ちゃんとトピックごとにブランチを作るのを諦めざるを得ない状況ってことね。
ブランチ切らないなら、FFでのmasterマージは
ブランチそのものがないから、ありえないだろう？
トピックごとにブランチがあるからこそ
masterへマージするときにFFにマージすることが出来るんだろう
263:デフォルトの名無しさん
14/04/29 16:26:11.71 jiz/CQ6q
>>259
いや、お前の主張には納得できなかったが議論してくれたことに感謝する。ありがとう。
264:デフォルトの名無しさん
14/04/29 16:29:31.48 jiz/CQ6q
>>260
> さっきからrebase && FFが問題であるかのように言ってるが、
> 問題なのは「FF only の masterマージ」だろう？
そうなんだけど、FF only の masterマージをしようと思ったら
(コンフリクトするかどうか関係なしに) rebase が必須になるよな？
> さらに言えば、masterへのマージ以外には
> 当てはまらないだろう？
統合ブランチへのマージの話であって、
統合ブランチがmasterとは限らないのでコレは賛同できないが、
話をシンプルにするためにmasterへのマージに限定してもらってもいいよ。
265:デフォルトの名無しさん
14/04/29 16:30:46.56 +oyspTjV
>>262
ブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
266:デフォルトの名無しさん
14/04/29 16:30:55.69 jiz/CQ6q
>>261
> そしてFF only で masterマージ している（かのようなログをした）
> 有名なライブラリ例を上げておく。
> URLﾘﾝｸ(github.com)
そうかい。
それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
267:デフォルトの名無しさん
14/04/29 16:31:51.96 EYu9TTok
>>252
> だが利益もないのに「履歴が一直線になってわかりやすい！」とか主張するやつが増えて、
「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
実際にわかりやすいんだから。
さて本当の問題は「FF only の masterマージ」といったわけだが、
no-ffのmasterへのマージ。これでも履歴は一直線に出来る。
履歴は一直線だが、no-ffを使っているから、この場合は問題ないだろう？
268:デフォルトの名無しさん
14/04/29 16:40:59.32 jiz/CQ6q
>>267
> 「履歴が一直線になってわかりやすい！」のは明確な利益だよ。
> 実際にわかりやすいんだから。
うーん、FFマージせずに、必要に応じてno-FFしてfirst-parentで要約したほうが
直線的なだけでなく情報が圧縮されてわかりやすいと主張しているんだが、
君には伝わってないように思えるな。 >>254 をもう一回読んでみてくれないか？
269:デフォルトの名無しさん
14/04/29 16:43:19.24 EYu9TTok
>>266
> それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
俺がそのライブラリの開発者じゃないからしらんけど、
no-ffにする理由がないからだろ？
トピックブランチでは複数の修正を行わない。
トピックブランチでは必ず一つの修正のみを行う。
大きな修正はせずに小さく修正する。小さな修正を連続させて開発する。
そうするとトピックブランチに含まれるコミットは必然的に一つになる。
もしくはトピックブランチの内容は必ずsquashしてからマージすると考えてもいい。
そうする--first-parentでまとめてみたいと思っていたログは
masterへマージする段階で単に一つのコミットにまとまるだけの話。
逆にまとまって見れれば十分なわけでそれを分割する必要あるの？
と考えていると推測。
俺は小さな修正の連続での開発にしきれないから
トピックブランチに複数の修正を入れるけどね。
270:デフォルトの名無しさん
14/04/29 16:51:05.11 jiz/CQ6q
>>269
> > それで、このライブラリでは何の利点があって FF only で master マージしてるんだってばよ？
> 俺がそのライブラリの開発者じゃないからしらんけど、
ちゃんと説明できないならこのライブラリの例は無視するよ。
# いったいどこからどこまでがお前の主張なの？
俺もトピックでは複数の修正をよく入れるし、
意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
271:デフォルトの名無しさん
14/04/29 16:53:09.53 EYu9TTok
>>270
説明してるじゃねーか。
ライブラリの作者じゃないんだから
作者の本当の考えはわからん。
それは当たり前。
それとは別に推測で
ちゃんと説明してる。
272:デフォルトの名無しさん
14/04/29 16:59:55.32 EYu9TTok
>>270
> 意味のある単位で分割してる(つもりだ)からsquashなんてしたくない。
意味のある単位で分割してるのであれば、
それを一つづつのコミットに分割して、それぞれマージすることは可能だよね？
また一つのコミットだけのトピックブランチは作ったこと無いの？
コミット一つに対応する、マージコミットを作るなんて無駄だしなくてよい。
（rebase・・・かどうかは実は関係なくて）して
FF-onlyでmasterにマージするってのは、単にコミットを
一つづつマージしていると考えれば良い。
大きな修正を一度にするのではなくて、
小さな修正の繰り返しで開発するとこうなるんだよ。
273:デフォルトの名無しさん
14/04/29 17:07:40.73 EYu9TTok
ちなみに俺が反論している所を明確にしておくと、
「履歴が一直線になってわかりやすい！」というのが
メリットではないような言い方をしている点。
トピックブランチに複数のコミットが含まれている時に
それをno-ffでマージというのは俺もしている。
履歴が多少一直線になっていなくても、ちょっと見づらいだけだから目をつぶる。
目をつぶるのであって、履歴は一直線になっていたほうがわかりやすい。これは事実。
rebaseなんてコンフリクトが起きなければ大した作業ではないし、
とある誰かが要求しているようにno-ffでのmasterへのマージはちゃんとするんだから
「わかりやすくするためにrebaseで履歴を一直線に直してもいいだろう？」ということ。
（>>261はあくまでFFでmasterにマージするのも
小さな修正の繰り返しで開発できてるならありという例であげただけ）
274:デフォルトの名無しさん
14/04/29 17:14:28.12 jobIXRFq
トピックブランチのコミットが2個以上なら
マージはどうあれno-ffでやるべきだろ。
ffでマージしちゃったら、
あとでそれらコミットがなんのトピックに属していたのか
わかりにくくなるんだから。
そういうケースまで一直線のほうがいいとか言うのはアホ。相手にするだけ無駄。
275:デフォルトの名無しさん
14/04/29 17:18:53.63 EYu9TTok
連投するが、俺がいいたいのは
・masterへのマージするときはno-ffをつけろ。（念を押すがmasterへのマージの話）
・コンフリクトが起きるようなmasterへのマージは禁止。
・rebaseはしたほうがベター。なぜベターなのかというと履歴が一直線になって見やすいから。
ということ
この結果、no-ffでmasterへマージする前に「rebaseするのは一般的なオペレーション」になる。
そしてrebaseしていなくても、コンフリクトが起きなければmasterへno-ffマージしてよいので
そうするとマージ前のrebaseの有無は関係なくて単に「masterへはno-ffマージしろ」って話になる。
276:デフォルトの名無しさん
14/04/29 18:11:38.86 jiz/CQ6q
>>273
コミットグラフを書けるかちょっと試し書き。ずれてたらすまん。
お前の主張は
A-B-C
/ \
X-------M-M
\ /
D--E--F
こういう変更は DEF をrebaseして
A-B-C
/ \
X-------M---------M
\ /
D'-E'-F'
こうすべき、ってことでいいかい？
俺的にはどちらもfirst-parentで
\
X-M-M
/
に要約可能だからどっちでもいいよ。
# ただ自分でやる場合はコンフリクトしない限り前者のほうがrebaseしなくていいから楽だけと思うけどね。
# もちろんDEFのマージ時にコンフリクトしたらrebaseすることもある。DEF開発者によるmergeも可。
277:デフォルトの名無しさん
14/04/29 18:12:17.95 jiz/CQ6q
疑問視してるのは
X-A-B-C-D'-E'-F'
にすべきという主張だ。
これはA-B-CとD-E-Fが本来別の目的を目指して重ねたコミットだという情報が失われてしまうから
たとえ一直線でもわかりにくいと俺は主張しているんだよ。
トピックが2個程度ならどっちでも良さそうだが、トピックが数十の場合を想像してくれ
X-M-M-M-.....M-M
という数十個の要約を見る(必要に応じてトピック内のABC等を確認する)のと
X-A-B-C......(区切りもなく、めちゃくちゃたくさんのコミット)....x-y-z
を見るのと、どっちがわかりやすいの？ってこと。
278:デフォルトの名無しさん
14/04/29 18:15:08.80 jiz/CQ6q
ブラウザによっては結構ずれるな。わかんなきゃ無視してくれ。
279:デフォルトの名無しさん
14/04/29 18:24:55.80 VGBInRA4
2.0からデフォルトでFF onlyになるのは知ってるよね君たち
どうしてこうなったのかもちろん議論されてるのも知ってるよね
280:デフォルトの名無しさん
14/04/29 18:25:46.52 ABe1tyQZ
これもうわかんねえな(バグったときの修正範囲が)
281:デフォルトの名無しさん
14/04/29 18:30:04.67 qq5sN0hH
>履歴は一直線になっていたほうがわかりやすい。これは事実。
一見わかりやすい気がするっていうのと、意味的にわかりやすいというのは別だと思うのだがどうだろう
svn のように時系列にコミットが一直線に並んでるのはわかりやすいか？
rebase → ff マージでトピック内の全コミットをフラットにしたのがわかりやすいか？
rebase → squash マージだと master のコミットグラフは一見綺麗になるかもしれんが実態はちょっとアレだし
そしてfirst-parentオプションつければたとえ一直線でなくとも意味的に見やすいログが手に入るんだろう
282:デフォルトの名無しさん
14/04/29 18:44:21.18 jiz/CQ6q
>>279
pull.ff 設定が可能になったのは確かだし、単に上流を追従するだけでその上で作業しないリポジトリなら
ff-onlyのほうが嬉しいのは確かだが、今議論してる内容とは前提が全然違うぞ。
# rc1だがmergeもpullもデフォルトでFF onlyな動作じゃないのを確認しちまったじゃねーか。
283:デフォルトの名無しさん
14/04/29 18:45:53.07 jiz/CQ6q
>>281
そうそう。
ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
284:デフォルトの名無しさん
14/04/29 19:02:08.02 ABe1tyQZ
ベースブランチの状態が多いイコール検証箇所も多くなって面倒だからそうならないようコミットも最小限にしたほうがいいんじゃないの
285:デフォルトの名無しさん
14/04/29 19:47:52.24 6KBRCzBr
>>223
というわけで、実験してみた。
ブランチ削除しても履歴はのこるんですね。
そのツリーがごっそりなるものだと思ってた。
マージにしても、前やったときは、強制的に変なコミットログ追加されて気色わるかったきがしたけど、今やると普通だな。
僕含めまわりもまだ不慣れなので、ＦＦ縛りは、外せないけどマージするだけなら問題なさそう。
286:デフォルトの名無しさん
14/04/29 19:56:50.37 EYu9TTok
> ちなみに gitk --first-parent すると要約されたコミットグラフは事実上一直線なのがわかると思う。
ね？ 一直線は見やすいでしょ？
常にに--first-parentするわけじゃないので、
しなくても一直線になったほうが嬉しいよ。
287:デフォルトの名無しさん
14/04/29 19:58:40.00 jiz/CQ6q
>>285
報告ありがとう。
今後もGitに慣れるにしたがって、見え方も変わってくるかもしれないな。
周りも不慣れということで大変だと思うが、お前のプロジェクトのベストプラクティス確立にむけて頑張ってくれ。
グッドラック。
288:デフォルトの名無しさん
14/04/29 20:21:45.22 jobIXRFq
一直線バカは救いようのないバカだな
289:デフォルトの名無しさん
14/04/29 23:30:04.09 +oyspTjV
「履歴が一直線になってわかりやすい！」かどうかって、もはやコミットの順序というものにどういう意味があるかどうかという意味論なのだから、
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
290:デフォルトの名無しさん
14/04/30 00:35:08.42 UGHSixxv
一直線が良いケースが挙げられてないけどな
291:デフォルトの名無しさん
14/04/30 01:11:54.22 pWom3qZR
一直線： 見えを貼りたいだけのバカ。俺はまっすぐ順調に開発をしてきたというアピールがしたい
292:デフォルトの名無しさん
14/04/30 01:29:11.37 Gbwo+6jG
東大一直線
293:デフォルトの名無しさん
14/04/30 05:04:21.07 mdKtpEfX
意味不明なエラーでpush不可能になった
remote: FATAL: WM refs/heads/*** **** **** DENIED by fallthru
remote: error: hook declined to update refs/heads/***
git reset --hard origin/upstream_worktree
して差分再適用してやり直したら通った
こんな意味不明なことが多発するのがgit
現実的には使い物にならないね
294:デフォルトの名無しさん
14/04/30 08:30:44.87 1vNQkGgC
hook declined
ってかいてあんじゃん
295:デフォルトの名無しさん
14/04/30 11:02:23.25 4gXDKzV2
書き込み時刻を見ろ 察してやれ
296:デフォルトの名無しさん
14/04/30 14:42:09.85 mdKtpEfX
dis発言に対してはただ叩くだけ
それも論理的に叩けないから人格攻撃に走るしかない
情けない奴らだよな
297:デフォルトの名無しさん
14/04/30 14:48:31.80 mdKtpEfX
別リポジトリで他人による大量の更新があって
半端にマージした挙げ句途中でこけて
半端にステージングした状態になり
結局
git reset --hard origin/upstream_worktree
するしかなくなった
ここまで致命的に腐ってると使い物になるならない以前の次元だね
298:デフォルトの名無しさん
14/04/30 14:55:49.07 nKoANYQ+
またいつものコンフリクト恐怖症の人か
299:デフォルトの名無しさん
14/04/30 18:26:55.40 mdKtpEfX
コンフリクト解消で済めばいいんだが腐ってるから済まないんだよね
300:デフォルトの名無しさん
14/04/30 18:51:13.84 h9gMUOtr
なるほど、コンフリクトの解消の仕方が分からないから
コンフリクト恐怖症になってしまったのか
301:デフォルトの名無しさん
14/04/30 18:51:51.42 rHgIYikH
Aリポジトリでもらったpull requestを
Bリポジトリに反映する方法を教えてください
302:デフォルトの名無しさん
14/04/30 18:59:19.90 1L5gAVQy
ところで、大声でジットと呼ぶ人がいて困ってるんだ
ディスクトップパソコンみたいな
職場がSubversion教に汚染されてるので仕方ないな
303:デフォルトの名無しさん
14/04/30 19:12:36.93 ZY5HChQC
じっと我慢汁
304:デフォルトの名無しさん
14/04/30 19:50:56.80 fWhizGrM
レーダーデスクカラオケ
305:デフォルトの名無しさん
14/04/30 19:56:34.41 EonfyA0Y
ギットギトにしてやんよ
306:デフォルトの名無しさん
14/04/30 20:25:07.89 WuyiDL68
>>297
> 半端にマージした挙げ句途中でこけて
(コンフリクトしたときのデフォルトの動作だ・・・)
> 半端にステージングした状態になり
(コンフリクトしたときのデフォルトの動作だ・・・)
> 結局
> git reset --hard origin/upstream_worktree
> するしかなくなった
(コンフリクト解消できなかったなら git merge --abort すればよかったんじゃ・・・)
307:デフォルトの名無しさん
14/04/30 21:19:26.86 livyiFPX
>>297
> git reset --hard origin/upstream_worktree
わろたｗｗｗｗ
え？ あんた自分の作業けしちゃったの？ｗｗｗ
馬鹿だなぁ。
gitはsubversionと違ってmergeやrebaseの途中で
コンフリクト起きてごちゃごちゃなっても、
merge/rebase作業をキャンセルして簡単に戻せるのにｗｗｗ
情けだ、ヒントをあげよう。
mergeしてるってことはコミットしてるってこと。
そのコミットIDはgit reflogすればわかるので
あとはそのコミットIDをチェックアウトすれば前の状態に戻せる。
gitはコミットしたものが消えることはない。
gitって安全だよねー
308:デフォルトの名無しさん
14/04/30 21:28:01.99 upmIhAH5
>>217
プロジェクト名に言語が入ってないとなんの言語で作ってるのかわからないじゃん
言語を変えたらリポジトリ名を変更すればいいじゃん
309:デフォルトの名無しさん
14/04/30 21:58:49.74 Y0BKcERE
>>308
悪いことは言わないから足を洗え。
310:デフォルトの名無しさん
14/04/30 22:12:33.53 livyiFPX
そういやgithubってプロジェクトで使用している言語がわかるようになったよね。
gitだと、カラフルなバーをクリックすると以下のように表示される。
C 45.5% Shell 34.6% Perl 9.6% JavaScript 3.4% Python 2.9% Tcl 2.6% Other 1.4%
>>308
で、このようにリポジトリにプロジェクト名入れなくても
githubならわかるし、gitのように複数言語使ってる時どうすんの？
そんなことも考えれずに、言語名にこだわるなら、
センス無いなとしか言えないなｗ
311:デフォルトの名無しさん
14/04/30 22:41:41.21 rUdHCEgh
githubだけの視野で語られても
312:デフォルトの名無しさん
14/04/30 22:42:55.54 livyiFPX
github以外のプロジェクトでも
複数言語でアプリ作るのは一般的だけど？ｗ
313:デフォルトの名無しさん
14/04/30 23:26:12.17 mdKtpEfX
307は本当に馬鹿なんだなぁ
管理されてないファイルがreset --hardの対象にならないことは以前に確認済みだから関係ないし
コミットしたものはすぐに権限持ちに差分送ってるし
コンフリクトは元々未来分の作業は既に入っててそこからコメント消す程度
俺が泣かなくて残念だったな
314:デフォルトの名無しさん
14/04/30 23:51:07.78 1vNQkGgC
結局gitのおかげで無事でした
めでたしめでたし
315:デフォルトの名無しさん
14/05/01 00:28:44.24 WukXr8jq
＞＞３１２
プロジェクトを1つのディレクトリに詰め込むタイプですか？
316:デフォルトの名無しさん
14/05/01 09:28:45.91 PzUwUPDQ
>>313
意味がわからないなあ
コミットしたものを権限持ちに既に送ってあるとしたら、
お前が上流からマージしようとしたブランチは一体何なの？
お前がコミットしたものを含んでいないブランチ？
317:デフォルトの名無しさん
14/05/01 11:07:25.45 PVO7jj2i
>>315
なんでそんな発想が出てくるんだ？ (w
318:デフォルトの名無しさん
14/05/01 11:24:48.42 /DVUm5po
おれはさ
php/wiki
php/cms
php/mailform
っていうふうに管理してるの
他の言語で同じ物を作ることもあるから
ruby/wiki
みたいに言語をネームスペースにすると管理が楽なんだよ
319:デフォルトの名無しさん
14/05/01 17:12:30.25 PzUwUPDQ
>>318
それとGitと何の関係があるんだ？
320:デフォルトの名無しさん
14/05/01 17:20:29.51 U31MyfYF
Gitはソースコードを管理するわけだからプロジェクトと関係あるだろ
C:/appData/User/toyohiko/マイドキュメント/mycode/php/wiki
これを外部のリポジトリ管理サービスに突っ込むときのリポジトリ名はphp-wiki
321:デフォルトの名無しさん
14/05/01 17:24:28.79 n23f7Uie
名前付けのポリシーとか別に好きにすればいいと思う。
322:デフォルトの名無しさん
14/05/01 17:44:02.84 PzUwUPDQ
>>320
そんなもん上流のリポジトリ管理方針次第だ
例えば俺はandroidのapp01プロジェクトを
ssh://remotehost/repo/android/app01.git とかに格納してる
323:デフォルトの名無しさん
14/05/01 17:52:02.03 U31MyfYF
>>310
複数言語使っているときは
C:/appData/User/toyohiko/マイドキュメント/mycode/other/wiki
というようにして言語名のフォルダにいれず名前空間に言語名を付けない
324:デフォルトの名無しさん
14/05/01 18:01:12.45 n23f7Uie
もう自由にタグ付けできる自分用プロジェクト管理ツール使っちゃえよ。
325:デフォルトの名無しさん
14/05/01 18:13:02.15 ZgnY/tZG
>>318
コードネームつければいい。
phpは犬の種類、rubyは猫の種類とか原則を持たせても良い。
326:デフォルトの名無しさん
14/05/01 19:05:29.45 PzUwUPDQ
>>323
githubがリポジトリを「URLﾘﾝｸ(github.com)ユーザー名/リポジトリ名」で管理してるのは
githubの管理方針であって、gitとは直接関係無いということが理解できた？トヨヒコくん
327:デフォルトの名無しさん
14/05/01 19:26:56.62 3NSQaEE2
だからさGitHubだけで語るな
328:デフォルトの名無しさん
14/05/01 22:47:07.56 dcOXu/fE
確かにSubversion使ってたときは一つのリポジトリに色々入れてたけど(そしてSubversionを適当に使う限りではそれで事足りてた)、
Gitは部分チェックアウトも出来ないしコミットもブランチも困ることだらけだからプロジェクトごとにリポジトリ分けるのが当然だよな。
自分もGit初心者の頃はSubversionと比較しちゃって部分チェックアウトが出来ないのが不便だのsvn:externalsと完璧に同等のものがないのが困るだの言ってたけど、
そのときGitユーザーから「Subversionとは思想が違うから比較するのは意味が無い」的なことを言われたけど、今はまさにそのとおりだと思うよ。
とりあえずSubversionでややこしい開発はしたくないね、もう。
329:デフォルトの名無しさん
14/05/02 03:41:26.83 ZGvM0amq
>>316 pullするだけでその状態になることすらわからないとかお前本当に馬鹿だな
330:デフォルトの名無しさん
14/05/02 03:48:34.89 PU3lP69m
>>326
はあ？リポジトリ名の話なのに
＞「URLﾘﾝｸ(github.com)ユーザー名/リポジトリ名」
ってなんだよ話そらしてんじゃねえよ
331:デフォルトの名無しさん
14/05/02 06:22:29.35 KJDTZacL
自分の管理下にあるリポジトリなら好きに名前付けりゃいいじゃん
332:デフォルトの名無しさん
14/05/02 06:35:41.08 Ujs4NpLL
>>330
とよひこ君はまだわからないのか
githubじゃなければ、リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
333:デフォルトの名無しさん
14/05/02 06:37:10.90 Ujs4NpLL
>>329
pullするだけですべてうまく行くと思ってるのは幻想だ
ちゃんと勉強したほうがいいな
334:デフォルトの名無しさん
14/05/02 08:09:07.29 ZGvM0amq
わざわざvcsの勉強なくて無価値なことはしたくもないね
335:デフォルトの名無しさん
14/05/02 08:29:32.57 Ujs4NpLL
Gitに関しては勉強する価値があった
正直まともなVCS使わないのは、高機能エディタやIDEも使わずメモ帳で開発するようなもんだわ
336:デフォルトの名無しさん
14/05/02 11:30:23.12 W9jDDFpi
パスワードを含んだファイルがあるんですけど
このファイル内のパスワードを削除して雛形だけの状態にしてからプッシュしてます
一度プッシュしたらほとんど修正はしないファイルなんですがこういう場合ってどうするものですか？
337:デフォルトの名無しさん
14/05/02 13:03:04.92 pbdRog+k
>>336
$ touch password.txt; git add password.txt; git commit
$ git update-index --skip-worktree password.txt
$ echo -n 'himitsu' > password.txt; git status
On branch master
nothing to commit, working directory clean
とか？
338:デフォルトの名無しさん
14/05/02 13:06:17.10 Pfd+HO5D
>>332
> リポジトリ名をphp/wikiとかruby/wikiみたいにネームスペースにして管理できるって言ってんだよ
別に、/ スラッシュを使わなくても
php\wiki や ruby\wik でもいいだろう？
php_wiki や ruby_wik でもいいだろう？
339:デフォルトの名無しさん
14/05/02 13:17:21.62 Oia8PEO/
>>336
aaa.confってファイル名だとしたら
.gitignoreにaaa.confを登録してaaa.conf.sampleみたいなファイル名で
コミットしておくのが多いんでないかな
340:デフォルトの名無しさん
14/05/02 14:47:13.55 Ujs4NpLL
>>338
話の流れを読めないアホなのか？>>216が話のはじまりだ
別に本人が / 以外でいいのならそれでいいぞ
ただし、\ で区切るのは勘弁してくれ
341:デフォルトの名無しさん
14/05/02 15:06:33.45 WqSAbr7K
User/repository.gitが
User/php/oreore.gitじゃなくてGItHubが/を-に変換してUser/php-oreore.gitになる
bitbucketは名前を強制的に変換はしないがurlのほうは変換される
余計な機能
342:デフォルトの名無しさん
14/05/02 17:26:31.17 BNaPh7J8
% git clone URLﾘﾝｸ(...) php/oreore.git
すればいいだけじゃねーの。
手元で php ディレクトリが存在してるかどうかに関わらず
Gitは指定したパスにクローンしてくれるよ。
わざわざ指定するのがイヤなら
そういうcloneをするようなスクリプトかぶせてもいいし。
343:デフォルトの名無しさん
14/05/02 17:34:19.17 XSE+HkNu
C:￥testからD:￥testに移動したいんですけど
ファイラーで移動したらgitできなくなりました
.gitの中でどのファイルを開いてパスを書き換えたらいいですか？
344:デフォルトの名無しさん
14/05/02 17:44:12.24 BNaPh7J8
>>343
わからん。ありそうなのは .git/config だが、
適切に答えるには情報が不十分かつ不正確。
345:デフォルトの名無しさん
14/05/02 17:53:43.03 XSE+HkNu
C:￥testでgit initして適当にファイルを作ってコミットして
C:￥testをコピーしてD:￥testにペーストしたんです
D:￥testのなかでgit logしたらログが表示されません
346:デフォルトの名無しさん
14/05/02 18:06:55.59 +HIQMOvh
全く再現しねえな
347:デフォルトの名無しさん
14/05/02 18:07:33.93 XSE+HkNu
eeeeeeeeeeee
348:デフォルトの名無しさん
14/05/02 18:14:47.14 +HIQMOvh
GitBushから
cd /c/temp
mkdir git
cd git
mkdir test1
cd test1
git init
vim README
git add .
git commit -m "initial commit"
エクスプローラで
Cドライブ(C:\Temp\Git\Test1)を右クリックメニューでコピー
Dドライブ(D:\Temp\Git)にて右クリックメニューから貼り付け
GitBushから
cd /d/temp/git/test1
(ちゃんとmasterって表示になった)
git log
(ちゃんとinitial commitのコミットが表示された)
まったく再現しない
エクスプローラ以外のファイラーは知らんが、隠しファイルや隠しフォルダは移動しない設定になってんじゃないの
349:デフォルトの名無しさん
14/05/02 18:23:12.12 3JApfdBs
おかしいな・・・またあとできます
350:デフォルトの名無しさん
14/05/02 20:15:24.71 dlumt8FZ
Gitのこともほとんど具体的な操作方とか知らないままなんだけど、GitHub実践入門を買った
ので、Git操作のお勉強と同時にGithubも使いだした。
351:デフォルトの名無しさん
14/05/02 20:18:51.30 6MkiwdiC
rmした後に全く関係ないファイルをaddするとrmしたファイルのrename扱いになるんですが
単に新規ステージングしたファイル扱いにできますか？
直後にrmしたファイルではなく、始めにrmしたファイルのrenameになっていたり
動作がわけわららんです
352:デフォルトの名無しさん
14/05/02 20:48:37.15 YmhbMTXU
>>337 横レス
設定ファイルとか便利そうだな。覚えておこう。
353:デフォルトの名無しさん
14/05/02 20:49:12.42 6MkiwdiC
どうやら中身が同じファイルは勝手にrename扱いにしてくれるようですね
空ファイルでトレーニングしていたので混乱してしまいました
354:デフォルトの名無しさん
14/05/02 20:59:01.62 6ajnVdK2
>>351
gitのデータ構造としては、ファイルの移動や改名とかは管理してなくて、
表示の時にヒューリスティックに判断してrenameとか出してるだけだから、
気にする必要ないよ。
355:デフォルトの名無しさん
14/05/02 21:02:26.52 6MkiwdiC
>>354
ありがとうございます
そういうものだと、気にしないようにします
356:デフォルトの名無しさん
14/05/02 21:42:27.82 x3xYwsX7
gitはファイルではなくコンテンツを管理していると言われる所以だね。
357:デフォルトの名無しさん
14/05/02 22:17:35.97 Xf1Tcq77
gitでhookファイルを変更した場合
これをGitHubにプッシュした阿戸に
ローカルのファイルとリポジトリを削除してからクローンしたらhookファイルの内容がないんですが何故ですか？
358:デフォルトの名無しさん
14/05/02 23:58:46.02 ojQzvTVb
こんなGit入門の本を買った。
URLﾘﾝｸ(2ch-dc.net)
359:デフォルトの名無しさん
14/05/03 00:29:50.84 9lt90aGA
喜ぶべきか悼むべきか・・・
360:デフォルトの名無しさん
14/05/03 01:42:57.16 fa3rSR83
>>358
それってどう？
361:デフォルトの名無しさん
14/05/03 02:05:49.12 Z2xjVVlJ
>>357
フックは版管理されてないから。configも同様。
フックをシェアしたいならワーキングディレクトリにフックを置いて、Makefileなりsetupスクリプトからインストールできるようにする。
クローンしただけで勝手にスクリプトに走られたら困る。
362:デフォルトの名無しさん
14/05/03 02:07:15.00 vyhhlfA3
>>360
文章読むだけならGithubで公開されてる
363:デフォルトの名無しさん
14/05/03 02:11:26.95 Z2xjVVlJ
>>353
rmしたファイルのindexに注意。git rm。
git mvはgit addとgit rmを同時にやってくれる。
364:デフォルトの名無しさん
14/05/03 07:45:11.01 n1PIULKZ
>>353
中身が似てるファイルね
rename扱いにしてるのはログ表示の時だから、まあ気にしなくていいには変わらない
コピペ検出機能だとでも思っておけ
365:デフォルトの名無しさん
14/05/03 13:12:50.33 EAqxmtFF
リモートにtagをpushした後、リモートに存在するtagを確認するにはどうすればよいのでしょうか
ローカルリポジトリのtagなら git tag, リモートのブランチなら git branch -r ですが、
リモートのtagを表示するコマンドが見つかりません
366:デフォルトの名無しさん
14/05/03 14:26:01.92 H1NY/7i6
git ls-remote リモート名
367:デフォルトの名無しさん
14/05/03 14:26:42.30 oP8j+OVm
>>365
これでリポジトリを直接指定して確認できるけど、
git ls-remote --tags リポジトリのURL
もっといい方法があるかも？
368:デフォルトの名無しさん
14/05/03 14:47:09.37 EAqxmtFF
>>366-367
感謝です！ありがとうございました！
369:デフォルトの名無しさん
14/05/04 11:33:46.82 bQKl4dNQ
リモートリポジトリからPullした直後で一切変更を加えていないにも関わらず
git statusでいくつかのファイルで差分が検出されてしまう現象にが起きています
差分が検出されているファイルのdiffを見るとソースコード全体が入れ替えられたような表示になります
しかし、該当ファイルをgit addしてから再度git diffすると変更点なしと表示されます
現象が起きるファイルは.cpp、.cs等複数の拡張子で
その拡張子のファイルすべてで起きる訳ではなく、頻繁に更新されるファイルで起きているように見えました
この現象についてWeb検索したのですが、該当しそうな情報は得られませんでした
githubのクライアントとVisualStudio2013のgit機能を併用していることに
原因がありそうな気がしているのでそのあたり調査する予定ですが
見直すべき設定等、何かヒントを頂けたら嬉しいです
370:デフォルトの名無しさん
14/05/04 11:50:13.22 IxrX60Uq
>>369
改行コードだな
371:デフォルトの名無しさん
14/05/04 18:11:29.06 Efc5dGc7
git config core.filemode false
git config core.symlinks false
372:デフォルトの名無しさん
14/05/05 12:36:20.36 qzGHizbC
pullは1箇所から取得してpushは複数にする方法を教えてください
AitHubのみpullして
pushはAitHub,BitHub,CitHubの3箇所に送信してバックアップがしたいんです
373:デフォルトの名無しさん
14/05/05 13:48:29.73 bcw2AmGJ
>>372
git remote add知ってる?
374:デフォルトの名無しさん
14/05/05 13:50:28.20 HNW3XBXV
それ知ってますけど1つのとこしかpushできませんよね
375:デフォルトの名無しさん
14/05/05 14:07:54.45 NnoKU6B2
一つの所ってなんですか？ originですか？
なんでいちいち名前を指定すると思いますか？
一つだけなら名前は必要ないはずですよね？
376:デフォルトの名無しさん
14/05/05 14:08:40.84 NnoKU6B2
なんでremote addだと思いますか？
一つだけならremote setでいいはずですよね？
あとは自分で考えてください。
377:デフォルトの名無しさん
14/05/05 18:39:57.72 G1VleuAd
git push {A,B,C}itHub branch
378:デフォルトの名無しさん
14/05/06 11:11:21.75 wWugdkdR
>>369
autocrlfくさい
379:369
14/05/06 15:12:16.47 5E8fiGLl
>>370,371,378
ありがとうございます。
いただいた助言を参考に試行錯誤して、とりあえず以下の操作をしたら
現象が落ち着きました。
・core.autocrlfをtrueからfalseに(Windowsでしか開発しないので)
・core.whitespaceを明示(space-before-tab,trailing-space)
・該当ファイルをVisualStudioの「ドキュメントのフォーマット」を使用して整形
もしかしたらwhitespace周りが原因だったのかもしれません。
どうもありがとうございました。
380:デフォルトの名無しさん
14/05/06 16:27:04.50 dFD2Q7zD
masterブランチの内容をtestブランチに移動して
masterブランチ内のファイルの内容を空の状態にする方法を教えてください
381:デフォルトの名無しさん
14/05/06 18:22:58.02 ms/T2S5F
ファイルの内容を空の状態にする？ファイルのサイズを0バイトにするってこと？
382:デフォルトの名無しさん
14/05/06 18:53:05.44 2kojW0Cn
あるブランチでコミットした内容をmasterに反映させる時rebaseを使えっていうのをここで習ったんですが
具体的にどうやるのか教えてください
git init
touch a
git add a
git commit -m "INITIAL COMMIT"
git checkout -b kaihatu1"
echo "1" > a
git add a
git commit -m "1を追加"
echo "1" > a
git add a
git commit -m "数字を2に変更" ←いまここ
この後から何をしたらいいのか教えてください
383:デフォルトの名無しさん
14/05/06 18:59:41.16 WvF/ZXc8
絵に描いたような教えてクン
384:デフォルトの名無しさん
14/05/06 19:03:35.48 Fr+PW76D
あるブランチでコミットした内容をmasterに反映させる時に使うのはmerge
ブランチには複数のコミットが含まれている。という前提とする。
masterにマージする時のやり方
1. squashして一つのコミットにしてマージ
2. squashせず、マージコミットを作ってマージ（no fast foward）
3. squashせず、マージコミットもつくらずマージ（fast forward）
ブランチは作業履歴とか入っていてコミットが汚いことがあるので
mergeする前にブランチを綺麗にしておくと良い。
ただし1ならコミットは一つになるからrebaseする必要はない。
2. もしくは 3の時、マージされたコミットを綺麗にしておきたいならrebaseする。
小さなバグ修正とか、タイポの修正とかそんなのが残ってても気にしないならrebase不要。
ただし、rebaseせずにfast fowardでmasterにマージすると
revertしづらくて死ぬだろう。コミットが綺麗なら3でも良いが、
2にしておくと、ブランチ単位でrevertできるから楽。