Git 17
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、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 15 http://mevius.2ch.net/test/read.cgi/tech/1486239735/ Git 16©2ch.net https://mevius.5ch.net/test/read.cgi/tech/1502726047/ - VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured 特定のバージョンが必要なら一旦それ入れれば良いだけだろ 要は変換できる環境で変換してしまえばできたものを持ってくればそれで良いんだから おお、皆さんコメントありがとうございます。 >>749 CVSを無くすことが目的の一つでもあるんです。 で、変更履歴が見れることも必要です。 >>750 SVN経由ですか。 できるなら避けたいですが、ちょっと調べてみます。 >>751 その通りなんですが、CVSからの移行をサブシステムごとに行うので、それなりの期間(多分1年以上)変換できる環境を維持する必要があるんです。 いろいろありがとうございました。 全ての要件を満たしてというのは難しそうですね。 いただいた意見を参考にもうちょっと検討します。 git cloneする時にsshのurl指定でBranchまで指定する事って出来るの? -bとか使わないで >>753 それ出来ないと思う 海外サイトで@でブランチ指定とか/でブランチ指定とかでやれるって書いてあるサイトも見つけたけど 実際やって見ても全然上手くいかねぇ ガチでない用途、雑多スクリプト集とかは平気で半年コミットしてないのとかあるんですけど ローカルディレクトリをスキャンして最終編集日 - 最終コミット日の数字が多い順に表示して いい加減コミットするか編集内容破棄するかしろと警告してくれるツールとかないですか リモートのHEADをリモートのdevelopを参照させるようにしたいのですがやり方がさっぱりわかりません。 とても単純なことのように思えるのですがどの方法でやってもSourceTreeなどでクローンするとmaster参照してて困ってます。 origin/HEAD -> origin/master 教えてくださいお願いいたします。 こうなってます .git]$ ls COMMIT_EDITMSG HEAD branches description index logs packed-refs FETCH_HEAD ORIG_HEAD config hooks info objects refs というか僕何か勘違いしてるかも。 要はSourceTreeでクローンしたとき最新のコミットをHEADが参照してほしいのです。 そうしないと上に登ってってチェックアウトしないとだから。 shallow clone(--depth 1)で特定コミットの指定な git cloneにdepth指定はできるが 同時に指定できるのはタグやブランチ名だけで SHA1で過去のコミット一つだけみたいな指定はできない なぜかgit fetchではSHA1指定とdepthの組み合わせが出来るらしい 解せぬ >>99 番号割り振ればできるだろ、知恵を絞れよ 何のために頭付いてるんだ、大学生にもなってなんだその頭の悪さは gitのせいか、gitのせいでそんなに頭の悪い人間になってしまったんだな ようし、gitを禁止します ブランチ切り忘れてコミットしまくったあとに 過去にさかのぼってブランチを作成して 全部そこで作業していたことにしたいんだけど どうしたらいいかな? 今いる場所でブランチを作成 元のブランチはリセット 間違ってコミットしまくったブランチをまだpushしてないなら コミットしまくった最後のコミットで新しいブランチ作って 間違ってコミットしまくったブランチの方を「git reset --hard origin/間違ったブランチ」とかすれば良いだろ? git bashでlsの実行結果が文字化けしたらコレ export LANG=$(locale -uU) echo "export LANG=$(locale -uU)" > %USERPROFILE%\.bashrc 知っている方いたら教えてください。 CVSからGitに移行しようとしてます。 開発にはEclipseを使っていて、今はEclipseのプラグインでCVSと連携しています。 Git用にはEGitというプラグインが必要ということはググってわかりました。 EclipseでEGitを使う場合ローカルPCにGitの導入は別途必要ですか? ネットで見た例だと、EGitで直接GitHubのリポジトリを指定してたんだけど、EGitを使えばリモートのリポジトリに直接アクセスすることになって、ローカルにリポジトリは作らない(なので、Gitの導入は不要)という理解であってますか? 事前に試せる環境がないため、経験者のかたがいれば教えてもらいたいです。 >>771 gitはローカルリポジトリでコミットしてからリモートリポジトリにプッシュする二段階の仕組みなので、ローカルにgit「クライアント」は必要。(gitクライアントにローカルリポジトリを操作する機能が存在する) >>772 ちょっと補足。 Egitは使ったこと無いからは詳しく無いけど、解説とか見るとEgit+eclipseで一通りのgit操作はできるみたい。ただ、gitの仕組みとして(通常の利用方法だと)必ずローカルリポジトリを使うので、ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。 逆に、gitはリモートリポジトリ無しでローカルリポジトリのみの運用というのができるから、まずはそれで色々と試したら? >>771 Eclipseを使ったことはないが、こんなのを見つけた https://www.casleyconsulting.co.jp/blog/engineer/223/ >EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。 https://wiki.eclipse.org/EGit/FAQ >What are the main differences between original Git and JGit(EGit)? >>771 egitは現在のeclipseに含まれています。 別途PCにgitのインストールは不要です。 >>772 ,773,774,775,776 ああ、こんなすぐに親切なレスがいっぱい!! > ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。 そうですよね。だからGit本体も必要じゃないかと思ってたんです。 >EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。 Gitそのものではないけど、Gitと同じ動きをするJGitが使われているという事ですかね。 それでEclipse+Git関連の記事でもGitのインストールについて特に触れる必要がないと。 で、今時のElipseならEGitもついてくるんですね。Pleiadesのサイト見ましたが、確かにEGitもパッケージされてますね。 JGitでググってみたら紹介してくれたwikipedia以外にも日本語で紹介/解説しているサイトがいろいあるみたいなので、まずはそちらで勉強してみます。 モヤっとしてたのがスッキリしました。 またここで追加質問しちゃうかもしれませんがよろしくお願いします。 個人で開発してる場合に、subversionと比較してGitのほうが優れていることってどんなことがありますか? Git使ってみてるんですが、ローカルリポジトリとリモートリポジトリに別れてるのが面倒くさく感じてしまうんです。 個人でやってるならリモートリポジトリを使う必要ないよ 別の場所にバックアップしたいときだけ稀にプッシュしておいてもいいかな程度 Gitはブランチ開発が圧倒的に便利 次バージョンの開発をしながら、ヤバいバグを見つけたらスイッチして現行リリースにパッチを当てるなんて作業がやりやすい コミット等の操作を間違えたときの復元方法も充実してるからガンガンコミットするスタイルが身についてロスがない あまりにも小規模な開発しかしてないならGitに移行したところで便利さに気付かないかもね svnはもう使わなくなってから何年も立つけど、ローカルブランチ作るのに全コピーが発生する問題は改善されたん? gitは瞬間的にローカルブランチ作れることが、当時、最大のメリットだと個人的には感じてたけど svnも物理コピーしてるわけじゃなくポインタをコピーしてるだけだからそこは別にデメリットではないと思う ローカルで何でもできるのとrebaseできるのが大きいな。 --filter=blob:noneでcloneしたレポで久しぶりにpullすると remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (1/1), 334 bytes | 334.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (1/1), 413 bytes | 413.00 KiB/s, done. が延々続く .git/configのpromiser=trueとpartialclonefilter=blob:noneを消すと秒で終わる これは仕様? >>792 git使うとmsに握られるというのが意味不明なんだが gitとgithubの区別がつかない人がMSアレルギーをこじらせている姿はもう見飽きた 情報のアップデートをできずに屈折した持論を垂れ流すから老害の部類かな すぐキレるLinusも若手から老害と言われてるんだろうな。 プライベートなリポジトリをローカルにcloneしようとしたら 重いファイル(15MB程度)だけ弾かれる・・どうして・・ ちなみに学習済みの.h5ファイル 何か制限緩和するような手続きしないといけないのかな (ただ、google経由だと全部cloneできた) 全然わからん・・ 10年程昔からの自作のフリーウェアを git で公開しようとしているんだけど あまり昔の version はもう環境が変わっていて動かない 動くものだけを公開した方が良いのかな それとも最新のものだけにした方がいいですか gitの変更履歴より細かい単位で変更を戻したいとき、うまい方法はありますかね。 例えば一つのファイルの中で3つの関数を変更してコミットした後、1つの関数だけ 元に戻したくなった場合などに。 >>804 git rebase 1 2 3 ← ここで止める 4 5 1 2 3.1 3.2 3.3 ← こんな感じにコミット git rebase --continue でリベース完了 あと慣れたら 2つの関数だけコミットして、 1つは戻ればいい >>804 pushする前ならcommit amend して修正してからrebase。 push後なら新たにcommit。 >>807 わかりづらいな……試してないけど …56 3関数commit abc……master ここをchechout -b mod …56 3関数commit abc……master [mod:2関数commit] 元に戻してcommit amend …56 3関数commit abc…… mod abc……[master] masterをchechoutしてmodにrebase ただし、コミットを他人と共有済みなら混乱の元なので禁止。 >>804 履歴改変をするわけじゃないんだよね?それならば、 git revert -n でindexに三つの関数の修正を打ち消す修正を持ってきて、git reset -p でindexの余分な修正を取り除いて、git commit どうも>>804 です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは 可能です(よね?) なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。 例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく? アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回 同じ変更を入力したくはないし危険... とかなんとか。 >>812 だから何をしたいのかはっきりしろ pushしてないのは分かった pushしてないローカルな履歴を改変したいのか? pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか? >>812 変更の用意はrevert -nとreset -pでいいだろ この2つを使えば自分でコードを入力する必要は無い >>812 だから>>806 だって rebaseで過去の歴史の途中に戻って そこでコミットを分けるなりして 再び歴史を再生する もう面倒くさいから一か所もどしましたってコミットしたらいいやん >>818 必要なのは結果だけ お前が試行錯誤した後なんかどうでもいい >>817 そのコミットを簡単に作る方法が知りたいのだと思う >>820 Winmergeをdiffツールに設定して git windiff HEAD^^^ で戻してcommitだな俺なら >>812 そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第 いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す >>812 そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。 機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。 追えてないけど、どれか。 ・そもそもコミットきれいにしても結局使わないから作り直さない ・頻繁にコンパイル?して頻繁にコミットしておく ・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。 ・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。 コミットをセーブ機能だと思うからだめなんだよ 袋だと思え袋 コードを書くたびに適切な袋に入れろ >>825 ・追加機能ごとにブランチ切る も追加で。 最近では、機能ブランチは問題を先送りにしているだけだという批判もある 機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには マージの失敗でトラブルが起こることは日常茶飯事だったね それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね 何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める 互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし こういうコミットをしてたとして $ git log --oneline commit_id_5 やっぱり××を復活させる(2021/05/01) commit_id_4 □□を修正(2021/04/01) commit_id_3 ××を削除(2021/03/01) commit_id_2 △△を修正(2021/02/01) commit_id_1 〇〇を修正(2021/01/01) 「commit_id_3 と commit_id_5 を消して、コミットログをきれいにした状態でリモートブランチにpushする」というようなことは可能ですか? こういう場合にgit rebaseが使われるんですかね? >>832 ありがとうございます てか真上に同じような質問ありましたね… >>831 俺は作りながら片付ける 作ってる途中で、この修正はこのコミットに含めよう などと考えならが小さくコミットし 適度なタイミングでrebaseする >>831 別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ これだとrebaseは不要 gitもcvs,svnと同じ運命をたどるだろう 私の企業は次世代バージョン管理システムfossilに切り替えました 次世代って書いてるけどGitやMercurialと同期だね 統合が特徴みたいだけど、少なくとも統合指向=先進的というのは言えない 昔のMSや古いエンタープライズシステムが通ってきた道 >>844 gitを業務で使われている方は翻訳に参加してください すみません、git pushをこっそりキャンセルしたく $ git reset --hard HEAD^; git push -f origin HEAD をしたのですが To prevent you from losing history, non-fast-forward updates were rejected. と言われてpushが失敗します。 もしかしてリポジトリの設定でこういう強制pushが禁止されていたりしますかね? サーバー側の receive.denyNonFastForwards の設定で禁止されてる >>848 git push --delete 〜 でリモートブランチ消してpushしなおせばまだワンチャンある ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる