Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、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 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/03/30(木) 03:19:39.83

>>468
あなたこそ、現実にオープンソースソフトウェアを試してない。
試したらすぐ分かること。

2023/03/30(木) 03:56:59.98

>>469
Windows にシンボリック・リンクが無かったのは大昔に話ですよ。いくら 2ch が老人集会所だからって、知識が Windows XP どまりとか笑える。

2023/03/30(木) 04:09:23.59

git スレにきて、「お前はオープンソースソフトウェアを試していない」とか言い出す奴おる？
長文君といい、このスレ定期的に変な奴湧くなあ

2023/03/30(木) 15:38:07.97

>>470
あっても大部分のオープンソースアプリでは使われて無い。
馬鹿だから。

2023/03/30(木) 18:20:59.63

>>472
ここはお前の妄想を語る場所じゃないよ。
git の話しろ。

2023/03/30(木) 20:36:16.47

複数人が同一ブランチで作業していて、それぞれ異なるファイルを修正しているのですが、
一人がプッシュすると、他の人がそれをプルしてくる際にマージのコミットが発生します。
ff-onlyの設定だと、複数人の作業ではいつもプルに失敗します。
Gitでは複数人での作業はこういうものなのでしょうか。

2023/03/30(木) 21:17:24.39

そういうもんだけどその複数人たる他の人達はそのことについてあなたになんて言ってるのさ

2023/03/30(木) 23:49:49.22

>>474
普通は同じブランチ上で作業しない。
ブランチ切るのは無料なので各自が自分用の作業ブランチを切ってそこで作業する。ff-only の場合は特に。
ブランチ切らずに作業するのは hot fix とか超急いでる時だけ。

2023/03/31(金) 09:11:50.51

>>475-476
一つの機能追加やバグ修正を、複数人で対応するようなケースなんですが、
こういう場合も一人一人ブランチを切って作業するものなんですか？
そうなると、ブランチでフェッチやプルが必要なケースってなくなってしまいそうですが。

2023/03/31(金) 10:25:27.66

>>474
異なるファイルを編集しようが、すでに起こったコミット済みのファイル間で一貫性が保たれていないかもしれない状態かもしれないわけだしマージするしかなくない？
モジュールAとモジュールBはお互いの内部実装に依存しているが、AとBを変更した担当者がお互いの変更を知らないでコミットツリーが1本になっちゃっても困るでしょう。
見た目上マージを避ける方法としてはrebaseとかあるけど。

2023/03/31(金) 10:58:07.02

>>478
プルのときにリベースをすると、マージコミットが発生しないようにできるんですね。
いろいろ勉強していたら、複数人での開発でマージコミットが履歴の上に何度も現れるのは目障り、
と同じような感想を持っているサイトがあり、リベースが紹介されていました。

2023/03/31(金) 12:50:57.47

merge commit ない方が履歴を追いやすいので普段の小さな更新は rebase でやるのが一般的。
一方で長く別れていた異なる経歴のものを混ぜる場合には merge commit があった方が分かりやすいので merge にするべき。

2023/03/31(金) 12:57:43.80

>>477
作業ブランチの共有をどのようにするかはチームごとのルールがあるので仲間に確認
プルリクエストを出して取り込んでもらうという運用もあるし、
共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的。

2023/03/31(金) 13:39:22.27

>>480-481
>共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的
この運用だと、複数人での同一ブランチでの作業でも、履歴を1本化できるのですよね。
もちろん、他のブランチでの修正などをマージするときは、履歴として残していくつもりです。

2023/04/05(水) 18:00:34.21

WindowsのSourcetree、起動するたびに右に1ピクセルずつ広がっていくんだけど、おま環？

2023/04/06(木) 18:18:24.64

めっちゃ判りますωωω

2023/04/08(土) 16:07:30.25

Git初心者後輩のrebase童貞とreset童貞
卒業させてやった

2023/04/09(日) 19:33:50.10

>>485
おめ。
次はSquashで大量コミットお化け童貞も捨てさせるチャンスだな。

2023/04/12(水) 16:25:18.28

pushしてPRしてアーッって新境地へ

2023/04/20(木) 22:47:39.66

開発用ML見てたら、git replay　ってのを作ってる人がいる模様。

https://public-inbox.org/git/20230407072415.1360068-1-christian.couder@gmail.com/T/#m982eda816df06532f97ec30be5dda768cea5338f

2023/04/26(水) 19:09:19.52

マージして削除したブランチって、ログの樹形図を見ても、
そのブランチが何という名前だったのかは基本的にわからないものですか？

2023/04/26(水) 19:49:05.13

Git v2.40.1

2023/04/26(水) 19:58:42.13

マージコミットのメッセージがあればそれを信用するしかない

2023/04/27(木) 09:18:11.67

>>491
そういうものなんですか。
Subversionのときは、ブランチの作成自体が1つのコミットで、
ブランチの名前や、どういう作業を始めるのかをログに残しておけたけど、
そのへんの感覚も違うんですね。

2023/04/27(木) 10:53:45.90

>>492
だからマージの時にどのブランチからどのブランチにマージしたのかデブォルトでコミットログに残るでしょ

2023/04/27(木) 21:42:03.12

>>492
subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
git はブランチが軽くて余計な容量を食わないので百でも千でも好きなだけ切れる。しょっちゅう作ったり消したりできるし、ずっと残しておく事もできる。
そのせいでブランチに対する考え方が違う。必要ならなんで消したの？みたいになる。

2023/04/27(木) 21:51:10.24

>>494
> subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、

んなこたーない。
https://tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-dug-branchtag.html
> つまり、リポジトリの完全なコピーを作成する代わりに、指定したツリーやリビジョンを指す内部リンクを作成します。そのため、ブランチやタグの作成は、非常に高速で、リポジトリに追加スペースをほとんど使用しません。

ダメなのはマージの追跡が後付けで非効率なところ。

2023/04/27(木) 22:14:47.72

いい加減なこと言ってないで、実プロジェクトで git と svn のブランチを使い比べてみろ。

2023/04/28(金) 05:15:11.41

Error: explorer.exe not found in PATH の修正来たわ

please note that the latest snapshot has the fix
https://wingit.blob.core.windows.net/files/index.html

2023/04/28(金) 15:09:32.21

svn 屋がいくら cheap copy でコピーが速いって自慢しても、git のブランチ作成はそもそも zero copy なんで比べものにならないんだよな。
設計思想の根本的な違い。

2023/04/28(金) 15:30:18.71

別に Subversion を擁護するわけでも自慢するわけでもないんだけど、少なくともブランチ作成に限れば
どちらも一瞬なんで何を見て「ディスク容量とかで制限されてた」「比べものにならない」とか言ってるのか
わからない。 Subversion 嫌い過ぎなだけなんじゃないかと。

マージはクソなのでそこも含めての話なら「ブランチの使用が重くて」はわかる。

2023/04/28(金) 17:05:37.81

>>499
そこまで言うのなら大きめのプロジェクト、例えば linux のソースコードくらいのやつに git と svn で100個ずつブランチを切って作業時間を比べてみ。当然だが作業コピーも作って1回ずつ作業しろよ。
どっちも一瞬かどうか、自分で体験すれば納得いくだろ。

ディスク容量の話は昔の容量が小さかったころの経験なので、最近の大容量だと問題ないかもだから撤回しとく。

2023/04/28(金) 17:47:03.47

>>500
え？ブランチ作るごとに作業コピー作るってのが意味わからんのだけど？
そんなことしたらどっちでも作業コピー作る時間が圧倒的ネックになって比較の意味も無くなりそうだし。

2023/04/29(土) 10:58:48.12

>>501
使ってないこと丸わかりの馬鹿コメントだな。svnスレに帰れ。
お前は作業もしないのにブランチ切るの？
圧倒的ネックなのは svn だけ。git を巻き込むな

2023/04/29(土) 11:49:10.88

>>502
どういうことなの・・・
git branch x でブランチ作るにあたって作業コピーなんか作らないし、
svn copy ^/trunk ^/branches/x -m "..." でブランチ作ってもそれは同じでしょ。

なんで「当然だが作業コピーも作って」なんて話になるんだ？

2023/04/29(土) 13:24:59.65

>>503
git checkout -b xxx
edit filename
git cimmit -a
が git のやり方

2023/04/29(土) 15:34:03.46

あー >500 の「作業コピーも作って」は「作業コピーを切り替えて」の意味で、
git checkout -b xxx
↑が↓になる違いを言ってたのかな。
svn copy ^/trunk ^/branches/xxx -m "..."
svn switch ^/branches/xxx

git だと切り替え含めてほぼ何もしないからこれでも一瞬だけど、
svn のほうは切り替え含めれば数秒はかかりそうだから 100 も作ればだいぶ違うだろうね。

2023/04/29(土) 17:08:24.97

branch に名前をつけるだけじゃなくて、branch を実際に使うとこまで含めて git は軽々ということ
そしてそれが git 文化の根底にあるので、旧世代の認識で見ると不思議に見えるという話

2023/05/02(火) 12:10:21.01

git で「ブランチ作る」って言ったら commit してブランチを伸ばすとこまで含めてだな
中身空っぽの名前だけのブランチとか作ったとは言わない、せいぜい「名前をつけた」だな

2023/05/02(火) 12:13:06.79

といあたりに誤解の元がありそう。

2023/05/02(火) 12:33:04.68

>>507
git branchで作った時点で「ブランチを作る」だろ。ヘルプからしてそうなっているんだし。

2023/05/02(火) 12:44:34.23

>>509
お前がそう思うんならな。
でも git branch でブランチを「作る」なんて普通しないからな。昔の作法にとらわれてるロートルくらいだよ

2023/05/02(火) 14:06:39.43

中身からっぽだと思ってる時点で素人だな

2023/05/03(水) 10:19:00.05

>>510
man書いている公式に文句言え。
混乱の元だからオレオレ用語使うなよ。

2023/05/03(水) 13:21:30.84

マニュアルは正確には branch head を作成するな。

2023/05/03(水) 15:40:13.27

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 が「ブランチ作る」で正しいよ

2023/05/07(日) 02:53:34.47

2点質問があります。もし詳しい人がいましたらご教授いただけると幸いです。

【自己紹介・置かれている状況】
私はGitが全くわかっていない人間です。業務もITとは無関係です。
私の部署はワードやエクセルで書類を作成したり、電話対応を行うのが主な業務です。
pythonやphpなど、プログラミング言語を使った業務は皆無です（エクセルで若干関数を扱う程度）。
現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。

【質問】
1）エクセルやワードが使えるだけの人（高齢者や短時間勤務の主婦もいます）でもGitは扱えますでしょうか？
2）PCやタブレットが50台くらいあるのですが、環境設定は大変でしょうか？作業者は私になるそうです。

【余談】
「サル先生のGit入門」や「Gitの良さが分からない？ちょっとそこに座れ」という記事は読みました。
専門用語が多く、理解できていません...

よろしくお願いいたします。

2023/05/07(日) 07:04:06.12

>>515
使えなくないだろうけど、そんなに役には立たないと思うよ。他のことを勉強するのに時間を使った方がいい。
git は複数の人で作品を作り上げるためのコラボレーション・ツール。そういうのが必要になったら戻っておいで。

2023/05/07(日) 08:33:30.66

個人でもバージョン管理できると良い事はあるけど、帳簿みたいにExcel や DB で管理した方が良いものは、Git で管理ではないしね。

2023/05/07(日) 10:33:19.76

>>515
> 現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。
他の人の言うとおり、gitではないよ。gitしか知らない馬鹿コンサルは無視でいい。
他部署がなぜgitを推すのかはちょっと確認した方がいいが。

俺は使ったこと無いけど、ワードやエクセル台帳を管理する為のものは、MS謹製のSharePointだよ。
ググれば大量に記事も出てくるし、オフィススイートにも含まれてる。（から君の職場のPCにも既にインストール済みかも？)
プログラミングをしない人向けに出来てるから、君の職場にも十分フィットする。(というかMSはそれが目的)

gitは基本的に（プログラムの）ソースコード用であって、
逆に、ソースコード以外の物をgitで管理するメリットがまるでない。余計に煩雑になるだけ。

ついでに言っとくと、SharePointの名前が出てこないコンサルなんて無能だから切るべきだし、
このスレの連中もgitには詳しいがその他には無知なので、例えばすぐ上の489～とか、
今のgitと20年前のsvnを比較してるからそんな空回りするのでは？みたいなことになってるだろ。
みんな自分の周りしか見えてないんだよ。(まあ俺もだが）

どのパッケージソフトを導入するかで今後10年ほどの運命が決まる。
君の責任は重大だし、その前に調査しようという君の姿勢は正しい。
ただ、全ての管理ツールを使ったことがある奴は基本的にいないから、
どいつもこいつも断片的で偏った情報しか出してこないはずだけど、それも含めて頑張って調査するんだね。
(だからこそコンサルなのだが、そのコンサルは不勉強でgitしか知らないからそんな提案しか出来ないわけだ)
使用感とか実際のところは分からんが、仕様だけ見ると、君の職場にはgitよりSharePointの方が100倍いい。
あとはわらしべ長者方式でがんばれ。

君が担当＝君の職場では君がその分野の第一人者、なのだから、
君が分からないものを職場の他の人が理解出来るはずがない。
少なくとも、君にとっては簡単過ぎる物を選ばないと、職場のみんなが使える物にはならないよ。

2023/05/07(日) 12:04:22.46

長々と無駄なレス書いてるやつもいるが、一人で考えたり、いきなり SharePoint とか始めるじゃなくて社内でよく相談することを推奨するよ。
他部署とかでも SharePoint 使ってるならお勧めだが、社内全体が git で染まってるなら自部署だけ違うのを使うのはお勧めしない。
自部署単独ではあまり役に立たなくても全社での交流を考えると有用ということもある。

2023/05/07(日) 13:02:47.23

>>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を布教する面もあるからそのつもりで。

2023/05/07(日) 13:23:48.22

>>520
お前は考えが浅いよ。他の部門やコンサルが git 勧めてる理由をよく聞いて判断すべき。局所最適ではなく全体の最適化に協力すべき。

例えばうちだと、git は画像ファイルや pdf の管理にはあまり役に立たないけど gitlab で管理している。画像作成部門とかからしたら無駄な手間だが、全体として他の素材(プログラムやhtml)と一元管理できるメリットはとても大きい。

git 覚える手間は大きいので推奨はしないが、状況次第。全員が覚える必要はなくて登録担当者（リーダー）だけ使うとかもありえる。

2023/05/07(日) 14:05:32.22

>>521
だからその場合は全社規模の導入チームがやってきて、有無を言わさず導入させられて終わりなんだよ。
下っ端の部署に拒否権なんて無い。
それが分からないのはお前が中規模以上の会社で働いたこと無いからだよ。

> 画像作成部門とかからしたら無駄な手間だが
それは無駄ではないんだよ。鯖に置く画像等はある程度HTML/CSS/JavaScriptとセットなのだから、
それらと密着してるのならプログラム側のgitで一括管理するもの妥当だし、
データとして後で嵌め込むだけなら別管理でDBにブチ込んどけ、でしかない。
つかお前が管理の仕方分かってないだけだろ。
それ、「無駄だ」とか上司やチームメンバーに言ったら呆れられると思うぞ。

> 全員が覚える必要はなくて登録担当者（リーダー）だけ使うとかもありえる。
ねえよ。もし仮にそれやったら、更新作業が全部515に降り積もってきて回らなくなるだけ。
実際、お前の会社の画像作成部門は、リーダーが全部とりまとめてgitに登録するのか？違うだろ。
少なくともgitの導入はbreaking changeで、今現在の業務フローの延長上にはない。
対してSharePointは基本共有鯖に毛が生えただけだから、共有鯖で問題になってきてる程度の状況なら、
ほぼ何も気にせず何も勉強せずに導入できるようになってる（はず)

つか俺は>>516の中身には反対しないぞ。
ただ無理な布教は止めろ、そしてgit以外のことについて無知なのを自覚しとけ、というだけで。
お前らはgitを使ってきてるからsvnを使っておらず、結果、svnの知識は20年前で止まってるだろ。
だから現役でsvn使ってる奴とは話が合わない、それはお前らが不勉強だからだ、って事。

2023/05/07(日) 15:42:28.21

他部署やコンサルが勧めるからgit導入しろとか言ってる奴やば🤭
よっぽど外部の人間信用してるのね

**515** (ﾜｯﾁｮｲ 1610-Z+mA) · 2023/05/07(日) 16:37:14.01

沢山の返答、提案ありがとうございます。参考になりました。
私は「gitの導入は難しそう」という第一印象を抱きました。代替案として挙がったSharePointは現在調査しています。
いただいた情報を元に材料を収集し、次のミーティングで活かそうと思います。

>>518
>他部署がなぜgitを推すのかはちょっと確認した方がいい
gitを推す理由は以下になります
・システム系の部署は、すでにgitを使用しているため賛成
・新しいものが好きな部署も賛成

2023/05/07(日) 16:37:14.91

ただコンサルは基本的に詐欺師だから無視でいいとして、
他部署が何故推してくるのかは一応確認した方がいいとは思うが。
(とは言えその理由を聞かされても今の515では判断付かないとも思うが）

しかし、
> エクセルやワードが使えるだけの人（高齢者や短時間勤務の主婦もいます）
で誰もgit知らないのに導入するのは狂気の沙汰過ぎるし、
521の通り仮に他部署から書類を引っ張るときにgitが便利だからだとしても、プログラマが
> ワードやエクセルで書類を作成したり、電話対応
の関連書類を必要とするケースなんて無いしね。
そもそも電話対応関連書類ってヤバイクレーマーの実名とか入ってるだろうしで、
gitで管理していいものではないし。
(>>515に分かる様に補足すると、gitは分散型の為、本体のコピーが各人の端末内に作られる。
だから情報漏洩はするものだと認識した方がいい。
そもそもオープンソース《いつでもダウンロード出来る》向けの物だから、その辺考慮されてない。
だから例えばその50台のタブレット、出先で落としてデータ抜かれたら、会社の本体データと同じ物がそこにあるので、全部漏れる。
中央集権型でシンクライアントなら、毎回アクセスが必要だけど、電源切ったらその端末にはデータが残らないので、落としても漏れない。
まあgitにもシンクライアントを構成する為のツールは多分あるのだろうけど、その辺は他の人に聞いてみて)

2023/05/07(日) 17:00:11.23

>>524
0.9秒違いで前後してしまったが、
> ・システム系の部署は、すでにgitを使用しているため賛成
> ・新しいものが好きな部署も賛成
これは止めとけ、だな。
前者は自分が勉強するのが面倒だから他人に投げてるだけだし、(これは実際よくあるけど)
後者は有りだしそういう好奇心こそが上達の鍵ではあるが、導入後のメリットが無いからね。

(使ってない俺が言うのも色々おかしいが、覚えてる範囲で言うと)SharePointは下から攻めてて、

第一段階：個人のPC内に各人が管理。
　メリット：何もしなくてもいい
　デメリット：○○さんが居ないと最新版がどこにあるのか分からない、バックアップが大変
第二段階：共通PCまたはサーバで管理。
　メリット：各人の端末から最新版にアクセス出来る、鯖だけバックアップすればいい
　デメリット：誰かが編集中の場合、開けない
第三段階：SharePointで管理。
　メリット：同時に鯖上のExcelやWordが編集出来る、履歴もガッツリ管理出来る、
　　閉じ忘れてる馬鹿がいても何とか出来る（だったはず）

要は第二段階での問題、
順番にしか編集出来ないのと、閉じ忘れて帰った馬鹿がいたら次にそいつが出社するまでどうにもならない、を対策してたはず。
だから多分Excel/Wordの簡易マージ機能を持ってる。(はず)

対してgitはLinuxの「全世界規模で同時開発」という、上から攻めてる状況で、
大は小を兼ねる程度には小にも使える程度。小用では決してないが、他も糞だから使われてるだけ。
君の部署が現在上記の第二段階なら、次はSharePointだと思う。
まさか第一段階なら、まずは第二段階を目指すべき。

2023/05/07(日) 17:06:13.57

前とは別の長文君が誕生してしまった。

2023/05/07(日) 20:34:45.89

>>522
お前が考え方に柔軟性がないのが良く分かった。場所ごとに最適のやり方があるんだよ。
画像部門は納品作業の代わりに git に上げてるだけだから、リーダー数人でチェックして問題なけれpushで十分まわってるよ。全員が使う必要はない。
受け渡しはファイル共有でも何でもできるが、社内が git だから合わせてるだけ。そういう協力もある。

2023/05/07(日) 21:50:56.04

>>528
まあ水掛け論も意味がないので>>515用に纏めると、

515のみが学んで他の人はgitの使い方を知らずに済ます場合、
これまで各自がセーブして業務完了だったところを、全部515がその後commitしてpushしないと完了しなくなる。
528の様に元々業務形態が階層化されてて上位で承認/却下を常に行う構造ならそれでも負担がないが、
一般的なExcel台帳やWord文書って社員各自がセーブして終わりだろ。
それをgit導入後は515が全部commitしてpushしないと終わらない構造になる。

それが嫌なら全員に少なくともcommitとpushまでは出来る様にさせる必要がある。
その教育に何時間かかるかは、515が今まで「サル先生」等でgit学習に何時間かけたか、
或いは今後今俺らがグダグダ言ってる内容をサクッと理解できるようになるまで何時間かかったか、を計測すればいい。
ただ、ExcelやWord文書をマージ機能もないgitでbranch切ってcommitしてpushしても、何もメリット無いけどね。

まあやるのはご自由にだが、
そのシステム部門も君達が作成した文書を日常的に更新チェックする事もないし、意味もないと思うのだけど。
やるにしても、普通に「文書管理システム」のどれかを導入した方がいい気がする。

2023/05/08(月) 00:56:41.88

github desktopなら使いやすい

2023/05/08(月) 20:09:44.72

>>515
まず「よく知らないものには投資しない」というのが大原則。
導入したら最終的にどういう運用になるのか具体的なビジョンが思いつかないなら、git導入に投資してはいけない。

そもそもの話、今の課題が何でこのままだとどういう悪い状況に陥るのか、その状況をどういう状況に改善すればどういう利益を得られるのか、といった基本的な部分はどうなのかね。

具体的なゴールのビジョンも無しに考えても無駄。まずはコンサルにゴールとなる運用のビジョンと利益を説明させるべき(gitうんぬんはその先の話)だけど、>>515の会社の誰も理解していない感じだなぁ。まともな改善プロセスとか手法を勉強しておかないとコンサルのカモになるだけだよ。

2023/05/08(月) 23:26:24.91

今回はシステム部門もコンサルも糞無能なgit信者なのだろう。
とはいえ515がこれを突っぱねるのも多分無理だろう。
なるほど世の中の使えないシステムはこうやって出来上がるのか、とは思う。

5chであれ、とりあえず詳しい人に聞いてみよう、と出来た515を救ってやりたいが、かなり無理だな。
とはいえ、勝手につらつらと馬鹿git信者を論破する鍵を書いてみる。

まずgit信者はgitが万能だと勘違いしてるからこそ何でもgitで、という発想なわけだが、
現実は、「文書管理システム」が百花繚乱であり、git信者はこの矛盾に気づけないほどの低脳でしかない。
という精神論でジャブをかましつつ、そもそもフローが違う、という技術論に持ち込めばいいのではないかと。

>>515の職場でも、メールやチャットは「送信」、ファイルは「保存」しないと他人に変更/追記内容が見えない、
というのは当たり前に認識されてるはず。この「他人に公開」する手続きが、

メールやチャット：送信
ファイルサーバーやSharePoint：セーブ(=保存)
svn：セーブしてcommit
git：セーブしてcommitしてpush

と、プログラミング用のgitやsvnではセーブとは意図的に分離されてる。
これはプログラミングではセーブ後にデバッグが必要であり、実際このデバッグの方が時間もかかる為だ。
そしてcommit(=公開またはその準備）は基本的にはデバッグ完了後の完成品のみで、
共用リポジトリ（=公開サーバ)上での巻き戻しは想定されてない。
公開する前に完成品に仕上げろ、完成品のみ公開しろ、というノリだ。

対して文書、何をやってるのか分からんから勝手にエスパーだが、
「昨日の○○の件、纏めて鯖の○○フォルダに置いておきました。
関係者はチェック願います。そうでない方も軽く目を通しておいてください」
みたいなメールでの通知＋共用ファイルサーバーで情報共有を行っているとき、
まず公開した上でみんなでつついてブラッシュアップし、さらに精度を上げていくことになる。
そして十分と見なされれば決済され、駄目なら差し戻しで書き直しとなる。

2023/05/08(月) 23:26:50.45

この場合、

プログラミング：セーブして一人で「デバッグ」して完成品に仕上げてから、「公開」(commit+push)
　（=完成品のみ公開、未完成なら原則公開してはいけない)
文書：まずみんなに「公開」(=他人に見える状態に)してからブラッシュアップ（=修正=「デバッグ」)
　(=未完成品を公開した上で細部修正して完成させる)

なので、公開とデバッグの順が逆だから、
そもそもプログラミング用のシステムを通常文書に流用するのは無理がある、というより無茶苦茶だ。
そしてgitの場合、公開(=共用リポジトリでcommit済み)の後に上長に却下されて差し戻しで全面書きなおし、
みたいなことは想定されてない。これが日常的に行われたら多分すぐ破綻する。
(差し戻し履歴も全部保持するんだ！なら行けるのかもしれんが…)

そのシステム部門もコンサルも無能な馬鹿なのはほぼ間違いないが、
みんながやらないことには理由があるのだから、その理由を理解出来ないのなら変に突っ込んでいかないことだ。
無料のgitで文書も便利に管理出来るのなら、みんなやってるはずだろ。
実際は無理だからやってないんだよ。
gitの知識が豊富であったとしても、上記の通りフローが逆なのだからどうにも無理。
つか、ほぼ全員がgit使えるIT系の会社でも、ExcelやWord文書をgitで管理してるところは無いんじゃないかと。
いわゆる「ドキュメントを書け」のドキュメントはソースコードと対だから、gitにブチ込むべきではあるが、
実際GitHubにExcel/Wordが載ってるのなんて見たこと無いし。

2023/05/09(火) 00:07:48.25

長文くんとIP同じだな戻ってきたのか
なんかスレ立ててそっち行ってなかったっけ?

2023/05/09(火) 00:11:36.52

いつまで515に壁打ちしてんの？
もう515としては結論出てると言うのに

2023/05/09(火) 00:37:38.37

長文くんとバレると、アレは出来たのかと聞かれてしまうな。

2023/05/09(火) 02:17:09.65

論文はgit管理するけど

2023/05/09(火) 03:37:35.14

>>534
その立てたスレで、プロトタイプつくって公開し
使った人の意見を取り入れて改良するしかないんだから
早くつくれと言われたら、俺は迫害されてると言っていなくなった

2023/05/09(火) 10:33:39.58

>>537
論文ってTeX

2023/05/09(火) 11:39:03.14

>>537
テキストファイルならありなんじゃね

2023/05/09(火) 15:07:22.27

最近は xlsx も docx も text を zip してるだけなのでtext形式でgit管理（git hooks とかで unzip して xmllint とか）も出来なくはない…
初心者にはちょっとハードルが高いが。

2023/05/09(火) 17:30:01.20

>>541
人が目で見て解析できる書き方はされてないから無理じゃないかな、と試みて諦めた事はある。
xlsx は、共同編集できるし、SharePointならバックアップに戻れるしで他所の製品凄いと思っている。

2023/05/09(火) 19:03:05.97

>>539
tex か簡単なときはmd ですね
公開とデバグの順序でgitを使うべきか決めることに違和感があったので文書の例を挙げてみたんです

2023/05/09(火) 21:06:02.48

>>541
自分ですら絶対にやらないことを人に勧めるものではないよ。
ただそもそもExcelには差分表示機能があったはず。

つか、515って普通に背任案件の気がしてきた。
git信者が布教するなら、普通は「『僕が』インストールして回って、教育もしますから、一緒に頑張りましょう」だろ。
全く知らん奴に全部やらせるのは、明らかにおかしい。失敗するに決まってる。

>>543
君が使ってて君がそれでいいんならそうだねとしか。
しかしmdってMarkdownかー。時代は変わるもんだね。
今時HTML手打ちってどんな奴よ？と思ってたが、Wordの代わりに使ってる奴居るのね。

2023/05/09(火) 22:00:19.19

>>544
作るとか言ってたなんとかツールは結局どうなったの?

2023/05/09(火) 22:20:30.89

ズレたコメントするから長文くんてすぐにわかるねw

2023/05/11(木) 13:20:24.80

だって >>515 自体、読んだ瞬間に嘘ネタって分かるもの。

ドキュメントの履歴管理したいならMicrosoft365のSharePointだけで実現できるし、タブレットが
なんか知らんがandroidやiPadなら英語版しかないGitクライアントなんかPC初心者に扱える訳なくて
どんなに無能なコンサルでもGitなんか提案してくる訳ないから。

2023/05/11(木) 13:35:23.92

>>547
「だって」って何なんだろ
話がつながらないんだけど

本当に「読んだ瞬間に嘘ネタって分かる」ようなものなら
スルーするか「嘘ネタ乙」で終わりにすればいいようなものだけど
長文くんらしき人もそうしてないんだよな

2023/05/16(火) 20:12:24.34

Git v2.41.0-rc0

2023/05/20(土) 03:22:53.91

Git v2.41.0-rc1

2023/06/02(金) 21:08:39.93

Git v2.41.0

2023/06/08(木) 21:49:01.57

3点質問させてほしい

次郎と太郎は、Aブランチにチェックアウトしている時に git branch -u origin/A コマンドを実行したことがあるとする。

次郎がまずAブランチにpushをした。

次に、太郎がAブランチの内容をpull(①git pullじゃなくてgit pull originと打ってやる必要がある？？)して、少し変更を加えてAブランチにpushした。

最後に、次郎がAブランチをBブランチにマージしたい。
そのためにローカルリポジトリを最新化する必要があるはず。
②この時、次郎はAブランチにチェックアウトしている状態で、git pull originと打てばいい？それともgit pull origin Aと打たなきゃダメ？

③Aブランチにチェックアウトしている時にgit pull originを実行するとローカルのBブランチも最新化される？

自分で試せばいいじゃんと思う質問もあるかもしれないけど、git初心者すぎていずれも試そうとしたけどよくわからんかった

すまんが知恵を貸してくれ

2023/06/08(木) 22:33:33.64

git fetch origin
git branch -f B origin/B

2023/06/09(金) 00:04:51.74

git は動作をカスタマイズできるのでカスタマイズしてない前提で
① git pull と git pull origin は全く同じ動作。 origin の全ブランチを取得してローカルを更新
➁ git pull origin A は origin からブランチ A だけ取得してローカルのAを更新
➂ 上の2つ見れば分かるだろう

2023/06/09(金) 23:02:05.34

>>554
回答ありがとう
②についてだけど、もしBブランチにチェックアウトしている時にgit pull origin Aとやったら、ローカルのBブランチにoriginのAブランチの内容が反映されるの？

2023/06/10(土) 01:16:50.63

>>555
されない。pull の場合、今どれをチェックアウトしてるかは関係ない。あくまで origin の A を取って来てローカルの A を更新

2023/06/10(土) 01:38:23.55

ややこしいの考える前に基本の使い方を覚えろ。B に A をマージしたいんなら慣れるまでは
git pull （AとBを最新に更新）
git checkout B （Bを対象にする）
git merge A （BにAをマージする）
git push （今更新したBをプッシュ）
としろ。

2023/06/21(水) 08:18:04.06

gitって個人で使ってる分にはなんてことないけど
複数で使うと途端にいろんなトラブル起きるなぁ
ソフトを開発することが仕事なのに、ソースを管理することが目的になってる人もいるくらいw

2023/06/21(水) 08:55:55.22

>>558
別にそんなことないけど

2023/06/21(水) 09:27:39.89

Gitがトラブル起こしてるんじゃなくてGitを運用してる人がトラブル起こしてるんじゃないの
開発規模にもよるとは思うけどただ導入するんじゃなくてある程度運用ルール決めないとみんな自由気ままに使ってめんどくさくなるだけだと思う

2023/06/21(水) 09:41:11.46

>>559
別にそんなことないけど

2023/06/21(水) 10:59:35.25

具体的にトラブルの事例書いてくれ

2023/06/21(水) 12:07:34.93

複数で使う＝低レベルプログラマーが使う
という事ではないから必ずトラブルが起こるなんてことはない

2023/06/21(水) 12:13:40.13

>>558
同感だが、理由は、Gitはパッチ管理ツールであって、ソースコード管理ツールではないからだ。
Gitをソースコード管理ツールとして見た場合、典型的にはGitHubFlowなんて敗北そのものだが、
このスレの連中は信者だからこれにも気づけない。

ただ、パッチ管理ツールとしては極めて優秀だよ。
だから他のろくでもないソースコード管理ツールの代用とされているわけだが、やはり無理がある。
なお、信者は常に「運用が悪い」と考えて「Gitの不備」とは認めないから、このスレでは会話は成立しない。
ネットで言えば、「岡山の用水路」だね。
「落ちる奴が悪い」か「落ちるような構造なのが悪い」か。

2023/06/21(水) 12:24:57.58

>>564
君の使い方の参考になる資料のリンクを下さい。

**デフォルトの名無しさん** (JP 0Hd5-iIiP) · 2023/06/21(水) 12:33:39.30

>>564
お？
WitBucketくんかな？

2023/06/21(水) 14:38:02.37

>>564
長文君はまず自分の仕事したら？

gitがパッチ(変更)管理ツールなのは同意だが、ソフト開発に必要なのは変更管理ツールであって、素人の欲しがるようなソースコード管理ツールではないという点に気付いたら戻って来てね

2023/06/21(水) 14:53:26.93

git は「いつ、誰が、何のために、どこの、何を、どのように」変更したかを管理するツール。
5W1H だな。注目すべきは「何のために」