Git 12©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net
2015/03/23(月) 13:35:13.83ID:aBYp+bVsGit - 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/
0488デフォルトの名無しさん
2015/05/20(水) 17:07:28.79ID:qzEPJuINなんで？ 意味がある単位で小さくすればいいよ。
でも意味がないのに分割する必要はない。
（ローカルでの作業中に）
例えば、関数名これでいいかな・・・コミット
やっぱり、関数名こっちにしよう・・・コミット
いやいや、やっぱり戻そう・・・コミット
ってタイポしてたよ修正・・・コミット
これってコミットを細かく分けたかったわけじゃない。
作業上の都合でコミットがわかれてしまっただけ。
こういう意味が無いコミットはまとめるべき。もちろん
別々の修正であれば、どんどん細かく分けた方がいい。
細かく分けておくと並び替えや分離がしやすくなるよ。
修正しているうちにコミットがたくさんになって、これ一度に
レビューするの無理だろと思ったら、抜き出して別のブランチにするとかね。
でももし意味が無いコミットに分かれていたら、逆に抜き出すの難しくなるからね。
重要なのは、意味がある単位で小さいコミットに分けておくこと。分ける意味が無いものはまとめること。
これがコミットをうまく管理するコツだよ。
0489デフォルトの名無しさん
2015/05/20(水) 17:15:41.65ID:qzEPJuIN> みんなそこまでやってたの？ すげーな
git歴は2年ぐらいかな？
最初は当然できなかったよｗ
ただレビュー可能なコードの重要性はわかっていたから、
subversion使っている時、こんな行き当たりばったりの修正履歴じゃ
レビューできないだろっていう認識はあった。
（計画的にやれって思うかもしれないが、ミスや漏れどうしても発生する）
gitを使ってからはどうすればレビューしやすくなるか？を
考えてコミットを作るようにしていたよ。
（ちなみにどちらかと言うと俺はレビュー依頼する側じゃなてレビューする方だけどね）
0490デフォルトの名無しさん
2015/05/20(水) 17:18:24.50ID:zo5n24wvそのケースで実際にコンフリクトが発生する場合は
2 の粒度がでかすぎるってのがよくあるパターンなので、
2 を分割して 4←3+2a+1←2b という形になるようにしている
0491デフォルトの名無しさん
2015/05/20(水) 21:06:38.40ID:vVwXnjIW>あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
>たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。
たぶん>>480の場合は、例えば分野が小さなWebサイトの開発とかで、
そもそもの開発規模や自動テストの規模が少ないとか、昔のコミットや
昔の挙動を残しておいても問題調査の役に立つことが少ないとか、そういう
特徴があるんだろう。
0492デフォルトの名無しさん
2015/05/20(水) 22:00:00.11ID:qzEPJuIN数秒で終わらないのが困るのなら、大量にあるコミットが
ある状態で、rebaseとかどうするのさ？
数秒で終わらないなら、逆にコミット減らすべきだろ。
矛盾してるぞｗ
あと中間ファイルが残ってるはずだから、
適切にソースコードが分割されて依存関係が少ないなら
一つ一つのコミットの修正が僅かなはずなので
コンパイルにそんなに時間がかかるはずがない。
0493デフォルトの名無しさん
2015/05/20(水) 22:05:10.63ID:qzEPJuIN> 問題調査の役に立つことが少ないとか
これも逆に不要なコミットは消すべきだよね。
何か勘違いしてる（他の人にされそう）だから
念の為に言っておくけど、俺が言ってるのは、
本来一つであるべきコミットは一つにするって話で
何でもかんでもまとめろって話じゃない。
だから当然、昔のコミットは残ってる。
調査に使うよ。git bisectで二分探索で。
でだ、この時大量にコミットがあるとその分探索の回数増えるわけで、
コンパイルと自動テストが数秒で終わらないとしたら大変だよなぁ？
問題調査のためにも無駄なコミット減らしたほうがいいって結論になるぜ？
0494デフォルトの名無しさん
2015/05/20(水) 22:19:59.27ID:MjY1jVeQ＞数秒で終わらないのが困るのなら、大量にあるコミットが
＞ある状態で、rebaseとかどうするのさ？
だから、「間を飛ばしたコミットまとめをしない」って言ってるんじゃないのか？
A→B→C→Dの順にコミットされてるなら、連続したBCやBCDをまとめるのは
コンパイルや自動テストに問題ないから。
0495デフォルトの名無しさん
2015/05/20(水) 22:30:23.27ID:qzEPJuINrebaseって二つの複数の意味があるから気をつけないといけないなｗ
master(1)
＼A→B→C→D
で開発をはじめてさ、他の人のマージが先に加わった時、
master(1) → master(2)
＼A→B→C→D
master(2)からの開発にrebaseするという話。
master(1) → master(2)
＼A→B→C→D
この時、A〜Dまですべてが書き換わるわけだから、
コンパイルと自動テストをするわけでしょ？
時間がかかるのならなおのこと、まとめておいたほうがいいでしょ。
master(1) → master(2)
＼AC→B→D
もしかしてこのタイプのrebaseも禁止してるのかな？
なんか下手なコミットのせいで、時間が掛かるから便利なものを
封印せざるを得ない状態を作っているようにしか見えない。
0496デフォルトの名無しさん
2015/05/20(水) 22:49:40.28ID:MjY1jVeQなんでfeatureブランチの各コミットを直接masterにつなごうとするのかがよく分からない
このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
0497デフォルトの名無しさん
2015/05/20(水) 22:50:55.88ID:qzEPJuINと思った理由もかいておく。
A, B, C, D が同じ箇所の修正（前のコミットのやり直し）をして
本来一つであるべきものが分かれていたとする。
そしてmaster(2)にrebaesしたときにAでコンフリクトが発生したとする
master(1) → master(2)
＼A→B→C→D
そうすると、B, C, D も同じ箇所の修正だから
必然的に、BでもCでもDでもコンフリクトが発生するわけよ。
わー、大変だ。コンフリクトだ。しかもこれさっき直したじゃないか？
コンフリクトわけわからん。わー。ってなってるはず。
同じ箇所の修正を一つにまとめておけば、コンフリクトの修正も一回だけだよ。
関連あるコミットをまとめておかないから、コンフリクトが沢山発生する。
時間かかるし正しく修正できたわからんからrebaseしない方がいい！ってなってると思う。
コミットが沢山にわかれている → コンフリクトが沢山発生する → そうなるからrebase禁止 と
考えているのだろうが、本当の原因はコミットが沢山にわかれていて、それが意味もない順番でごちゃごちゃ並んでることだから。
関連あるコミットは随時まとめておく。順番も適切な順番になおしておく。そうしておけばコンフリクトの発生は少ない。
コミットの数も少なくなるし、だからrebaseしてもコンパイルにも自動テストに時間はかからなくなる。
コミットは意味がある形で最小限に抑えられているから、レビューも楽になる。
後から問題の調査をするときも、存在理由がわからない大量の謎コミットを見る必要もなくなる。
gitの機能を最大限使うことが出来るわけよ。
ってもう何回も言ってるねｗ 毎回長文でｗ
0498デフォルトの名無しさん
2015/05/20(水) 22:54:58.15ID:qzEPJuIN> その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが
その場合ってどの場合？
一人で開発してるんじゃないんだよ。
自分が開発をし始めた時からコードは変わっているから
これをmaster(3)になんか出来ない。
他人の仕事を消してしまうじゃないか。
他人の仕事と自分の仕事を合わせてないと行けないんだよ。
コンフリクトが起きようと起きまいとね。
コミットが沢山あればあるだけ、全てのコミットが
正しく動くか再テストをする必要がある。
0499デフォルトの名無しさん
2015/05/20(水) 22:58:20.56ID:MjY1jVeQ＞master(1) → master(2)
＞ ＼AC→B→D
これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
これが許されるチームなら、各メンバーが自由にコミットをまとめても、たしかに問題ないな。
0500デフォルトの名無しさん
2015/05/20(水) 23:01:15.60ID:qzEPJuIN> このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
別ブランチにできるかどうかは内容次第だね。
コミットとしては一つ一つ取り込めたとしても
機能としては一つ一つでは完成しないこともある。
で、俺は一連の作業中に、先にマージ可能なものができたら、
別ブランチに抜き取って先にマージした方がいいとも書いた。
そのためにも、コミットをそのまま放置するのではなく
関連があるものはまとめていくようにって言ってるんだよ。
関連あるコミットがバラバラだったら、別のブランチに抜き出すのは大変だからね。
それもあって、そのケースでAとCをまとめたんだよ。
つまり最初のAとCが関係ある内容ならまとめますか？の質問の
答えはまとめた方がいいってこと。
で、これやるとコンフリクトが〜とかいって、まとめない方がいい
並び替えないほうがいいって言ってる人がいるわけよ。
0501デフォルトの名無しさん
2015/05/20(水) 23:05:27.02ID:qzEPJuIN> これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
> 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
話がループしているがｗ
rebase後にACとBのコンパイルと自動テストをスレばいいだけだろう？
そんなのすぐに終わる。たった2回（ACとB）じゃないか？
すぐに終わらないのは、コミットがたくさんあるからだよ。
そりゃコミットが10個も20個もあれば、10回20回もコンパイルと自動テストをしなきゃならんだろうさ。
コミットがたくさんあるために、rebaseを許さない状況になってしまっている。
rebaseってさ、gitの基本じゃん？
チュートリアルの最初のほうで出てくる作業だよ。
許されるも何もこれは普通にやるべきことだよ。
ね？ 下手なコミットのせいで普通にやることがやれない状況になってしまっている。
コミットがたくさんあるために、rebase（master(2)への付け替え）を
封印してしまってるでしょ？
0502デフォルトの名無しさん
2015/05/20(水) 23:19:51.82ID:MjY1jVeQAとCをまとめますか？の回答には「そう思う」だが、
AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。
AとBとDはブランチを分けるな。
もしブランチを分けとけば、レビュー前？Push前？にAのバグに気付いても、AとCのコミットは連続してるだろうからな。
逆に、レビュー後？Push後？に問題に気付いたなら、自分の負けを認めてバグ修正のコミットを残す。
一方、後になって「コミットが連続しない、AとBとDをブランチに分けておけば良かった〜」なんてなるようなら、自分の腕のなさを呪ってブランチを切りなおす？？？かな。
0503デフォルトの名無しさん
2015/05/20(水) 23:21:45.30ID:MjY1jVeQ＞そんなのすぐに終わる。たった2回（ACとB）じゃないか？
「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
0504デフォルトの名無しさん
2015/05/20(水) 23:28:53.73ID:qzEPJuIN> AとBとDはブランチを分けるな。
分けたいなら後で分ければよくね？
作業用ブランチなんだからそれはどっちでもいい話だと思うが。
AとBとDがお互い前のコミットに依存している場合、
最初にブランチを分けておくと、ごちゃごちゃしてくると思うが。
Aを作ったはいいけれど本当にこれでいいかは、そのAを使う
Bを作らないとはっきりしないことだってあるしさ。
残念ながら人間はミスを犯すんで、どうしても後からバグを発見する。
後から修正をするものだよ。
一つのブランチで作業しておいて、ある程度納得がいったら別ブランチに
抜き出せばいいと思うけど。コミットが整理されていれば簡単な作業だし。
それとレビューは間違いを見つけるものだから、修正が入るのはあたりまえだよ。
レビュー中はまだ作業中段階。作業中のごみコミットを残したままマージする必要はないよ。
一連のレビューが終わったら整理すればいいだけの話。整理し終わってそこで完成。
0505デフォルトの名無しさん
2015/05/20(水) 23:30:22.13ID:qzEPJuIN> 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
そんなのすぐに終わらないって前提がおかしいんだよ。
だって開発中に何度もコミットしてるじゃん？
その段階でコンパイルと自動テストしてるじゃん？
コミットがたくさんあるのなら、その分だけやってるわけじゃん
開発中にすぐに終わらない作業を何回もやってるのか？
まずそれを解決した方がいいぞｗ
0506デフォルトの名無しさん
2015/05/20(水) 23:35:21.24ID:qzEPJuINなぜなら、コミットの前後で修正されるファイルは少しだから
該当ファイル以外のオブジェクトファイルはそのまま使えるわけで
差分のみのコンパイルしかしないはずだから。
そして自動テストは作業中は関連のあるところだけテストすれば良い。
で、最終段階（もう変更がないと思った時点）で全部やればいいんだよ。
最後にブランチ内の全コミットをテストするのか！という疑問に対しては
だからぁ、コミット数が多いから大変なんじゃねぇかそれ。という話。
関連あるものはまとめろ。先にマージできるのは別ブランチに分けろ。
コミットは小さく分けろ。だが無駄なコミットはまとめろ。
0507デフォルトの名無しさん
2015/05/20(水) 23:39:45.06ID:MjY1jVeQ自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。
例えばWebサイトの開発とかでは、そういうのほとんどないだろうし、ぶっちゃけ過去より今が大事なのかもしれない。
（過去の状態が「Webサイトの純然たる作りかけ」とかだったら、そのスナップショットを完全に残すことに価値はないだろうし）
だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
その方が、短期的な効率は出るだろうしさ。
0508デフォルトの名無しさん
2015/05/20(水) 23:56:43.98ID:/feEo/hsgitのブランチって使いづらくね？
0509デフォルトの名無しさん
2015/05/21(木) 00:28:17.62ID:0lqSGmSkfix_numberブランチを作って"fix number value"ってログを書いてコミットしました
その後はプッシュする前に最新の情報を取得するべきって聞いたのでgit pullしました
そしたら
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> fix_number_value
ってでました
これってリポート上のmasterブランチを指定したらいいんでしょうか？
実践で誰かと一緒に開発したことがないので怖くてどうしたらいいのかわかりません
ご教示おねぎあします
0510デフォルトの名無しさん
2015/05/21(木) 00:41:14.37ID:/NlBmKMh俺もそう思ってた
でもわかった、gitのブランチにはブランチモデルが必要なんだ
自由になんでも出来すぎるからブランチモデルで制約を付ける
「A successful Git branching model」てのを見つけて、
git-flowを使うようになってからだいぶまとまりが出来てきた
その後で他にもいくつかブランチモデルがあることも知った
今はブロジェクトの初めに
git-flowを使って「A successful Git branching model」をベースにやります。変更点はこれこれ。
みたいに宣言することにしてる。
だからお願い。VisualStudioにもgit-flow付けて、Microsoftさん。
0511デフォルトの名無しさん
2015/05/21(木) 11:22:31.08ID:PvdFF4ayなんか引っかかるねｗ
短期的じゃなくて長期的な効率が出てる。
ヘッダを書き換えれば多くのソースファイルに影響する話なら知ってる。
そうならないためのやり方があるのは知ってるかい？
ビルド依存を回避するような作り方をするんだよ。
あんたのやり方だと普段の開発から時間かかってしょうがないでしょ？
ちょっと修正するたびにビルドに多く時間がかかってるはずだよね。
それはもはやgitとは関係ない話だよ。
それからウェブの開発ではないって思ってるかもしれないけど、
今はウェブの開発でもビルド行う。
> だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
> その方が、短期的な効率は出るだろうしさ。
なんか、俺が知らないと思ってそういうこと言っているような雰囲気だが
俺知ってるからね？ ウェブだけじゃなくてビルドが必要な開発も。
0512デフォルトの名無しさん
2015/05/21(木) 11:33:41.78ID:PvdFF4ay最近の若いもんは〜みたいな発言になってるからだ。
言葉の節々に、ウェブ開発をしてるもんは〜とか
テストしてるわけがないはずだ〜とか
過去はどうでもいいと思ってるはずだ〜とか
まともな自分の想像ばかり言ってる。
0513デフォルトの名無しさん
2015/05/21(木) 11:34:23.74ID:PvdFF4ay× まともな自分の想像ばかり言ってる。
○ 的はずれな自分の想像ばかり言ってる。
0514デフォルトの名無しさん
2015/05/21(木) 11:55:03.21ID:PvdFF4ayこれに関してはだから何なんだ？といいたい。
（ごみ）コミットがたくさんあって、コミット毎に全部
アプリケーションの再起動を行っているのか？
だとしたら、テスト効率が極めて悪い。
10個のコミットがあって、それぞれのテストに
1時間かかるとしたら10時間じゃないか？
俺ならまずおおむね十分だと思われるテストだけを行って
コミットを減らしてからテストするね。5個に減らせば5時間で済む。
コミットしてテストした後で、さっきのコミットに混ぜるべきコードをコミットしてテストしたら
さっきテストした時間は無駄になるじゃないか。
後から修正が入るかもしれないような不安定な所のテストに時間はかけない。もう修正は入らないなって
思った時にちゃんとテストをする。コミットを減らしてテストしたらテスト時間も減る。
git以前にテストのやり方そのものを見なおしたほうがいいよ。
効率を考えないで流れ作業をこなしているかのような開発になってる。
0515デフォルトの名無しさん
2015/05/21(木) 12:05:21.48ID:PvdFF4ay> ブランチってほんとにみんな使ってる？
> gitのブランチって使いづらくね？
一人で開発してるとか？
使いづらいかどうかは置いといて
使わないと、複数人で並行して開発できないよ。
使いづらいと思ったことはないな。
最初の頃は苦労したけど、それはgitのブランチのせいではなくて
自分の技術力不足だってわかっていたし。
作者のリーナスがどうしても必要だって思って作った道具であり
gitの機能も必要だと思っているからこそ作ってるわけだしさ。
もっといい案があるというなら別だけど、わかってないのに
リーナスが作ったものに、ケチつけるなんてだいそれたことなんか出来んってｗ
わかった今ならよく出来てるって思うよ。
0516デフォルトの名無しさん
2015/05/21(木) 22:28:03.52ID:fr6zPWaF0517デフォルトの名無しさん
2015/05/22(金) 00:01:21.71ID:6DaqA/5uリーナスだろうと関係ないよ
リーナスには使いやすいものでも
俺には使いにくいってのは普通にあるよ
0518デフォルトの名無しさん
2015/05/22(金) 22:43:05.39ID:SSdLqWaE俺は一人開発だけど、master と daily の二つの branch を使っているよ。git 使い始
めの一年ぐらいは master だけだったけど。
master の commit/merge は version 番号より少し細かい粒度で行っている。daily
branch は bug/issue tracking の粒度より少し細かいぐらいで commit している。とい
うより、daily branch の commit message の殆どは bug/issue 番号に紐付けている。
Version 番号の粒度の履歴に bug tracking 粒度の履歴を残したくない。
ちなみに bug/issue tracking はソースとは別ディレクトリのテキスト・ファイルで
git 管理している。
>>508 gitのブランチって使いづらくね？
Time stamp が checkout 時刻に強制変更されてしまうのが使いにくいと感ずる。make
compile 時の便利さは分かるが、ファイルの time stamp 自体は重要な属性だから。俺
が git を作ったならば、time stamp を commit 時の時刻にするオプションを絶対設け
ていた。
実際には commit 時刻に変更する script を書いてあるけれど、殆ど使っていないの実
情だ。その script が必要になるのは master 側だけだから。そして その master 側で
push するときには、time stamp など構っていれらない状態が殆どだという実情なのが
情けない。
0519デフォルトの名無しさん
2015/05/23(土) 16:05:57.79ID:4OfmjrZC途中経過の整合性が合わなくなるのが許されたり、
途中経過の整合性を合わせるためのテストやり直しが許されることがあるんだな
pushした修正がバグってたからって、pushしたもんをリベースで打ち消すのはご法度と思っていたが
プロジェクトの大きさによってはそれもあり得るということか
0520デフォルトの名無しさん
2015/05/23(土) 17:21:41.69ID:x743ZDZ30521デフォルトの名無しさん
2015/05/23(土) 17:24:16.06ID:x743ZDZ3push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。
0522デフォルトの名無しさん
2015/05/24(日) 00:38:55.87ID:NuukhrjTサブプロジェクトどころか、一人プロジェクトだな
0523デフォルトの名無しさん
2015/05/24(日) 10:38:28.38ID:GI5iGoR+gitだと特に、ブランチの運用によって前提が大きく変わる。
GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、
それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。
だからpushしたブランチをrebaseしてもまったく問題ない。
むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい
0524デフォルトの名無しさん
2015/05/24(日) 11:16:37.86ID:VWanxcqXん〜と、前提が大ブランチになってるとそうかもしれないけど
Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから
得意技を積極的に使った方がお得な気がするな
うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた
その代わり、細かくコミットしろ、作業単位でブランチを分けろ
って、半年くらいは口うるさく言い続ける必要があったけどね
レビューの時にコミットツリー図を見ながら
ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか
ややこしいコンフリクトが生じた時に
どういう手順ならマージが簡単だったかとか
具体的に教えたり、みんなで考えたりした
新しい文化を根付かせるのは大変だよ、いつでもさ
0525デフォルトの名無しさん
2015/05/24(日) 14:14:44.04ID:J9ZjzLe3branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
に push するの？
レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
0526デフォルトの名無しさん
2015/05/24(日) 15:41:15.45ID:1k2HbjOC0527デフォルトの名無しさん
2015/05/24(日) 19:35:16.30ID:LHzJ6dIN今コミットしたログの後にそのリモートのログが来てしまいました
git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません
git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません
これってどうしたらいいんでしょうか？
0528デフォルトの名無しさん
2015/05/24(日) 19:41:30.07ID:Ewhf1zLwとなると、やはり 本体はSVNで、ローカルはgitで
別に管理したほうが全体が幸せになりそうだな
0529デフォルトの名無しさん
2015/05/24(日) 19:50:34.06ID:Jl9gFOkM共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな
0530デフォルトの名無しさん
2015/05/24(日) 20:03:35.12ID:Jl9gFOkMこの人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ
（それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう
0531デフォルトの名無しさん
2015/05/24(日) 21:34:38.73ID:VWanxcqXそれはいい解の一つだと思う。特に移行期には。
うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。
でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。
当時の対象プロジェクトがちょうど区切り良く、
過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、
フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。
最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど
結局馴染んでくればgitの方が扱いやすくなってきたよ。
しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。
（でも日本語変だよマイクロソフトのgit）
0532デフォルトの名無しさん
2015/05/24(日) 22:05:23.23ID:VWanxcqXおれ>>524な
「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、
俺がgit使ってる（使わせてる）理由の一番大きい所は
「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。
俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。
レビューもそのままで特に問題は無かったな。
でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
特に問題だったのは（svn使っていた頃の話ね）
何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。
svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で
みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。
ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。
そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。
今は「マージ操作間違えても俺が直してやる。
安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。
これだけでも後から意図を読み取るのは随分楽になったよ。
0533デフォルトの名無しさん
2015/05/24(日) 22:19:55.92ID:mdHWC0Am一つのブランチに押しこんでるからじゃないの
機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし
>>529
閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう
>>527
リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ
次から最初からブランチ切っとけばこんなことで困らん
0534デフォルトの名無しさん
2015/05/25(月) 03:10:39.76ID:WhsXE+Ib個人でブランチ作ってコミットしたあと、どうすればいいの？
そのブランチを本家に取り込ませるの？
0535デフォルトの名無しさん
2015/05/25(月) 05:59:36.31ID:/VFybrtgこれ大事よね
master に
0536デフォルトの名無しさん
2015/05/25(月) 06:01:10.35ID:/VFybrtg> でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
これ大事よね
master に wip と fix typo が積み重なってた時は流石に萎えたけど
0537デフォルトの名無しさん
2015/05/25(月) 08:14:58.07ID:y6DNlXTS＞master に wip と fix typo が積み重なってた時は流石に萎えたけど
そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう
0538523
2015/05/25(月) 09:19:23.83ID:E69UDjHE> >>523 だからpushしたブランチをrebaseしてもまったく問題ない。
>
> branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
> に push するの？
>
> レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。
典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する
0539デフォルトの名無しさん
2015/05/25(月) 13:36:42.28ID:XuKAmWn9まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
0540デフォルトの名無しさん
2015/05/25(月) 13:49:29.09ID:XuKAmWn9あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い
検索すりゃ方法わかると思うので調べてみてくれ
0541デフォルトの名無しさん
2015/05/25(月) 22:51:38.00ID:o/eCAQPj書き換え前のコミットををベースにしている人への配慮が必要そうだな
各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース
してください」って頼んで回れる環境が必要だ
0542212
2015/05/25(月) 23:42:12.33ID:fVXVPz7Eアンインストール作業が苦痛なんですよ
makeだけでアンインストールさせてくださいよ
0543538
2015/05/26(火) 00:30:58.55ID:VHuDuKFu> 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、
> まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。
これが GitHub flow な。
元が「 >>522 Pushしたブランチは書き換えてはならん」への反論だから、
そうでない運用もごく一般的、という主張をしたということ。
0544デフォルトの名無しさん
2015/05/26(火) 08:35:26.55ID:n+9g7Zguこれじゃ>>522への反論になってないっていうか、>>522が言ってることそのままだな
0545デフォルトの名無しさん
2015/05/26(火) 17:27:09.33ID:sKFLbSMMそうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。
0546デフォルトの名無しさん
2015/05/26(火) 17:39:03.82ID:sKFLbSMM個人用ブランチは作成者だけが見るわけじゃないから>>522とは違うな。
>>522は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？
単に極論言って煽ってるだけかもしれないけどね。
0547デフォルトの名無しさん
2015/05/26(火) 18:06:24.50ID:2IsijlAj規約任せかツールかスクリプトか
0548デフォルトの名無しさん
2015/05/26(火) 18:23:29.30ID:O0gIeBts0549デフォルトの名無しさん
2015/05/26(火) 20:10:30.68ID:qT5tL8rR一回オプション総ざらいしてみよう
0550デフォルトの名無しさん
2015/05/26(火) 22:07:42.46ID:1ouiCH4Fで、>>519が言ってる「プロジェクトの規模が小さい場合には
それができる」って話につながってくるのか…。
0551デフォルトの名無しさん
2015/05/26(火) 23:55:53.54ID:2IsijlAjそれブランチごとじゃなくて一律だからアクセス制限にはならないぞ
0552デフォルトの名無しさん
2015/05/27(水) 12:17:18.05ID:98FdFg1Vhttps://github.com/git/git/releases/tag/v2.4.2
0553デフォルトの名無しさん
2015/05/31(日) 20:55:03.14ID:2hiQrePQa.txtをHEAD@{12}のa.txtの内容にしたいんです
git reset HEAD@{12} a.txtじゃ戻りませんでした
0554デフォルトの名無しさん
2015/05/31(日) 21:23:55.63ID:q0XD6tk+0555デフォルトの名無しさん
2015/06/01(月) 22:34:02.79ID:6w2KJtLOgit add -A
このaddを取り消したいんですがgit reset HEADをやると
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
ってでます
git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？
0556デフォルトの名無しさん
2015/06/01(月) 22:37:39.31ID:wXX1PCBE0557デフォルトの名無しさん
2015/06/01(月) 22:37:41.39ID:60FC1uF10558デフォルトの名無しさん
2015/06/01(月) 22:43:38.24ID:wXX1PCBEぐぐると git rm --cached が使えるみたいだな
0559デフォルトの名無しさん
2015/06/02(火) 10:41:16.23ID:2Bq+WaXR例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合
一緒にまとめたほうがいいんでしょうか？
0560デフォルトの名無しさん
2015/06/02(火) 22:36:32.71ID:ENh0ws/u0561デフォルトの名無しさん
2015/06/02(火) 22:37:29.49ID:dwjHRJAm0562デフォルトの名無しさん
2015/06/02(火) 22:37:35.29ID:H1H2VilBその二つならまとめない。
もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。
0563デフォルトの名無しさん
2015/06/03(水) 01:22:55.03ID:knJmPdD6そういうgit運用の話は、「管理者の意見に従うべき」
個人用or自分が管理者なら、好きなようにやっていい。
0564デフォルトの名無しさん
2015/06/03(水) 01:42:10.75ID:3kJPkUc2少しは助言してやれよ
0565デフォルトの名無しさん
2015/06/03(水) 03:55:40.59ID:cOL0IOxC色々試して自分が一番しっくりする形を探すか
最も採用されていると思えるやり方というのを見出してそれを選択するか
有名どころのオープンソースプロジェクトの方針を色々と見てくるといい
0566デフォルトの名無しさん
2015/06/03(水) 05:32:16.44ID:5OGKD7dqでも優先されるべきはそのリポジトリの管理方針なのは間違いない
0567デフォルトの名無しさん
2015/06/03(水) 10:17:17.28ID:qaWpPbOFうちはmultimail使ってるがなんかしっくり来ない
0568デフォルトの名無しさん
2015/06/04(木) 01:27:40.14ID:FZpfA7xpお前はどうやってるんだよ
0569デフォルトの名無しさん
2015/06/04(木) 10:38:54.51ID:ixdJmRIHその時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ
一体まとめろ！まとめるな！のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる
1. initial commit
---- ここから -----
2. save
3. type
4. ○○実装
5.save
6.○○実装
7.typo
8.ファイル追加
----- ここまでまとめる -------
tagで1.0って付ける
0570デフォルトの名無しさん
2015/06/04(木) 10:43:29.77ID:lUVfOohh具体的にそのやりとは何スレ目だよ
0571デフォルトの名無しさん
2015/06/04(木) 10:47:48.34ID:w41Ky1ux「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、
どういうときはまとめたほうがよい
どういうときはまとめないほうがよい
というガイドラインのようなものならある程度意見はまとまってきそうだね
0572デフォルトの名無しさん
2015/06/04(木) 13:46:30.21ID:7Y8AXPNC要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか？と考えればいい
0573デフォルトの名無しさん
2015/06/04(木) 13:49:14.71ID:5FZxl5co0574デフォルトの名無しさん
2015/06/04(木) 16:11:36.89ID:a/IZmogkgit init
touch README.md
git add README.md
git commit -m "Initial commit"
echo 1 > a.txt
git add a.txt
git commit -m "add a.txt"
echo b1 > b.txt
git add b.txt
git commit -m "add b.txt"
echo a1 > a.txt
git add a.txt
git commit -m "modified a.txt"
git rebase -i HEAD^^^
以下のように並べ替え
pick 06da9a6 add a
pick 2c80b8f modified a
pick 7a6a277 add b
git checkout HEAD^
lsするとbファイルがありません
"modified a"のコミットにはbはないことになるんですか？gitが自動的に面倒見てくれてるんですか？
0575デフォルトの名無しさん
2015/06/04(木) 20:10:10.65ID:lUVfOohhrebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな
>>574のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、
"modified a"コミットにbは存在しなくなる
rebase -iでコンフリクトは起こる
例えば>>574の"add a"と"modified a"コミットの順番を逆にしたりすれば
0576デフォルトの名無しさん
2015/06/04(木) 20:23:21.52ID:69dFu2L0正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな
0577デフォルトの名無しさん
2015/06/04(木) 20:46:29.00ID:b+4KVUcq大きくても機能ごとにはコミット分ける
でその間はプロジェクトごとに方針あれば何でも
0578デフォルトの名無しさん
2015/06/06(土) 22:34:59.14ID:4eOWDqlW俺がルールを決めなきゃいけない時だな
0579デフォルトの名無しさん
2015/06/06(土) 22:35:56.50ID:yk/a5xMgお前、マージ使ってないだろ？
まず前提として「一つのプロジェクトを複数の人が平行で開発している」という
個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。
よくある間違いが、小さい規模の例だけで考えて、
それがそのまま大きな開発にも適用できちゃうって考えること。
君はその間違いはまってる。
（俺が知ってる）小さい規模ではこれでうまくいくんだ。ではなくて
大きな規模になった時それでうまくいくのか？を考えた方がいい。
適切なやり方というのは、規模によって変わるんだから。
0580デフォルトの名無しさん
2015/06/06(土) 22:41:32.51ID:yk/a5xMg問題は1コミットを後から見直すかどうかだよな。
後から見なおさないのであれば、どんなに意味不明な修正でも
同じ所を試行錯誤したコミットでも、何百行あるコミットでも
何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい
でもあとからそのコミットを見るのであれば
修正内容が明確にわかるコミットが必要最低限あった方がいい。
あとからそのコミットを見るかどうかだよ。
もちろん俺はよく見る。
仕事でもその修正が適切であるかを見たり、
オープンソースとかでもある修正内容を見たり
だからコミットは分かりやすくなっていたほうがいいと考える。
0581デフォルトの名無しさん
2015/06/06(土) 22:46:03.75ID:yk/a5xMg> というガイドラインのようなものならある程度意見はまとまってきそうだね
コミットをまとめる or まとめないのが目的じゃないからね。
コミットを綺麗にするのが目的。
当然の話だけどガイドラインには理由が必要だろうね。
まとめる理由が。（もしまとめないのであれば、まとめない理由も）
コミットをまとめたりまとめなかったりして、綺麗にする理由は
簡単にいえば、後からコミットを見た時にわかりやすいように
するためなんだが、もっと細かい理由って必要だろうか？
0582デフォルトの名無しさん
2015/06/06(土) 22:54:18.21ID:yk/a5xMg・一つのコミットで複数の修正を行わない
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
・一つの修正を複数のコミットにわけない（分かれていればまとめる）
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
例外 リリースしてしまったコミットはまとめることは出来ない。
いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。
と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。
0583デフォルトの名無しさん
2015/06/06(土) 23:00:59.08ID:OBriYrAJ0584デフォルトの名無しさん
2015/06/07(日) 00:12:36.70ID:5CuOmznLまとめる とか まとめない とかどちらか一方じゃない
どちらもやって、綺麗にしておけ。
0585デフォルトの名無しさん
2015/06/07(日) 02:04:34.40ID:VSY66R2E>>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ
無駄ではないか
それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド
ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう
0586デフォルトの名無しさん
2015/06/07(日) 02:08:39.07ID:VSY66R2Eそういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う
0587デフォルトの名無しさん
2015/06/07(日) 02:48:23.33ID:5CuOmznL> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
いないだろｗ
あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。
物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。
コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。
そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。
このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
■ このスレッドは過去ログ倉庫に格納されています