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/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コミットだけをマージする、ということはできるんだろうか？

2019/05/27(月) 02:35:58.34

githubでOSSを修正したい場合、
さらにそのOSSをカスタムしたソフトウェアを作りたい場合、
フォークを2つ作るべき？

2019/05/27(月) 02:42:44.37

もし最後の1コミットだけマージできるとして、それにどんな意味があるの?

2019/05/27(月) 02:58:02.56

例えばコミット1をPR、問題点が指摘される、コミット1をrevertしてコミット2を作る。
このときコミット2だけをマージして欲しい。
ところがgithubの画面上ではコミット1もrevertもコミット2も表示される。
その一連のヒストリーが表示されてしまう。

さらに、PR中に本家の追従をしてマージコミットが入るかもしれない。

2019/05/27(月) 03:17:05.13

git使うとヒストリーを適切に保つ必要が出てきて
開発が難しくなる

2019/05/27(月) 03:23:35.65

実際の作業ヒストリーは紆余曲折を経ているわけで、
自分のforkリポジトリにそういうヒストリーがあるのは妥当。
追跡しやすいし。

ところが本家にマージする段階ではヒストリーを圧縮して1コミットにしたい。
でもそんな操作できなかった。
しかもPR中にも紆余曲折してヒストリーが伸びる。
どうやってヒストリーを圧縮すれば？

2019/05/27(月) 03:36:54.35

squashするとマージした人がAuthorになるという記事があったが
コミットした人になると言ってる記事もあるな

https://qiita.com/ko-he-8/items/94e872f2154829c868df#squash-and-merge
＞この時、マージコミットSのAuthorはBになります

https://qiita.com/pshiko/items/1e9acd114b7e85884866
＞最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまった

2019/05/27(月) 03:55:13.09

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

よく見ればわかるが、git flowの話もgithub flowの話もしていない。マージの話
ただ「git flowが複雑で、それよりもシンプルなgithub flowなどがある」のに
git flowが複雑だという事実を知らなそうな人に、git flowを使えと言われたから、
世間の認識を知らないなって思っただけ

2019/05/27(月) 04:01:54.78

>>702
単に本家のコミット（通常はmasterのHEAD）からの
修正へとrebaseすればいいだけ

2019/05/27(月) 04:04:09.92

>>696
> 複雑なので我流でやりますというなら好きにやればいいんでないの

git flowが他のフローに比べて複雑なのは世間で共通している認識なので
その話をすることに意味はない。そのレベルの話はしてない。

2019/05/27(月) 04:53:17.89

git難しい

コミット内容に問題があり修正したい
→修正＆動作確認成功
→前のコミット内容は単に要らなくなったからrevertしよう
→作業ディレクトリで変更されているせいでエラー
→じゃあrevertじゃなくて新たなコミットで

みたいな。revertダメなんだ、みたいなのが多い。
分かる？gitのために発想を制限される感じ。
作業手順を見通せるようになるには相当な経験を積む必要がある

2019/05/27(月) 04:58:45.67

しかも人によってrevertした方がヒストリー的に好ましいというかもしれない
でも作業手順上、revertしていいのかは新しい変更内容で動作確認をした後じゃないと
分からないから、revertは自然じゃない。

2019/05/27(月) 05:16:31.13

>>707
> 作業手順を見通せるようになるには相当な経験を積む必要がある

gitは作業手順を見せるもんじゃないよ。
変更履歴を見せるのであって、作業履歴を見せるものじゃない。
あんたが一日こういうふうに頑張りましたっていう報告はいらない
欲しいのは結果

だいたいrevertは、みんなが共有しているブランチでやるものであって
個人的なブランチでは使う必要がない
前のコミットが要らなくなったらrebaseして消すのが普通
欲しいのは結果であって、途中の作業報告なんかソースコードの修正の邪魔
（作業報告したけりゃissueでもprでもslackでも好きなところでやればいい）

2019/05/27(月) 06:03:00.33

”見通せる”の意味が分かってないのか

2019/05/27(月) 06:04:57.03

作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる
rebaseで履歴を消すというアイデアは同意できない

2019/05/27(月) 06:20:02.37

> 作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる

それ何が目的？何がしたいのかわからない。

2019/05/27(月) 06:21:18.22

>>710
ああだこうだという試行錯誤があると
コードの変更が "見通せない"

あんたの試行錯誤のあとなんかどうでもいい。
結果を見せろ。重要なのは結果だ。

2019/05/27(月) 12:34:48.28

ただのアップロードツールだとしか思ってない人いるみたいだし
そういう人はロダ使えば良いと思うの

2019/05/27(月) 12:38:42.12

コードの変更は本家のヒストリーで分かるから
forkリポジトリに細かい履歴が残っているのは基本的に良い事

2019/05/27(月) 13:03:43.27

>>715
だから試行錯誤の後とコードの変更履歴は別
残すのはコードの変更履歴（みんなに公開する確定した修正の履歴）であって
試行錯誤の履歴（みんなに公開しない確定してない修正の履歴）じゃない

他人が見る価値がないようなものを残したって
見ないんだから意味ないだろ。
それはノイズでしかない

2019/05/27(月) 13:42:14.87

試行錯誤はpushする前にやれよ

2019/05/27(月) 13:45:46.73

>>717
当然pushする前にも試行錯誤するが、
レビューしてもらうためにpushする必要がある。

ただしその内容は確定した変更内容ではないので
全てを残す必要はない

2019/05/27(月) 13:45:59.16

>>717
わかった
とりあえずpushしておくよ

2019/05/27(月) 13:57:46.15

コミットの内容はあとから見るっていうことを
全く考えてないんだよなｗ

あとから見る時、見なくても良いものがたくさんあったら
本当に見なければ行けないものがどれかわからなくなる。

あとから見るということを全く考えてないから
記録だけしていればいいと間違った考えになる

あと見るだけじゃなくコミット単位でcherry-pickしたりするので
一連の修正がバラバラになってると再利用できなくなる。

2019/05/31(金) 12:48:41.61

Git v2.22.0-rc2

先日のLinusからの指摘の修正は入ってない模様。

2019/06/08(土) 08:15:28.17

Git v2.22.0

2019/06/08(土) 10:46:37.85

Gitはコミット間違えたとかブランチ名間違えた時の修正がめんどくさい

2019/06/08(土) 10:59:38.65

>>723
どういう手順で修正してる？
ちょっと書いてみたよ

（どうせやり方知らないくせにって思ってる）

2019/06/08(土) 11:27:18.12

>>723
何に比べてどうめんどくさいの？

2019/06/16(日) 11:58:31.44

きっとzipとくらべてだろうな

2019/06/16(日) 12:37:19.10

>>726
比較にならんな

2019/07/15(月) 00:54:22.25

>>563
>>636
新しいコマンド、 "git switch" と "git restore"　は次の2.23で入る模様。

2019/08/03(土) 11:15:50.66

Git v2.23.0-rc1

2019/08/10(土) 10:25:40.53

Git v2.23.0-rc2

Qiita に git switch　/ restore の記事を載せるべくアップを始めた奴いる？

2019/08/10(土) 16:58:57.63

そもそもコマンドライン直接叩くことって少なくね

2019/08/10(土) 19:03:44.35

少なくないよ

2019/08/11(日) 16:00:39.56

そもそもキータ()なんて情弱サイトに書くやつ少なくね

2019/08/11(日) 16:41:38.02

gistにメモ書きできない人間にキータ(笑)は向いてない

2019/08/13(火) 12:43:02.27

Git v2.22.1

2019/08/13(火) 21:01:03.08

gitの本探してるのだけど
cuiメインでguiの本があまりなくて困っています
いい本知りませんか？

2019/08/14(水) 02:47:20.96

GUIはいっぱいある上に決定版がないからあんまりないんじゃないの

2019/08/14(水) 13:59:15.84

CUI知ってればGUIの本は要らない
逆は偽

2019/08/14(水) 16:34:08.01

CUIでgitの概念学んだらGUIにほぼそのまま応用できるからGUIの本は不要だわな

2019/08/14(水) 17:23:57.49

TortoiseGitでのマージが感覚と反対で最初逆にやってしまった

2019/08/15(木) 22:11:23.02

セキュリティの都合上インターネットに繋げない開発環境があって(ファイルを1個やりとりするのは可能、rsync的なことは無理)、手元のマシンとのリポジトリ同期に困ってたんだが
(format-patchとamじゃhashまでは面倒見てくれないしコミット毎の管理になるしで面倒)、
bundleという機能を見つけたんだがすごく便利だな

コミットの範囲は確認しなくちゃいけないけど、push、pullとほとんど同等な感じで使えるね。

2019/08/15(木) 22:16:49.78

git switch/restoreはgit checkoutがコンテキストによって全然違う動作をすることを避けるべくブランチ間の移動はswitch、ファイルをHEADまで戻すはrestoreにしたってことなんだな

確かにcheckoutでやらかしたことあるから嬉しいんだが、switch/restoreに慣れると古いgitにイライラしそうだな。

2019/08/17(土) 13:59:47.08

Git v2.23.0

2019/08/17(土) 14:06:00.48

Highlights from Git 2.23
https://github.blog/2019-08-16-highlights-from-git-2-23/

2019/08/20(火) 07:47:09.82

resetも分割しろや

2019/08/31(土) 14:48:50.96

>>736
GUIなんていらない
CUIなら必要なレポート簡単に書けるでしょ
git log --name-status --pretty=format:"Xxx Yyy Zzz" |foo|bar|baz...

2019/09/04(水) 11:14:25.75

サブプロジェクトを使ったことがありません。
現プロジェクトの3つの派生プロジェクトを始めるることになりました。共通のソースは9割です。此の場合は、共通のソースをサブプロジェクトに移して使用するのが良いのでしょうか

2019/09/04(水) 11:15:55.34

747はサブプロジェクトじゃなくてサブモジュールの誤りです

2019/09/04(水) 11:36:25.80

逆じゃね

2019/09/04(水) 22:15:50.21

これからも派生が増えてくならそれでいいけど、あまり増えないなら、ブランチで管理するかな。

2019/09/05(木) 12:35:53.77

>>747
管理体制次第だな。
普通はブランチ管理じゃない？
共通ソースの管理者が別にいるならモジュール化も検討するけど、そこまで大きなプロジェクトならgitプロフェッショナル必要な気がする。

2019/09/06(金) 11:38:49.20

>>747です。
ご意見ありがとう。　変更が多いのは共通部分なんでブランチで管理すると他のブランチへのマージを忘れそう。

2019/09/07(土) 16:54:15.29

今後マージするかどうかは運用次第として、一旦ブランチはしておけば良い
ブランチしたのをマージしない運用にするのは簡単だけど、ブランチしないで分離したプロジェクトをマージするのは面倒くさい

2019/09/13(金) 16:19:53.06

保守

2019/09/20(金) 14:19:09.55

個人開発者です。
2年前までlocalでgitコマンドを使ってた。
その後、開発から離れてたんだけど、再度戻ってきた。

昨日からGithubへpushする様になって、色々勉強中。
ヨロピコ！

2019/09/20(金) 14:22:02.16

>>755
ちなみに参考になったのは、
実践Git、第4章
Web+DB Magazine vol. 50(2009)、はじめてのGit

Pro Gitって参考になる？

2019/09/20(金) 16:41:54.43

ProGitが一番

2019/09/20(金) 17:48:25.26

>>757
>ProGit
thx

iPadで読もうとSendToKindleってメールサービスでmobiファイル送ってみた。

ドキドキしながらKindleで同期すると本が来た。
ヨカっタァ。

しかし、すごいボリュームの本だ。

2019/09/20(金) 17:59:22.84

tree object
commit object
のデータ構造を理解した。

coutesy of WEB+DB vol.50

2019/09/20(金) 18:00:13.71

>>758
最近使い始めたAir Dropってので送ろうとしたらNGだった。

2019/09/20(金) 18:05:22.67

GitHubだけど
パソコンのwebブラウザで
new repository
は出来るのに
スマホのwebブラウザだと
new repository
のボタンが出て来ないのはなぜ？
あとクライアント(コンソール)からコマンドで
new repository
ってどうすれば出来る？

2019/09/20(金) 18:28:21.02

ここ良いね
https://git-scm.com/book/ja/v2

2019/09/20(金) 18:49:06.23

https://codenotfound.com/github-add-remote-git-gui-windows.html

2019/09/20(金) 19:32:07.56

>>761
俺もlocalのterminal.appで作業する際、remote(Github)にnew repositoryを作製する方法を知りたい。

多分、出来ないのかな？

2019/09/20(金) 19:40:20.88

pythonとかでスクレイピングでもすればいけるかもしれないが
最近はgithubも二段階認証になって色々面倒なことに

2019/09/20(金) 19:40:59.16

>>764
出来ない理由
terminal.appでnew repositoryできるとすると、数万のrepositoryがbotによって作製されるかもしれない。

shell scriptを書いてやれば、そういった嫌がらせも出来てしまう。
それは避けたいので、ボタンを使ったUIになってるのでは？◀New Repositoryが。

あくまで俺の妄想っす。

2019/09/20(金) 19:45:03.18

markdownで書いた、図入りのテクニカル文書を管理したいんだけど、blogでは色々面倒で、GitHub使おうかと思うんだけど、良いかなぁ？

ソースコードのsyntax highlightが出来て、imageも埋め込めるmarkdownを管理したいんだけど。

それとも、便利なblogサイトある？
livedoor blogをsyntax highlight plugin付きで試したら、大なり小なり記号＜、＞をエスケープしないとsource codeを表示できないので、ガッカリなのだ。

2019/09/20(金) 19:49:37.03

GitHub GistにMarkdown文書を置いた時に、imageファイルってどうやって管理すれば良いのだ？

imgurとかに置いて、url指定するってのがbest practice?

2019/09/20(金) 19:56:01.52

>>768
ここにいくつか解法が示されてる。
https://gist.github.com/Tatzyr/3847141

しかし、
GitHub上のフォームで画像をコピペするとGitHubのS3にアップロードされ、URLがはりつきますよ。

これは、どう言う操作の事だ？

2019/09/20(金) 20:05:34.11

>>769
そう言う事かぁ。
https://gist.github.com/kannankumar/4c613cac6d9db896062a16e1cc57d3e5

2019/09/20(金) 20:13:29.14

gistに貼り付けたmarkdown中にimage貼り付けたけどresize出来ん。
https://gist.github.com/uupaa/f77d2bcf4dc7a294d109
ここにresizing howto記載されてるが、Gistでは効果無し。

<img>タグを使えば上手くresizeされるんだけど、![](url)形式で書きたい。

2019/09/21(土) 09:19:25.03

ここまで酷い自演は久々に観た