Git 16©2ch.net

2017/08/15(火) 00:54:07.61

ソースコード管理を行う分散型バージョン管理システム、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 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/

VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

2019/02/20(水) 23:08:56.76

stashしたらcheckoutできなくなったんですが

2019/02/20(水) 23:46:11.50

Git v2.21.0-rc2

2019/02/21(木) 08:33:26.35

>>597
stash の pop や apply はコンフリクトする可能性があるから、git status で確認

2019/02/24(日) 10:34:56.98

stageしてない変更を全部消すのってどうやるんでしたっけ？

2019/02/24(日) 12:47:14.02

git checkout .

2019/02/24(日) 14:21:29.00

ググればわかることを聞く奴って伸びないだろうね

2019/02/24(日) 14:55:48.22

>>601
ありがとうございました
>>602
サーセン
ググってもわからんかった

2019/02/25(月) 02:37:37.21

>>600
git checkmate

2019/02/25(月) 08:05:24.26

https://github.blog/2019-02-24-highlights-from-git-2-21/

2019/02/25(月) 19:24:20.46

Git v2.21.0

2019/02/25(月) 22:03:49.04

いくらバージョンアップしても今まで以上のことは何もする必要ないからもうバージョンアップしなくていい

2019/02/25(月) 22:16:05.40

いや、どんどんバージョンアップして欲しい

2019/02/25(月) 23:10:10.00

git reset --hardを最強に高速化してほしい

2019/02/27(水) 19:57:33.46

Git 2.21」リリース
2019年2月26日16:30 末岡洋子
https://mag.osdn.jp/19/02/26/163000

2019/02/27(水) 22:57:51.85

git punish

2019/03/10(日) 05:51:26.31

>>569
Duy が　git restore と　git switch の新しいパッチを3/8 に投げてる。

https://public-inbox.org/git/20190308101655.9767-1-pclouds@gmail.com/T/#t
https://public-inbox.org/git/20190208090401.14793-1-pclouds@gmail.com/T/#t

2019/03/13(水) 19:45:06.23

gitkで表示されるコミットヘッダに Follows: という直近のタグっぽいものがあるけど、
同じものを表示するコマンドって何？
git log かなと思ってヘルプを探したけどわからなかった。

2019/03/14(木) 03:04:50.39

Follows が前で Precedes が後ろなのね
git describe で直近の tag は分かるけどちょっと挙動が違うし、Precedes は調べられなさそう
git tag --contains の結果をひとつづつチェックして Precedes を、
git tag --no-contains の結果をひとつづつチェックして Follows を、
探してるのかな？

2019/03/14(木) 21:01:53.07

なるほど、単純な話じゃないんだ。ありがとう。

2019/03/17(日) 11:01:38.58

GitのwindowsGUIの質問はスレ違い？
普段MercurialでTortoiseHgを使ってるのだが
Gitも触ってみようとTortoiseGitを導入したところ、これが使いにくい

複数のブランチがある状況で、リビジョングラフを見ながらdiffテキストをサクッと見たり、
コミット等を行ったり、リビジョンに復旧したりしたいが
TortoiseHgだと単一ウィンドウですべて収まってできて便利なんだけど、
TortoiseGitは状況の把握と操作が複数のウィンドウにまたがっていて簡単にはできないような気がする
コマンドライン実行をそのままウィンドウ出力にしている感じ

これに文句が出ていないのは、何かうまい使い方があるということ？
（いくつかのウィンドウを開きっぱなしにするのが常識とか）
それともGitとMercurialの考え方の違いからくるものなのか？

2019/03/17(日) 11:57:46.78

文句が出ないのは誰も使ってないから

Git for Windows の方が良い

2019/03/17(日) 12:52:22.96

エクスプローラに統合されるのはウザイから亀シリーズは使わないなあ
自分はVisual Studioとgit bashの併用だけど、単体のGUIはSourceTreeが人気らしいね

2019/03/17(日) 12:58:06.43

>>617
妙に情報少ないなと思ったがやはりTortoiseGitはマイナーか
ありがとう

2019/03/17(日) 13:16:52.36

>>618
SourceTreeいいですね、ありがとう

TortoiseGitは意味わからんな、なぜHG版とここまで使用感が違うのか
歴史的な経緯だろうが

2019/03/17(日) 13:59:24.87

SourceTree派だけどお気に入り。
git初めての新米たちにも教えやすくてありがたい。

2019/03/17(日) 14:50:59.86

sourcetreeはインストールして放置してるけど何が強みなんだろうか
ブラウザ(プルリク/マージ)+VSCode+GitLensで出来ない機能ってある？

2019/03/17(日) 15:36:09.20

GitLensいいな、もう少しでIntelljIDEAのGit拡張に追いつけそう

2019/03/17(日) 17:22:15.96

>>622
VSCodeに依存せずに使えるメリットがある

2019/03/17(日) 18:02:48.69

>>616
ログを表示したあとのグラフのウィンドウの左下にある2つのチェックボックスにチェックを入れて
すべてのブランチを表示
プロジェクト全体を表示
を有効にすればよいのでは

2019/03/17(日) 18:04:30.30

TortoiseGitめっちゃ気に入って使ってるけどなあ
日本語化するとGitのコマンド名と離れすぎてよく分からなくなるから
英語のまま使うのがいいよ

2019/03/17(日) 23:35:46.09

>>622
強みか微妙だけど、gitに絞ったGUIだから初心者には取っつきやすいし操作が覚えやすいと思う。

2019/03/18(月) 18:36:16.77

>>620
どちらかと言うとTortoiseHgが特殊。

2019/03/18(月) 22:16:45.63

Mercurial使ってる人まだいたのか

2019/03/18(月) 22:56:00.46

そりゃまだsvn使ってる現場さえも珍しくないですからね

2019/03/18(月) 23:52:50.82

>>630
その理屈はおかしい

svnはgitが出る前の標準だった。使ってる所は多かったので今も残ってるだろう。
そしてsvnの次として、同時期に似ているコンセプトで git or mercurial がでてきた。
すぐにgitが勝利したので、mercurialを使ってる所は少ないままだったはずだ。

2019/03/19(火) 02:10:00.72

>>631の謎理論が面白かったので俺も謎理論を展開してみる

svnからgitやmercurialに移行する動機は大いにあってもmercurialからgitに移行する動機はさほどなく、場合によっては新しくmercurialを採用することもありうる
となるとsvnユーザーは出涸らし状態であり、svnよりmercurialの方がユーザー数が多いと言える

2019/03/19(火) 02:35:08.23

？
ユーザー数や検索トレンドの推移を見ればどの理屈が事実に最も近いかわかると思うんだが

2019/03/19(火) 04:00:18.53

>>632
svn -> mercurial ・・・初期に僅かに移行。その一部はgitに移行。最初から少なく更に減っている。
svn -> git ・・・殆どがこのケース。多い
svn ・・・どちらにも移行できない所がまだ残ってる。移行したとしてもgit

mercurialに移行した所よりも、svnのまま移行できない所の方が多いので
mercurialのユーザーは少ないよ。

2019/03/19(火) 07:29:51.60

facebook は mercurial 使ってるはず
google も独自 vcs で、git をメインには使っていない

2019/03/20(水) 21:20:50.51

What's cooking in git.git　に　switch と restore について記載来た。

> Two new commands "git switch" and "git restore" are introduced to
> split "checking out a branch to work on advancing its history" and
> "checking out paths out of the index and/or a tree-ish to work on
> advancing the current history" out of the single "git checkout"
> command.

早くて　2.23 あたりかなー

2019/03/20(水) 21:36:01.21

>>450
GCCのgit への移行は

昨年末に

GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang
https://www.phoronix.com/scan.php?page=news_item&;px=GCC-Reposurgeon-Py-To-Go-90

って記事が出て、さらに数か月かかるのかと思っていたら、

https://gcc.gnu.org/wiki/GitMirror
を見ると readonly ではアクセスできる模様。

2019/03/21(木) 16:53:08.88

gitattributesとeditorconfigで文字コードと改行コードが二重管理になってしまった
どっちかを移譲にできないものか

2019/04/02(火) 22:45:02.75

git flowについてと、実際の運用に適用する時について教えてください。
一次開発が終わりリリース済みのシステムがあります。今後二次開発があり、開発開始時期は同じですが、顧客テスト（例えば6/1、7/1、8/1）、本番リリース（例えば6/20、7/20、8/20）の時期が異なる機能が複数あります。

一次開発終了時点をmasterブランチ、二次開発用にdevelopブランチまでは作成しました。
今後開発する際は、developブランチから機能ごとにfeatureブランチを作成し、顧客テスト時はテストを行う機能（featureブランチ）をdevelopブランチにマージする運用が良いのでしょうか？（顧客テストokならdevelopをmasterにマージ）

気になっているのは、先に8/1顧客テスト用の機能を作った場合、マージしない（できない）ままのブランチが発生するのが良いのかわからないことです。

プルリクは使用しない想定です。

良い案があれば教えてもらえると助かります。

2019/04/03(水) 02:16:59.33

その3つの機能が依存関係が少なくてパラレルに開発した後にマージするので問題が起こりにくいのか、
それとも依存関係があってシリアルに開発、もしくは互いを調整しながら開発してしないといけないのかで違いそうな気がする。
前者ならはじめにブランチ作ってdevelopにマージしてテストすればよいと思うけれど、
後者ならdevelopブランチ1本で開発していってテストのときだけ
その時点でdevelop顧客テスト用のブランチを切ってテスト対応はそっちで行って
developにマージする、とかが良いような気がする

2019/04/03(水) 07:04:24.17

git flowならreleaseブランチを作ろうよ
8/1顧客テストの機能をdevelopにマージしたいけど前の機能がまだmasterにマージできていないので無理、という状況を避けられる
リリースのタイミングが多少変わった程度でブランチ設計を見直さずに済む

2019/04/14(日) 10:32:24.84

ffって何？

2019/04/14(日) 12:09:34.47

<< ● □ > >>

2019/04/15(月) 14:36:52.51

>>642
git ffで検索ぐらいしろ。
fast forwardの略。

2019/05/03(金) 01:02:41.49

　個人プロジェクトの管理がにっちもさっちも状態に陥ってきたので、噂のGitを導入しようと勉強開始したのですが。

　現在オーム社の『入門git』(初版平成21年／第9刷平成25年)を読んでいるのですが、途中まで読んでやや古い書籍である事に気が付きました。
　当方Windows10なのでGitHubがMS社に買収された事だし導入もかなり簡単になってるかな・・・と思ったら、CygwinとMSYSへの記述があって、思ってたのと違うと改めてネットで調べ直したのですが。
　>>1の関連サイトの"Pro Git - Table of Contents"によれば違う分類による方法が幾つかあるみたいですね。

　そうなると、読み始めたオーム社の入門書はどこまで現状に即しているのでしょうか。
　基本的な操作が変更される事はないでしょうが、非推奨とかになる事も考えられるので。
　あと、良い書籍紹介があると嬉しいです。

2019/05/03(金) 01:04:27.23

>>645
ごちゃごちゃ言わずに手動かさんかいボケェ！

2019/05/03(金) 01:24:21.30

>>645
何も考えずにgit for windows入れたら済む話だと思うよ
cygwinがベースの技術使われてるけど別途インストールする必要はないし

2019/05/03(金) 01:41:14.58

>>645
gitとGitHubは全く別のもの。プロジェクト的には無関係。

gitの本がGitHubについて詳しく書いていることはまずないし、
買収前のGitHub社も、Microsoftも、gitの開発には関わっていないといって良い。
（Git LFSなど一部影響を与えているがコア部分ではない）

2019/05/03(金) 14:16:43.99

javascriptの勉強するためにJava始めました観たいな感じ

2019/05/03(金) 18:32:18.06

GitHubがGitクライアントのひとつではないということは、エンドユーザーからみればどうでもいいことなのかもしれない
それこそがSaaSの目指すべき透過性のry

2019/05/03(金) 18:38:29.21

GitHubはサーバーじゃないのか

2019/05/03(金) 19:20:02.06

>>651
githubデスクトップアプリのことを言ってるんじゃないかな

**645** (ﾜｯﾁｮｲ b6ca-o1CB [119.240.132.157]) · 2019/05/04(土) 01:29:13.43

>>646-652
　反応ありがとうございます。
　当方WINDOWSに入る前もファイラ時代が長かったもので、コマンドライン感覚が退化してしまっています。
　深く考えず教本を読破して、その操作を猿真似して馴染む事を目標に作業再開しようと思います。
　指針を与えてくださり、ありがとうございました。

2019/05/04(土) 01:49:51.51

別に無理して最初からコマンドライン使う必要もないと思うけど
Visual StudioとかVSCodeとかGUIからgit扱えるし

2019/05/05(日) 23:16:29.51

git extensions...

2019/05/10(金) 23:01:31.97

gitを学ぶだけでも一苦労だ

2019/05/10(金) 23:30:40.02

今時gitが使えないとチームで開発できないからプログラミング言語同様必須知識だよ

2019/05/11(土) 02:31:02.75

基本的な流れは分かったけど
細かいコマンドやオプションまで入れたらとんでもない量ある

2019/05/11(土) 14:30:22.85

https://qiita.com/xtetsuji/items/555a1ef19ed21ee42873
upstreamという名前を付けてるけど
リポジトリ自体に名前がついてるんじゃなくて
リポジトリの利用者側が勝手に名前を付けてるの？

おかしくない？

2019/05/11(土) 14:35:55.50

そうすることで名前の重複問題を解決させようとしてるのか
名前空間みたいな概念が無いのか

2019/05/11(土) 14:39:05.89

ローカルリポジトリから見たremoteの名前なんだから勝手につけて当然。originだってそう。

2019/05/11(土) 14:45:36.03

>>659
エイリアスだよ
本当のリポジトリの名前は、URIそのもの
URIは一意なんだから名前空間などなくてもかぶらない
長いから、originとかupstreamという別名を付けてるだけの話

2019/05/11(土) 15:11:58.93

git remote -v
でリモートリポジトリの一覧が表示されますが、
push先として設定されているリモートリポジトリを一部削除する事はできますか？
fetch元としては使い続けたい

2019/05/11(土) 21:51:57.68

できる

2019/05/11(土) 22:37:01.91

>>663
https://stackoverflow.com/questions/7556155/git-set-up-a-fetch-only-remote/

2019/05/11(土) 23:23:16.58

そのリモートリポジトリはgithubのなんですが
そもそもgithubのリポジトリは権限が無ければ書き込まれないかも、と思ったんですが
合ってますか

2019/05/12(日) 00:15:09.76

そりゃ他人が勝手にウイルスコード埋め込めるわけ無いやろ

2019/05/12(日) 16:25:08.69

いや、できるんじゃないか・・・これ・・・
githubガバガバ

2019/05/13(月) 08:43:03.43

ローカルリポジトリに権限の概念はないぞ。
リモートにpushできるかは権限による。

2019/05/14(火) 12:14:26.51

Git v2.22.0-rc0

2019/05/21(火) 19:51:06.30

https://www.theregister.co.uk/2019/05/03/git_ransomware_bitcoin/

↑によると、git向けのランサムウェアがあるらしいので、
peffがパッチ投げてたけど、2.22に入るのかな？

2019/05/25(土) 01:07:57.56

>>637
ESR Switches To Threadripper But His GCC SVN-To-Git Conversion Could Still Take Months
https://phoronix.com/scan.php?page=news_item&;px=ESR-Threadripper-GCC-Git

gccのsvnからgitへの変換はまだ数ヶ月かかるらしい。

2019/05/25(土) 17:03:27.06

そこまでしてやる必要あるの？

2019/05/25(土) 22:41:08.29

>>673
あるやろ。
いまどきgitじゃないと開発者が寄って来ない。
開発者が居ないOSSは死ぬよ。

2019/05/26(日) 09:21:13.31

「今時」ってそれだけの理由かよ。
開発者だけどどっちでもいいわ

2019/05/26(日) 13:39:03.80

> 開発者だけどどっちでもいいわ

どっちでもいいってことは、どっちも知ってるはずだけど
違いしてていていってんの？svnとgitの比較言える？

2019/05/26(日) 13:39:30.92

違い知ってて言ってんの？

2019/05/26(日) 14:28:24.43

昔はsvn使ってたけど今更使うのは嫌だよ

2019/05/26(日) 16:53:36.40

git cloneしたフォルダをコピペで別の位置に移したら
何か問題出る？

2019/05/26(日) 17:05:52.30

無問題

2019/05/26(日) 17:46:50.08

githubで自分がフォークしてるプロジェクトがあって
他の人もフォークしてて、他の人がその人のリポジトリでやったコミットを本家にPRしてて、
でもマージされてなくて、でも自分のフォークでそれをマージしたい場合、どうすれば？

2019/05/26(日) 17:49:28.34

そのコミットを自分のフォークにマージするだけ

2019/05/26(日) 20:42:05.66

>>675
emacs, ruby など大きなプロジェクトがgit に移行している。
何故移行したか、どんな効果があったか、事例見ると判る話。

2019/05/26(日) 21:11:49.05

masterブランチで開発していて、
リリースする時、masterの全部の修正をリリースするんじゃなくて
一部だけリリースする時、リリース用のブランチを作ってそこに
リリースしたいもののみを集めるってやり方でいい？

そしてリリース用のブランチをリリースするわけだけど、
そこにはmasterに入れてないコミットが含まれる。
READMEの修正とか

そういった場合、masterにそれを戻さないといけないんだけど、
リリース用のブランチをmasterにmerge戻すと、同じコミットが二重にできちゃうじゃん？
それを防ぐにはどうしたら良い？mergeじゃなくてcherry-pickで戻す？
それともsquashする？（コミット消したくないけど）
それともリリース用のブランチをmasterからの変更にrebaseしてから、masterにマージする（少し面倒そう）

2019/05/26(日) 21:30:20.90

git flow使えよ

2019/05/26(日) 21:44:10.79

基本個人開発なんでそこまで面倒くさいことはしたくない
今回バグ修正のプルリクが来て、今masterでやってる作業の切りが悪いので
プルリクと先に出せる部分を、先に出したほうがいいなと判断したので
例外的にリリースブランチを切った

2019/05/26(日) 21:48:34.15

git flowなんてめんどくさくもなんともないやろ
むしろmasterで開発してるからそんなめんどくさいことになってるんじゃないか

2019/05/26(日) 21:54:45.52

github flowへの文句なら、github flowを論破してからにしてくれ

2019/05/26(日) 21:58:46.66

説明しなくてもわかると思うが、
一人github flow = レビューする人はいない = ブランチきってその都度一人マージ = masterでの開発と何も変わらん

2019/05/26(日) 22:37:24.14

日本語通じてないわこいつ

2019/05/26(日) 22:40:52.72

日本語通じてないのはお前だ。
俺はgit flowが複雑であることは世界共通の認識であることを知っているし、
その事実に関して反論していないし、興味も質問もしていない。
git flowが複雑ではないという話をしたいならよそでやれってこと

2019/05/26(日) 22:45:12.24

はっきり言わないとわからないようだから言っておくと

git flowは複雑（事実）だから使わないと言ってる。
git flowは複雑（事実）ではないと主張したいのなら、俺ではなく世界とやってくれ
git flowは複雑（事実）ということは、俺が主張していることではない。

2019/05/26(日) 22:50:04.83

ごめん触れちゃいけないキチガイやったわ

2019/05/26(日) 22:51:42.71

>>693もうレスしないでね。

ということで >>684 の質問へのレスよろしく

2019/05/27(月) 00:30:06.46

なんで1回git flowの話からgithub flowの話に逸れたん

2019/05/27(月) 01:48:52.81

git flowとgithub flowの区別も付いてないのは置いといて、複雑なので我流でやりますというなら好きにやればいいんでないの

2019/05/27(月) 02:12:28.92

githubで本家にPR出して、しかしやりとりのなかで
revertだとか再コミットだとかでヒストリーが伸びて、
本家側は最後の1コミットだけをマージする、ということはできるんだろうか？