[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
492(2): (ﾜｯﾁｮｲ c5e6-FGqy) 2023/04/27(木)09:18 ID:4Ldu38ha0(1) AAS
>>491
そういうものなんですか。
Subversionのときは、ブランチの作成自体が1つのコミットで、
ブランチの名前や、どういう作業を始めるのかをログに残しておけたけど、
そのへんの感覚も違うんですね。
493: (ｽｰｯﾌﾟ Sd0a-3RjN) 2023/04/27(木)10:53 ID:SsZf7nuSd(1) AAS
>>492
だからマージの時にどのブランチからどのブランチにマージしたのかデブォルトでコミットログに残るでしょ
494(1): (ﾜｯﾁｮｲ e6bb-QZyk) 2023/04/27(木)21:42 ID:yMUedyDf0(1/2) AAS
>>492
subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
git はブランチが軽くて余計な容量を食わないので百でも千でも好きなだけ切れる。しょっちゅう作ったり消したりできるし、ずっと残しておく事もできる。
そのせいでブランチに対する考え方が違う。必要ならなんで消したの？ みたいになる。
495: (ﾜｯﾁｮｲ c55f-ASru) 2023/04/27(木)21:51 ID:aeCa0uwW0(1) AAS
>>494
> subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
んなこたーない。
外部ﾘﾝｸ[html]:tortoisesvn.net
> つまり、リポジトリの完全なコピーを作成する代わりに、指定したツリーやリビジョンを指す内部リンクを作成します。そのため、ブランチやタグの作成は、非常に高速で、リポジトリに追加スペースをほとんど使用しません。
ダメなのはマージの追跡が後付けで非効率なところ。
496: (ﾜｯﾁｮｲ e6bb-QZyk) 2023/04/27(木)22:14 ID:yMUedyDf0(2/2) AAS
いい加減なこと言ってないで、実プロジェクトで git と svn のブランチを使い比べてみろ。
497: (ｵｲｺﾗﾐﾈｵ MMb5-brYh) 2023/04/28(金)05:15 ID:PA/2QVhjM(1) AAS
Error: explorer.exe not found in PATH の修正来たわ
please note that the latest snapshot has the fix
外部ﾘﾝｸ[html]:wingit.blob.core.windows.net
498: (ﾌﾞｰｲﾓ MM0a-QZyk) 2023/04/28(金)15:09 ID:dkx3B1sjM(1) AAS
svn 屋がいくら cheap copy でコピーが速いって自慢しても、git のブランチ作成はそもそも zero copy なんで比べものにならないんだよな。
設計思想の根本的な違い。
499(1): (ﾜｯﾁｮｲ c55f-ASru) 2023/04/28(金)15:30 ID:dDRImt5V0(1/2) AAS
別に Subversion を擁護するわけでも自慢するわけでもないんだけど、少なくともブランチ作成に限れば
どちらも一瞬なんで何を見て「ディスク容量とかで制限されてた」「比べものにならない」とか言ってるのか
わからない。 Subversion 嫌い過ぎなだけなんじゃないかと。
マージはクソなのでそこも含めての話なら「ブランチの使用が重くて」はわかる。
500(2): (ﾌﾞｰｲﾓ MM0a-QZyk) 2023/04/28(金)17:05 ID:8y/8q1m4M(1) AAS
>>499
そこまで言うのなら大きめのプロジェクト、例えば linux のソースコードくらいのやつに git と svn で100個ずつブランチを切って作業時間を比べてみ。当然だが作業コピーも作って1回ずつ作業しろよ。
どっちも一瞬かどうか、自分で体験すれば納得いくだろ。
ディスク容量の話は昔の容量が小さかったころの経験なので、最近の大容量だと問題ないかもだから撤回しとく。
501(1): (ﾜｯﾁｮｲ c55f-ASru) 2023/04/28(金)17:47 ID:dDRImt5V0(2/2) AAS
>>500
え？ブランチ作るごとに作業コピー作るってのが意味わからんのだけど？
そんなことしたらどっちでも作業コピー作る時間が圧倒的ネックになって比較の意味も無くなりそうだし。
502(1): (ﾜｯﾁｮｲ ffbb-E3WC) 2023/04/29(土)10:58 ID:Toi7lz0e0(1/3) AAS
>>501
使ってないこと丸わかりの馬鹿コメントだな。svnスレに帰れ。
お前は作業もしないのにブランチ切るの？
圧倒的ネックなのは svn だけ。git を巻き込むな
503(1): (ﾜｯﾁｮｲ 975f-By2c) 2023/04/29(土)11:49 ID:YEumeQ4R0(1/2) AAS
>>502
どういうことなの・・・
git branch x でブランチ作るにあたって作業コピーなんか作らないし、
svn copy ^/trunk ^/branches/x -m "..." でブランチ作ってもそれは同じでしょ。
なんで「当然だが作業コピーも作って」なんて話になるんだ？
504: (ﾜｯﾁｮｲ ffbb-E3WC) 2023/04/29(土)13:24 ID:Toi7lz0e0(2/3) AAS
>>503
git checkout -b xxx
edit filename
git cimmit -a
が git のやり方
505: (ﾜｯﾁｮｲ 975f-By2c) 2023/04/29(土)15:34 ID:YEumeQ4R0(2/2) AAS
あー >500 の「作業コピーも作って」は「作業コピーを切り替えて」の意味で、
git checkout -b xxx
↑が↓になる違いを言ってたのかな。
svn copy ^/trunk ^/branches/xxx -m "..."
svn switch ^/branches/xxx
git だと切り替え含めてほぼ何もしないからこれでも一瞬だけど、
svn のほうは切り替え含めれば数秒はかかりそうだから 100 も作ればだいぶ違うだろうね。
506: (ﾜｯﾁｮｲ ffbb-E3WC) 2023/04/29(土)17:08 ID:Toi7lz0e0(3/3) AAS
branch に名前をつけるだけじゃなくて、branch を実際に使うとこまで含めて git は軽々ということ
そしてそれが git 文化の根底にあるので、旧世代の認識で見ると不思議に見えるという話
507(1): (ﾜｯﾁｮｲ ffbb-E3WC) 2023/05/02(火)12:10 ID:qiaRnW6F0(1/3) AAS
git で「ブランチ作る」って言ったら commit してブランチを伸ばすとこまで含めてだな
中身空っぽの名前だけのブランチとか作ったとは言わない、せいぜい「名前をつけた」だな
508: (ﾜｯﾁｮｲ ffbb-E3WC) 2023/05/02(火)12:13 ID:qiaRnW6F0(2/3) AAS
といあたりに誤解の元がありそう。
509(1): (ﾃﾃﾝﾃﾝﾃﾝ MM8f-gobk) 2023/05/02(火)12:33 ID:izIA5aWFM(1) AAS
>>507
git branchで作った時点で「ブランチを作る」だろ。ヘルプからしてそうなっているんだし。
510(1): (ﾜｯﾁｮｲ ffbb-E3WC) 2023/05/02(火)12:44 ID:qiaRnW6F0(3/3) AAS
>>509
お前がそう思うんならな。
でも git branch でブランチを「作る」なんて普通しないからな。昔の作法にとらわれてるロートルくらいだよ
511: (ﾜｯﾁｮｲ ff8f-q0ED) 2023/05/02(火)14:06 ID:mR5RoZxq0(1) AAS
中身からっぽだと思ってる時点で素人だな
512: (ﾜｯﾁｮｲ b79c-gobk) 2023/05/03(水)10:19 ID:psoe33uP0(1) AAS
>>510
man書いている公式に文句言え。
混乱の元だからオレオレ用語使うなよ。
513: (ﾜｯﾁｮｲ ffbb-E3WC) 2023/05/03(水)13:21 ID:wjk3BEO40(1) AAS
マニュアルは正確には branch head を作成するな。
514: (ﾜｯﾁｮｲ ff8f-q0ED) 2023/05/03(水)15:40 ID:toMmOllu0(1) AAS
Creating a New Branch
What happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called testing. You do this with the git branch command:
$ git branch testing
git branch が「ブランチ作る」で正しいよ
515(8): (ﾜｯﾁｮｲ 1610-Z+mA) 2023/05/07(日)02:53 ID:9zTyX7Ss0(1/2) AAS
2点質問があります。もし詳しい人がいましたらご教授いただけると幸いです。
【自己紹介・置かれている状況】
私はGitが全くわかっていない人間です。業務もITとは無関係です。
私の部署はワードやエクセルで書類を作成したり、電話対応を行うのが主な業務です。
pythonやphpなど、プログラミング言語を使った業務は皆無です（エクセルで若干関数を扱う程度）。
現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。
【質問】
1）エクセルやワードが使えるだけの人（高齢者や短時間勤務の主婦もいます）でもGitは扱えますでしょうか？
2）PCやタブレットが50台くらいあるのですが、環境設定は大変でしょうか？作業者は私になるそうです。
【余談】
「サル先生のGit入門」や「Gitの良さが分からない？ ちょっとそこに座れ」という記事は読みました。
専門用語が多く、理解できていません...
よろしくお願いいたします。
516(1): (ﾜｯﾁｮｲ 96bb-J6v/) 2023/05/07(日)07:04 ID:oLYbcGcf0(1/4) AAS
>>515
使えなくないだろうけど、そんなに役には立たないと思うよ。他のことを勉強するのに時間を使った方がいい。
git は複数の人で作品を作り上げるためのコラボレーション・ツール。そういうのが必要になったら戻っておいで。
517: (ｱｳｱｳｳｰ Sac3-wpjJ) 2023/05/07(日)08:33 ID:uPYz4dpTa(1) AAS
個人でもバージョン管理できると良い事はあるけど、帳簿みたいにExcel や DB で管理した方が良いものは、Git で管理ではないしね。
518(1): (ﾜｯﾁｮｲ 477b-sttf) 2023/05/07(日)10:33 ID:DNOpmTqI0(1/6) AAS
>>515
> 現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。
他の人の言うとおり、gitではないよ。gitしか知らない馬鹿コンサルは無視でいい。
他部署がなぜgitを推すのかはちょっと確認した方がいいが。
俺は使ったこと無いけど、ワードやエクセル台帳を管理する為のものは、MS謹製のSharePointだよ。
ググれば大量に記事も出てくるし、オフィススイートにも含まれてる。（から君の職場のPCにも既にインストール済みかも？)
プログラミングをしない人向けに出来てるから、君の職場にも十分フィットする。(というかMSはそれが目的)
gitは基本的に（プログラムの）ソースコード用であって、
逆に、ソースコード以外の物をgitで管理するメリットがまるでない。余計に煩雑になるだけ。
ついでに言っとくと、SharePointの名前が出てこないコンサルなんて無能だから切るべきだし、
このスレの連中もgitには詳しいがその他には無知なので、例えばすぐ上の489～とか、
今のgitと20年前のsvnを比較してるからそんな空回りするのでは？みたいなことになってるだろ。
みんな自分の周りしか見えてないんだよ。(まあ俺もだが）
どのパッケージソフトを導入するかで今後10年ほどの運命が決まる。
君の責任は重大だし、その前に調査しようという君の姿勢は正しい。
ただ、全ての管理ツールを使ったことがある奴は基本的にいないから、
どいつもこいつも断片的で偏った情報しか出してこないはずだけど、それも含めて頑張って調査するんだね。
(だからこそコンサルなのだが、そのコンサルは不勉強でgitしか知らないからそんな提案しか出来ないわけだ)
使用感とか実際のところは分からんが、仕様だけ見ると、君の職場にはgitよりSharePointの方が100倍いい。
あとはわらしべ長者方式でがんばれ。
君が担当＝君の職場では君がその分野の第一人者、なのだから、
君が分からないものを職場の他の人が理解出来るはずがない。
少なくとも、君にとっては簡単過ぎる物を選ばないと、職場のみんなが使える物にはならないよ。
519(1): (ﾜｯﾁｮｲ 96bb-J6v/) 2023/05/07(日)12:04 ID:oLYbcGcf0(2/4) AAS
長々と無駄なレス書いてるやつもいるが、一人で考えたり、いきなり SharePoint とか始めるじゃなくて社内でよく相談することを推奨するよ。
他部署とかでも SharePoint 使ってるならお勧めだが、社内全体が git で染まってるなら自部署だけ違うのを使うのはお勧めしない。
自部署単独ではあまり役に立たなくても全社での交流を考えると有用ということもある。
520(1): (ﾜｯﾁｮｲ 477b-sttf) 2023/05/07(日)13:02 ID:DNOpmTqI0(2/6) AAS
>>519
全社規模でgit導入済みの大企業が、git知らない奴にgit導入の可否判断/作業なんてさせるはず無いだろ。
この程度なのがこのスレの実態だよ。会社で働いたことないんだ。
> 社内でよく相談することを推奨するよ。
勿論そうだが、その結果、他部署やコンサルからgitを勧められてるんだろ。
>>515
まあ俺はgitの達人ではないが、俺の知ってる限りで直接質問にも答えておくと、
1) 無理。gitは使う前に100時間程度の予習が『全員に』必要。
実際君は「サル先生のGit入門」に何時間かけた？それでも全然足りないんだろ。そういう事。
そしてgit導入したとしても、メリット無いよ。ExcelやWordファイルをマージする機能なんて無いと思うし。
svnはExcel/Wordのdiffが取れるが、確か外部ツールを介してたはずで、ゴネればgitでも出来たはず。
けどここら辺、結局MS製品(Excel/Word)ならMS製品(SharePoint)に合わせておいた方が色々将来的にも得策だよ。
結局外部ツールなら箱は何でもいいし、公式ツールが最初に実装されるのはMS謹製ソフトだし。
2) 環境設定自体は50台なら手際よくやれば1日で終わるんじゃないの？
そこら辺に転がってるgitソフトをインストールして回るだけだから。1台10分なら1日だよね。
ただこれだと君も危惧してるとおり、箱を用意しただけで、中身は入らない。
このスレの連中はgitの達人だから、gitの機能については俺よりも他の連中を当てにした方がいい。
ただ同時にgit信者で、無理にgitを布教する面もあるからそのつもりで。
521(1): (ﾜｯﾁｮｲ 96bb-J6v/) 2023/05/07(日)13:23 ID:oLYbcGcf0(3/4) AAS
>>520
お前は考えが浅いよ。他の部門やコンサルが git 勧めてる理由をよく聞いて判断すべき。局所最適ではなく全体の最適化に協力すべき。
例えばうちだと、git は画像ファイルや pdf の管理にはあまり役に立たないけど gitlab で管理している。画像作成部門とかからしたら無駄な手間だが、全体として他の素材(プログラムやhtml)と一元管理できるメリットはとても大きい。
git 覚える手間は大きいので推奨はしないが、状況次第。全員が覚える必要はなくて登録担当者（リーダー）だけ使うとかもありえる。
上下前次1-新書関写板覧索設栞歴
あと 481 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.019s