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 >>492
あるよ。（だからマージされた後自動テストを走らせる）
例えば一つのブランチで、ファイルの上の方に
#define VALUE 100 という定義を追加する。
ずっと下の方で、VALUEを参照したコードを書く。
もちろんテストは通る
別のブランチで、ファイルの中頃に
#define VALUE 200 という定義を追加
そのすぐ下で、VALUEを参照したコードを書く
もちろんこれもテストは通る
この２つをマージすると
#define VALUE 100
#define VALUE 200
VALUE=200を期待しているコード
VALUE=100を期待しているコード
となる。
gitに限らずどんなものでもブランチ単体では問題ないし、
コンフリクトも起こさずにマージできるが、
テストに失敗してしまうことはある >>490
むしろロックでの開発が分からんって話なんだけど
テキストファイルを一回の作業で一個だけ編集する
ブランチは無し
って状況でも無けりゃ使えなくね
さらに
VSSは複数のファイルを同時にコミットみたいな機能が無いみたいに書いてあったけどまじ？ >>495
人間から見た操作的には同時コミット（チェクイン）可能ではあるが、履歴は基本的にRCS/CVS的なファイル単位の差分管理のみ。 Now available: Git for Windows 2.19, including experimental built-ins for rebase and stash that make them both much, much faster! https://gitforwindows.org/ 共有用なんかで作るベアレポジトリって、中身はHEADとかbranch/とかばかりで、実際に管理しているファイルは入ってませんよね
git ls-filesしても、なにも出てきません
そのベアレポジトリで管理されてるファイルの一覧を見る方法を教えてください
cloneすると、管理しているファイルもclone先に作成出てきますが、そうて'はなく、コマンド等で確認したいです Git 2.14.5, 2.15.3, 2.16.5, 2.17.2, 2.18.1, and 2.19.1 CVSとかsubversionでブランチを作るのはgitに比べると遅いといわれる理由は何なんや
gitではブランチはコミットオブジェクトを指すだけの参照だから、ブランチを作成するには、コミットオブジェクトを書き込むだけで済むから高速というのはわかる
一方CVSやsubversionではブランチをどうやって作ってるんや(´・ω・`) CVSは知らんがsubversionのブランチってほぼファイルコピーみたいなもんだからじゃない？ svnはブランチ作るだけなら言うほど遅くないと思うがな。
ブランチ作った時点では差分がないからファイル内容はコピーされないで参照ができるだけだよ。
それでもgitよりやることは多いだろうけど、ブランチ作るのもリモートリポジトリ操作だからってのが一番大きいんじゃないかな。
CVSはRCSというdiffファイルで世代管理するツールがベースになっている。
リポジトリもRCSそのままのdiffファイルに毛が生えたようなテキストファイルの束だから遅いと聞けばそりゃまあそうだろうと思う。
当時のPC環境が今より数段遅かったというのもあるがローカルで使っても遅かった。 >>507
subversionはブランチはリモートに作るもの
ローカルだけでは作れないので遅いし
ネットワークがつながってないと使えない ブランチ作成でファイルを全部コピーするのは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 に汁 ■ このスレッドは過去ログ倉庫に格納されています
