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/
0039デフォルトの名無しさん
2015/03/25(水) 15:17:55.54ID:7WluZNwFその開発ブランチからさらにブランチを作って、
そこにこまかくコミットしたものをリベースして開発ブランチにマージする
実装する機能単位でそれを繰り返す
0040デフォルトの名無しさん
2015/03/25(水) 15:38:52.70ID:8K+/BW9F0041デフォルトの名無しさん
2015/03/25(水) 19:19:14.80ID:5Dq5kMph0042デフォルトの名無しさん
2015/03/25(水) 19:31:03.19ID:7vrJVraD> ※1つのプルリクエストに複数の目的の修正が入っているなら、そのプルリクエストが間違ってる
一つのプルリクエストは、一つの機能だよ。
その機能は複数のコミットからなっている。
誰かが新しい機能のプルリクエストを出す所を考えて見ればわかるはず。
新しい機能を、プラグインみたいに簡単に追加できる場合ならいいが、
一般的には既存のコードを拡張可能なように修正して、
そこに機能追加を行う。
0043デフォルトの名無しさん
2015/03/25(水) 19:33:42.33ID:7vrJVraD> 途中のコミットがあろうがなかろうがレビューは困難にも容易にもならないよね？(´･ω･｀)
なるよ。
いきなり複数のファイルにまたがる1000行の修正を送られたって
何をしたいのかわからない。
一つ一つ説明が必要。それが一つのコミットになる。
0044デフォルトの名無しさん
2015/03/25(水) 20:00:32.67ID:1QZDV4EM（33で言ってた内容）
＞途中のコミットの話が抜けてる。同じ内容になるからという理由だけなら
＞途中のコミットが汚なくてもいい（レビューが困難）でもいいって話になってしまう。
＞rebaseの目的はレビューを容易にすること。
（43で言ってた内容）
＞いきなり複数のファイルにまたがる1000行の修正を送られたって
＞何をしたいのかわからない。
プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
コミットをまとめないべき、にすりかわっている。
あなたの意見どころかあなた自身が、反論に耐えうるものじゃないんじゃなかろうか
0045デフォルトの名無しさん
2015/03/25(水) 20:07:29.90ID:7vrJVraDReplace highlight.js with rouge-fork rugments
https://github.com/gitlabhq/gitlabhq/pull/8425/commits
どうやらこれは、highlight.js を rouge-fork rugments に入れ替える
プルリクエストのようだ。
これは一つのプロリクエストに三つのコミットが入っている。
1. テストの修正
2. ライブラリ入れ替え
3. 2以外の関連ライブラリバージョンアップ
これは一つのコミットにまとめてはいけない。なぜなら入れ替えを行った結果
既存のコードが動かなくなるかもしれないからだ。
最初にテストの修正を行っているのは、ライブラリの入れ替えの前と後の両方で同じテストが通るようにするためだろう。
入れ替え前に問題となるテストを修正し（もちろん入れ替え前にテストは通る）
入れ替えた後でもテストが通れば壊れていないことが確認できる。
そして1, 2, 3のそれぞれがわかれているから何を行ったのかレビューしやすい。
テストの修正とライブラリの入れ替えと関連ライブラリのバージョンアップが
一つのコミットになっていれば、いきなり複数の変更をこんなに変えて大丈夫か？ってなるだろう？
また逆に、この3つのコミットを分離して、一個ずつマージするという案もあるが、
それだと1のテストの修正は2の為にやるのだが、いきなり1.テストの修正という理由がわからない
プルリクエストが届くことになる。なぜ1が必要な理由が不明だし、もしかしたら2を直せば
1は不要になるかもしれない。
だからこの三つのコミットは独立していたら駄目だし、一つのコミットにしてもいけない。
それぞれのコミットがレビューしやすいように、無駄なコミットもない。
0046デフォルトの名無しさん
2015/03/25(水) 20:16:05.54ID:7vrJVraD> プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
> コミットをまとめないべき、にすりかわっている。
「綺麗に」まとめるということ。
汚いものをまとめろと言っただけで、
一つにまとめろとは言ってないない。
一つにまとめる・・・これはだめ。
まったくまとめない・・・これもだめ。
一つのプルリクエストは、1つ以上のコミットから成り立ち、
それぞれのコミットがレビューしやすいように
意味のある単位にまとめる。
0047デフォルトの名無しさん
2015/03/25(水) 20:17:13.12ID:1QZDV4EMあなた自体が説明に耐えうるものじゃないな・・・
自分の主張や情報を後出し後出しにして、ハイ反論どうぞ、なんて言われてもねぇ
そんなんじゃ、周りの人とまともな議論ができないだろう・・・
自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか？
まぁおそらくは、反論してくるだろうと思うが
0048デフォルトの名無しさん
2015/03/25(水) 20:20:44.43ID:7vrJVraD一つにまとめる・・・何も考えずに何でもかんでも一つにまとめるのはだめ。綺麗にまとめた結果一個になる場合は良い。
まったくまとめない・・・だめ。ただし最初からきれいな単位にまとまっているのであればそれで良い。
重要なのは一つのプルリクエストをレビューがしやすいように、
「意味がある単位で1個以上のコミットで綺麗にまとめる」ということ。
0049デフォルトの名無しさん
2015/03/25(水) 20:23:04.00ID:7vrJVraD反論も何も、お前は、
俺のことを「チームで開発作業をしたことはあまりない」と感じましたって
個人の感想を言ってるだけじゃんか。
えとさ、俺の言っている内容に対してレスしてくれない？
俺の言っている内容にコメントできないからって
「お前は○○だ。ばーか、ばーか。なにか言い返してみろよ」
と同等のレスをされて困るんだがね。
下らないレスはいらないから内容に対してコメントしろ。
お前が>>47で何か内容に対してコメントしたか？
0050デフォルトの名無しさん
2015/03/25(水) 20:32:17.06ID:7vrJVraD自分が「コミットをまとめる」って言ったと思って
レスしていたが、自分のレス読み返してみたが
「綺麗にする」とは書いてあるが
「まとめる」とは書いてないじゃないか？
おかしいな？
もしかして>>44のレスって単なる言いがかりか？
0051デフォルトの名無しさん
2015/03/25(水) 20:49:15.42ID:7vrJVraD>>32の用な無名な人が書いた駄文じゃなくて有名な人の意見
http://blog.marc-andre.ca/2014/02/05/why-i-wont-squash-my-commits/
http://qiita.com/gogotanaka/items/8c55f69120965b077737 (↑の翻訳)
> RubyのコミッターでもありRailsなどの多くのOSSで活躍されている
> Marc-Andre Lafortune さんのブログに面白い記事があったので筆を取りました.
> 各プロジェクトのコミッターらの素晴らしい仕事に対して失礼ながら、
> 私はコミットをまとめたいとは思わない. だから私にまとめろ言わないで欲しい.
> 例えば5つのコミットからなるpull requestがあったとして、もし私が何もミスをしてなければ、
> この5つのコミットはそれぞれ独立しているはずで、それらをわざわざまとめるべきでないと思っている.
※↑これはゴミコミットを残せって言ってるんじゃないよ。↓ ほらゴミコミットはキレにするべきと言ってる。
> 例えばこんな感じ
>
> ・素晴らしいfeatureを思いつき、手をつける
> ・しまったtypoしてた直さないと
> ・しまったバグを直さないと
> ・featureを仕上げる
>
> この様なcontributor達がもし、そのままのcommitをpull-requestに出して、
> それが受け入れられない（つまりマージされない）という事は当然の報いだとは思うが、
> 良い例がここ(https://github.com/sdsykes/fastimage/pull/27)にある.
> これは一つのbugを修正するためのpull-requestだが私は15つのコミットに分けた.
> それぞのリファクタ１つ１つはしかるべく順序で並んでおり、最後の１つだけがbugの修正それ自体なのだ.
なんだｗ 俺が探してこなくても、ここに書いてあったじゃないかｗ
0052デフォルトの名無しさん
2015/03/25(水) 20:58:15.28ID:2zE2JJLlそういう人は相手にせずスルーすべし
0053デフォルトの名無しさん
2015/03/25(水) 21:18:09.55ID:1QZDV4EM>>48に書いたことを、>>33のときに書いていれば反論を招かずに済んだ話だと思う
自分が言いたいのは、まさにこの一点
このスレをgitに例えれば、あなたは>>33におけるタイプミスの修正を>>51まで延々と
続けているということだ
0054デフォルトの名無しさん
2015/03/25(水) 21:21:46.19ID:7vrJVraDお前が読み間違っただけだろう？
それに俺がお前に言いたいのは
内容に対してレスしろってことだ。
お前の人間として品性がないって話をしている。
お前の反論がないんだから、俺の意見は正しくて
残るはお前の品性の問題しかないからな。
0055デフォルトの名無しさん
2015/03/25(水) 21:23:46.76ID:7vrJVraD俺は、コミットを綺麗にしろ言っただけで、
一つにまとめろとか言ってないからな。
そもそもまとめるという単語すら
>>33には書いてない。
勘違いしたのは、 ID:1QZDV4EM
0056デフォルトの名無しさん
2015/03/25(水) 21:25:18.08ID:0It7vtDM0057デフォルトの名無しさん
2015/03/25(水) 21:32:07.66ID:1QZDV4EM＞お前の人間として品性がないって話をしている。
違うだろう、今度はいつの間に「反論があるかないか」の話からすりかわったんだ
まぁでもお前がgitのスレでやりたいのは、反論があるかないかじゃなく、人を馬鹿にする方なんだろうが・・・
0058デフォルトの名無しさん
2015/03/25(水) 21:40:49.98ID:7vrJVraD人を馬鹿にしたのはお前だろう？
お前が読み間違っただけなのに、反論が〜とか言った挙句
> 自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
> 「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか？
> まぁおそらくは、反論してくるだろうと思うが
こんな事言ったよな？
お前が何を考えてこんなレスをしたかあててやろうか？
1. 反論しない（俺が言い返さない）・・・やっぱりチーム開発したことないやつだったな。俺が言ったことは正しかった（優越感）
2. 反論する・・・俺が予想したとおり反論してきたか。俺が言ったことは正しかった（優越感）
どうだ？ あってるだろ？ どちらにしろ優越感を感じられれるなｗ （まあそれをばらしたから優越感を味わえないだろうがｗ）
そもそも、俺がどういうやつかなんて「お前の母ちゃん出ベソ」と同じで
証明しようがない問題だ。俺がなんと言おうが、お前が信じなければそれまでだからな。
それぐらいお前もわかっててやっただろ？
単にお前が優越感を得るためだけの意味が無いレス。
だからこんな下らないレスだと言った。
こういうレスを見たから俺は、お前は品性のないやつだと確定できて、
最後の挽回のチャンスとして、反論しろといったわけだが結局反論できなかったな。
はははｗ お前が>>57でレスしてくれたから、俺にこういう説明をするチャンスになったよ。ありがとなｗ
0059デフォルトの名無しさん
2015/03/25(水) 21:46:25.46ID:1QZDV4EMけっきょく、このスレで言った言わないの議論をするお前じゃなくて、今技術者をやってるお前ってどうなの？
なぜ軽くスルーできなかったのか？やっぱ、そこに問題があるから怒ったのか？そうだったら謝りたいが
0060デフォルトの名無しさん
2015/03/25(水) 21:49:20.02ID:7vrJVraDほらなｗ やっぱり品性がない。
人を馬鹿にする方向にしかレスが出来ない。
お前無意識にやってるだろ？
無意識で品性がないｗ
最初にそんなことやらずに、内容に対してレスする方向に
変えていれば、今頃は挽回できたかもしれないのにな。
哀れ。
0061デフォルトの名無しさん
2015/03/25(水) 21:53:44.04ID:1QZDV4EM第三者的には、>>58の時点でバカ2名のやり取りにしか見えないと思うぞ
0062デフォルトの名無しさん
2015/03/25(水) 22:21:34.29ID:2zE2JJLl五十歩百歩かもしれんが
百の方が五十の方を道連れにしようとすんなｗ
0063デフォルトの名無しさん
2015/03/25(水) 22:23:48.78ID:1QZDV4EMそうかもね、すまない
0064デフォルトの名無しさん
2015/03/25(水) 23:32:40.35ID:7vrJVraD勘違い君、かわいい（哀れ）
0065デフォルトの名無しさん
2015/03/26(木) 06:42:05.21ID:zxUHxD8M> 百の方は俺のことだろｗ
勘違い君、かわいい（哀れ）
0066デフォルトの名無しさん
2015/03/26(木) 07:47:28.35ID:IO0z/ZIB0067デフォルトの名無しさん
2015/03/26(木) 11:04:14.40ID:RWcMqhbhdiff.mnemonicprefix ってなんのオプションかわかる？
これをつけるとつけないとで何が変わるの？
0068デフォルトの名無しさん
2015/03/26(木) 11:45:31.23ID:7Tklw0eChttp://stackoverflow.com/questions/28017249/what-does-diff-mnemonicprefix-do
0069デフォルトの名無しさん
2015/03/26(木) 12:01:03.18ID:Z4IoHfg80070デフォルトの名無しさん
2015/03/26(木) 12:18:51.15ID:RWcMqhbhありがとう
diffしたときのファイル名になぜかついてた a/ とか b/ とかを
出さないようにするオプションなのね
0071デフォルトの名無しさん
2015/03/26(木) 20:54:55.68ID:bNJI23fgちょっと違うで
a/ とか b/ とかのプレフィックスを出さないようにするのは diff.noprefix
diff.mnemonicprefix は意味のあるプレフィックスを出力する
意味のある、というのは、どことどこの diff なのか、つまりインデックスなら i/、ワークツリーなら w/、という具合に出力する
0072デフォルトの名無しさん
2015/03/27(金) 15:17:35.69ID:NmkvbaYsありがとう。じゃあnoprefixの方使うようにするよ。
ところで、すでに運用してるgitをWEBから管理したくて
でもgitwebが使いづらいので乗り換えたいんだけど
gitlabをインストールしてみたいんだけど
これってそういう風には使えるものなのかな
0073デフォルトの名無しさん
2015/03/27(金) 17:14:19.11ID:wC2EsVxWgitlabはdbも使ってるし移行作業は必要になると思うよ
0074デフォルトの名無しさん
2015/03/27(金) 18:38:26.72ID:HpSv3zdu素直にインポートしたら。たいした手間でなし。
0075デフォルトの名無しさん
2015/03/27(金) 19:45:18.53ID:+T9VOHOm認証、通信の暗号化の可否はそれぞれどうですか？
0076デフォルトの名無しさん
2015/03/27(金) 21:37:55.61ID:9ALWzfda当たり前だけど、gitのリポジトリをpushするだけ。
gitlabのgit以外の機能（IssueとかMergeRequestとか）に、
データベースを使っているが、gitwebにはgit以外の機能ってほぼないだろ？
0077デフォルトの名無しさん
2015/03/27(金) 23:36:40.51ID:+T9VOHOmで、GitBucket上で、移行したコミットのコミット者を見ようとすると、
ユーザ名ではなくメールアドレスでユーザーの識別をしているように見えます
この識別方法はGitBucket固有ですか？
また、リモートリポジトリにpushした後の各コミットについて、
コミット者のメールアドレスを変更することは可能ですか？
0078デフォルトの名無しさん
2015/03/27(金) 23:54:27.14ID:Z8DJNpSP0079デフォルトの名無しさん
2015/03/28(土) 14:15:10.16ID:w2Z+yJkJhttps://github.com/git/git/releases/tag/v5.6.24
0080デフォルトの名無しさん
2015/03/28(土) 18:47:44.36ID:+R+DyebJこんなん初めて知った
diff結果のパスを引数に合わせて変える模様
$ git diff
i/foo.txt # indexの'i'
w/foo.txt # worktreeの'w'
008180
2015/03/28(土) 18:49:53.09ID:+R+DyebJ0082デフォルトの名無しさん
2015/03/29(日) 18:08:14.32ID:E72jh6+u0083デフォルトの名無しさん
2015/03/29(日) 19:10:29.25ID:GIfRQ9M60084デフォルトの名無しさん
2015/03/29(日) 21:45:52.31ID:SsUrZhnW補完すごいよね
addすべき対象をtabで一発で当ててきたときはビビったよ
0085デフォルトの名無しさん
2015/03/29(日) 22:04:26.44ID:vkiGWuNthttps://github.com/git/git/search?l=c&;q=add&utf8=✓
0086デフォルトの名無しさん
2015/03/30(月) 08:52:02.76ID:ebxMPih7そんなもの使ってない
0087デフォルトの名無しさん
2015/03/30(月) 10:57:03.31ID:QTBkdmd4そんなのディストリビューション次第じゃないの。
0088デフォルトの名無しさん
2015/03/30(月) 11:53:27.54ID:eSl2sveJなぜbashだけが優遇されるのか？
今使われてるのはzshだろ。
0089デフォルトの名無しさん
2015/03/30(月) 12:10:49.96ID:pDn2M2s4zsh なら、oh-my-zsh に git プラグインあるだろ。
0090デフォルトの名無しさん
2015/03/30(月) 13:24:21.18ID:pQkawj3/あー、普通にgitについてたよｗ
0091デフォルトの名無しさん
2015/03/30(月) 21:52:59.70ID:7jnhpj+r今zsh使ってる人って残ってるの？
みんなbashに戻ったとばかり思ってた
0092デフォルトの名無しさん
2015/03/31(火) 04:25:40.16ID:DVVpWgeR0093デフォルトの名無しさん
2015/03/31(火) 10:24:36.59ID:byVPP9+b使い方が分かる人しかいませんか？
便利なGitクライアントソフトとか、各種Gitサーバソフトの
使い方とか、そういうのを質問したかったらどこがオススメ
でしょうか？
0094デフォルトの名無しさん
2015/03/31(火) 10:48:52.86ID:jsR2iUWdここでいいと思うけど。もしかして >>77 かな？
GitBucketは使ったことないけど、
・gitは各コミットのauthorとcomitterそれぞれのnameとemailを記録してる。
・gitはユーザーを管理してない。ってか、分散システムだから管理しようがない。
・authorやcomitterの変更はできるけど、コミットID(ハッシュ値)も変わるので、変更というよりは履歴の書き換えになる。
0095デフォルトの名無しさん
2015/03/31(火) 12:02:22.73ID:DMT7op/Iそれgitに限定する意味あるの?
0096デフォルトの名無しさん
2015/03/31(火) 21:52:09.98ID:N1jW3NRegithub固有の話は専用スレがある
他はここでいいんじゃない？
0097デフォルトの名無しさん
2015/04/03(金) 00:52:20.92ID:bxWPklRz0098デフォルトの名無しさん
2015/04/03(金) 09:00:43.05ID:fygFc6bt税法的にもアウトですよ。コレ。
0099デフォルトの名無しさん
2015/04/03(金) 09:06:27.04ID:TGMPBffS0100デフォルトの名無しさん
2015/04/03(金) 11:50:44.23ID:uPiWXVNBこれでコンフリクトが出た場合はコミットされないのでgit merge --abortで元に戻せますよね
じゃあgit merge --no-commitってなんの意味があるんですか？
0101デフォルトの名無しさん
2015/04/03(金) 12:16:47.24ID:/qzMUQum0102１００
2015/04/03(金) 13:02:08.91ID:/gPIw7xIそうなると問題なくマージできる場合はコミットして当然だと思いますがおかしいですかね
0103１００
2015/04/03(金) 13:03:07.82ID:/gPIw7xI0104デフォルトの名無しさん
2015/04/03(金) 13:49:11.28ID:/qzMUQumコミットする余裕があってもいいんじゃね
0105デフォルトの名無しさん
2015/04/03(金) 20:25:53.13ID:pcIMeknY0106デフォルトの名無しさん
2015/04/03(金) 23:06:07.33ID:TGMPBffS理想としては全てのコミットは
テストに通れなければならない。
それはマージでも同じ話で、マージ前
マージ後、どちらもテストに通らなければならない。
起きる可能性は低いけれど、起こりえるのが
問題なくマージできたがテストには失敗するいうもの。
この時
1. (マージ前) テスト実行して問題ないことを確認。
2. (マージ後) テスト実行して問題発覚
3. git reset --hard HEAD^ でマージ前に戻す。
(rebaseだとマージに含まれる複数のコミットが分解されてしまうのでまずい）
4. git merge --no-commitでコミットせずにマージ
5. テスト実行して問題ないことを確認してからコミット
という流れで使うのではないだろうか？
0107デフォルトの名無しさん
2015/04/04(土) 00:01:59.62ID:qXtcXItO0108デフォルトの名無しさん
2015/04/04(土) 00:02:51.56ID:o7ivvLL/0109デフォルトの名無しさん
2015/04/04(土) 15:34:05.03ID:4aWMIGVn0110デフォルトの名無しさん
2015/04/05(日) 13:00:59.30ID:AGMqJGUT>> 106 が正しい。そういうマージコミットのことを evil マージという。
名前は悪そうだが、必要悪、といった感じだな。
0111デフォルトの名無しさん
2015/04/05(日) 14:07:33.73ID:Gn5PCEDnこのディレクトリは.gitignoreで除外されています
git pullをしたらdata/を汚さずに最新版にアップデートできるんですが
data/の中身を毎日zipでバックアップを取ってます
data/の中身をgithubとかdropboxにリポジトリ作るとか何でもいいのでgit pushで簡単にバックアップ取れるようにしたいんですが
どうしたらいいのか教えてください
0112デフォルトの名無しさん
2015/04/05(日) 14:40:52.20ID:OOK6R9Sygitはバックアップツールじゃない。
ソースコードのバージョン管理ツールだ。
gitというのは、ソースコードのバージョンに含まれる
機能を管理し、その機能を追加したり、削除したり
何が変わったか確認したり、バグを探したり
そういう事をするために使うツールだ。
コミット毎に内容に意味があって、そのコミットをうまく
活用できるためのツールがgitだ。
日付ごとのデータのバックアップなら別のツールを使いなさい。
0113111
2015/04/05(日) 15:39:11.36ID:Gn5PCEDn分かる方教えてください
0114デフォルトの名無しさん
2015/04/05(日) 15:49:35.25ID:KkKmAC5t0115デフォルトの名無しさん
2015/04/05(日) 17:38:56.13ID:lc+vonxV0116デフォルトの名無しさん
2015/04/05(日) 18:52:26.59ID:OOK6R9Sy間違いだよ。
素人は黙ってな。
0117デフォルトの名無しさん
2015/04/05(日) 20:05:27.42ID:/p4ZvisL0118デフォルトの名無しさん
2015/04/05(日) 22:45:55.43ID:vTKOQGSX老害をからかってちゃ後が面倒だぜ
0119デフォルトの名無しさん
2015/04/05(日) 23:02:46.40ID:JNGfMGjI0120デフォルトの名無しさん
2015/04/06(月) 07:57:53.43ID:/B7mQxeO不具合修正は別 commit にするし。
0121デフォルトの名無しさん
2015/04/06(月) 19:47:22.89ID:opDSS45mブランチAでリモートにpushしてプルリク
ブランチAの作業が残っている状態でブランチB作成
ブランチBで作業
ブランチAで追加コミットを修正してsquashしてリモートにpush -f
ブランチA
2015/4/6 19:00 9deflrm23dfggcfa6emlvfcg4a27ac8aca50fgf5475cg ← pick
2015/4/6 20:00 85jvoutvg9f003afgj54vklgkptkh585jvouft9ufjocjoxf ← squash
この状態でブランチBにしたら、squashしたはずのコミットがログに残っているんです・・・・。
どうしてなんでしょうか？
また、解決策としては、ブランチBでも同じようにsquashするしかないのでしょうか？
0122デフォルトの名無しさん
2015/04/06(月) 20:05:46.15ID:qFLwaw7j>どうしてなんでしょうか？
squashしたからブランチAとブランチBは異なる歴史になった
0123デフォルトの名無しさん
2015/04/06(月) 20:31:20.34ID:opDSS45m0124デフォルトの名無しさん
2015/04/07(火) 02:46:12.38ID:CzyUtHJJブランチBをrebaseすればいいんじゃねーの？
0125デフォルトの名無しさん
2015/04/07(火) 08:01:35.49ID:had6wKpc0126デフォルトの名無しさん
2015/04/07(火) 13:53:47.58ID:1qTlkWNC--ontoありのリベースで、リベースされるコミット群の先頭とリベースの基点のそれぞれを別個に指定する必要がある
0127デフォルトの名無しさん
2015/04/07(火) 13:54:59.96ID:xmsupUvw0128デフォルトの名無しさん
2015/04/07(火) 15:02:13.44ID:biFZC1fKひとりでやってても禁止するべきだ
0129デフォルトの名無しさん
2015/04/07(火) 15:20:32.75ID:1qTlkWNCgitは基本的な仕組みがシンプルだからコミットやブランチがどうやって管理されているかとか理解しやすい
逆にシンプルな故に、その仕組みを理解せずに使い方を覚えようとするととても難しく感じる
0130デフォルトの名無しさん
2015/04/07(火) 15:39:49.42ID:xmsupUvwそうそう、pull ―rebase は内部的に rebase ―onto をやってくれるんだよ
push -f はパスワードとか入れてはいけないものを入れてしまった時とか
リベースし続けているものを意図的に公開したいとか、そういう用途向けかな
共有リポジトリで push -f すると全員に pull ―rebase をお願いしたり、
クローン済みリポジトリを全部チェックする羽目になるのでなかなか大変
0131デフォルトの名無しさん
2015/04/07(火) 16:04:18.37ID:biFZC1fK0132デフォルトの名無しさん
2015/04/07(火) 19:08:37.15ID:had6wKpcありがとうございます。
勉強になりました
0133デフォルトの名無しさん
2015/04/07(火) 21:29:48.07ID:CzyUtHJJ> push -fはやるべきじゃない
> ひとりでやってても禁止するべきだ
またお前かｗ
問題ないって結論出ただろ。
過去レス嫁。
0134デフォルトの名無しさん
2015/04/08(水) 12:17:07.98ID:mhUDdxzX自分のところにもサーバにもコミットの履歴が残ってるんですよね？
サーバ側はともかく、自分のところにはコミットの履歴をあまり残したくないので
過去1か月分ほどを残してあとは削除したいんですが
どうしたらよいですか？
0135デフォルトの名無しさん
2015/04/08(水) 15:36:13.30ID:uhPXCuzkGitでは最新のコミットは過去のすべてのコミットの情報が存在しなければ意味を持たない構造になっている
0136デフォルトの名無しさん
2015/04/08(水) 16:20:42.00ID:mhUDdxzXマジか
bitcoinもびっくりの冗長性ですな
適当なタイミングで新規プロジェクトにするしかないのかな
0137デフォルトの名無しさん
2015/04/08(水) 16:25:51.16ID:uhPXCuzk新規プロジェクトにしなくてもリベースを使えば過去の歴史をまとめてしまうことができるよ
でもリベースしたら最新のファイルの状態が一緒でもコミットとしては別物だからね
0138デフォルトの名無しさん
2015/04/08(水) 16:41:12.55ID:xOKsYf2d■ このスレッドは過去ログ倉庫に格納されています