トップページtech
983コメント406KB

Git 12©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net2015/03/23(月) 13:35:13.83ID:aBYp+bVs
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - 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/
0022デフォルトの名無しさん2015/03/24(火) 17:17:23.80ID:LMCtJA+5
>>21
お前が自分が知ってる形態を説明しないから、理解できないんだよ。
0023デフォルトの名無しさん2015/03/24(火) 19:47:13.61ID:NaTfFmmD
>>20
それはgit的には間違った解釈じゃないかな?(´・ω・`)
グループマスタはグループ全員から見えてもいいと思うけどプロジェクトマスタの
更新権も全グループの全要員にないとダメという訳じゃないよね?(´・ω・`)
グループリーダーだけがグループマスタをプロジェクトマスタに更新できる方が
組織的な運用としてはやりやすいと思うよ?(´・ω・`)
0024デフォルトの名無しさん2015/03/24(火) 19:55:25.10ID:AMK4q4iG
これがゆとりか
0025デフォルトの名無しさん2015/03/24(火) 20:29:10.23ID:LMCtJA+5
>>23
リモートリポジトリがどこにあるべきかって話に
ブランチ戦略の話が混じってしまっている気がして、何とも答えにくい
0026デフォルトの名無しさん2015/03/24(火) 20:33:49.43ID:NaTfFmmD
リポジトリはアクセスする必要がある人から参照できる所にあれば
いいんじゃないかな?(´・ω・`)
0027デフォルトの名無しさん2015/03/24(火) 20:48:23.99ID:sz/ymt1l
gitlab(githubでも可)使えばいいのに。

一台gitlabサーバーを立てれば、

1. プロジェクトのリモートリポジトリ
2. そのプロジェクトをforkした個人のリモートリポジトリ
3. ローカルリポジトリ

って自然に三つのリポジトリをシンプルに使うことが出来るよ。

開発は、
3. ローカルリポジトリを修正
2. 個人のリモートリポジトリにpush
1. そこからプロジェクトのリモートリポジトリにマージ(ウェブから実行できる)

という流れが出来上がる。
0028デフォルトの名無しさん2015/03/24(火) 20:55:16.60ID:LMCtJA+5
>>26
自分も同意見だ

ただ、>>15>>16の時点で、リモートリポジトリの話かmasterブランチの話か既に分かりにくくなってるんだな
20の「master」は、「リモートリポジトリ」のつもりで話していた
0029デフォルトの名無しさん2015/03/24(火) 21:05:35.91ID:LMCtJA+5
>>27
ソースコードが社外に置かれるgithubがお堅い企業で使われてるかは微妙だけど、
gitlabは商用でサポート受けれるし、githubを抜くとおそらく1番手で使われてるんじゃないか?
0030デフォルトの名無しさん2015/03/24(火) 23:26:42.53ID:CRqFXs0T
git init
touch a; git add a; git commit "initial commit"

git checkout -b test
touch b; git add b; git commit "b"
touch c; git add c; git commit "c"
git checkout master
git merge dev --squah

git checkout test
touch d; git add d; git commit "d"
touch e; git add e; git commit "e"
git checkout master
git merge dev --squah
これでこういうメッセージが出ます。どうしてマージできないんですか?
>Squash commit -- not updating HEAD
>Automatic merge went well; stopped before committing as requested
0031デフォルトの名無しさん2015/03/24(火) 23:27:52.62ID:CRqFXs0T
ここに入力する時にcommit の部分に-mを書き漏れたので-mがあるものとしてお読みください
0032デフォルトの名無しさん2015/03/25(水) 10:38:07.54ID:DffMWI2J
rebaseはコミットグラフを綺麗にするためじゃなくてffマージをするためにあるのであった
https://gist.github.com/katzchang/4126092
0033デフォルトの名無しさん2015/03/25(水) 12:53:22.29ID:7vrJVraD
>>32
それ書いたやつここに連れてくるか、
お前が代わりに反論してくれ。

まずrebaseはコミット履歴を綺麗にするためであって
コミット"グラフ"を綺麗にするものじゃない。
この時点でそれ書いたやつは勘違いしている。

そしてffマージ推奨みたいな感じだが、
"master"へのマージは--no-ffでやるのが常識
gitlabのウェブ管理画面からは--no-ffしか行えない。
(もちろんmasterじゃないところならffマージでも良い)

さらに言えば「開発中のブランチ」と「そのブランチがffマージされた未来のmaster」が
同じ内容になるからテストが安心できるというのはまあいいんだが、
途中のコミットの話が抜けてる。同じ内容になるからという理由だけなら
途中のコミットが汚なくてもいい(レビューが困難)でもいいって話になってしまう。
rebaseの目的はレビューを容易にすること。テストが安心っていうのはおまけでしかない。
0034デフォルトの名無しさん2015/03/25(水) 12:58:04.22ID:IRTth2yB
途中のコミットがあろうがなかろうがレビューは困難にも容易にもならないよね?(´・ω・`)
0035デフォルトの名無しさん2015/03/25(水) 13:40:29.78ID:1QZDV4EM
>>33
レビューっていうのは、プルリクエストが出された「ひとまとまりのコミット」に対して行われるものだ
その時にレビュアーは、その「ひとまとまりのコミット」が何のための修正かを把握しているはずである
※1つのプルリクエストに複数の目的の修正が入っているなら、そのプルリクエストが間違ってる

レビュアーが、その「ひとまとまりのコミット」が何のためなのかを分かっていれば、各コミットが
どれだけ細分化されていようと、(レビュアーは「ひとまとまりのコミット」で最終的にどうなったかだけを
チェックし、各コミットで何をしたかまでは追いかけない、という理由で)コードが合っているかの
チェックを阻害したりはしない

これで反論になってるだろうか
0036デフォルトの名無しさん2015/03/25(水) 13:43:12.20ID:jY89TDAe
rebaseで使うのは
reword
fixup
squash
pick

editとexecは必要ないと思ってるんですがあなたたちは使いますか?
0037デフォルトの名無しさん2015/03/25(水) 14:47:57.92ID:7WluZNwF
rebaseをしてから--no-ffマージしたりするからなw
0038デフォルトの名無しさん2015/03/25(水) 15:04:11.83ID:8K+/BW9F
開発ブランチも公開しちゃってるからリベースできないお
0039デフォルトの名無しさん2015/03/25(水) 15:17:55.54ID:7WluZNwF
>>38
その開発ブランチからさらにブランチを作って、
そこにこまかくコミットしたものをリベースして開発ブランチにマージする
実装する機能単位でそれを繰り返す
0040デフォルトの名無しさん2015/03/25(水) 15:38:52.70ID:8K+/BW9F
一度公開したブランチをどんな形にせよリベースするなんてやっちゃあいけませんよ旦那
0041デフォルトの名無しさん2015/03/25(水) 19:19:14.80ID:5Dq5kMph
こらからの話だよ
0042デフォルトの名無しさん2015/03/25(水) 19:31:03.19ID:7vrJVraD
>>35
> ※1つのプルリクエストに複数の目的の修正が入っているなら、そのプルリクエストが間違ってる

一つのプルリクエストは、一つの機能だよ。
その機能は複数のコミットからなっている。

誰かが新しい機能のプルリクエストを出す所を考えて見ればわかるはず。
新しい機能を、プラグインみたいに簡単に追加できる場合ならいいが、

一般的には既存のコードを拡張可能なように修正して、
そこに機能追加を行う。
0043デフォルトの名無しさん2015/03/25(水) 19:33:42.33ID:7vrJVraD
>>34
> 途中のコミットがあろうがなかろうがレビューは困難にも容易にもならないよね?(´・ω・`)

なるよ。

いきなり複数のファイルにまたがる1000行の修正を送られたって
何をしたいのかわからない。

一つ一つ説明が必要。それが一つのコミットになる。
0044デフォルトの名無しさん2015/03/25(水) 20:00:32.67ID:1QZDV4EM
>>43
(33で言ってた内容)
>途中のコミットの話が抜けてる。同じ内容になるからという理由だけなら
>途中のコミットが汚なくてもいい(レビューが困難)でもいいって話になってしまう。
>rebaseの目的はレビューを容易にすること。

(43で言ってた内容)
>いきなり複数のファイルにまたがる1000行の修正を送られたって
>何をしたいのかわからない。

プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
コミットをまとめないべき、にすりかわっている。

あなたの意見どころかあなた自身が、反論に耐えうるものじゃないんじゃなかろうか
0045デフォルトの名無しさん2015/03/25(水) 20:07:29.90ID:7vrJVraD
説明しやすいサンプル見つけてきたぞ。

Replace 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
>>44
> プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
> コミットをまとめないべき、にすりかわっている。

「綺麗に」まとめるということ。
汚いものをまとめろと言っただけで、
一つにまとめろとは言ってないない。

一つにまとめる・・・これはだめ。
まったくまとめない・・・これもだめ。

一つのプルリクエストは、1つ以上のコミットから成り立ち、
それぞれのコミットがレビューしやすいように
意味のある単位にまとめる。
0047デフォルトの名無しさん2015/03/25(水) 20:17:13.12ID:1QZDV4EM
>>45
あなた自体が説明に耐えうるものじゃないな・・・
自分の主張や情報を後出し後出しにして、ハイ反論どうぞ、なんて言われてもねぇ
そんなんじゃ、周りの人とまともな議論ができないだろう・・・

自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか?
まぁおそらくは、反論してくるだろうと思うが
0048デフォルトの名無しさん2015/03/25(水) 20:20:44.43ID:7vrJVraD
正確じゃなかったから訂正

一つにまとめる・・・何も考えずに何でもかんでも一つにまとめるのはだめ。綺麗にまとめた結果一個になる場合は良い。
まったくまとめない・・・だめ。ただし最初からきれいな単位にまとまっているのであればそれで良い。

重要なのは一つのプルリクエストをレビューがしやすいように、
「意味がある単位で1個以上のコミットで綺麗にまとめる」ということ。
0049デフォルトの名無しさん2015/03/25(水) 20:23:04.00ID:7vrJVraD
>>47

反論も何も、お前は、
俺のことを「チームで開発作業をしたことはあまりない」と感じましたって
個人の感想を言ってるだけじゃんか。

えとさ、俺の言っている内容に対してレスしてくれない?
俺の言っている内容にコメントできないからって

「お前は○○だ。ばーか、ばーか。なにか言い返してみろよ」
と同等のレスをされて困るんだがね。

下らないレスはいらないから内容に対してコメントしろ。
お前が>>47で何か内容に対してコメントしたか?
0050デフォルトの名無しさん2015/03/25(水) 20:32:17.06ID:7vrJVraD
>>44

自分が「コミットをまとめる」って言ったと思って
レスしていたが、自分のレス読み返してみたが
「綺麗にする」とは書いてあるが
「まとめる」とは書いてないじゃないか?

おかしいな?
もしかして>>44のレスって単なる言いがかりか?
0051デフォルトの名無しさん2015/03/25(水) 20:49:15.42ID:7vrJVraD
今更だが俺なんかが言わなくても、有名な人の意見があったっけw
>>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つのコミットに分けた.
> それぞのリファクタ1つ1つはしかるべく順序で並んでおり、最後の1つだけがbugの修正それ自体なのだ.

なんだw 俺が探してこなくても、ここに書いてあったじゃないかw
0052デフォルトの名無しさん2015/03/25(水) 20:58:15.28ID:2zE2JJLl
数レスのつながりすら読めない人に長文で相手しても意味ないよ
そういう人は相手にせずスルーすべし
0053デフォルトの名無しさん2015/03/25(水) 21:18:09.55ID:1QZDV4EM
>>49
>>48に書いたことを、>>33のときに書いていれば反論を招かずに済んだ話だと思う
自分が言いたいのは、まさにこの一点

このスレをgitに例えれば、あなたは>>33におけるタイプミスの修正を>>51まで延々と
続けているということだ
0054デフォルトの名無しさん2015/03/25(水) 21:21:46.19ID:7vrJVraD
>>53
お前が読み間違っただけだろう?

それに俺がお前に言いたいのは
内容に対してレスしろってことだ。

お前の人間として品性がないって話をしている。

お前の反論がないんだから、俺の意見は正しくて
残るはお前の品性の問題しかないからな。
0055デフォルトの名無しさん2015/03/25(水) 21:23:46.76ID:7vrJVraD
しつこいようだが、勘違いしているようだからはっきり言っておくわ。

俺は、コミットを綺麗にしろ言っただけで、
一つにまとめろとか言ってないからな。

そもそもまとめるという単語すら
>>33には書いてない。

勘違いしたのは、 ID:1QZDV4EM
0056デフォルトの名無しさん2015/03/25(水) 21:25:18.08ID:0It7vtDM
ケンカをやめて
0057デフォルトの名無しさん2015/03/25(水) 21:32:07.66ID:1QZDV4EM
>>54
>お前の人間として品性がないって話をしている。

違うだろう、今度はいつの間に「反論があるかないか」の話からすりかわったんだ
まぁでもお前がgitのスレでやりたいのは、反論があるかないかじゃなく、人を馬鹿にする方なんだろうが・・・
0058デフォルトの名無しさん2015/03/25(水) 21:40:49.98ID:7vrJVraD
>>57
人を馬鹿にしたのはお前だろう?

お前が読み間違っただけなのに、反論が〜とか言った挙句

> 自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
> 「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか?
> まぁおそらくは、反論してくるだろうと思うが

こんな事言ったよな?

お前が何を考えてこんなレスをしたかあててやろうか?

1. 反論しない(俺が言い返さない)・・・やっぱりチーム開発したことないやつだったな。俺が言ったことは正しかった(優越感)
2. 反論する・・・俺が予想したとおり反論してきたか。俺が言ったことは正しかった(優越感)

どうだ? あってるだろ? どちらにしろ優越感を感じられれるなw (まあそれをばらしたから優越感を味わえないだろうがw)

そもそも、俺がどういうやつかなんて「お前の母ちゃん出ベソ」と同じで
証明しようがない問題だ。俺がなんと言おうが、お前が信じなければそれまでだからな。

それぐらいお前もわかっててやっただろ?
単にお前が優越感を得るためだけの意味が無いレス。
だからこんな下らないレスだと言った。

こういうレスを見たから俺は、お前は品性のないやつだと確定できて、
最後の挽回のチャンスとして、反論しろといったわけだが結局反論できなかったな。


はははw お前が>>57でレスしてくれたから、俺にこういう説明をするチャンスになったよ。ありがとなw 
0059デフォルトの名無しさん2015/03/25(水) 21:46:25.46ID:1QZDV4EM
自分には、どうして>>47の後半で言ったことがお前をそこまで刺激したのかが、よく分からないんだよ
けっきょく、このスレで言った言わないの議論をするお前じゃなくて、今技術者をやってるお前ってどうなの?
なぜ軽くスルーできなかったのか?やっぱ、そこに問題があるから怒ったのか?そうだったら謝りたいが
0060デフォルトの名無しさん2015/03/25(水) 21:49:20.02ID:7vrJVraD
>>59
ほらなw やっぱり品性がない。
人を馬鹿にする方向にしかレスが出来ない。

お前無意識にやってるだろ?
無意識で品性がないw

最初にそんなことやらずに、内容に対してレスする方向に
変えていれば、今頃は挽回できたかもしれないのにな。
哀れ。
0061デフォルトの名無しさん2015/03/25(水) 21:53:44.04ID:1QZDV4EM
>>60
第三者的には、>>58の時点でバカ2名のやり取りにしか見えないと思うぞ
0062デフォルトの名無しさん2015/03/25(水) 22:21:34.29ID:2zE2JJLl
ワロタ
五十歩百歩かもしれんが
百の方が五十の方を道連れにしようとすんなw
0063デフォルトの名無しさん2015/03/25(水) 22:23:48.78ID:1QZDV4EM
>>62
そうかもね、すまない
0064デフォルトの名無しさん2015/03/25(水) 23:32:40.35ID:7vrJVraD
長文書いたのは俺だし、百の方は俺のことだろw
勘違い君、かわいい(哀れ)
0065デフォルトの名無しさん2015/03/26(木) 06:42:05.21ID:zxUHxD8M
>>64
> 百の方は俺のことだろw
勘違い君、かわいい(哀れ)
0066デフォルトの名無しさん2015/03/26(木) 07:47:28.35ID:IO0z/ZIB
どんぐりの背比べ
0067デフォルトの名無しさん2015/03/26(木) 11:04:14.40ID:RWcMqhbh
ところで話の腰を折るようで悪いんだけど
diff.mnemonicprefix ってなんのオプションかわかる?
これをつけるとつけないとで何が変わるの?
0068デフォルトの名無しさん2015/03/26(木) 11:45:31.23ID:7Tklw0eC
>>67
http://stackoverflow.com/questions/28017249/what-does-diff-mnemonicprefix-do
0069デフォルトの名無しさん2015/03/26(木) 12:01:03.18ID:Z4IoHfg8
このスレには(哀れ)な人しかいないね
0070デフォルトの名無しさん2015/03/26(木) 12:18:51.15ID:RWcMqhbh
>>68
ありがとう
diffしたときのファイル名になぜかついてた a/ とか b/ とかを
出さないようにするオプションなのね
0071デフォルトの名無しさん2015/03/26(木) 20:54:55.68ID:bNJI23fg
>>70
ちょっと違うで
a/ とか b/ とかのプレフィックスを出さないようにするのは diff.noprefix
diff.mnemonicprefix は意味のあるプレフィックスを出力する
意味のある、というのは、どことどこの diff なのか、つまりインデックスなら i/、ワークツリーなら w/、という具合に出力する
0072デフォルトの名無しさん2015/03/27(金) 15:17:35.69ID:NmkvbaYs
>>71
ありがとう。じゃあnoprefixの方使うようにするよ。


ところで、すでに運用してるgitをWEBから管理したくて
でもgitwebが使いづらいので乗り換えたいんだけど
gitlabをインストールしてみたいんだけど
これってそういう風には使えるものなのかな
0073デフォルトの名無しさん2015/03/27(金) 17:14:19.11ID:wC2EsVxW
そういう風ってどういう風?
gitlabはdbも使ってるし移行作業は必要になると思うよ
0074デフォルトの名無しさん2015/03/27(金) 18:38:26.72ID:HpSv3zdu
>>72
素直にインポートしたら。たいした手間でなし。
0075デフォルトの名無しさん2015/03/27(金) 19:45:18.53ID:+T9VOHOm
gitを使うときのgit://、http://https://のプロトコルは、
認証、通信の暗号化の可否はそれぞれどうですか?
0076デフォルトの名無しさん2015/03/27(金) 21:37:55.61ID:9ALWzfda
>>72
当たり前だけど、gitのリポジトリをpushするだけ。

gitlabのgit以外の機能(IssueとかMergeRequestとか)に、
データベースを使っているが、gitwebにはgit以外の機能ってほぼないだろ?
0077デフォルトの名無しさん2015/03/27(金) 23:36:40.51ID:+T9VOHOm
git svnを使って、SVNのデータをGitサーバ(GitBucket)に移行しました

で、GitBucket上で、移行したコミットのコミット者を見ようとすると、
ユーザ名ではなくメールアドレスでユーザーの識別をしているように見えます
この識別方法はGitBucket固有ですか?

また、リモートリポジトリにpushした後の各コミットについて、
コミット者のメールアドレスを変更することは可能ですか?
0078デフォルトの名無しさん2015/03/27(金) 23:54:27.14ID:Z8DJNpSP
GitBucketって日本人が作ったのか
0079デフォルトの名無しさん2015/03/28(土) 14:15:10.16ID:w2Z+yJkJ
Git 5.6.24
https://github.com/git/git/releases/tag/v5.6.24
0080デフォルトの名無しさん2015/03/28(土) 18:47:44.36ID:+R+DyebJ
>>18
こんなん初めて知った
diff結果のパスを引数に合わせて変える模様

$ git diff
i/foo.txt # indexの'i'
w/foo.txt # worktreeの'w'
0081802015/03/28(土) 18:49:53.09ID:+R+DyebJ
ごめんログ更新してなかった
0082デフォルトの名無しさん2015/03/29(日) 18:08:14.32ID:E72jh6+u
最近のgitってインストールするとbash completionが自動的にインストールされる?
0083デフォルトの名無しさん2015/03/29(日) 19:10:29.25ID:GIfRQ9M6
依存パッケージが自動でインストールされるかは知らんがな
0084デフォルトの名無しさん2015/03/29(日) 21:45:52.31ID:SsUrZhnW
>>82
補完すごいよね
addすべき対象をtabで一発で当ててきたときはビビったよ
0085デフォルトの名無しさん2015/03/29(日) 22:04:26.44ID:vkiGWuNt
>>83
https://github.com/git/git/search?l=c&;q=add&utf8=✓
0086デフォルトの名無しさん2015/03/30(月) 08:52:02.76ID:ebxMPih7
>>14
そんなもの使ってない
0087デフォルトの名無しさん2015/03/30(月) 10:57:03.31ID:QTBkdmd4
>>82
そんなのディストリビューション次第じゃないの。
0088デフォルトの名無しさん2015/03/30(月) 11:53:27.54ID:eSl2sveJ
>>82
なぜbashだけが優遇されるのか?
今使われてるのはzshだろ。
0089デフォルトの名無しさん2015/03/30(月) 12:10:49.96ID:pDn2M2s4
>>88
zsh なら、oh-my-zsh に git プラグインあるだろ。
0090デフォルトの名無しさん2015/03/30(月) 13:24:21.18ID:pQkawj3/
>>89
あー、普通にgitについてたよw
0091デフォルトの名無しさん2015/03/30(月) 21:52:59.70ID:7jnhpj+r
>>88
今zsh使ってる人って残ってるの?
みんなbashに戻ったとばかり思ってた
0092デフォルトの名無しさん2015/03/31(火) 04:25:40.16ID:DVVpWgeR
え? 戻る理由は?
0093デフォルトの名無しさん2015/03/31(火) 10:24:36.59ID:byVPP9+b
ここのスレって、Gitのクライアント側の基本的なコマンドの
使い方が分かる人しかいませんか?

便利なGitクライアントソフトとか、各種Gitサーバソフトの
使い方とか、そういうのを質問したかったらどこがオススメ
でしょうか?
0094デフォルトの名無しさん2015/03/31(火) 10:48:52.86ID:jsR2iUWd
>>93
ここでいいと思うけど。もしかして >>77 かな?

GitBucketは使ったことないけど、
・gitは各コミットのauthorとcomitterそれぞれのnameとemailを記録してる。
・gitはユーザーを管理してない。ってか、分散システムだから管理しようがない。
・authorやcomitterの変更はできるけど、コミットID(ハッシュ値)も変わるので、変更というよりは履歴の書き換えになる。
0095デフォルトの名無しさん2015/03/31(火) 12:02:22.73ID:DMT7op/I
>>93
それgitに限定する意味あるの?
0096デフォルトの名無しさん2015/03/31(火) 21:52:09.98ID:N1jW3NRe
>>93
github固有の話は専用スレがある
他はここでいいんじゃない?
0097デフォルトの名無しさん2015/04/03(金) 00:52:20.92ID:bxWPklRz
コンフリクトをわざと発生させたいんだけど発生させ方を教えてください
0098デフォルトの名無しさん2015/04/03(金) 09:00:43.05ID:fygFc6bt
>>734
税法的にもアウトですよ。コレ。
0099デフォルトの名無しさん2015/04/03(金) 09:06:27.04ID:TGMPBffS
マジでか!
0100デフォルトの名無しさん2015/04/03(金) 11:50:44.23ID:uPiWXVNB
git merge topic
これでコンフリクトが出た場合はコミットされないのでgit merge --abortで元に戻せますよね
じゃあgit merge --no-commitってなんの意味があるんですか?
0101デフォルトの名無しさん2015/04/03(金) 12:16:47.24ID:/qzMUQum
そりゃコンフリクトしない時にコミットしたくない場合じゃないの?
01021002015/04/03(金) 13:02:08.91ID:/gPIw7xI
マージしたいからmergeコマンドを打つと思うんですが
そうなると問題なくマージできる場合はコミットして当然だと思いますがおかしいですかね
01031002015/04/03(金) 13:03:07.82ID:/gPIw7xI
つまり--no-commitは開発に置いて不要な引数だと思うんですよ
0104デフォルトの名無しさん2015/04/03(金) 13:49:11.28ID:/qzMUQum
コンフリクトしなくてもビルド通らないことだってあるし、一手間加えてから
コミットする余裕があってもいいんじゃね
0105デフォルトの名無しさん2015/04/03(金) 20:25:53.13ID:pcIMeknY
mergeするときに手作業でcommitログを書きたいときに使ってるよ
0106デフォルトの名無しさん2015/04/03(金) 23:06:07.33ID:TGMPBffS
>>103
理想としては全てのコミットは
テストに通れなければならない。

それはマージでも同じ話で、マージ前
マージ後、どちらもテストに通らなければならない。

起きる可能性は低いけれど、起こりえるのが
問題なくマージできたがテストには失敗するいうもの。

この時
1. (マージ前) テスト実行して問題ないことを確認。
2. (マージ後) テスト実行して問題発覚
3. git reset --hard HEAD^ でマージ前に戻す。
(rebaseだとマージに含まれる複数のコミットが分解されてしまうのでまずい)
4. git merge --no-commitでコミットせずにマージ
5. テスト実行して問題ないことを確認してからコミット

という流れで使うのではないだろうか?
0107デフォルトの名無しさん2015/04/04(土) 00:01:59.62ID:qXtcXItO
マージテストのためのブランチ作ればいいだけじゃね
0108デフォルトの名無しさん2015/04/04(土) 00:02:51.56ID:o7ivvLL/
ん? テストした後は?
0109デフォルトの名無しさん2015/04/04(土) 15:34:05.03ID:4aWMIGVn
TortoiseGitがエクスプローラーをフリーズさせる糞だったから思わずアンインストールした
0110デフォルトの名無しさん2015/04/05(日) 13:00:59.30ID:AGMqJGUT
>> 100
>> 106 が正しい。そういうマージコミットのことを evil マージという。
名前は悪そうだが、必要悪、といった感じだな。
0111デフォルトの名無しさん2015/04/05(日) 14:07:33.73ID:Gn5PCEDn
cloneしたファイルやディレクトリの中からdata/というデータを貯めるディレクトリがありまして
このディレクトリは.gitignoreで除外されています

git pullをしたらdata/を汚さずに最新版にアップデートできるんですが
data/の中身を毎日zipでバックアップを取ってます
data/の中身をgithubとかdropboxにリポジトリ作るとか何でもいいのでgit pushで簡単にバックアップ取れるようにしたいんですが
どうしたらいいのか教えてください
0112デフォルトの名無しさん2015/04/05(日) 14:40:52.20ID:OOK6R9Sy
>>111
gitはバックアップツールじゃない。
ソースコードのバージョン管理ツールだ。

gitというのは、ソースコードのバージョンに含まれる
機能を管理し、その機能を追加したり、削除したり
何が変わったか確認したり、バグを探したり
そういう事をするために使うツールだ。

コミット毎に内容に意味があって、そのコミットをうまく
活用できるためのツールがgitだ。

日付ごとのデータのバックアップなら別のツールを使いなさい。
01131112015/04/05(日) 15:39:11.36ID:Gn5PCEDn
データのバージョンを管理することになるので間違ってはないですよ。
分かる方教えてください
0114デフォルトの名無しさん2015/04/05(日) 15:49:35.25ID:KkKmAC5t
data/ の中でgit initすればいいんじゃね
0115デフォルトの名無しさん2015/04/05(日) 17:38:56.13ID:lc+vonxV
リポジトリ別にするとかシェルスクリプトとか別に何でもいいよね
0116デフォルトの名無しさん2015/04/05(日) 18:52:26.59ID:OOK6R9Sy
>>113
間違いだよ。
素人は黙ってな。
0117デフォルトの名無しさん2015/04/05(日) 20:05:27.42ID:/p4ZvisL
>>116頭の固い玄人パイセンオッスオッス
0118デフォルトの名無しさん2015/04/05(日) 22:45:55.43ID:vTKOQGSX
>>117
老害をからかってちゃ後が面倒だぜ
0119デフォルトの名無しさん2015/04/05(日) 23:02:46.40ID:JNGfMGjI
じゃあなんで答えないんだろうねw
0120デフォルトの名無しさん2015/04/06(月) 07:57:53.43ID:/B7mQxeO
ローカルでの事だからテスト前でも merge commit するなぁ。
不具合修正は別 commit にするし。
0121デフォルトの名無しさん2015/04/06(月) 19:47:22.89ID:opDSS45m
ブランチAで作業
ブランチ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するしかないのでしょうか?
■ このスレッドは過去ログ倉庫に格納されています