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 >>620 どちらかと言うとTortoiseHgが特殊。 そりゃまだsvn使ってる現場さえも珍しくないですからね >>630 その理屈はおかしい svnはgitが出る前の標準だった。使ってる所は多かったので今も残ってるだろう。 そしてsvnの次として、同時期に似ているコンセプトで git or mercurial がでてきた。 すぐにgitが勝利したので、mercurialを使ってる所は少ないままだったはずだ。 >>631 の謎理論が面白かったので俺も謎理論を展開してみる svnからgitやmercurialに移行する動機は大いにあってもmercurialからgitに移行する動機はさほどなく、場合によっては新しくmercurialを採用することもありうる となるとsvnユーザーは出涸らし状態であり、svnよりmercurialの方がユーザー数が多いと言える ? ユーザー数や検索トレンドの推移を見ればどの理屈が事実に最も近いかわかると思うんだが >>632 svn -> mercurial ・・・ 初期に僅かに移行。その一部はgitに移行。最初から少なく更に減っている。 svn -> git ・・・ 殆どがこのケース。多い svn ・・・どちらにも移行できない所がまだ残ってる。移行したとしてもgit mercurialに移行した所よりも、svnのまま移行できない所の方が多いので mercurialのユーザーは少ないよ。 facebook は mercurial 使ってるはず google も独自 vcs で、git をメインには使っていない What's cooking in git.git に switch と restore について記載来た。 > Two new commands "git switch" and "git restore" are introduced to > split "checking out a branch to work on advancing its history" and > "checking out paths out of the index and/or a tree-ish to work on > advancing the current history" out of the single "git checkout" > command. 早くて 2.23 あたりかなー >>450 GCCのgit への移行は 昨年末に GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang https://www.phoronix.com/scan.php?page=news_item& ;px=GCC-Reposurgeon-Py-To-Go-90 って記事が出て、さらに数か月かかるのかと思っていたら、 https://gcc.gnu.org/wiki/GitMirror を見ると readonly ではアクセスできる模様。 gitattributesとeditorconfigで文字コードと改行コードが二重管理になってしまった どっちかを移譲にできないものか git flowについてと、実際の運用に適用する時について教えてください。 一次開発が終わりリリース済みのシステムがあります。今後二次開発があり、開発開始時期は同じですが、顧客テスト(例えば6/1、7/1、8/1)、本番リリース(例えば6/20、7/20、8/20)の時期が異なる機能が複数あります。 一次開発終了時点をmasterブランチ、二次開発用にdevelopブランチまでは作成しました。 今後開発する際は、developブランチから機能ごとにfeatureブランチを作成し、顧客テスト時はテストを行う機能(featureブランチ)をdevelopブランチにマージする運用が良いのでしょうか?(顧客テストokならdevelopをmasterにマージ) 気になっているのは、先に8/1顧客テスト用の機能を作った場合、マージしない(できない)ままのブランチが発生するのが良いのかわからないことです。 プルリクは使用しない想定です。 良い案があれば教えてもらえると助かります。 その3つの機能が依存関係が少なくてパラレルに開発した後にマージするので問題が起こりにくいのか、 それとも依存関係があってシリアルに開発、もしくは互いを調整しながら開発してしないといけないのかで違いそうな気がする。 前者ならはじめにブランチ作ってdevelopにマージしてテストすればよいと思うけれど、 後者ならdevelopブランチ1本で開発していってテストのときだけ その時点でdevelop顧客テスト用のブランチを切ってテスト対応はそっちで行って developにマージする、とかが良いような気がする git flowならreleaseブランチを作ろうよ 8/1顧客テストの機能をdevelopにマージしたいけど前の機能がまだmasterにマージできていないので無理、という状況を避けられる リリースのタイミングが多少変わった程度でブランチ設計を見直さずに済む >>642 git ffで検索ぐらいしろ。 fast forwardの略。 個人プロジェクトの管理がにっちもさっちも状態に陥ってきたので、噂のGitを導入しようと勉強開始したのですが。 現在オーム社の『入門git』(初版平成21年/第9刷平成25年)を読んでいるのですが、途中まで読んでやや古い書籍である事に気が付きました。 当方Windows10なのでGitHubがMS社に買収された事だし導入もかなり簡単になってるかな・・・と思ったら、CygwinとMSYSへの記述があって、思ってたのと違うと改めてネットで調べ直したのですが。 >>1 の関連サイトの"Pro Git - Table of Contents"によれば違う分類による方法が幾つかあるみたいですね。 そうなると、読み始めたオーム社の入門書はどこまで現状に即しているのでしょうか。 基本的な操作が変更される事はないでしょうが、非推奨とかになる事も考えられるので。 あと、良い書籍紹介があると嬉しいです。 >>645 ごちゃごちゃ言わずに手動かさんかいボケェ! >>645 何も考えずにgit for windows入れたら済む話だと思うよ cygwinがベースの技術使われてるけど別途インストールする必要はないし >>645 gitとGitHubは全く別のもの。プロジェクト的には無関係。 gitの本がGitHubについて詳しく書いていることはまずないし、 買収前のGitHub社も、Microsoftも、gitの開発には関わっていないといって良い。 (Git LFSなど一部影響を与えているがコア部分ではない) javascriptの勉強するためにJava始めました観たいな感じ GitHubがGitクライアントのひとつではないということは、エンドユーザーからみればどうでもいいことなのかもしれない それこそがSaaSの目指すべき透過性のry >>651 githubデスクトップアプリのことを言ってるんじゃないかな >>646-652 反応ありがとうございます。 当方WINDOWSに入る前もファイラ時代が長かったもので、コマンドライン感覚が退化してしまっています。 深く考えず教本を読破して、その操作を猿真似して馴染む事を目標に作業再開しようと思います。 指針を与えてくださり、ありがとうございました。 別に無理して最初からコマンドライン使う必要もないと思うけど Visual StudioとかVSCodeとかGUIからgit扱えるし 今時gitが使えないとチームで開発できないからプログラミング言語同様必須知識だよ 基本的な流れは分かったけど 細かいコマンドやオプションまで入れたらとんでもない量ある https://qiita.com/xtetsuji/items/555a1ef19ed21ee42873 upstreamという名前を付けてるけど リポジトリ自体に名前がついてるんじゃなくて リポジトリの利用者側が勝手に名前を付けてるの? おかしくない? そうすることで名前の重複問題を解決させようとしてるのか 名前空間みたいな概念が無いのか ローカルリポジトリから見たremoteの名前なんだから勝手につけて当然。originだってそう。 >>659 エイリアスだよ 本当のリポジトリの名前は、URIそのもの URIは一意なんだから名前空間などなくてもかぶらない 長いから、originとかupstreamという別名を付けてるだけの話 git remote -v でリモートリポジトリの一覧が表示されますが、 push先として設定されているリモートリポジトリを一部削除する事はできますか? fetch元としては使い続けたい そのリモートリポジトリはgithubのなんですが そもそもgithubのリポジトリは権限が無ければ書き込まれないかも、と思ったんですが 合ってますか そりゃ他人が勝手にウイルスコード埋め込めるわけ無いやろ いや、できるんじゃないか・・・これ・・・ githubガバガバ ローカルリポジトリに権限の概念はないぞ。 リモートにpushできるかは権限による。 >>637 ESR Switches To Threadripper But His GCC SVN-To-Git Conversion Could Still Take Months https://phoronix.com/scan.php?page=news_item& ;px=ESR-Threadripper-GCC-Git gccのsvnからgitへの変換はまだ数ヶ月かかるらしい。 >>673 あるやろ。 いまどきgitじゃないと開発者が寄って来ない。 開発者が居ないOSSは死ぬよ。 「今時」ってそれだけの理由かよ。 開発者だけどどっちでもいいわ > 開発者だけどどっちでもいいわ どっちでもいいってことは、どっちも知ってるはずだけど 違いしてていていってんの?svnとgitの比較言える? git cloneしたフォルダをコピペで別の位置に移したら 何か問題出る? githubで自分がフォークしてるプロジェクトがあって 他の人もフォークしてて、他の人がその人のリポジトリでやったコミットを本家にPRしてて、 でもマージされてなくて、でも自分のフォークでそれをマージしたい場合、どうすれば? >>675 emacs, ruby など大きなプロジェクトがgit に移行している。 何故移行したか、どんな効果があったか、事例見ると判る話。 masterブランチで開発していて、 リリースする時、masterの全部の修正をリリースするんじゃなくて 一部だけリリースする時、リリース用のブランチを作ってそこに リリースしたいもののみを集めるってやり方でいい? そしてリリース用のブランチをリリースするわけだけど、 そこにはmasterに入れてないコミットが含まれる。 READMEの修正とか そういった場合、masterにそれを戻さないといけないんだけど、 リリース用のブランチをmasterにmerge戻すと、同じコミットが二重にできちゃうじゃん? それを防ぐにはどうしたら良い?mergeじゃなくてcherry-pickで戻す? それともsquashする?(コミット消したくないけど) それともリリース用のブランチをmasterからの変更にrebaseしてから、masterにマージする(少し面倒そう) 基本個人開発なんでそこまで面倒くさいことはしたくない 今回バグ修正のプルリクが来て、今masterでやってる作業の切りが悪いので プルリクと先に出せる部分を、先に出したほうがいいなと判断したので 例外的にリリースブランチを切った git flowなんてめんどくさくもなんともないやろ むしろmasterで開発してるからそんなめんどくさいことになってるんじゃないか github flowへの文句なら、github flowを論破してからにしてくれ 説明しなくてもわかると思うが、 一人github flow = レビューする人はいない = ブランチきってその都度一人マージ = masterでの開発と何も変わらん 日本語通じてないのはお前だ。 俺はgit flowが複雑であることは世界共通の認識であることを知っているし、 その事実に関して反論していないし、興味も質問もしていない。 git flowが複雑ではないという話をしたいならよそでやれってこと はっきり言わないとわからないようだから言っておくと git flowは複雑(事実)だから使わないと言ってる。 git flowは複雑(事実)ではないと主張したいのなら、俺ではなく世界とやってくれ git flowは複雑(事実)ということは、俺が主張していることではない。 >>693 もうレスしないでね。 ということで >>684 の質問へのレスよろしく なんで1回git flowの話からgithub flowの話に逸れたん git flowとgithub flowの区別も付いてないのは置いといて、複雑なので我流でやりますというなら好きにやればいいんでないの githubで本家にPR出して、しかしやりとりのなかで revertだとか再コミットだとかでヒストリーが伸びて、 本家側は最後の1コミットだけをマージする、ということはできるんだろうか? githubでOSSを修正したい場合、 さらにそのOSSをカスタムしたソフトウェアを作りたい場合、 フォークを2つ作るべき? もし最後の1コミットだけマージできるとして、それにどんな意味があるの? 例えばコミット1をPR、問題点が指摘される、コミット1をrevertしてコミット2を作る。 このときコミット2だけをマージして欲しい。 ところがgithubの画面上ではコミット1もrevertもコミット2も表示される。 その一連のヒストリーが表示されてしまう。 さらに、PR中に本家の追従をしてマージコミットが入るかもしれない。 git使うとヒストリーを適切に保つ必要が出てきて 開発が難しくなる 実際の作業ヒストリーは紆余曲折を経ているわけで、 自分のforkリポジトリにそういうヒストリーがあるのは妥当。 追跡しやすいし。 ところが本家にマージする段階ではヒストリーを圧縮して1コミットにしたい。 でもそんな操作できなかった。 しかもPR中にも紆余曲折してヒストリーが伸びる。 どうやってヒストリーを圧縮すれば? squashするとマージした人がAuthorになるという記事があったが コミットした人になると言ってる記事もあるな https://qiita.com/ko-he-8/items/94e872f2154829c868df#squash-and-merge >この時、マージコミットSのAuthorはBになります https://qiita.com/pshiko/items/1e9acd114b7e85884866 >最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまった >>695 > なんで1回git flowの話からgithub flowの話に逸れたん よく見ればわかるが、git flowの話もgithub flowの話もしていない。マージの話 ただ「git flowが複雑で、それよりもシンプルなgithub flowなどがある」のに git flowが複雑だという事実を知らなそうな人に、git flowを使えと言われたから、 世間の認識を知らないなって思っただけ >>702 単に本家のコミット(通常はmasterのHEAD)からの 修正へとrebaseすればいいだけ >>696 > 複雑なので我流でやりますというなら好きにやればいいんでないの git flowが他のフローに比べて複雑なのは世間で共通している認識なので その話をすることに意味はない。そのレベルの話はしてない。 git難しい コミット内容に問題があり修正したい →修正&動作確認成功 →前のコミット内容は単に要らなくなったからrevertしよう →作業ディレクトリで変更されているせいでエラー →じゃあrevertじゃなくて新たなコミットで みたいな。revertダメなんだ、みたいなのが多い。 分かる?gitのために発想を制限される感じ。 作業手順を見通せるようになるには相当な経験を積む必要がある しかも人によってrevertした方がヒストリー的に好ましいというかもしれない でも作業手順上、revertしていいのかは新しい変更内容で動作確認をした後じゃないと 分からないから、revertは自然じゃない。 >>707 > 作業手順を見通せるようになるには相当な経験を積む必要がある gitは作業手順を見せるもんじゃないよ。 変更履歴を見せるのであって、作業履歴を見せるものじゃない。 あんたが一日こういうふうに頑張りましたっていう報告はいらない 欲しいのは結果 だいたいrevertは、みんなが共有しているブランチでやるものであって 個人的なブランチでは使う必要がない 前のコミットが要らなくなったらrebaseして消すのが普通 欲しいのは結果であって、途中の作業報告なんかソースコードの修正の邪魔 (作業報告したけりゃissueでもprでもslackでも好きなところでやればいい) 作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる rebaseで履歴を消すというアイデアは同意できない > 作業の履歴はコードベースでどんな間違いが起こりやすいかが分かる それ何が目的?何がしたいのかわからない。 >>710 ああだこうだという試行錯誤があると コードの変更が "見通せない" あんたの試行錯誤のあとなんかどうでもいい。 結果を見せろ。重要なのは結果だ。 ただのアップロードツールだとしか思ってない人いるみたいだし そういう人はロダ使えば良いと思うの コードの変更は本家のヒストリーで分かるから forkリポジトリに細かい履歴が残っているのは基本的に良い事 >>715 だから試行錯誤の後とコードの変更履歴は別 残すのはコードの変更履歴(みんなに公開する確定した修正の履歴)であって 試行錯誤の履歴(みんなに公開しない確定してない修正の履歴)じゃない 他人が見る価値がないようなものを残したって 見ないんだから意味ないだろ。 それはノイズでしかない >>717 当然pushする前にも試行錯誤するが、 レビューしてもらうためにpushする必要がある。 ただしその内容は確定した変更内容ではないので 全てを残す必要はない >>717 わかった とりあえずpushしておくよ コミットの内容はあとから見るっていうことを 全く考えてないんだよなw あとから見る時、見なくても良いものがたくさんあったら 本当に見なければ行けないものがどれかわからなくなる。 あとから見るということを全く考えてないから 記録だけしていればいいと間違った考えになる あと見るだけじゃなくコミット単位でcherry-pickしたりするので 一連の修正がバラバラになってると再利用できなくなる。 Git v2.22.0-rc2 先日のLinusからの指摘の修正は入ってない模様。 Gitはコミット間違えたとかブランチ名間違えた時の修正がめんどくさい >>723 どういう手順で修正してる? ちょっと書いてみたよ (どうせやり方知らないくせにって思ってる) ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる