- 1 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 21:16:57.41 .net]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 7
toro.2ch.net/test/read.cgi/tech/1381929347/
- 81 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 20:43:25.61 .net]
- ありがとう
ブランチって削除できないのかぁ
- 82 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 20:46:06.48 .net]
- タグに重要度みたいなのをつけられる？
重要なタグと重要じゃないタグをあとから区別したいんだけど
どうすらいいか
- 83 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 20:55:54.41 .net]
- まるまるメインにコミットしたなら消してもいいだろ
試行錯誤して採用しなかった結果を個人的に残しておきたいときもあるんで、
リポジトリを別に作ってpushしておいたりもするが
- 84 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 20:56:38.29 .net]
- >>80
ブランチ削除できるだろ
- 85 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 20:58:15.64 .net]
- >>74
> 今読んだけどGithub-flowではリクエストをいったん取り込んで細かいとこ修正という流れができないから
> オープンソース開発には向いてないんじゃないか
なんで？
そのリクエストが動作に問題がないのであれば、取り込んで後から修正すればいいじゃん。
動作に問題があるのなら、github-flowでなくても取り込んじゃいけないし（ちゃんとテストしてから取り込む）
そういうのは、取り込まずに修正させればいいし、別ブランチで修正してから取り込んでもいい。
- 86 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 21:40:54.79 .net]
- >>81
タグ名にルールをつけて、後でgrepすればいいんじゃない。
- 87 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 22:05:55.02 .net]
- >>84
リクエストはマスターに来るだろうから即デプロイ可能な品質のコード以外は一度破棄することになる
マスタに入れる前に信用できるメンバーがテストをしないといけないが修正とテストをするためには相手か自分でブランチを切らないといけない
git-flowならデベロップにガンガン突っ込んで自分で直していけるのにリクエスト1個1個にブランチ切るのは効率悪すぎるしコンフリクトの温床になるだろ
ならメンバーはホットフィクスその他はデベロップでgit-flow流用したほうがいいんじゃないの
- 88 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 22:13:06.06 .net]
- git-flow打つの面倒だから略語くれ
- 89 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 22:37:37.91 .net]
- >>86
それのどこがgithubフローと関係あるの？
即デプロイ可能な品質のコード以外を一度破棄するのは
どのフローでも同じじゃん。
> マスタに入れる前に信用できるメンバーがテストをしないといけないが
信頼できるメンバーがテストしていないコードをマスターに入れていいフローなんてあるの？
> git-flowならデベロップにガンガン突っ込んで自分で直していけるのに
コードは手に入ってるんだからマスターに入れずに直せばいいだろ。
> リクエスト1個1個にブランチ切るのは効率悪すぎるし
gitでブランチ切るコストはほぼ0だろ？ いくら切っても効率は下がらない。
> コンフリクトの温床になるだろ
それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
開発者が一人しかしないというのなら話は別だが？
- 90 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:26:32.45 .net]
- > 即デプロイ可能な品質のコード以外を一度破棄するのは
> どのフローでも同じじゃん。
OSS開発で集まる技術レベルのまばらな人間に十分な品質のコードを求めるのは非現実的
修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い
> 信頼できるメンバーがテストしていないコードをマスターに入れていいフローなんてあるの？
デベロップに入れるなら動かなくてもかまわないがgithubはマスタしかないのでそれができない
> コードは手に入ってるんだからマスターに入れずに直せばいいだろ。
マージしないで手で拾っていくのはGitの効率性を捨ててるし協力してくれる人もいなくなる
> gitでブランチ切るコストはほぼ0だろ？ いくら切っても効率は下がらない。
なくていいブランチが増えまくって見通しが悪くなるのは明らかに余計な負担
バグフィクスのリクエスト100個のために100個のブランチがある状態にしたいか？
> それはどんなフローでも一緒。同じファイルを修正すればコンフリクトは起きる。
順次修正するならそうだが複数のリクエストをまとめて取り込んで修正する方法の選びやすさが違う
温床は書きすぎたのでもとになる程度にしとく
- 91 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:40:11.08 .net]
- コンフリクトの量じゃなくて解消しやすさだな
- 92 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:47:20.75 .net]
- git-flowやgithub-flowに替わる新しいflowを誰か考えてくれや
- 93 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:54:17.71 .net]
- >>89
> バグフィクスのリクエスト100個のために100個のブランチがある状態にしたいか？
それgitでは普通だけど？
言っておくけど、gitではブランチは消すものなので、
バグがフィクスされれば、ブランチはなくなる。
- 94 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:56:07.46 .net]
- >>89
> デベロップに入れるなら動かなくてもかまわないがgithubはマスタしかないのでそれができない
デベロップでも入れたらダメだろ。
なんで、自分のレポジトリで修正するって考えが浮かばないのかな？
> マージしないで手で拾っていくのはGitの効率性を捨ててるし協力してくれる人もいなくなる
完成してから、ブランチをマージすればいいだけ。
Gitの効率性＝分散開発 なのだから別リポジトリで作業すれば良い。
- 95 名前：デフォルトの名無しさん mailto:sage [2014/01/28(火) 23:56:59.26 .net]
- >>89
> 修正させてもどうせ満足なもんにならないし自分で直すのが手っ取り早い
自分のリポジトリで、自分で直してからマージすれば？
つか、なんでマージしてからじゃないと修正できないと思うんだよ？
- 96 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 00:08:22.02 .net]
- なんでケンカ腰なの？戦闘民族なの？
- 97 名前：デフォルトの名無しさん [2014/01/29(水) 00:25:36.01 .net]
- ' , ＼､ 、| ヽ l / ／ ヽ, ／ / /
｀`ヽ ヽヽ! , lj ヽ i／ , ' u !／ ／ /
、 ヽ＼ ｀ l_/ /｀ヽ､ ヽ/ ／ ,. ' ´ヽ l ,'／'´ ／__
､ ヽ、 ,へ､/ ,ﾍ｀`ヽ､ヽ. ｀ / ／,. -‐,´ _!,-､ ／ ／'´／
ヽ＼｀` l l^ヽ,', ', oヽ`､} ﾚ／o ,' 〉"^l/／'´／
＼､ l l r' ', ー―‐",｀ｰ´`ｰ―‐' //_',/_,. -;ｧ
,.ゝ-＼ｰ､ ','""""" ﾉ_ ゛゛゛゛｀ /'_j / ／
｀`,ゝ-ゝ､_',u r====ｮ /-／_／
´￣｀`ｰ,ﾍ `===='' /=''"´
,'､ ｀ヽ、,:' -‐- , '｀`>、
ﾉ`::ｰ-､_＼＿＿,／_,. ::'´:::::冫二ニ７7ｰ-
,...-､‐ニ二{{:::::::::::::::::::::::::::::::::::::::::::::::::::::/ニニﾆ〃::::::::
:::::::::ヽニ二ヽ:::::::::::::::::::::::::::::::::::::::::::::::/二二ﾆ〃:::::::::::
- 98 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 01:49:37.30 .net]
- こんな感じでもめるから *-flow が出来るわけなんだよな
- 99 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 02:03:40.19 .net]
- 何か実装するときにはみんなdevelopブランチから新しいブランチ作って始めるんだから、
developブランチに動かないものマージするなんて言語道断
- 100 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 02:07:30.71 .net]
- すぐ喧嘩するなお前ら。まあ俺もだけど。
- 101 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 03:25:17.30 .net]
- メジャーなリポジトリの使用例見てきた
> それgitでは普通だけど？
仕事でやれば普通でも通りすがりの他人にそこまでやらせんだろうと思ったけどやらせるのか・・・？
実際は完成させてから入れてるからそんな状況にはならないようだけど
終わったブランチは消してる
> なんで、自分のレポジトリで修正するって考えが浮かばないのかな？
自分のリポジトリ
> 完成してから、ブランチをマージすればいいだけ。
要求レベル高すぎと思ってたけどほかの人みたらそれで回してるようなのでそうします
> つか、なんでマージしてからじゃないと修正できないと思うんだよ？
気分的に投げられたコード放置しづらかったので
> 何か実装するときにはみんなdevelopブランチから新しいブランチ作って始めるんだから、
> developブランチに動かないものマージするなんて言語道断
そういや担当を決めないからとんでもないことになるか
やめよう
夜更かししすぎた
- 102 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 21:40:58.44 .net]
- >>85
ありがとう
それしか方法がないのか
意外とかゆいところに手が届かないね
- 103 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 22:00:17.62 .net]
- ふつうのひとは
そんなところ
かゆくならない
- 104 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 22:03:07.40 .net]
- 世の中便利ツールが増えすぎて人間が不精になってきてるのな
grep程度を手間とか
- 105 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 22:07:25.84 .net]
- >>103
grepが手間とかじゃあないんだよんべ
タグ名にそういう意味も持たせる ってのがちょっと嫌なだけ
みんな大好きなハンガリアン記法でしょ
- 106 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 22:17:35.92 .net]
- つgit notes
- 107 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 23:37:14.60 .net]
- jpegやbmpみたいなバイナリファイル、ワードやエクセルのファイルを
管理するにはどうすればいいの？
企業内開発では避けては通れないんだけど、チェックイン＆チェックア�
- 108 名前：Eト
みたいな管理はできるの？ [] - [ここ壊れてます]
- 109 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 23:38:47.49 .net]
- あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
- 110 名前：デフォルトの名無しさん mailto:sage [2014/01/29(水) 23:41:34.39 .net]
- あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
- 111 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 00:08:24.68 .net]
- 開発用と社内アーカイブ用で分けるとか？
- 112 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 00:20:52.94 .net]
- >>108
1度言えばわかる
- 113 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 00:35:08.71 .net]
- >>110
すまぬ
タイムアウトして、リロードせずに再度投稿しちゃったもんだから…
- 114 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 01:22:17.29 .net]
- あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
- 115 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 01:36:43.35 .net]
- gitってどの辺がperlに依存してんの？
今一分からん
- 116 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 01:52:33.89 .net]
- >106
SVG
- 117 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 02:28:21.77 .net]
- >>101
Excelとか何でもかんでも詰め込んだアプリでも使っとけ。
俺は今のgitでも詰め込みすぎててちょっと不安。キープシンプル。
- 118 名前：デフォルトの名無しさん [2014/01/30(木) 03:58:50.02 .net]
- あんまり要素増やされてもなあ…
既存の要素で出来るなら、それでいいと思う
- 119 名前：デフォルトの名無しさん mailto:sage [2014/01/30(木) 17:16:32.69 .net]
- >>106
シェアポイント
- 120 名前：デフォルトの名無しさん [2014/01/30(木) 23:51:55.27 .net]
- あるタグから後ろのコミットのメッセージの一覧
ってどうやって取得できるんだっけか
- 121 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 00:06:29.73 .net]
- 後ろって？
- 122 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 00:11:14.15 .net]
- >>118
git log tag..
でカレントブランチのtag以降のコミットを見れる。
git log tag..branch
で任意のブランチのtag以降のコミットを見れる。
- 123 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 00:28:16.85 .net]
- 後ろって言えば、そりゃ、右を90度回転させたところよ。
- 124 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 00:30:58.29 .net]
- >>121
おかしいな、前にみえる。
- 125 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 00:33:43.32 .net]
- どんな規模のプロジェクトだろうと一番の問題はコミュニケーション齟齬、あいまいな言葉を使うなどで生じやすい
- 126 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 01:29:51.93 .net]
- >>120
おっ サンキュウ
- 127 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 10:01:32.16 .net]
- 右手の親指と人差し指を90度に開いてL字にして
親指を垂直上方向に向けて人差し指を正面に向けた時に
人差し指を反転した方向が後ろ
- 128 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 10:04:31.35 .net]
- 右京区は地図の上では左
- 129 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 10:37:43.01 .net]
- ITpro
伝わる文章：5日目「曖昧な曖抽象的表現の多い文章」はダメである 2014年01月31日
www.nikkeibp.co.jp/article/news/20140131/382014/
相手に伝えやすくする方法の一つに「曖昧に書かない、抽象的表現を使わない」ということがあります。
曖昧な表現や抽象的な表現は、読み手の理解を妨げます。「かなりよい」、「とても大変」、
「我々には考えつかない程の大きな考慮点が必要」などの表現は、
相手に正しく理解してもらえないダメ文章に繋がります。
- 130 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 23:49:10.43 .net]
- Gitを使い始めてから俺の生産性が500%上がった
- 131 名前：デフォルトの名無しさん mailto:sage [2014/01/31(金) 23:59:44.14 .net]
- >>127
フェルミ推定をディスってるな。
フェルミ推定は曖昧な情報で
相手を納得させる技術だからな。
- 132 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 00:18:36.80 .net]
- フェルミ推定 - Wikipedia
ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A
> 手掛かりを元に論理的に推論し、短時間で概算することを指す
「曖昧」や「抽象」とは異なる
フェルミ推定を誤解してると言わざるを得ない
- 133 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 08:04:08.63 .net]
- ～すると、大変なことになります。[EOF]
という文章を見ると殺意がこみ上げてくる
- 134 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 08:12:37.83 .net]
- 禿丸ω
- 135 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 09:19:35.19 .net]
- ～すると幸せになれる
ブログなんかの解説でこれ見たらファビョりそうになる
- 136 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 09:44:53.70 .net]
- でお前らはどこにリポジトリをぶん投げてるの？
GitHub？
- 137 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 10:39:24.08 .net]
- githubでしか使ってない
会社はsvn
- 138 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 10:59:58.72 .net]
- >>134
GitLab
- 139 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 17:22:58.76 .net]
- 最近色々な同様のサービスのサイトが出来てきて迷うよな
GitLabはGitLab cloud?
- 140 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 18:27:59.15 .net]
- GitLabはサービスじゃないよ。
GitHubのEnterprise相当の機能をもった
オープンソースのウェブアプリ
- 141 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 18:29:31.06 .net]
- >>134
どこってVPSとかそういうことか?
- 142 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 20:21:27.39 .net]
- リモートはSourceForge.JPの作業部屋っていう個人リポジトリとGitHubの個人リポジトリ使ってる
GitLab cloudやbibucketも最近気になってる
- 143 名前：デフォルトの名無しさん mailto:sage [2014/02/01(土) 23:53:17.42 .net]
- Dropboxにベアリポジトリ置くの超便利
- 144 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 00:03:37.19 .net]
- 自動同期はあまり好きじゃない
- 145 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 04:25:13.05 .net]
- azure
- 146 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 04:57:28.17 .net]
- そこらにある普通の無料レンタルホームページサービスじゃ
gitのベアリポジトリの公開は無理そうだな
OSSのホスティングサービス使うしかないのか
- 147 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 05:56:10.49 .net]
- なんでGitLab cloudがあるのに
レンタルサーバーなんか使わんといかんのだ？
- 148 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:29:58.87 .net]
- サーバーに対する信用性の問題じゃね
そこらのレンタルサーバーのほうが信用性がおけるならレンサバのほうでGitLabなりを構築する
レンサバよりもGitLab cloudなどの非公開リポジトリ可のサービスのほうが信用たるならそっち使う
という感じだろ
- 149 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:30:52.13 .net]
- あとレンサバ使う理由としては独自ドメインを使いたいとかもあるんじゃないかな
- 150 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:38:11.08 .net]
- あとは費用の問題とか
GitLab cloudなどのサービスだとgitサーバー以外の出来ることが限られるけど
サーバーマシンそのものを借りるレンサバなら色々好きに構築できるし
- 151 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:39:36.24 .net]
- おいおい、前提として
「そこらにある普通の無料レンタルホームページサービス」
だろ？
専用サーバーとかVPSの話はするなよ。
- 152 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:50:00.38 .net]
- >>149
勝手に前提つけるなよ
- 153 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:56:15.17 .net]
- 「そこらにある普通の無料レンタルホームページサービス」
これは自動挿入される広告とかで収入上げてんだろ？
gitみたいなダウンロードだけのことは規約違反だろＪＫ
- 154 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 06:58:10.48 .net]
- >>150
>>144にかいてあるじゃないか
> そこらにある普通の無料レンタルホームページサービスじゃ
- 155 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 07:52:02.69 .net]
- >>152
もともとの>>134の話題にレスしてる人もいるんだからってことだよ。
- 156 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 14:28:11.08 .net]
- 現在のブランチから分岐している(=fast-forwardの関係にない)ブランチを簡単に
リストアップする方法ってありますか？
- 157 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 19:18:24.63 .net]
- 現在のブランチのHEADから分岐してる別のブランチは、fast-forwardの関係にあるだろ？
- 158 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 21:38:19.41 .net]
- >>154をどう読んだら「HEADから」と思うんだ？
- 159 名前：デフォルトの名無しさん mailto:sage [2014/02/02(日) 21:38:35.69 .net]
- git branch --no-merged
とかじゃだめ？
- 160 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:00:05.83 .net]
- >>156
「現在のブランチから分岐している(=fast-forwardの関係にない)」
- 161 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:01:18.39 .net]
- >>158
それのどこにHEADの要素が？
- 162 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:06:23.60 .net]
- それのどこにHEADを除外すると書いてあるんだ？
- 163 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:14:50.84 .net]
- ┌────────── ← fast-forwardでないブランチ
┬┴─────┬──── ← 現在のブランチ
└─┬────┘ ← マージされたブランチ
└───────── ← fast-forwardなブランチ
こんな感じ？
- 164 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:17:14.79 .net]
- ┌─■──■──■───── ← fast-forwardでないブランチ
┬─■─┴─■─■───┬──── ← 現在のブランチ
└─■─┬───────┘ ← マージされたブランチ
└──■──■───── ← fast-forwardなブランチ
こんな感じ？
- 165 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:18:23.13 .net]
- fast-forwardになってない
- 166 名前：￣￣￣∨￣￣￣￣￣￣￣￣￣ mailto:sage [2014/02/03(月) 00:23:28.23 .net]
- ┌■─■─■─■─■── ← fast-forwardでないブランチ
┬■┴■─■─■─■┬─── ← 現在のブランチ
│ │ └■─■─ ← fast-forwardなブランチ
└■┬■─■─┘
└■─■─■─■─■── ← fast-forwardでないブランチ
こんな感じ？
- 167 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:23:57.45 .net]
- fast-forwardは重要な概念だからちゃんと理解しとけよ
>>161-162は落第
- 168 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:30:19.95 .net]
- fast-forwardの解説おながいしまうｓ
- 169 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:30:24.95 .net]
- 一番下のブランチは派生元のブランチがマージされてるから現在のブランチの分岐扱いになるのかな
- 170 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:32:23.03 .net]
- >>166
fast-forwardとは
HEADが指すコミットを最新のコミットを指すようにするだけで済むマージ
fast-forwardでないとは
マージコミットが発生する
- 171 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:34:23.66 .net]
- ブランチ切った後にそれぞれにコミットが発生すると初めて分岐が発生して
fast-forward じゃなくなる、でOKじゃないのかね
- 172 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:44:11.57 .net]
- ┌■─■─■─■─■── ← ノーマルエンド
┬■┴■─■─■─■┬─── ← ハッピーエンド
│ │ └■─■─ ← 真のエンディング
└■┬■─■─┘
└■─■─■─■─■── ← バッドエンド
- 173 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:48:50.26 .net]
- >>169
それぞれ、だけと片方だけでもよさそうだからダメだな。
それぞれに異なるコミットが、にすればいい。
あと、さっきからHEADをsvnみたいな意味で使ってるやつがいるのか？
- 174 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 00:57:32.30 .net]
- >>168
よくある説明だけど、わかっている人にはわかって
わからない人には全然わからない答えだよな。
たとえば、オープンソースのコードをcloneして
手元にソースコードをダウンロードしているとする。
数日後バージョンアップしてソースコードが更新された。
fast-forwardとは 最新のソースコードまで更新履歴を単純に進めること（早送り）
fast-forwardをするとソースコード消して取りなおしたのと同じことになる。
それとは別にfast-forwardをしないでマージコミットを作るやり方があって
これは現在から最新までの変更分を一つ（ないし複数の）コミットとしてつけたすもの。
fast-forwardの代わりにマージコミットを使っても最終的に同じになるのだが変更履歴内容が違う。
またfast-forwardはclone元から単純に遅れている時にしか使えない。
clone元には無い修正を加えてしまうとfast-forwardできない。
- 175 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 01:34:49.46 .net]
- こんな感じ？
ideone.com/hvgkDV
- 176 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 01:43:15.60 .net]
- 全然違う
- 177 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 01:57:26.57 .net]
- 以下のようにコミットの履歴が番号順に育っていて、AブランチのHEADが4で、BブランチのHEADが6だとする。
1─2─3─4─5─6
その状態では、BブランチをAブランチへマージするにはAブランチのHEADを6に変更するだけで済む。
その状態をfast-forwardマージ可能な状態と呼び、
そのHEADを変更するだけのマージを、fast-forwardマージと呼ぶ。
fast-forwardマージ可能で無い状態では、「マージコミットを作成することによるマージ」しかできない。
fast-forwardマージ可能な状態では、「fast-forwardマージ」と「マージコミットを作成することによるマージ」
のどちらかを任意に選択可能。
- 178 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 02:04:08.14 .net]
- リスト構造の概念が分かってればgitも似たようなもんだから理解は難しくないと思われ
- 179 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 02:11:48.62 .net]
- 全然違うよ
- 180 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 02:12:10.74 .net]
- >>174,177
なにがだ。
- 181 名前：デフォルトの名無しさん mailto:sage [2014/02/03(月) 04:47:05.44 .net]
- ┌I─J─K─L─M ← ノーマルエンド
┬A┴B─C─D─E─┬──F ← ハッピーエンド
│ └G─H ← 真のエンディング
└N┬O─P ← 鬱エンド
└Q─R─S─T─U ← バッドエンド
左から初めて右へと進む。左へは戻れない。
現在Aにいるのであれば、ノーマルエンドやハッピーエンド、真のエンディングに辿れる＝fast-forward
しかしNに入り込んでしまったら、鬱エンドかバットエンドにしかならない＝fast-forwardできない。
AルートにきてもIルートに来てしまったらノーマルエンドになる。
IからJ,K,L,Mまではメッセージスキップ（fast-forward）で進めるが、
ハッピーエンド、真のエンディングにはfast-forwardで進めない。
Oまで来てしまったら鬱エンドは回避不可能。
|
 |
