Git 18

2022/04/23(土) 03:25:45.27

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

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

2022/08/25(木) 10:19:53.57

>>466-467
whoyou.txtが復活するのは勘違いしていたみたいすまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。

ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな

2022/08/25(木) 11:07:47.22

>>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる

git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示

2022/08/25(木) 11:08:10.42

git status -v
とかじゃダメなのか？

2022/08/25(木) 11:14:51.48

git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る

2022/08/26(金) 18:45:49.38

たかだかpushするだけなのに、ターミナルからやった方がエモいですか？

2022/08/26(金) 19:07:22.83

エモいと言う言葉の意味がわからない

2022/08/26(金) 19:30:50.57

>>472=>>407

2022/08/27(土) 07:34:04.59

エモいかどうかは知らんけど、ターミナルの方が便利

2022/08/30(火) 12:28:50.29

興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww

2022/08/30(火) 23:04:23.35

まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？

2022/08/31(水) 08:44:21.38

ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ

2022/08/31(水) 08:46:09.80

Git v2.37.3

2022/08/31(水) 12:34:16.47

>>478

最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw

2022/08/31(水) 15:08:11.70

タイムスタンプω
パソコン初心者かよωωω=2πf

2022/08/31(水) 15:34:18.76

gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった

2022/08/31(水) 16:40:45.15

あと、扱うファイル形式的にも難しそう

>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？

2022/09/01(木) 01:20:40.38

>>481
涙拭けよ

2022/09/01(木) 02:02:37.38

タイムスタンプみたいな信用できないものに依存するなよ

2022/09/03(土) 12:08:05.86

https://github.com/zhlynn/zsign
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？

2022/09/03(土) 12:50:36.25

git clone github.com:witwall/mman-win32

2022/09/03(土) 12:56:48.05

>>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → https://github.com/
に読み替えてhttpsでやればいい

2022/09/03(土) 15:32:09.11

>>488
ありがとう

2022/09/04(日) 18:01:40.46

情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども

2022/09/04(日) 18:03:08.45

日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども

2022/09/04(日) 18:09:17.04

いいよ
間違ったとこにpushすることを防げる

2022/09/05(月) 00:07:59.17

おとなしくGUI使えよ

タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ

2022/09/05(月) 01:29:30.11

>>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです

2022/09/05(月) 01:33:50.45

>>494
論破しましたね

2022/09/05(月) 12:14:03.67

論破ww
久々に聞いた、平成かよw

2022/09/05(月) 14:19:44.96

ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるのも過去に完全論破されたのがよっぽど悔しかったんだろうな

2022/09/05(月) 16:50:12.49

ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？

2022/09/05(月) 18:08:18.48

別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？

2022/09/05(月) 19:17:05.40

>>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた

2022/09/05(月) 20:13:32.62

気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる

2022/09/05(月) 23:32:13.90

気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する

2022/09/10(土) 14:36:31.13

>>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok

2022/09/10(土) 17:37:58.38

.gitattributesで.rcファイルをUTF-16LE-BOMに指定してから、git cloneした時にエラーが発生するようになりました
書き方が間違ってるのでしょうか？
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM

.editorconfig
------------------
root = true

[*]
end_of_line = crlf
charset = utf-8
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = false

[*.rc]
charset = utf-16
------------------

.gitattributes
------------------
*.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF

2022/09/10(土) 17:55:34.66

>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？

そもそも、UTF-16LE-BOM を使う事ってある？

普通は、BOM 無しUTF-8 を使う

2022/09/10(土) 18:08:59.50

>>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります

2022/09/10(土) 18:17:08.28

>>505
使う理由があって使ってんのに難癖はやめとけ

2022/09/10(土) 19:58:42.22

>>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？

2022/09/10(土) 20:18:35.22

素直に文字コード変換ソフト使ってからpushしたほうがイイんじゃね？
文字コードの問題は結構根深いとこあるし

2022/09/10(土) 20:23:42.76

情報学部卒IT企業勤務1年目だけどGit難しいよ
よくみんな使いこなせるな
ブランチ切り替えとか発生した瞬間に混乱するわ

2022/09/10(土) 20:25:06.14

とあるブランチで開発を進めていて、pushまで完了していつでもブランチ切り替えできる状態ではあるけど
新しくブランチ切ったからそこで作業してと言われた瞬間パニックになる　ブランチ切り替えすると作業フォルダの中身変わるの緊張するわ

2022/09/10(土) 20:40:06.16

慣れないうちはコミットログやブランチ同士の関係をグラフ表示できるGitクライアントに頼ったほうがいいよ
ミスっても所詮は手元だけだから、適宜リモートにプッシュしてさえいれば操作は大胆にやればいい
ただしプッシュ前のチェックだけは入念に

2022/09/10(土) 21:23:42.21

>>508
リモートの.editorconfigと.gitattributesでUTF-16LE-BOMを指定してるので
.rcファイルもUTF-16LE-BOMで上がっているんじゃないのかな
cloneした.rcファイルはUTF-16LE-BOMになってます

>>510
よくわからないエラーで悩むよ

2022/09/11(日) 01:22:10.61

そもそもutf-16 leを推奨しているMicrosoftがおかしいからな(直す気もないらしい)

>>504
多分もう色々調べてると思うけど、もし見てなかったら参考に

https://developercommunity.visualstudio.com/t/git-failed-to-encode-from-utf-16-le-bom-to-utf-8-w/920369

https://qiita.com/syoyo/items/37a917aa5932f626d5cc

2022/09/11(日) 06:37:15.30

>>514
ありがとうなんだか設定ミスのようだ

× charset = utf-16
〇 charset = utf-16le

× *.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF
〇 *.rc text working-tree-encoding=UTF-16-LE-BOM eol=CRLF

2022/09/11(日) 08:17:11.62

>>510
頭が良い悪いは関係なくて、単に慣れの問題だと思うよ
心配しなくても、そのうち慣れる

2022/09/11(日) 12:15:22.07

ある程度の難しさがあるのは確かだと思うので地図を読むことの得手不得手みたいな適性は何かしらあるかもしれない

2022/09/11(日) 12:17:08.26

けどブランチ切り替えくらいなら慣れだな
分散開発で計画やマージを任せられるとなると人によって難しい

2022/09/15(木) 14:34:12.65

githubの質問ってここで良いのかな？
フォーク基のリポジトリをPublicからPrivateに変更したら、Publicの時にフォークしたユーザーのリポジトリに影響って出る？

2022/09/15(木) 23:28:16.29

>>519
こっちでお願いします

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/

2022/09/16(金) 13:09:50.05

Git v2.38.0-rc0

2022/09/23(金) 16:47:47.90

Git v2.38.0-rc1

2022/09/27(火) 03:57:55.82

c:\gittest\server\proj01
c:\gittest\client\proj01

というフォルダ作って上から下にcloneはできて下のフォルダで完結する操作はできたんだけど
下から上にpushしようとすると失敗する

To c:\gittest\server\proj01
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'c:\gittest\server\proj01'

こういう学習のためのテスト環境ってローカル同士じゃダメなんですか？

2022/09/27(火) 07:59:31.26

bare repositoryになってないとかmaster,developへの直接push不可になってるとか

2022/09/27(火) 09:48:59.09

【Git】bare リポジトリで無いならば、push を受け入れないことを知りました
https://oki2a24.com/2016/10/11/do-not-recive-push-unless-bare-repository/

学習のためだけならreceive.denyCurrentBranchを設定してもいいかもね

2022/09/27(火) 10:14:08.47

不可解な挙動で学習時間や意欲をロスしないためにも普通の構成にしたほうがいいと思う
俺ならserver(bare)とclient1とclient2を作る

2022/09/27(火) 11:33:58.99

そもそもどこからcloneしてきたのか不明だし、こういう質問する奴って情報が不足し過ぎてるような
githubとかにあるようなのをcloneしてpushして失敗しましたとかなら草だがｗ

2022/09/27(火) 13:09:21.05

別にどこからcloneしてきたとか関係ないよ
デフォルト設定だとbareでないレポジトリへpushできないことがあるのは仕様
bareにするとかdenyCurrentBranchは危ないよとかググれば日本語の情報もいっぱいある

2022/09/28(水) 09:04:02.38

Git v2.38.0-rc2

2022/09/28(水) 11:25:13.07

server側をベアで作り直したらうまくいきました
ありがとうございます

なぜ入門書はここら辺を説明してくれずに
まずGitHubのアカウントを作ります。とか言い出してしまうのか

2022/09/28(水) 11:44:27.73

選び方が悪いね
そういう方向性の入門書ならプロジェクトリーダー濱野氏の入門Gitだ
5章「2か所で使う」でバックアップリポジトリをbareで作って云々を解説してる
githubには一切触れていない(と思う)
git clone /pub/repositories/～みたいなローカルマシン内でのcloneを解説してる本は他にあるのかな

2022/10/01(土) 10:02:20.72

Gitをインストールした記憶がないのに、なぜかインストール済みでした。
Git Bashを起動すると、プロンプトが変だし、フォントが小さいし、色付けもされません。
プロンプトは「~>」です。

これはどういうことでしょうか？

2022/10/01(土) 14:10:19.42

それウィルスに感染してる

2022/10/02(日) 17:48:34.37

コミットメッセージについてです
テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が
あるみたいですが、基本的にはどっちを使うべきなんでしょうか？

2022/10/02(日) 18:05:40.19

仕事や既存OSSならチームのルールがあるだろうから先輩に聞け
個人ならどっちでも自分が楽な方でいい
ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、
そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない

**534** (ﾜｯﾁｮｲ c31d-755I) · 2022/10/02(日) 18:30:26.77

>>535
分かりました　ありがとうございます
取り敢えずVSCodeを使っておこうと思います

2022/10/02(日) 18:55:33.63

Vimを使って書くのが正しいやり方です

**534** (ﾜｯﾁｮｲ c31d-755I) · 2022/10/02(日) 19:05:01.56

>>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました

2022/10/02(日) 19:10:39.82

コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。
自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。
コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。

2022/10/02(日) 19:16:22.79

長文したためなくてもバグトラッカーのID書いてあればいいよ
繰り返しになるけどプロジェクト次第

2022/10/02(日) 19:28:14.51

>>539
まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄
コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ

2022/10/02(日) 20:42:06.76

https://git-scm.com/docs/SubmittingPatches#describe-changes
> The log message that explains your changes is just as important as the changes themselves. Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons:
...

2022/10/02(日) 21:53:11.93

>>539
コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが

2022/10/02(日) 21:57:22.79

>>541
ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね

2022/10/02(日) 22:11:44.82

>>543
vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。

2022/10/02(日) 22:30:04.49

コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね
ログもGUIの方が見やすいし、diffもそうだしね

2022/10/02(日) 23:56:46.78

今時Tortoiseはないでしょ
GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、
SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい
普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな

2022/10/03(月) 01:53:25.03

Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの

2022/10/03(月) 11:24:33.95

以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？

2022/10/03(月) 11:33:15.47

gitに関係ないのでこっちで質問してください

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/

**549** (ﾜｯﾁｮｲ c31d-vqPj) · 2022/10/03(月) 16:52:54.84

>>550
分かりました
失礼しました

2022/10/03(月) 17:51:58.05

>>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ

2022/10/03(月) 19:22:26.43

クラーケンでいいっすよ

2022/10/03(月) 23:39:02.11

>>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。

2022/10/03(月) 23:41:51.85

あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。

2022/10/04(火) 08:23:42.03

Git v2.38.0

2022/10/04(火) 11:25:30.61

TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット

2022/10/04(火) 13:18:54.26

TortoiseGitはシェルエクステンションの時点でインスコする気失せる

2022/10/04(火) 15:00:17.58

git使うなら開発者が愛用してるEmacsのmagitを使おうぜ

2022/10/05(水) 08:43:21.48

GUIクライアントならForkおすすめ

2022/10/05(水) 22:35:11.78

そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。

2022/10/06(木) 18:25:19.94

fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。

2022/10/06(木) 18:28:48.47

女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。

2022/10/06(木) 18:57:50.90

使い方が分からないという話？
それともソース管理がイマイチ分からない話？

2022/10/06(木) 19:20:02.27

なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。

2022/10/06(木) 19:26:53.11

>>565
知らんがな。
Git採用を決定したヤツに言えよ。

2022/10/06(木) 19:37:44.16

決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません