Git 16©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
2017/08/15(火) 00:54:07.61ID:brNIopECE
ソースコード管理を行う分散型バージョン管理システム、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/04/14(日) 10:32:24.84ID:zEHeHyPc0
ffって何？
643デフォルトの名無しさん (ﾜｯﾁｮｲ 067c-grM/ [113.32.86.138])
垢版 |
2019/04/14(日) 12:09:34.47ID:mqiCDUBh0
<< ● □ > >>
2019/04/15(月) 14:36:52.51ID:TQXILdnuM
>>642
git ffで検索ぐらいしろ。
fast forwardの略。
645デフォルトの名無しさん (ﾜｯﾁｮｲ b6ca-o1CB [119.240.132.157])
垢版 |
2019/05/03(金) 01:02:41.49ID:l/s3GWfn0
　個人プロジェクトの管理がにっちもさっちも状態に陥ってきたので、噂のGitを導入しようと勉強開始したのですが。

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

　そうなると、読み始めたオーム社の入門書はどこまで現状に即しているのでしょうか。
　基本的な操作が変更される事はないでしょうが、非推奨とかになる事も考えられるので。
　あと、良い書籍紹介があると嬉しいです。
2019/05/03(金) 01:04:27.23ID:i/xHvCJ+0
>>645
ごちゃごちゃ言わずに手動かさんかいボケェ！
2019/05/03(金) 01:24:21.30ID:D3mIW/FO0
>>645
何も考えずにgit for windows入れたら済む話だと思うよ
cygwinがベースの技術使われてるけど別途インストールする必要はないし
2019/05/03(金) 01:41:14.58ID:m+FxQhlt0
>>645
gitとGitHubは全く別のもの。プロジェクト的には無関係。

gitの本がGitHubについて詳しく書いていることはまずないし、
買収前のGitHub社も、Microsoftも、gitの開発には関わっていないといって良い。
（Git LFSなど一部影響を与えているがコア部分ではない）
649デフォルトの名無しさん (ﾜｲｰﾜ2 FF12-7GOi [103.5.142.235])
垢版 |
2019/05/03(金) 14:16:43.99ID:3Vz/qKohF
javascriptの勉強するためにJava始めました観たいな感じ
2019/05/03(金) 18:32:18.06ID:DMALnIma0
GitHubがGitクライアントのひとつではないということは、エンドユーザーからみればどうでもいいことなのかもしれない
それこそがSaaSの目指すべき透過性のry
651デフォルトの名無しさん (ﾜｲｰﾜ2 FF12-7GOi [103.5.142.234])
垢版 |
2019/05/03(金) 18:38:29.21ID:taX/i1G/F
GitHubはサーバーじゃないのか
2019/05/03(金) 19:20:02.06ID:gopWPGQUd
>>651
githubデスクトップアプリのことを言ってるんじゃないかな
2019/05/04(土) 01:29:13.43ID:IjWp+gdg0
>>646-652
　反応ありがとうございます。
　当方WINDOWSに入る前もファイラ時代が長かったもので、コマンドライン感覚が退化してしまっています。
　深く考えず教本を読破して、その操作を猿真似して馴染む事を目標に作業再開しようと思います。
　指針を与えてくださり、ありがとうございました。
2019/05/04(土) 01:49:51.51ID:PdnPsaxZ0
別に無理して最初からコマンドライン使う必要もないと思うけど
Visual StudioとかVSCodeとかGUIからgit扱えるし
2019/05/05(日) 23:16:29.51ID:wnPGmEim0
git extensions...
656デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/10(金) 23:01:31.97ID:yjXVmj4x0
gitを学ぶだけでも一苦労だ
2019/05/10(金) 23:30:40.02ID:VCdUDnM60
今時gitが使えないとチームで開発できないからプログラミング言語同様必須知識だよ
658デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/11(土) 02:31:02.75ID:ouM2ubYj0
基本的な流れは分かったけど
細かいコマンドやオプションまで入れたらとんでもない量ある
659デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/11(土) 14:30:22.85ID:ouM2ubYj0
https://qiita.com/xtetsuji/items/555a1ef19ed21ee42873
upstreamという名前を付けてるけど
リポジトリ自体に名前がついてるんじゃなくて
リポジトリの利用者側が勝手に名前を付けてるの？

おかしくない？
660デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/11(土) 14:35:55.50ID:ouM2ubYj0
そうすることで名前の重複問題を解決させようとしてるのか
名前空間みたいな概念が無いのか
2019/05/11(土) 14:39:05.89ID:wRpxqjAk0
ローカルリポジトリから見たremoteの名前なんだから勝手につけて当然。originだってそう。
2019/05/11(土) 14:45:36.03ID:D877RybE0
>>659
エイリアスだよ
本当のリポジトリの名前は、URIそのもの
URIは一意なんだから名前空間などなくてもかぶらない
長いから、originとかupstreamという別名を付けてるだけの話
663デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/11(土) 15:11:58.93ID:ouM2ubYj0
git remote -v
でリモートリポジトリの一覧が表示されますが、
push先として設定されているリモートリポジトリを一部削除する事はできますか？
fetch元としては使い続けたい
2019/05/11(土) 21:51:57.68ID:sDkUvWEX0
できる
2019/05/11(土) 22:37:01.91ID:Naxi/oZi0
>>663
https://stackoverflow.com/questions/7556155/git-set-up-a-fetch-only-remote/
666デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/11(土) 23:23:16.58ID:ouM2ubYj0
そのリモートリポジトリはgithubのなんですが
そもそもgithubのリポジトリは権限が無ければ書き込まれないかも、と思ったんですが
合ってますか
2019/05/12(日) 00:15:09.76ID:OoMn1CYl0
そりゃ他人が勝手にウイルスコード埋め込めるわけ無いやろ
668デフォルトの名無しさん (ﾜｯﾁｮｲ 1394-vM1y [123.48.61.181])
垢版 |
2019/05/12(日) 16:25:08.69ID:AJtL4p1I0
いや、できるんじゃないか・・・これ・・・
githubガバガバ
2019/05/13(月) 08:43:03.43ID:+iu2JKCNM
ローカルリポジトリに権限の概念はないぞ。
リモートにpushできるかは権限による。
2019/05/14(火) 12:14:26.51ID:yieIctl/a
Git v2.22.0-rc0
2019/05/21(火) 19:51:06.30ID:ItBIHcGN0
https://www.theregister.co.uk/2019/05/03/git_ransomware_bitcoin/

↑によると、git向けのランサムウェアがあるらしいので、
peffがパッチ投げてたけど、2.22に入るのかな？
2019/05/25(土) 01:07:57.56ID:/gw0C7Kb0
>>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.06ID:MF7hUL6NM
そこまでしてやる必要あるの？
2019/05/25(土) 22:41:08.29ID:4zp+FHVLd
>>673
あるやろ。
いまどきgitじゃないと開発者が寄って来ない。
開発者が居ないOSSは死ぬよ。
2019/05/26(日) 09:21:13.31ID:AhpxmhZJM
「今時」ってそれだけの理由かよ。
開発者だけどどっちでもいいわ
2019/05/26(日) 13:39:03.80ID:n6k+d3Gb0
> 開発者だけどどっちでもいいわ

どっちでもいいってことは、どっちも知ってるはずだけど
違いしてていていってんの？svnとgitの比較言える？
2019/05/26(日) 13:39:30.92ID:n6k+d3Gb0
違い知ってて言ってんの？
2019/05/26(日) 14:28:24.43ID:K3Fa0Jrf0
昔はsvn使ってたけど今更使うのは嫌だよ
679デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/26(日) 16:53:36.40ID:TYT8T/KA0
git cloneしたフォルダをコピペで別の位置に移したら
何か問題出る？
680デフォルトの名無しさん (ｱｳｱｳｴｰ Sae3-LXSb [111.239.35.246])
垢版 |
2019/05/26(日) 17:05:52.30ID:KAaQkTQwa
無問題
681デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/26(日) 17:46:50.08ID:TYT8T/KA0
githubで自分がフォークしてるプロジェクトがあって
他の人もフォークしてて、他の人がその人のリポジトリでやったコミットを本家にPRしてて、
でもマージされてなくて、でも自分のフォークでそれをマージしたい場合、どうすれば？
2019/05/26(日) 17:49:28.34ID:n6k+d3Gb0
そのコミットを自分のフォークにマージするだけ
2019/05/26(日) 20:42:05.66ID:3rn09QiHd
>>675
emacs, ruby など大きなプロジェクトがgit に移行している。
何故移行したか、どんな効果があったか、事例見ると判る話。
2019/05/26(日) 21:11:49.05ID:LR3zsoru0
masterブランチで開発していて、
リリースする時、masterの全部の修正をリリースするんじゃなくて
一部だけリリースする時、リリース用のブランチを作ってそこに
リリースしたいもののみを集めるってやり方でいい？

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

そういった場合、masterにそれを戻さないといけないんだけど、
リリース用のブランチをmasterにmerge戻すと、同じコミットが二重にできちゃうじゃん？
それを防ぐにはどうしたら良い？mergeじゃなくてcherry-pickで戻す？
それともsquashする？（コミット消したくないけど）
それともリリース用のブランチをmasterからの変更にrebaseしてから、masterにマージする（少し面倒そう）
2019/05/26(日) 21:30:20.90ID:gL51xVlRd
git flow使えよ
2019/05/26(日) 21:44:10.79ID:LR3zsoru0
基本個人開発なんでそこまで面倒くさいことはしたくない
今回バグ修正のプルリクが来て、今masterでやってる作業の切りが悪いので
プルリクと先に出せる部分を、先に出したほうがいいなと判断したので
例外的にリリースブランチを切った
2019/05/26(日) 21:48:34.15ID:gL51xVlRd
git flowなんてめんどくさくもなんともないやろ
むしろmasterで開発してるからそんなめんどくさいことになってるんじゃないか
2019/05/26(日) 21:54:45.52ID:LR3zsoru0
github flowへの文句なら、github flowを論破してからにしてくれ
2019/05/26(日) 21:58:46.66ID:LR3zsoru0
説明しなくてもわかると思うが、
一人github flow = レビューする人はいない = ブランチきってその都度一人マージ = masterでの開発と何も変わらん
2019/05/26(日) 22:37:24.14ID:NmjYgqZc0
日本語通じてないわこいつ
2019/05/26(日) 22:40:52.72ID:LR3zsoru0
日本語通じてないのはお前だ。
俺はgit flowが複雑であることは世界共通の認識であることを知っているし、
その事実に関して反論していないし、興味も質問もしていない。
git flowが複雑ではないという話をしたいならよそでやれってこと
2019/05/26(日) 22:45:12.24ID:LR3zsoru0
はっきり言わないとわからないようだから言っておくと

git flowは複雑（事実）だから使わないと言ってる。
git flowは複雑（事実）ではないと主張したいのなら、俺ではなく世界とやってくれ
git flowは複雑（事実）ということは、俺が主張していることではない。
2019/05/26(日) 22:50:04.83ID:NmjYgqZc0
ごめん触れちゃいけないキチガイやったわ
2019/05/26(日) 22:51:42.71ID:LR3zsoru0
>>693もうレスしないでね。

ということで >>684 の質問へのレスよろしく
2019/05/27(月) 00:30:06.46ID:+/xGlUJM0
なんで1回git flowの話からgithub flowの話に逸れたん
2019/05/27(月) 01:48:52.81ID:C+5iEFBW0
git flowとgithub flowの区別も付いてないのは置いといて、複雑なので我流でやりますというなら好きにやればいいんでないの
697デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 02:12:28.92ID:Qfy1TG6f0
githubで本家にPR出して、しかしやりとりのなかで
revertだとか再コミットだとかでヒストリーが伸びて、
本家側は最後の1コミットだけをマージする、ということはできるんだろうか？
698デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 02:35:58.34ID:Qfy1TG6f0
githubでOSSを修正したい場合、
さらにそのOSSをカスタムしたソフトウェアを作りたい場合、
フォークを2つ作るべき？
2019/05/27(月) 02:42:44.37ID:udO0PU000
もし最後の1コミットだけマージできるとして、それにどんな意味があるの?
700デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 02:58:02.56ID:Qfy1TG6f0
例えばコミット1をPR、問題点が指摘される、コミット1をrevertしてコミット2を作る。
このときコミット2だけをマージして欲しい。
ところがgithubの画面上ではコミット1もrevertもコミット2も表示される。
その一連のヒストリーが表示されてしまう。

さらに、PR中に本家の追従をしてマージコミットが入るかもしれない。
701デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 03:17:05.13ID:Qfy1TG6f0
git使うとヒストリーを適切に保つ必要が出てきて
開発が難しくなる
702デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 03:23:35.65ID:Qfy1TG6f0
実際の作業ヒストリーは紆余曲折を経ているわけで、
自分のforkリポジトリにそういうヒストリーがあるのは妥当。
追跡しやすいし。

ところが本家にマージする段階ではヒストリーを圧縮して1コミットにしたい。
でもそんな操作できなかった。
しかもPR中にも紆余曲折してヒストリーが伸びる。
どうやってヒストリーを圧縮すれば？
703デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 03:36:54.35ID:Qfy1TG6f0
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.09ID:M+AjYQS+0
>>695
> なんで1回git flowの話からgithub flowの話に逸れたん

よく見ればわかるが、git flowの話もgithub flowの話もしていない。マージの話
ただ「git flowが複雑で、それよりもシンプルなgithub flowなどがある」のに
git flowが複雑だという事実を知らなそうな人に、git flowを使えと言われたから、
世間の認識を知らないなって思っただけ
2019/05/27(月) 04:01:54.78ID:M+AjYQS+0
>>702
単に本家のコミット（通常はmasterのHEAD）からの
修正へとrebaseすればいいだけ
2019/05/27(月) 04:04:09.92ID:M+AjYQS+0
>>696
> 複雑なので我流でやりますというなら好きにやればいいんでないの

git flowが他のフローに比べて複雑なのは世間で共通している認識なので
その話をすることに意味はない。そのレベルの話はしてない。
707デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 04:53:17.89ID:Qfy1TG6f0
git難しい

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

みたいな。revertダメなんだ、みたいなのが多い。
分かる？gitのために発想を制限される感じ。
作業手順を見通せるようになるには相当な経験を積む必要がある
708デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 04:58:45.67ID:Qfy1TG6f0
しかも人によってrevertした方がヒストリー的に好ましいというかもしれない
でも作業手順上、revertしていいのかは新しい変更内容で動作確認をした後じゃないと
分からないから、revertは自然じゃない。
2019/05/27(月) 05:16:31.13ID:M+AjYQS+0
>>707
> 作業手順を見通せるようになるには相当な経験を積む必要がある

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

だいたいrevertは、みんなが共有しているブランチでやるものであって
個人的なブランチでは使う必要がない
前のコミットが要らなくなったらrebaseして消すのが普通
欲しいのは結果であって、途中の作業報告なんかソースコードの修正の邪魔
（作業報告したけりゃissueでもprでもslackでも好きなところでやればいい）
710デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 06:03:00.33ID:Qfy1TG6f0
”見通せる”の意味が分かってないのか
711デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 06:04:57.03ID:Qfy1TG6f0
作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる
rebaseで履歴を消すというアイデアは同意できない
2019/05/27(月) 06:20:02.37ID:M+AjYQS+0
> 作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる

それ何が目的？何がしたいのかわからない。
2019/05/27(月) 06:21:18.22ID:M+AjYQS+0
>>710
ああだこうだという試行錯誤があると
コードの変更が "見通せない"

あんたの試行錯誤のあとなんかどうでもいい。
結果を見せろ。重要なのは結果だ。
714デフォルトの名無しさん (ﾜｯﾁｮｲ b17c-LXSb [122.215.159.99])
垢版 |
2019/05/27(月) 12:34:48.28ID:cl2rg6uY0
ただのアップロードツールだとしか思ってない人いるみたいだし
そういう人はロダ使えば良いと思うの
715デフォルトの名無しさん (ﾜｯﾁｮｲ 13b9-9b2Z [123.1.16.202])
垢版 |
2019/05/27(月) 12:38:42.12ID:Qfy1TG6f0
コードの変更は本家のヒストリーで分かるから
forkリポジトリに細かい履歴が残っているのは基本的に良い事
2019/05/27(月) 13:03:43.27ID:M+AjYQS+0
>>715
だから試行錯誤の後とコードの変更履歴は別
残すのはコードの変更履歴（みんなに公開する確定した修正の履歴）であって
試行錯誤の履歴（みんなに公開しない確定してない修正の履歴）じゃない

他人が見る価値がないようなものを残したって
見ないんだから意味ないだろ。
それはノイズでしかない
2019/05/27(月) 13:42:14.87ID:w3SoIN+ba
試行錯誤はpushする前にやれよ
2019/05/27(月) 13:45:46.73ID:M+AjYQS+0
>>717
当然pushする前にも試行錯誤するが、
レビューしてもらうためにpushする必要がある。

ただしその内容は確定した変更内容ではないので
全てを残す必要はない
2019/05/27(月) 13:45:59.16ID:qS8fmkRZ0
>>717
わかった
とりあえずpushしておくよ
2019/05/27(月) 13:57:46.15ID:M+AjYQS+0
コミットの内容はあとから見るっていうことを
全く考えてないんだよなｗ


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

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

あと見るだけじゃなくコミット単位でcherry-pickしたりするので
一連の修正がバラバラになってると再利用できなくなる。
2019/05/31(金) 12:48:41.61ID:ULN24Mdma
Git v2.22.0-rc2

先日のLinusからの指摘の修正は入ってない模様。
2019/06/08(土) 08:15:28.17ID:6fTN99E40
Git v2.22.0
2019/06/08(土) 10:46:37.85ID:U30olJT4M
Gitはコミット間違えたとかブランチ名間違えた時の修正がめんどくさい
2019/06/08(土) 10:59:38.65ID:fb9z00+40
>>723
どういう手順で修正してる？
ちょっと書いてみたよ

（どうせやり方知らないくせにって思ってる）
2019/06/08(土) 11:27:18.12ID:0abvY8430
>>723
何に比べてどうめんどくさいの？
2019/06/16(日) 11:58:31.44ID:xdoBotj7a
きっとzipとくらべてだろうな
2019/06/16(日) 12:37:19.10ID:wOx7igShd
>>726
比較にならんな
2019/07/15(月) 00:54:22.25ID:l1Zen+C+0
>>563
>>636
新しいコマンド、 "git switch" と "git restore"　は次の2.23で入る模様。
2019/08/03(土) 11:15:50.66ID:5eRnJvEc0
Git v2.23.0-rc1
2019/08/10(土) 10:25:40.53ID:cKTQ2yHJ0
Git v2.23.0-rc2

Qiita に git switch　/ restore の記事を載せるべくアップを始めた奴いる？
2019/08/10(土) 16:58:57.63ID:LQe3yXk0M
そもそもコマンドライン直接叩くことって少なくね
2019/08/10(土) 19:03:44.35ID:lOB1XgAmd
少なくないよ
2019/08/11(日) 16:00:39.56ID:vvCMvMRm0
そもそもキータ()なんて情弱サイトに書くやつ少なくね
2019/08/11(日) 16:41:38.02ID:1zjD928mM
gistにメモ書きできない人間にキータ(笑)は向いてない
2019/08/13(火) 12:43:02.27ID:VwKU7qro0
Git v2.22.1
736デフォルトの名無しさん (ｽｯｯﾌﾟ Sd03-D+Fm [49.98.158.165 [上級国民]])
垢版 |
2019/08/13(火) 21:01:03.08ID:oBta28P0d
gitの本探してるのだけど
cuiメインでguiの本があまりなくて困っています
いい本知りませんか？
2019/08/14(水) 02:47:20.96ID:GN/ut7360
GUIはいっぱいある上に決定版がないからあんまりないんじゃないの
738デフォルトの名無しさん (ｱｳｳｨﾌ FFf1-FHwm [106.171.68.27])
垢版 |
2019/08/14(水) 13:59:15.84ID:cbEBER6YF
CUI知ってればGUIの本は要らない
逆は偽
2019/08/14(水) 16:34:08.01ID:Q4kX3C+k0
CUIでgitの概念学んだらGUIにほぼそのまま応用できるからGUIの本は不要だわな
740デフォルトの名無しさん (ﾜｯﾁｮｲ e3ad-WJKE [27.139.3.34])
垢版 |
2019/08/14(水) 17:23:57.49ID:SBWKVrUs0
TortoiseGitでのマージが感覚と反対で最初逆にやってしまった
2019/08/15(木) 22:11:23.02ID:DmUAFdIwM
セキュリティの都合上インターネットに繋げない開発環境があって(ファイルを1個やりとりするのは可能、rsync的なことは無理)、手元のマシンとのリポジトリ同期に困ってたんだが
(format-patchとamじゃhashまでは面倒見てくれないしコミット毎の管理になるしで面倒)、
bundleという機能を見つけたんだがすごく便利だな

コミットの範囲は確認しなくちゃいけないけど、push、pullとほとんど同等な感じで使えるね。
2019/08/15(木) 22:16:49.78ID:DmUAFdIwM
git switch/restoreはgit checkoutがコンテキストによって全然違う動作をすることを避けるべくブランチ間の移動はswitch、ファイルをHEADまで戻すはrestoreにしたってことなんだな

確かにcheckoutでやらかしたことあるから嬉しいんだが、switch/restoreに慣れると古いgitにイライラしそうだな。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況