983コメント406KB

Git 12©5ch.io

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん転載ダメ©2ch.net

2015/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/

0002デフォルトの名無しさん

2015/03/23(月) 13:37:21.43ID:aBYp+bVs

◆関連スレ
バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ～ Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
【分散型バージョン管理】 Mercurial 2【hg】
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://peace.2ch.net/test/read.cgi/tech/1356521407/
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

◆関連スレ別板
CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/

0003デフォルトの名無しさん

2015/03/23(月) 18:37:08.09ID:5dh1GAQd

>>1乙

ところで
diff.mnemonicprefix
ってなに？

0004デフォルトの名無しさん

2015/03/23(月) 19:15:42.59ID:y5y7OlJ2

>>前996
＞そうか、いくつものプロジェクトを任されないやつは気楽でいいな。
＞部下の手間やオペミスを気にしない立派な方は言うことが違うな。

お前と違って、部下全員の動きを一挙手一投足全部自分で
チェックアウトできるほど暇じゃないもんで・・・

>>前997
＞どのくらいの頻度でプロジェクトの新規立ち上げするの？
＞やっぱり1日1個くらいのペースでどんどん増えていくもの？

さすがにそんな増えないでしょ
3か月ペースの開発プロジェクトが60個、それぞれに平均5人いるとしても
300人のエンジニアを率いていることになるよ
そんな人が、部署のマネジメントもろくにしないでしこしこgitのプロジェクトを
起こしてるとか考えにくい
gitのプロジェクトを起こすのが仕事の間接部隊の人なら、まぁあるかも
しれないけど

0005デフォルトの名無しさん

2015/03/23(月) 20:50:21.09ID:BMVzdvQz

こいつエンジニアではないな。

997 デフォルトの名無しさん sage 2015/03/23(月) 12:14:29.10 ID:5dh1GAQd
うちの会社は半年に1個くらいしかプロジェクトないので
いつも手書きのメモ見ながら作ってるわ・・・

0006デフォルトの名無しさん

2015/03/23(月) 20:51:21.38ID:BMVzdvQz

いや、運用エンジニアならアリか。

0007デフォルトの名無しさん

2015/03/23(月) 21:58:34.39ID:y5y7OlJ2

>>5-6
あなたにとっての突っ込みどころが「半年にプロジェクトが1個」なのか「手書きのメモ」なのか分からないけど、
半年に1個のペース（しかも一個人の目に見えるとこ）でgitリポジトリ＝新規製品が1個立ち上がってるとしたら
結構早い気が

自分がパッケージ開発系にいるからそう思うだけで、スマホゲーみたいな「いつもの手順で何個も作る」みたいな
開発形式だと、そういうペースになるのだろうか

0008デフォルトの名無しさん

2015/03/23(月) 23:09:04.71ID:BMVzdvQz

>>7
滅多にないなら、忘れないために自動化する。
頻繁にあるなら、手間をかけないために自動化する。

プロダクトとプロジェクトは別だよ。
同じっていうプロジェクトの分け方もあるとは思うけど、それはポリシーの話。

0009デフォルトの名無しさん

2015/03/24(火) 00:17:38.33ID:LMCtJA+5

>>8
＞滅多にないなら、忘れないために自動化する。
滅多にやらないことに自動化＋自動化ツールの手順書作成は、さすがにコストかかりすぎると思う

＞プロダクトとプロジェクトは別だよ。
話のピントがずれてきてるな・・・自分と前997が気にしてるのは、プロダクトとプロジェクトの定義じゃなく、
新しいgitリポジトリを毎日作らなきゃならない職場って一体どんなだろうってことだ

0010デフォルトの名無しさん

2015/03/24(火) 01:00:24.03ID:AMK4q4iG

>>9
普段GUI使ってる人にはわからないかもだけど、
5分もかからない。
スクリプトなら説明は要らないが、必要ならそのまま書き込める。

毎日なんて誰も言ってないだろ。
1週間でプロジェクトの立ち上げして、後は任せたとかなら割とある。

0011デフォルトの名無しさん

2015/03/24(火) 01:24:05.45ID:LMCtJA+5

>>10
＞普段GUI使ってる人にはわからないかもだけど、
＞5分もかからない。
うーんそれって、「自動化したんじゃなくって既に自動化されてる」とか、
「5個位コマンドを打たなきゃならないのを1個にした」って話か・・・

＞1週間でプロジェクトの立ち上げして、後は任せたとかなら割とある。
最初のたった1週間しかいないプロジェクトで、一体あなたが何の役割を果たすのか疑問だ
親会社が子会社に要求仕様を丸投げして消えるような感じだろうか
そうだとすると、肩書きというか所属はエンジニアだけど実態は発注者だな

そういう立ち位置の人がgitのリポジトリを作る必要があるのかもよく分からなくなってきた
親会社のサーバーにリポジトリを作るから、親会社の人しかリポジトリを作れないとかだろうか

0012デフォルトの名無しさん

2015/03/24(火) 01:48:04.53ID:AMK4q4iG

>>11
すまなかったな。
お前にとって、リポジトリを立てるというのが、とても難しいことだと言うのは、よくわかったよ。
理解できない人もいるんだな。

それしかやってないと言う思い込みをしてるのかな。

0013デフォルトの名無しさん

2015/03/24(火) 09:42:14.84ID:LMCtJA+5

>>12
リポジトリを立てるのが簡単なのは、よく分かったよ
コマンドラインを何発か叩くだけなんでしょ？

問題は、何十プロジェクト（50人ちかく？）のまとめ役をやってて、
しかもプロジェクトを丸投げして開発管理をしないような人が、
なんでgitの管理は自分でやることにこだわるのか、ってことだ

・・・実際はまとめ役じゃなくて開発環境を整備する役で、そっちが
メインだからなのかもしれないが・・・

0014デフォルトの名無しさん

2015/03/24(火) 11:47:24.75ID:FrFlsYhd

デカい会社ってgitをどう使ってるんだろ
gitをきちんとスター型にするのって面倒くさくね？

0015デフォルトの名無しさん

2015/03/24(火) 12:55:00.90ID:LMCtJA+5

>>14
それってネットワーク関係の話？

そういうときは、自部署の閉じたネットワークにgitサーバを立てるんじゃなくって、
社内どこからでも（場合によっては社外からも）接続可能な特別なgitサーバを
ネットワーク部門の人が用意してるから、そこにリポジトリ作成を「申請する」って
流れになると思う

0016デフォルトの名無しさん

2015/03/24(火) 13:00:03.66ID:jPXMtrDE

キャパシティやレスポンスの問題はあるけどgitのmasterなんか、どこに
あっても同じじゃん？そもそもでかいガタイの為にでかいRCSを「立てる」
必要がないってのがgit(系統)の売りだったんじゃ？

0017デフォルトの名無しさん

2015/03/24(火) 13:17:28.26ID:Z7mrPero

どこにあっても同じだけど、違うmasterが二箇所にあればどちらが正しいか分からなくなるのもgit
だから、中央リポジトリとコミッターが必要になる。

0018デフォルトの名無しさん

2015/03/24(火) 14:26:16.00ID:FrFlsYhd

ところで話は変わるけど
diff.mnemonicprefix ってなに？

sourceforgeでfetchしたときのオプションにあったんだけど
なにを意味するのかバヌアツ見てもよくわからない

0019デフォルトの名無しさん

2015/03/24(火) 14:57:15.56ID:jPXMtrDE

>>17
> 違うmasterが二箇所にあればどちらが正しいか分からなくなるのもgitだから、
それは「運用の不手際」であってgitと全く関係ないじゃん？

0020デフォルトの名無しさん

2015/03/24(火) 15:15:37.69ID:LMCtJA+5

>>19
違うmasterが2個あるのが「運用の不手際」であり、masterはただ1つでなければならないなら、
そのmasterは、プロジェクトに関わる全員から見える場所にないと困ると思うが・・・

0021デフォルトの名無しさん

2015/03/24(火) 16:19:57.62ID:AMK4q4iG

>>13
お前が自分が知ってる形態しか理解できないのはよくわかったよ。

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マージしたりするからなｗ

0038デフォルトの名無しさん

2015/03/25(水) 15:04:11.83ID:8K+/BW9F

開発ブランチも公開しちゃってるからリベースできないお

■ このスレッドは過去ログ倉庫に格納されています