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 もしかすると、特定の用途のときに優位性を発揮するとかはあるのかもしれないが すぐには思いつかないなあ .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, すげーw。嫁が8人目を妊娠中とかどんだけw ユタ大学ってことはモルモンなのかな。 >>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 gitkで表示されるコミットヘッダに Follows: という直近のタグっぽいものがあるけど、 同じものを表示するコマンドって何? git log かなと思ってヘルプを探したけどわからなかった。 Follows が前で Precedes が後ろなのね git describe で直近の tag は分かるけどちょっと挙動が違うし、Precedes は調べられなさそう git tag --contains の結果をひとつづつチェックして Precedes を、 git tag --no-contains の結果をひとつづつチェックして Follows を、 探してるのかな? GitのwindowsGUIの質問はスレ違い? 普段MercurialでTortoiseHgを使ってるのだが Gitも触ってみようとTortoiseGitを導入したところ、これが使いにくい 複数のブランチがある状況で、リビジョングラフを見ながらdiffテキストをサクッと見たり、 コミット等を行ったり、リビジョンに復旧したりしたいが TortoiseHgだと単一ウィンドウですべて収まってできて便利なんだけど、 TortoiseGitは状況の把握と操作が複数のウィンドウにまたがっていて簡単にはできないような気がする コマンドライン実行をそのままウィンドウ出力にしている感じ これに文句が出ていないのは、何かうまい使い方があるということ? (いくつかのウィンドウを開きっぱなしにするのが常識とか) それともGitとMercurialの考え方の違いからくるものなのか? 文句が出ないのは誰も使ってないから Git for Windows の方が良い エクスプローラに統合されるのはウザイから亀シリーズは使わないなあ 自分はVisual Studioとgit bashの併用だけど、単体のGUIはSourceTreeが人気らしいね >>617 妙に情報少ないなと思ったがやはりTortoiseGitはマイナーか ありがとう >>618 SourceTreeいいですね、ありがとう TortoiseGitは意味わからんな、なぜHG版とここまで使用感が違うのか 歴史的な経緯だろうが SourceTree派だけどお気に入り。 git初めての新米たちにも教えやすくてありがたい。 sourcetreeはインストールして放置してるけど何が強みなんだろうか ブラウザ(プルリク/マージ)+VSCode+GitLensで出来ない機能ってある? GitLensいいな、もう少しでIntelljIDEAのGit拡張に追いつけそう >>622 VSCodeに依存せずに使えるメリットがある >>616 ログを表示したあとのグラフのウィンドウの左下にある2つのチェックボックスにチェックを入れて すべてのブランチを表示 プロジェクト全体を表示 を有効にすればよいのでは TortoiseGitめっちゃ気に入って使ってるけどなあ 日本語化するとGitのコマンド名と離れすぎてよく分からなくなるから 英語のまま使うのがいいよ >>622 強みか微妙だけど、gitに絞ったGUIだから初心者には取っつきやすいし操作が覚えやすいと思う。 >>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にマージできていないので無理、という状況を避けられる リリースのタイミングが多少変わった程度でブランチ設計を見直さずに済む ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる