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 誰かに教えてもらった 「ここをコメントアウトするといいですよ」 をブランチを作ってコミットとか とりあえず一気に最後まで実装したのをコミット、 そこで似たような名前でブランチを作っておいて 最後のコミットをやり直しながらちょっとずつコミット、 途中でこれは別のブランチにも先にマージして使いたいので ブランチを作ってそれだけまとめるか とか なんぼでも思いつくけど、、 ブランチはいっぱい作るけど名前変更ってのはあんまりしないな git branch --help でwebページ(マニュアル)開くから -mオプションを見ろ 英語が読めないとかいう幼稚園児は死ね >>40 馬鹿だなー 質問は「tortoise git でブランチ名を変更する方法ってある?」なのに >>33 ですが、 >>32 さんの方法で名前変更だけでなくいろいろできることがわかりました! どうもありがとうございました! m(__)m 開発MLでGit for Windows のコミッタと浜野氏がもめているね。 Git for Windows のコミッタ => REBASEのパッチを出す。やり直しやり直しで6回出しても通らない。 浜野氏=> 9月2回目の Cooking in git.git で Expecting a reroll. と書く。 Git for Windows のコミッタ => No you don't と嫌味。 浜野氏=> 9月3回目の Cooking in git.git で 相変わらず、Expecting a reroll. と書く。 Git for Windows のコミッタ => うざいから俺のパッチを削除しろよ 浜野氏=> お前の意見のせいで頭おかしくなりそうだ。もう少しなんだから最後までパッチ書けよ。 Git for Windows のコミッタと浜野氏は8月5回目の Cooking in git.git でも揉めている。 この殺伐感こそが開発という気がする。 sourcetree以外を使わないといけない理由は何なの IDEから操作したいとかCUIで操作したいときとか Gitをコマンド以外で操作することって現場ではある? 全てコマンド上で出来る気がするんだけど、ディレクトリ右クリックからの〜って操作を推奨してるのかな ちな最近転職して内定、現在勉強中の身です 普通にsourcetreeの方がブランチが一覧できて楽 俺は gitk --all 見ながら操作はコマンドだな。 >>51 大体のことはVisual Studioから操作するけど TortoiseGitかVisualStudioかな ブランチ操作とかはSourceTreeは遅いからコマンドで打つことがかなり多いけど、addに関してはGUIで差分を確認しながらすることが多いかも Windowsで個人情報登録したくないなら亀git一択 >>57 これ つーかgitだけじゃなくて tortoise gitもGPLのオープンソースプロジェクトなのね 誰かtortoise gitのログウインドウのコンテキストメニューから ブランチ名を変更する機能の追加を tortoise gitのgitリポジトリから フォークしてマージまでやってくれないかな、、 >>59 すげぇ眼鏡クイってしながらドヤ顔で言ってそう >>51 うちの現場ではtortoiseGit使ってます 無能が運用ルール作ったせいでsvnのほうが100倍ましだった…みたいな状態ですが… コミット担当者にパッチ渡してマスターリポジトリにコミットしてもらう運用とか普通にありそうで怖い >>65 その前に5人くらいのハンコを貰わないと・・・ 個人の生産性を測ると、バグと手戻りと思い違いが増える。 一方、協調しよ うとかスキルを伸ばそうとか知見を共有しようとかいった態度は薄れていく。 各人がなんとしてでも自分自身の生産性を確保しようと躍起になるからだ。 心しておきたいのは、個人の生産性を計測すると、 プロジェクトで大切に育んでいきたい心構えと振る舞いを台無しにしてしまうということだ。 チームメンバー同士で考え方を共有すること。助け合うこと。 落とし穴にはまらないように気を配ること。 こうしたすべてが失われてしまう。 Git for Windows 2.14.2からtig同梱されんのマジうれしい 会社は未だにSVNでプライベートは共同作業するようなプロジェクト持ってないんだけどgitにするメリットってあります? >>73 ローカルコミットできるというだけでもメリット ディレクトリを作成する git init これでバージョン管理の準備が整う svnだとリポジトリ用のサーバー用意して〜から始まる >>79 いや、だからそのリンク先の内容が 面倒だって話だろw >>80 とりあえずサーバーなんて要らんと言うことはわかったかな? w gitはSVNに比べて気軽にブランチが作れるんで、 ちょっとした実験用の実装を別ブランチで分けて作っておいて、 あとから部分的に使いたい部分のコミットのみを別のブランチにマージさせたりできる これはSVNにはないメリットといえるのではないだろうか SVNでコミットログをいじくり回したいんだけど、どうすればいいでしょうか >>86 はまだgit並みになったのか? って言う意味だとも取れるけど>>88 はさすがにスレチだな と言うことで Subversion r15 http://mevius.2ch.net/test/read.cgi/tech/1406967657/ に行けよ プルリクによってOSS活動が捗るというのもgitのメリットでは SVNではこうはいかない >>91 プルリクエストはgitの機能ではないと思います 開発ML見ているけど、パッチ出してレビューしての繰り返しで、16回目のレビューのパッチとかあるね。 去年の夏ごろからレビューと再提出を繰り返しているみたいだ。 根性あるって感じ。 16回もレビューするようなコードは もういい。俺が自分で書くってなりそうw レビューする方は根性有るな 一回レビューしたあとにまた新たな実装を追加したりしてんじゃねーの たまにいるよそういうやつ レビュー修正のやり方を全くわかってないクソプロは死刑 git add -pで一部だけaddした場合 そのaddされた変更箇所がどこなのか確認する方法を教えてください git diffだとaddされてない部分が表示されました RC1 で An ancient bug ってのが直っているな。 どのバグか知らんが、そんな古いバグもあるんだな。 ローカルコミットの最新だけリモートにプッシュすることってできませんか? 一旦コミットしてしょうもない書き間違いに気がつくことがあって >>106 しょうもない書き間違いをしたのはリモートにプッシュしたの? まだしてないなら何でもできるよ gitで管理しているファイルの名前を 途中で変えたい場合はどうするのでしょうか? 別ファイルとしてコミットしなおすと履歴が切れてしまうので良くないですよね? 問題なく追従すると思うけど せっかくgitで管理してるんだから取りあえずやってみたら? あまりに変更箇所が追跡できなくなるけど、その場合は追跡する意味がない >>110 git mv ファイル名変えて元をrmしてaddし直すのと一緒だが なるほど、だから名前の変更だけでコミットするのが良いわけか 使い方の問題だな Tech Talk: Linus Torvalds on git https://youtu.be/4XpnKHJAok8?t=330 を見ると 2007/5 の時点でLinus はJunio Hamano って呼んでいる。 浜野氏はこのころからJunio って名乗っていたのか。 ミドルネームのCが何の略なのかはいまだに謎。 mv hoge/index.html index.html rm -a hoge git status↓ deleted: hoge/index.html Untracked files: (use "git add <file>..." to include in what will be committed) index.html git mvし忘れたんですけどこの場合どうやって index.htmlの履歴が引き継げなくなるのは困ります mvの履歴なんて保存されないから 普通にaddしてコミットで良い あの、git cloneした場合とreleaseから圧縮ファイルをダウンロードするのはどちらが通信量が少ないでしょうか? git cloneってgzで圧縮されたパケットですかね? gitのv2.5.0のみcloneしたら5.72MiB(約6MB) v2.15.0.tar.gzのサイズは6.9MB よってcloneのほうが通信量が少なかったです 圧縮ファイルのほうがサイズ小さいと思ったら以外でした あっホントだ!2.5.0と2.15.0だった いま気付いた git clone --depth 1 -b v2.15.0 だと7.21 MiB(7.56023296 MB) tar.gzは6.85MB tar.gzのほうが軽いですね gitってここ二三年、マイナーバージョンが上がりまくっているが、 お薦めの新機能ってある? >>132 タイトルを「なぜfast forwardマージをやめるべきか」に変えてほしい feature ブランチを rebase してから --no-ff merge feature ブランチを rebase してから --ff merge feature ブランチを rebase せずに --no-ff merge は、複数人開発だとデフォルトこっちになるけどffマージになっちゃうこともあるので一応指定 feature ブランチを rebase せずに --ff merge は、複数人開発だとffマージできなくてエラーになること多い ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる