Git 18
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、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 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>343
branch に 切る をくっつけ始めたやつはセンスない
なぜなら昔から枝を切るという表現はcutの意味で通っているから
英語に疎くて枝や支流のイメージがなかったのかもな
口火を切るや先陣を切るといった言葉にはそれがないので全く問題ない
もちろん既に慣用表現になっていしまった「ブランチを切る」を、慣用であるからという前提のもとに自分も使うという判断は全く問題ない（何度も言うが）
カードを切るという表現が生まれた当時の良し悪しについては昔すぎて情報不足で判断保留だが、カードを物理的に切るのはクレカ等を破棄するときくらいなので、どうあれ枝を切るほどには問題はなさそうだ >>346
その「センスのないマヌケな表現」をずっと疑問もなく使っていた ｱｳｱｳｳｰ Sa39-9B/I
>>325がなかったらその後もずっと使ってたんだろ >>347
そういうこと、そんな笑い話よ
ギガが足りないとかも使ってるわけだしな >>348
ｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケということだな
違和感がないから疑問も持たずに使い続けてたんだろうし
それは「始めたやつ」も同じこと >>349
冷静なタイプかと思ってたけど感情的になってるねw
俺はbranchを切るという使い方をしたことないとうそぶいてたけど
こりゃ実はマヌケ呼ばわりされて激昂しちゃったクチみたいだな >>352
センスのないマヌケはｱｳｱｳｳｰ Sa39-9B/I自身という自虐的な笑い話だったんだろ？
だからたしかにｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケだよねと返しただけ では幹に切り込みを入れて接ぎ木をするという視点はどうだろう
いやもうこの話題終わりにしよ >>348
別に自然だろ
「一千万不渡りの可能性」で通じるだろ
わざわざ一千万円の〜なんて言わなくね 一千万円という特定の額が足りないという例では全然ポイントが違うだろ
むしろこういう感じ
あたし食欲ヤバくて最近キロ余ってる
大きなセンチを私にください
週末にキロ出しすぎてオービス光らせた 一千万不渡りの可能性 に相当するのは 最近5キロ増えた
ギガが足りない に相当するのが 最近キロ余ってる ギガが足りないの「ギガ」は使用可能量に相当する概念だとわかるが
キロ余ってるは何？体重がどう余ってるの？ やれやれ重箱系の難癖だろそれ
3つの例文をそれぞれ否定できない時点で反論したいだけやろ
まあ余りについてあまり議論したくないから例文変えるけど「あたしキロがオーバーして最近ブスだからダイエットしなきゃ」ならどうよ
何にどうオーバーしてるんだとかこれ以上バカのフリはできまい
キロがオーバーしているというのは
体重がオーバーしていると理解できたんだよな
美容の文脈で体重オーバーといえば話者の理想体重に対して超過があるという意味だ
まだほかに難癖あるか？ スレから離れ過ぎるなら、他所で。と言いながら参戦するけど、
ブランチを切るの「切る」はチケットを切るの「切る」とは意味が違うぞ。
チケットを「切る」はチケットに挟みを入れて印をつける意味。
ブランチの「切る」は古くは「幕を切る」とか最近？だと「スタートを切る」のようなニュアンスから派生した「継続する物事を開始する」という意味。派生なので本来の「切る」の意味とは違うが広く受け入れられている表現だ。
誤解しやすいからその表現は良くないとうのも一つの見識だが、センスについては人それぞれなので、ここで議論しても結論は出ないぞ。 >>364
↑
会社にいるよな、
こういうめんどくさい奴
陰で、「またはじまった・・・」なんていわれてそうｗ きしめんやラザニア生地に切れ目入れて半分割いて
それを分枝の始まりとするイメージでいた mergeはリモート追跡ブランチからできるのに、pullとかfetchはリモートブランチじゃないといけないのなんでですか？ >>370
mergeはローカルから参照すればいいのに対して
pullやfetchはリモートを参照する必要があるからじゃね？ >>370
pullやfetchはリモートブランチからローカルに情報取得するためのコマンドだからでは >>371-372
ありがとうございます理解できました
>>373
試してみましたがリモートのブランチを指定しないとだめみたいです
origin/dev と origin devは別物でしょうか？
前者をリモート追跡ブランチとして認識しておりますが 訂正です。
引数にorigin/devを指定するとダメで、origin devならOKということがあるので
origin/dev と origin devは別物であるような気はしています。
いくつかコマンドを実行してみて得られた結果から推理したイメージは
①リモートのdevブランチと最も近い位置にあるローカルのブランチがorigin/dev
②リモートのdevブランチを指すのがorigin dev
といった感じです。
git logをした時に確認できるorigin/devは①のorigin/devと同一であり、これがリモート追跡ブランチだ
という理解であっておりますでしょうか。 origin dev は ローカルの dev ブランチが追跡している「リモート」のブランチ。
origin/dev はそれの「ローカル」コピー。コピーは最新ではない可能性がある。
という言い方をすると良いのかな。 正確に言うと違うのでややこしいな。順番が逆というか。必ずしも origin じゃなくても良いとうか。 リモートリポジトリは、origin以外を使ってみたり、ファイルシステム経由でベアリポジトリを使ってみたりすると理解が深まるね。
インターネット接続不可能な環境だと結構使う。 >>375
別物っちゃ別物だけど。
gitのヘルプを読んだほうがいいよ。
端的に言えば、origin/devは通常、リモート追跡ブランチと言っていいもので、origin devはコマンドに付けた2つの引数。
mergeはローカルレポジトリにあるrefとマージするもの。
fetchやpull(pullはfetch+mergeだから、以下fetchのみ説明する)は、リモートレポジトリにあるrefを、ローカルレポジトリにコピー/ダウンロードしてくるもの。
refは"コミットを指す参照"のこと。
つまり、refはローカルブランチ、リモートブランチ、タグなどのこと。
よく言われるように、ブランチやタグは、コミットへのポインタであるから、refはコミットを指す参照と言った。
refは、各々のレポジトリにルートにある.git/refs/**が実体。(以下.git/を省略)
refはすべてレポジトリごとに保存されている。
git branchコマンドなどでローカルブランチを作ったり、fetchやpushでリモートブランチを作ることができる。 >>380
リモートブランチという名前だけど、特定のレポジトリ(例えばorigin)のrefを、ローカルレポジトリにコピーしたもの。
リモートレポジトリoriginからfetchをすると、originにあるrefs/**をダウンロードしてきて、ローカルファイルシステムに、refs/origin/**として保存する。
fetchをしなければ、最後にダウンロードしたときのままで、リモートレポジトリが他人によって更新されてても、refs/origin/**は自動には更新されない。
いつもrefs/を付けるのは面倒だから、これは省略できる。
ローカルブランチの実体.git/refs/heads/branchAは、branchAのみで通常呼ばれる。
リモートブランチの実体.git/refs/remotes/origin/branchBは、origin/branchBのみで通常呼ばれる。 >>381
merge branchAは、merge refs/heads/branchAの省略形で、後者で書いてもマージできる。
refsであればマージできる。
上に書いたように、refsはリモートレポジトリからコピーしてきたもの(origin/...)と、自分で作ったref(ローカルブランチなど)のことだから、
merge branchAでも、merge origin/branchBでも正しい表現。
そのときそれらが指しているコミットとマージする。 >>382
fetch origin devは、fetch origin refs/heads/dev:refs/remotes/origin/devの省略形で、後者で書いてもfetchできる。
これは、originにある.git/refs/heads/devを、ローカルレポジトリの.git/refs/remotes/origin/devにコピーするということ。
だから、fetch origin develop:devと書けば、originのdevelopを、ローカルにdevという名前で保存することも可能。
ただしトラッキングブランチの設定がある場合は、もう少し前処理が入る。(説明が冗長になるので省略。ただし、ほとんどの場合はリモートトラッキングの設定しているはず。)
ここで、fetch origin/devと書くことが何をしているかは分かりますか？
何を省略しているかを考えれば想像できると思います。
答えは書きませんので、自分で実験するなり考えてみてください。
(普通このコマンドは失敗します。そのようなrefを普通は作らないからです。)
ちゃんと知りたければ、自分でヘルプ読んだほうがいいよ。
push, fetch, pull, refspecなどを読んでみて。 >>383
誤記あったので訂正。
> fetch origin/devと書くことが
→ fetch origin origin/devと書くことが
以上。
ちなみにfetch origin/devは必ず失敗すると思います。
その位置にはrefではなくてリモートレポジトリ名を書くわけだが、origin/devってい名前は作らないと(多分作れない)思うので。試したことないけど。 refspec使った例で、自分がたまにやるやつを紹介して補足すると、
pushの例になるけど、
git push origin @~2:developとかは使うかな。
update update ...っていくつかコミットしたあとに、2つ前までのやつならちゃんと作れてるから、それをpushしておこうなんてときに。
fetch方向だとそういう工夫は必要ないと思うから、追跡してるとおりに取ってきちゃうけど。 あと、上にorigin以外を...って話があるから、自分のユースケース紹介しておくと、
自分だけが使うようなコンフィグファイルの設定とかを、backupっていうリモートレポジトリの名前で、別のフォルダに向けておいて、
git push backup myconfig1とかやることあるかな。
この場合は、リモートブランチとしてbackup/myconfig1っていうのが作られるよ。
リモートレポジトリはoriginだけじゃなくてもよくて、
ローカルレポジトリに、backup/myconfig1はorigin/developと共存してる状態だよ。
ごめんね、自分語りが長くて。 gitクライアントからボタン一つクリックするだけで完了するような操作を、いちいちターミナル立ち上げてタイプしてる人は何？
しかもタイピングが遅いからまどろっこしくて仕方ないw >>387
コマンドでgitを使う=タイピングが遅い
決め付けの激しい人だな そもそも普段からキーボード打つ方が、何十倍も早いだろ。煽るにしてもレベル低すぎ。
それともマウスでプログラム組んでるとか主張するんだろうか？ >>377
origin/devはgit logで表示されるorigin/devと同一という理解であっていますか？
であれば、git logをした際にdevブランチの方がorigin/devよりも上（新しい）に表示されることがあるので
必ずしもorigin devのローカルコピー版であるorigin/devは最新ではない という説明には納得がいきます。
>>381
冒頭に書いてあることは、リモートブランチもリモート追跡ブランチと同様に、ローカルリポジトリ上に存在する という理解でよいですか？ >>388
そうとは言ってないだろ
文書が読めるようになってからレスしろよ 「タイピングが遅い」っていうのは自分のことを指していってるんじゃないかなぁ
たぶんある種の自虐かと いやよく読もう
> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw
タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件 特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ 開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い
そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね >>390
はい。わたしは>>381には、リモートブランチとリモート追跡ブランチが同じ意味で書いてます。
前半は自分にはわからなかったです。
どのorigin/devが、logのorigin/devと同じと言っているんだろう。
origin/devは普通.git/refs/remotes/origin/devの省略形として使われるのであって、
git logの引数の説明に、refspecとかrevisionとか書いてあったらそうだろうと思います。
自分はそういうつもりで使ってますが、ちゃんと知りたいなら調べてみたらどうでしょう？
文脈によっては.git/refs/heads/origin/devかもしれないですね。これは難癖ですが。（つまりorigin/devっていう名前のローカルブランチ。でもコマンドミスで、たまに作ってしまう…） >>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。 >>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。
原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。 >>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索すればリモート追跡ブランチの説明があります。
あと、git help gitで、使えるコマンドの大枠が見れます。
本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。
オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。
ただしこれはツールとしての使い方が主です。 >>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。
origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。
あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。 commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ commitコマンド実行したときにエディタ立ち上がるようにしてないの？ 環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?
ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません 呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。
（注:あくまでデフォルトなので変えることはできる…） ターミナルにコマンド入力してのがかっこいいと思ってる人いる？ >>407==>>387
どんだけコマンド敵視してんだよ 煽り耐性なさすぎだろ…
ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが >>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。 我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う 未だにSVNなんか使ってgit使ってないのはやばいなんて言う方がやばいなんて話題になってたんだけどgitに慣れた身からすると
ローカルでコミットできない、ブランチを気軽に切れない、もうそれだけであまりに不便だと思うんだけど、SVNユーザーはこれをデメリットと感じないのだろうか？ gitのことを知らないんだからsvnのデメリットにも気付かないよ ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末 >>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利 CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね >>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。 あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。 >>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん
それで回るのなら、cvsやめてzip管理でええやん 例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいいだろ、勉強する時間が無駄みたいな >>425
すまん俺が svn 糞 とかでググってるせいだわ >>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない >>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ >>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ
やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ >>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。
あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
https://richlab.org/coterie/tok.html >>440
gitを使ったシステムなんだから別物ではない repoってgithubとかgitlabみたいなもん？ >>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
複数のリポジトリを一括で操作できるのが特徴とか
ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも
個人的にはいらんなぁ 自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし
Android SDKのソース落としてくる時に使ったぐらい ■ このスレッドは過去ログ倉庫に格納されています
