Git 16©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、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 git的にはどうでもいいと思うけど、ファイルコピーしたという事実をわざわざ履歴に残したいの?意味なくない? >>528
コピーした事実というか、s2.cppからs1時代の履歴を追えるようにする
というのが一番の目的です
現状でも、分割したタイミングで分割したよとメッセージを残しておけば
人間なら内容を理解できるので、そちらを見てくれるとは思います
システム的なルールに限らず、定番のやり方だとか
別ツールで利用するときに相性の良い方法などあるのかな?
と思った次第 >>527
一回で充分
人間は
AをBにcopy
Aを編集
Bを編集
のつもりでも
gitは
AをBにrename
Aを新規作成
Bを編集
だったりする
(必ずこうなる訳ではない)
良きに計らえ >>530
ありがとう
リネーム扱いになるってことは、基本的にはちゃんと追ってくれるってことでいいのかな いまの操作でほぼ確実にログやblameが追跡できているのであれば
多分ほぼベストな方法なんじゃないかと思う 各commitの変更を見たりcheckoutするときとかはSourceTreeの方が便利だなぁと感じる
rebase -iとかfilter-branchを使う時はCLIでやってる 次に出る、2.20では
* "git rebase" and "git rebase -i" have been reimplemented in C.
なんだな。いろいろバグが出そう。 privateなリポジトリに誰がcloneしたか見る機能あります? 孫cloneできるのに意味あるのかな
GitHubやGitLabの監査ログには書かれると思う 個人の開発でパソコン二台で運営してる時、それぞれのパソコンでuser.nameとuser.emailは使い分けるべき? 何を運営してるか知らないけど、2台とも同じユーザが使うならuser.nameとuser.emailも同じでいいでしょ もしかすると、特定の用途のときに優位性を発揮するとかはあるのかもしれないが
すぐには思いつかないなあ .gitattributesで自前のxfuncnameを使おうと思ってるんだけど、xfuncnameの方をリポジトリに設定することって出来ないかな? Git Rev News: Edition 45
https://git.github.io/rev_news/2018/11/21/edition-45/
を読んでたんだけど、開発者紹介で
Developer Spotlight: Elijah Newren
> I’m a husband to the most amazing woman in the world, and a father
> to one son and six daughters. My wife is expecting again,
すげーw。嫁が8人目を妊娠中とかどんだけw
ユタ大学ってことはモルモンなのかな。 >>547
嫁さん大好きなんだろうな。なんかほっこりする jira使ってるところはbitbucket使うし問題ない gitはバージョンアップしなくても使えるからバージョンアップしない 次の次( git 2.22 ? ) あたりで、 git switch ってコマンドができるみたいだな。
git checkout とは似て非なるコマンドのようだ。 マジで?
tortoise gitはswitchって文言をcheckoutのために使ってるからややこしいね stashとcheckoutを合わせたようなニュアンスを感じるが、どんなもん? 最新リリースのバグ対策を進めながら、そのうちいくつかのバグ修正が旧リリースにも必要なことが判明したときとか
同僚が開発してた機能にDBの定義変更があって、自分の担当する機能にも同じ変更の影響があることに後から気付いてSQL周りを貰いたくなったときとか >>567
よそのブランチから良さげな修正だけを持ってくる時に使うくらいかな >>567
きれいなコミット履歴を作りたいときに多用するよ
コミットを終えた汚い(他の人がレビューしづらい、自分で振り返りづらい)ブランチの先端で
別の名前のブランチを作っておき、
やり直したいところで新たなブランチを作り、
そこに汚いブランチから、コミットの順序を入れ替えたり一部のみ取り込んだりするときにチェリーピックを使うよ そのブランチの分岐元でならともかく、先頭でやるなら rebase -i かな。 自分はほとんど使った経験ないけど
revabse -i があることで、割と気楽にコミットできる心理的メリットみたいなのあると思う チームによってrebace派とmerge派があって、
色々難しいお。 revabse vs rebace vs rebase vs merge
ファイッ マージのポリシーの派閥はこのぐらいある
rebase せずに merge --no-ff 派
rebase せずに merge 派
rebase して merge --ff 派
rebase して merge --no-ff 派 branchとcheckoutとcherrypickとrebase -iとmerge全部バンバン使うでしょ >rebase して merge --ff 派
>rebase して merge --no-ff 派
どちらか一方を revabse に汁 所詮は道具なんだし、
必要なときに調べながら使えばいいと思う stashしたらcheckoutできなくなったんですが >>597
stash の pop や apply はコンフリクトする可能性があるから、git status で確認 stageしてない変更を全部消すのってどうやるんでしたっけ? >>601
ありがとうございました
>>602
サーセン
ググってもわからんかった いくらバージョンアップしても今まで以上のことは何もする必要ないからもうバージョンアップしなくていい git reset --hardを最強に高速化してほしい Git 2.21」リリース
2019年2月26日16:30 末岡洋子
https://mag.osdn.jp/19/02/26/163000 gitkで表示されるコミットヘッダに Follows: という直近のタグっぽいものがあるけど、
同じものを表示するコマンドって何?
git log かなと思ってヘルプを探したけどわからなかった。 Follows が前で Precedes が後ろなのね
git describe で直近の tag は分かるけどちょっと挙動が違うし、Precedes は調べられなさそう
git tag --contains の結果をひとつづつチェックして Precedes を、
git tag --no-contains の結果をひとつづつチェックして Follows を、
探してるのかな? GitのwindowsGUIの質問はスレ違い?
普段MercurialでTortoiseHgを使ってるのだが
Gitも触ってみようとTortoiseGitを導入したところ、これが使いにくい
複数のブランチがある状況で、リビジョングラフを見ながらdiffテキストをサクッと見たり、
コミット等を行ったり、リビジョンに復旧したりしたいが
TortoiseHgだと単一ウィンドウですべて収まってできて便利なんだけど、
TortoiseGitは状況の把握と操作が複数のウィンドウにまたがっていて簡単にはできないような気がする
コマンドライン実行をそのままウィンドウ出力にしている感じ
これに文句が出ていないのは、何かうまい使い方があるということ?
(いくつかのウィンドウを開きっぱなしにするのが常識とか)
それともGitとMercurialの考え方の違いからくるものなのか? 文句が出ないのは誰も使ってないから
Git for Windows の方が良い エクスプローラに統合されるのはウザイから亀シリーズは使わないなあ
自分はVisual Studioとgit bashの併用だけど、単体のGUIはSourceTreeが人気らしいね >>617
妙に情報少ないなと思ったがやはりTortoiseGitはマイナーか
ありがとう >>618
SourceTreeいいですね、ありがとう
TortoiseGitは意味わからんな、なぜHG版とここまで使用感が違うのか
歴史的な経緯だろうが SourceTree派だけどお気に入り。
git初めての新米たちにも教えやすくてありがたい。 sourcetreeはインストールして放置してるけど何が強みなんだろうか
ブラウザ(プルリク/マージ)+VSCode+GitLensで出来ない機能ってある? GitLensいいな、もう少しでIntelljIDEAのGit拡張に追いつけそう >>622
VSCodeに依存せずに使えるメリットがある >>616
ログを表示したあとのグラフのウィンドウの左下にある2つのチェックボックスにチェックを入れて
すべてのブランチを表示
プロジェクト全体を表示
を有効にすればよいのでは TortoiseGitめっちゃ気に入って使ってるけどなあ
日本語化するとGitのコマンド名と離れすぎてよく分からなくなるから
英語のまま使うのがいいよ >>622
強みか微妙だけど、gitに絞ったGUIだから初心者には取っつきやすいし操作が覚えやすいと思う。 ■ このスレッドは過去ログ倉庫に格納されています