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 ブランチ作成でファイルを全部コピーするのはVSSぐらいだろ？ GitHubを使ってみたくてGit勉強してるんだけど
GitがGUIで使えるような奴はなんか欠点あるの？Windows環境とかでもCLIでやってる人が多いのはなぜ？ 日常的によく使う操作はIDE使った方が早いけど複雑な処理になったらCUI使わないとできなかったりするね
要は使い分け >>520
逆じゃないかな。
日常的にやってる操作はCUIの方が楽でしょ。
変遷をグラフィカルに表示して一望したかったりする時にGUIが大いに役立つ。 要は使い分けだよ
CUIが必要なければ使わなくていいし
とりあえずはCUIで勉強するのがおすすめ >>521
ほんそれ
CUIで充分
>変遷をグラフィカルに表示して一望したかったり
githubのnetworkで観てるわ >>521
グラフを見るなら
git log --oneline --decorate --graph --branches --tags --remotes
https://qiita.com/imudak/items/4a8549b46fe2e509a08c どうしてもキャラクタ表示じゃなきゃやだっていうこだわりが無けりゃ gitk --all& 一択だね。 初心者です。
長くなったソースファイル(s1.cpp)があり、
このコードの一部を、新規作成したファイル(s2.cpp)に分割したいと考えています。
この時、どのような方法で移行するのがGit的には望ましいのでしょうか。
とりあえず今までは、まず単純にコピーしてコミット、
両方のファイルから不要部分を削除（＋微修正）してコミット、
といった感じで2回コミットしていました。
なお、開発環境はWindows10 Pro、言語はC++、UIはGit Bash、
ホスティングサービスはGitHubを想定しています。 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,
すげーｗ。嫁が8人目を妊娠中とかどんだけｗ
ユタ大学ってことはモルモンなのかな。 >>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 ■ このスレッドは過去ログ倉庫に格納されています
