Git 12

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/ 528 名前：デフォルトの名無しさん mailto:sage [2015/05/23(土) 17:21:41.69 ID:x743ZDZ3.net] pushした先がリベースが許されるブランチかそうでないブランチかって違いであってプロジェクトの大きさは関係ないんじゃないの？ 529 名前：デフォルトの名無しさん mailto:sage [2015/05/23(土) 17:24:16.06 ID:x743ZDZ3.net] いや逆か。 push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。 530 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 00:38:55.87 ID:NuukhrjT.net] push後のリベースが許されるブランチ＝他の誰も見ていないブランチ？ サブプロジェクトどころか、一人プロジェクトだな 531 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 10:38:28.38 ID:GI5iGoR+.net] 話題がループしてるな。もうすこし世の流れを学んだ方がいいよ。 gitだと特に、ブランチの運用によって前提が大きく変わる。 GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、 それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。 だからpushしたブランチをrebaseしてもまったく問題ない。 むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい 532 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 11:16:37.86 ID:VWanxcqX.net] >>526 ん〜と、前提が大ブランチになってるとそうかもしれないけど Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから 得意技を積極的に使った方がお得な気がするな うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた その代わり、細かくコミットしろ、作業単位でブランチを分けろ って、半年くらいは口うるさく言い続ける必要があったけどね レビューの時にコミットツリー図を見ながら ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか ややこしいコンフリクトが生じた時に どういう手順ならマージが簡単だったかとか 具体的に教えたり、みんなで考えたりした 新しい文化を根付かせるのは大変だよ、いつでもさ 533 名前：デフォルトの名無しさん [2015/05/24(日) 14:14:44.04 ID:J9ZjzLe3.net] >>527 だからpushしたブランチをrebaseしてもまったく問題ない。 branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処 に push するの？ レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？ 534 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 15:41:15.45 ID:1k2HbjOC.net] ブランチを公開する際に中央リポジトリにpushする形式が考えられる 535 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:35:16.30 ID:LHzJ6dIN.net] 今コミットした後にgit pullしたらリモートの最新のログ（1個だけ）が追加されてしまいまして 今コミットしたログの後にそのリモートのログが来てしまいました git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません これってどうしたらいいんでしょうか？ 536 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:41:30.07 ID:Ewhf1zLw.net] >>528 となると、やはり 本体はSVNで、ローカルはgitで 別に管理したほうが全体が幸せになりそうだな 537 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:50:34.06 ID:Jl9gFOkM.net] レビューが終わって共有ブランチにpushしてからバグが見つかった場合に 共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな 538 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 20:03:35.12 ID:Jl9gFOkM.net] >>532 この人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ （それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう 539 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 21:34:38.73 ID:VWanxcqX.net] >>532 それはいい解の一つだと思う。特に移行期には。 うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。 でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。 当時の対象プロジェクトがちょうど区切り良く、 過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、 フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。 最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど 結局馴染んでくればgitの方が扱いやすくなってきたよ。 しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。 （でも日本語変だよマイクロソフトのgit） 540 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 22:05:23.23 ID:VWanxcqX.net] >>534 おれ>>528な 「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、 俺がgit使ってる（使わせてる）理由の一番大きい所は 「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。 俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。 レビューもそのままで特に問題は無かったな。 でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 特に問題だったのは（svn使っていた頃の話ね） 何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。 svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。 ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。 そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。 今は「マージ操作間違えても俺が直してやる。 安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。 これだけでも後から意図を読み取るのは随分楽になったよ。 541 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 22:19:55.92 ID:mdHWC0Am.net] 状況によるけどコミット分けたほうが見やすいというのは複数の作業単位(ブランチ)に分けるものを 一つのブランチに押しこんでるからじゃないの 機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし >>533 閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう >>531 リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ 次から最初からブランチ切っとけばこんなことで困らん 542 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 03:10:39.76 ID:WhsXE+Ib.net] >>536 個人でブランチ作ってコミットしたあと、どうすればいいの？ そのブランチを本家に取り込ませるの？ 543 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 05:59:36.31 ID:/VFybrtg.net] > でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 これ大事よね master に 544 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 06:01:10.35 ID:/VFybrtg.net] 途中で書きこんでしまった > でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 これ大事よね master に wip と fix typo が積み重なってた時は流石に萎えたけど 545 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 08:14:58.07 ID:y6DNlXTS.net] >>540 ＞master に wip と fix typo が積み重なってた時は流石に萎えたけど そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう 546 名前：523 mailto:sage [2015/05/25(月) 09:19:23.83 ID:E69UDjHE.net] >>529 > >>527 だからpushしたブランチをrebaseしてもまったく問題ない。 > > branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処 > に push するの？ > > レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？ 自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。 典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する 547 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 13:36:42.28 ID:XuKAmWn9.net] 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、 まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん 548 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 13:49:29.09 ID:XuKAmWn9.net] >>531 あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い 検索すりゃ方法わかると思うので調べてみてくれ 549 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 22:51:38.00 ID:o/eCAQPj.net] 共有ブランチ上のバグを直すために共有ブランチ上のコミットを書き換えるんだとしたら、 書き換え前のコミットををベースにしている人への配慮が必要そうだな 各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース してください」って頼んで回れる環境が必要だ 550 名前：212 mailto:sage [2015/05/25(月) 23:42:12.33 ID:fVXVPz7E.net] gitってなんでMakeFileにuninstallが用意されてないんですか？ アンインストール作業が苦痛なんですよ makeだけでアンインストールさせてくださいよ 551 名前：538 mailto:sage [2015/05/26(火) 00:30:58.55 ID:VHuDuKFu.net] >>543 > 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、 > まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん 中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。 これが GitHub flow な。 元が「 >>526 Pushしたブランチは書き換えてはならん」への反論だから、 そうでない運用もごく一般的、という主張をしたということ。 552 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 08:35:26.55 ID:n+9g7Zgu.net] 「各メンバーが、個人用ブランチをリモートリポジトリ上に持っている」 これじゃ>>526への反論になってないっていうか、>>526が言ってることそのままだな 553 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 17:27:09.33 ID:sKFLbSMM.net] >>545 そうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。 554 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 17:39:03.82 ID:sKFLbSMM.net] >>548 個人用ブランチは作成者だけが見るわけじゃないから>>526とは違うな。 >>526は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？ 単に極論言って煽ってるだけかもしれないけどね。 555 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 18:06:24.50 ID:2IsijlAj.net] ところでそれだけ熱心なブランチ管理のpush,rebase制限はどうやってる？ 規約任せかツールかスクリプトか 556 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 18:23:29.30 ID:O0gIeBts.net] うちは原則push -f禁止でやってるんで、みんながpushするサーバーにはreceive.denyNonFastforwardsとreceive.denyDeletesを設定してる 557 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 20:10:30.68 ID:qT5tL8rR.net] 横だがどうやって禁止するのかと思ったらちゃんとそういうコンフィグが用意されてるのか 一回オプション総ざらいしてみよう 558 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 22:07:42.46 ID:1ouiCH4F.net] >>549 で、>>523が言ってる「プロジェクトの規模が小さい場合には それができる」って話につながってくるのか…。 559 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 23:55:53.54 ID:2IsijlAj.net] >>553 それブランチごとじゃなくて一律だからアクセス制限にはならないぞ 560 名前：デフォルトの名無しさん mailto:sage [2015/05/27(水) 12:17:18.05 ID:98FdFg1V.net] Git 2.4.2 https://github.com/git/git/releases/tag/v2.4.2 561 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 20:55:03.14 ID:2hiQrePQ.net] 特定のファイルを特定の履歴に戻すのはどうやるんでしょうか？ a.txtをHEAD@{12}のa.txtの内容にしたいんです git reset HEAD@{12} a.txtじゃ戻りませんでした 562 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 21:23:55.63 ID:q0XD6tk+.net] checkoutせよ 563 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:34:02.79 ID:6w2KJtLO.net] git init git add -A このaddを取り消したいんですがgit reset HEADをやると fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. ってでます git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？ 564 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:39.31 ID:wXX1PCBE.net] まだHEADに相当するコミットが存在しないから 565 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:41.39 ID:60FC1uF1.net] 1回もコミットしてないとか？ 566 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:43:38.24 ID:wXX1PCBE.net] おれはそんなとき.gitをざっくり消したりしてたが、 ぐぐると git rm --cached が使えるみたいだな 567 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 10:41:16.23 ID:2Bq+WaXR.net] git rebaseでどこまでまとめるべきなのかわかりません 例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合 一緒にまとめたほうがいいんでしょうか？ 568 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:36:32.71 ID:ENh0ws/u.net] Windows版のバージョンは上がらんのかえ 569 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:29.49 ID:dwjHRJAm.net] 自分でコンパイルしろよ 570 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:35.29 ID:H1H2VilB.net] >>563 その二つならまとめない。 もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。 571 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:22:55.03 ID:knJmPdD6.net] >>563 そういうgit運用の話は、「管理者の意見に従うべき」 個人用or自分が管理者なら、好きなようにやっていい。 572 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:42:10.75 ID:3kJPkUc2.net] >>567 少しは助言してやれよ 573 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 03:55:40.59 ID:cOL0IOxC.net] どのやり方が良いかなんて決まっているわけじゃない 色々試して自分が一番しっくりする形を探すか 最も採用されていると思えるやり方というのを見出してそれを選択するか 有名どころのオープンソースプロジェクトの方針を色々と見てくるといい 574 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 05:32:16.44 ID:5OGKD7dq.net] 俺がまとめる基準はそのまとめたコミットに判り易いひとつのタイトルをつけられるかどうかあたり でも優先されるべきはそのリポジトリの管理方針なのは間違いない 575 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 10:17:17.28 ID:qaWpPbOF.net] ところでpost commit mail送るのに何使ってる？ うちはmultimail使ってるがなんかしっくり来ない 576 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 01:27:40.14 ID:FZpfA7xp.net] >>569 お前はどうやってるんだよ 577 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:38:54.51 ID:ixdJmRIH.net] 俺は初心者の頃にここでコミットをまとめるなって言ってこのスレを炎上させた初心者＋だけどさ その時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ 一体まとめろ！まとめるな！のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる 1. initial commit ---- ここから ----- 2. save 3. type 4.　○○実装 5.save 6.○○実装 7.typo 8.ファイル追加 ----- ここまでまとめる ------- tagで1.0って付ける 578 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:43:29.77 ID:lUVfOohh.net] バージョン毎にまとめろとか誰も言ってないだろ 具体的にそのやりとは何スレ目だよ 579 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:47:48.34 ID:w41Ky1ux.net] >>573 「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、 どういうときはまとめたほうがよい どういうときはまとめないほうがよい というガイドラインのようなものならある程度意見はまとまってきそうだね 580 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:46:30.21 ID:7Y8AXPNC.net] 後から分離したくならないものはまとめる 要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか？と考えればいい 581 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:49:14.71 ID:5FZxl5co.net] そうして全てのコミットはひとつになった 582 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 16:11:36.89 ID:a/IZmogk.net] コミットを入れ替えるときにコンフリクトって起きないんですか？ git 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が自動的に面倒見てくれてるんですか？ 583 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:10:10.65 ID:lUVfOohh.net] Gitでは各コミットがその時点での全ファイルの状態を持ってるけど、 rebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな >>578のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、 "modified a"コミットにbは存在しなくなる rebase -iでコンフリクトは起こる 例えば>>578の"add a"と"modified a"コミットの順番を逆にしたりすれば 584 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:23:21.52 ID:69dFu2L0.net] >>573 正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな 585 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:46:29.00 ID:b+4KVUcq.net] 少なくともどの時点でもコンパイル通るようにコミットまとめる 大きくても機能ごとにはコミット分ける でその間はプロジェクトごとに方針あれば何でも 586 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:34:59.14 ID:4eOWDqlW.net] 問題は俺自身に経験がないのに 俺がルールを決めなきゃいけない時だな 587 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:35:56.50 ID:yk/a ] [ここ壊れてます] 588 名前：5xMg.net mailto: >>573 お前、マージ使ってないだろ？ まず前提として「一つのプロジェクトを複数の人が平行で開発している」という 個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。 よくある間違いが、小さい規模の例だけで考えて、 それがそのまま大きな開発にも適用できちゃうって考えること。 君はその間違いはまってる。 （俺が知ってる）小さい規模ではこれでうまくいくんだ。ではなくて 大きな規模になった時それでうまくいくのか？を考えた方がいい。 適切なやり方というのは、規模によって変わるんだから。 [] [ここ壊れてます] 589 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:41:32.51 ID:yk/a5xMg.net] >>581 問題は1コミットを後から見直すかどうかだよな。 後から見なおさないのであれば、どんなに意味不明な修正でも 同じ所を試行錯誤したコミットでも、何百行あるコミットでも 何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい でもあとからそのコミットを見るのであれば 修正内容が明確にわかるコミットが必要最低限あった方がいい。 あとからそのコミットを見るかどうかだよ。 もちろん俺はよく見る。 仕事でもその修正が適切であるかを見たり、 オープンソースとかでもある修正内容を見たり だからコミットは分かりやすくなっていたほうがいいと考える。 590 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:46:03.75 ID:yk/a5xMg.net] >>575 > というガイドラインのようなものならある程度意見はまとまってきそうだね コミットをまとめる or まとめないのが目的じゃないからね。 コミットを綺麗にするのが目的。 当然の話だけどガイドラインには理由が必要だろうね。 まとめる理由が。（もしまとめないのであれば、まとめない理由も） コミットをまとめたりまとめなかったりして、綺麗にする理由は 簡単にいえば、後からコミットを見た時にわかりやすいように するためなんだが、もっと細かい理由って必要だろうか？ 591 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:54:18.21 ID:yk/a5xMg.net] 少しだけガイドライン考えてみた ・一つのコミットで複数の修正を行わない 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから ・一つの修正を複数のコミットにわけない（分かれていればまとめる） 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから 例外 リリースしてしまったコミットはまとめることは出来ない。 いま気づいたが、この「リリース」っていう概念が重要だな。 どの時点でリリースになるのかはそれぞれだろうが master、もしくは共有ブランチににマージされた時点がリリースだと考える。 と考えると、やはり>>573の例ははマージ機能を使ってない時点で 一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。 592 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 23:00:59.08 ID:OBriYrAJ.net] 3行で 593 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 00:12:36.70 ID:5CuOmznL.net] あとから見てわかるようにコミットを綺麗にしておけ まとめる とか まとめない とかどちらか一方じゃない どちらもやって、綺麗にしておけ。 594 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:04:34.40 ID:VSY66R2E.net] 一つのコミットに入れる一つor複数の修正って、何単位で一つと呼ぶのかって話もあるし、 >>545と>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」 って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ 無駄ではないか それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう 595 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:08:39.07 ID:VSY66R2E.net] >>582 そういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う 596 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:48:23.33 ID:5CuOmznL.net] >>589 > >>545と>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」 いないだろｗ あぁ、なんで共有ブランチにpushしたコミットは 編集したらだめなのかを書いていなかったね。 物事は単純で、他人の役に立つことをしましょう、 他人の迷惑になることはうやめましょう。これだけだよ。 コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。 これは他人の役に立つこと。 そして共有ブランチを修正したらだめというのは、他の人も その共有ブランチから派生して修正しているので、その派生元が変わると 今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。 これは他人の迷惑になること。 このように俺のガイドラインにはちゃんと理由がある。 反対のガイドラインを作りたいなら、その理由をいうことだけ。 でないと俺の意見に対抗できない 597 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:52:10.94 ID:5CuOmznL.net] 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。 俺が言ってる共有ブランチっていうのは、 他の人がそのブランチから作業をする、 または他の人がそのブランチにマージすると という目的で作られたブランチのこと。 つまり他の人が参照しているだけならば 共有ブランチとは言わない。 参照しているだけならば、そのブランチが変わっても 他の人の作業のじゃまにはならないからね 598 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:54:19.37 ID:5CuOmznL.net] ということで、何故そうするのか、どんなメリットがあるのかを しっかりと書いたガイドラインを、俺以外に出すのまってま〜すｗ 599 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:11:47.35 ID:V49LqTdE.net] >>591 ＞いないだろｗ いや、>>545が「共有ブランチ上のコミットを書き換えるんだとしたら」と言ったのに対して >>549が「そうだよ」と返しているので、いること自体は確かなようだ 545に対して、あなたがどうロンパするかは別に知らないが 600 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:31:51.05 ID:V49LqTdE.net] >>583-584 全部のコミットをひとつにまとめて周りから怒られなかったなら、 それは正しいまとめ方だったと思うんだけどね 601 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:19:13.74 ID:5CuOmznL.net] >>594 > 545に対して、あなたがどうロンパするかは別に知らないが 論破？ 何故そうするかの理由がないのだから、 まずその理由を言うのが先だろうｗ 602 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:20:45.23 ID:5CuOmznL.net] >>595 > 全部のコミットをひとつにまとめて周りから怒られなかったなら、 周りの人間がコードを見るということを知らないだけかもしれない。 スキルが低くてソースコード管理ツールすら知らない人もいるのだから。 だからそれは全く参考にならないな。 理由だよ理由。 俺は何故そうするかの理由を書いた。 この俺を論破する理由をかける奴はいないのか？ｗ 603 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:21:31.63 ID:yxti539q.net] 誰か運用スレ立ててくれない 604 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:52:14.95 ID:V49LqTdE.net] 結局は>>589の言ったとおりになるという、悲しい現実 >>598 運用スレを建てても、荒らしがそこに移動するかどうかは別問題だと思う 605 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:04:07.08 ID:yxti539q.net] 運用スレ行けと言えるようになるだけ幾分マシかと 606 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:08:53.36 ID:V49LqTdE.net] >>600 なるほどそうかもしれないね そういう意味だと、既存だとここあたりが適切なのかな バージョン管理システムについて語るスレ10 peace.2ch.net/test/read.cgi/tech/1393147031/ 607 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:12:32.75 ID:5CuOmznL.net] >>599 > 結局は>>589の言ったとおりになるという、悲しい現実 大丈夫。 俺が言った「ガイドラインを言う時は理由も明確書くこと」 のおかげで、今のところガイドラインは俺が言った一つしかでてない。 608 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:17:04.64 ID:yxti539q.net] >>601 ここでされてるの横断的でない個別的な内容だからスレチ 609 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:18:47.22 ID:V49LqTdE.net] >>603 そっか、じゃあ新スレがいるか・・・ 610 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:17.32 ID:V49LqTdE.net] >>602 ＞今のところガイドラインは俺が言った一つしかでてない。 そりゃ出ないでしょ 誰も関わりたくないんだから 611 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:26:15.60 ID:5CuOmznL.net] >>604 スレ立てておいたよ。 Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ >>605 > 誰も関わりたくないんだから 関わりたくないのが理由っていうのはおかしな話だな（笑） 言い返せない時に汎用的に使えそうな言い訳だ。 612 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:31:19.54 ID:V49LqTdE.net] >>606 ありがとう じゃあここから先は、ここで運用系の話をするのはスレ違いってことで、 あとはそっちでやってもらおう 613 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:42:31.68 ID:yxti539q.net] >>606 タイトルを単にGit運用スレにできないあたり自己顕示欲あふれるスレタイですね 614 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 15:41:57.12 ID:D5MO+jlJ.net] 立てたら立てたで文句言う奴 w 615 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:06:00.04 ID:D+Qsqenv6] はじめまして。　質問させてください。 とあるリポジトリに以下のようなブランチがあります。 ・master　特に進んでない ・masterから作成したブランチA　最初のほうだけ開発 ・ブランチAから作成したブランチB　あらかた開発 ・ブランチBから作成したブランチC　テストコード開発 masterとAは他人が作ったもので、 私はそれを引き継ぐ形でBで開発していました。 そこからCでテストコードを作ることになり、 一応終わったのでBにプルリクを出したところ少しのやり取りののちマージされました。 そのあとで不具合に気がついたのでまたコミットをしたいのですが、 この時`git checkout`でBに移動してから行うべきでしょうか？ それともそのまま行ってもよいのでしょうか？ CがマージされたBに続く形にしたいのですが、 Bで`git status`すると"Aより104コミット進んでいるから`git push`使って公開して"というような英文があり、 同様にCで行うと"Bより16コミット進んでいるから`git push`使って公開して"というような英文があるので、 言われたとおりにpushしたらコミットはどうなるのでしょう？ Cを作るときにpush漏れはないですし、Cがマージされた時も同様にないのですが。 616 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:26:22.23 ID:5CuOmznL.net] いるいるw 617 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:53:47.38 ID:V49LqTdE.net] >>608 荒らしが自分で建てたスレなんだから、そうなるのはしょうがない 運用の話はそっちでやってもらいましょう 618 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:53:48.87 ID:yxti539q.net] 自分で立てたスレなんだからもちろん自分は引っ越して誘導もするんですよね 期待してますよ 619 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 20:06:44.60 ID:5CuOmznL.net] >>613 はい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。 みなさんも協力してくださいね。 逆に運用以外の雑多な内容はこっちに移動しますよ。 620 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:10:56.78 ID:V49LqTdE.net] >>613 おみごと 621 名前：連続書込しすぎなのでID変えます mailto:sage [2015/06/07(日) 21:22:11.43 ID:rs3gN1uE.net] このスレから運用に関することをなくしたら どれだけのレスが残るか期待ですｗ ぜーんぶかっさらっていきますよーｗ 622 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:49:02.86 ID:HSoSL4U1.net] git とうまく組み合わせられるような バグトラッキングツールでおすすめのはある？ mantisってもう人気無い？ 623 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:52:12.28 ID:V49LqTdE.net] これでツールの質問ができるようになるのか、 または、ツールの質問に答えられる人なんて初めからいなかったのかがハッキリするな どっちにしても平和になってよかった 624 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:57:36.23 ID:/P0faz6I.net] Egitで、amendじゃなくてもっと過去のコミットを編集するには 画面上でどういう操作をすればいいんでしょうか？ 625 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:03:03.72 ID:rs3gN1uE.net] githubの使い方を教えて下さい。 626 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:13:31.59 ID:rs3gN1uE.net] >>619 よめ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja 627 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:14:24.04 ID:rs3gN1uE.net] WindowsでGUIでgitを使いたいです。 なんか良いツール無いですか？ 628 名前：616 mailto:sage [2015/06/07(日) 22:16:23.46 ID:rs3gN1uE.net] >>619 すまんすまん。EGitっていう名前のツールがあるのか。 ならこのスレだ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef