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 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マージできなくてエラーになること多い 綴り間違い治すだけとか rebaseしたくなるなー 綴り間違い治した程度でbisectが困ることにはならんと思ってるが違うの? ログメッセージの修正だけが目的で 元と同じ場所にrebaseするだけなら大丈夫だろう masterの新しいコミットの上に何も考えずにブランチのコミットをrebaseするのは 後々問題を引き起こす 後々ってのはどういうこと? 問題が発生するならrebaseしたその時じゃないのか?見落としは別として。 これ大前提としてコミット一つ一つを どう運用しているかによるよな コミットにバグが含まれていたとしても マージする単位で整合性が取れていればOKなのかとか 人によってはコミットを作業履歴みたいに ・○○修正した ・ミスが有ったので訂正 ・タイポ ・修正漏れがあったので対応 ・今日はここまで みたいにする人もいるし 作成したリポジトリから複数回プッシュした変更分ってmasterにも複数回マージすれば良いのんかね それとも最後のプッシュぶんだけマージすれば変更分は全てマージされるん? gitよくわかんねぇんご commitした時点で独立した完全版だから 最後のやつだけでいいよ >>143 コミットIDというのは歴史全て含んでそのID だから、遠い過去を書き換えてもコミットIDは変わる IDが分かれば歴史もすべてわかる 誰かgit初心者の勉強につきあってくれる人はいないかなぁ そんな人を探して初レス 勉強につきあってもいいよという人がいたら↓にきてよ open.open2chネットの/test/read.cgi/nohara/1511913106/ Git で管理しているJavaのクラスを リファクタリングで別のパッケージに移動させた場合、 物理的な移動 と 中身の変更(パッケージ宣言の変更) が同時に発生するので これらを同時にコミットすると、Git上で履歴が追跡できなくなるのがつらい いまは、ファイルだけ移動させていったんrenamedでコミットしたあとに、 別のコミットで中身(パッケージ宣言)を書き換えてしのいでいるんだけれど、 途中でコンパイルが通らないコミットができるのが、あまりうれしくない… みんなどうやっているの?? git log も git diff も、--followオプションを指定すれば、クラス名の変更ぐらいは余裕で追跡してくれる git blame はオプション無しでも大丈夫っぽい 2つの質問していいですか? 一つ目の質問してもいいですか? なぜpushには-uオプションがあるのにpullにはないのですか? 2つ目の質問してもいいですか? GITのコマンドが完全に成功するか完全に失敗するかのどちらかというのは 複数の人が同時に同じレポジトリーに対して別のGITからコマンドを実行しても 成り立ちますか? たぶん -u オプションの意味を勘違いしてる pushでも特に必須なオプションじゃない 同時にリモートリポジトリ操作は大丈夫なようになってる mao.5ch.net/test/read.cgi/linux/1468149353/501 501 login:Penguin sage 2017/12/22(金) 00:20:40.83 ID:0/XqAwW+ 誰もやらんかもしれないけど @ WSL の Ubuntu の bash から使う git A Git for Windows の Git Bash から使う git これらを混ぜると危険 Aでサブモジュールを含むローカルコピーを取ってきた後 サブモジュールを取り直す時に 間違って@で取ると 以降 git status --porcelain が失敗する TortoiseGit が Git for Windows に依存するので TortoiseGit でのいろんな操作も失敗するようになる ようやく気づいたよ、、 修復方法はサブモジュールを Git for Windows のGit Bash から取り直すこと よくわからないので教えてください。 リポジトリとなるフォルダとして、 git-sampleフォルダを作成し登録しました。 この中で20181231.txtというファイルを作ってコミットし、成功しました。 ここで、別のファイルも管理したいと思い、git-sampleフォルダの中で、 テスト用.txtを作成し、コミットさせると、20181231.txtと同じブランチに 紐づいてしまいます。 それぞれを別のファイルとして管理させたい場合は、ファイル登録時に どうすればよいのでしょうか? >>157 同じmasterブランチでは 別のファイルとして見えてるんでしょ? 今ので合ってるよ git add する前に git branch しろってこと? >>158 素人で申し訳ないのですが、樹形図列に表示されている線が1本のみで、 その1本に20181231.txtとテスト用.txtが紐づいている感じですが、 それぞれのファイルごとに樹形図があると思っていたのですが、そうでは ないのでしょうか? それであれば、ファイルごとの状態を把握するのが難しいような・・ >>160 masterブランチにマージする前提で使うのが基本だよ 途中は樹形図のように広がってもなるべく最後は一つにマージする 樹形図のように広がっている時は多くの人が編集途中だったり、 個人であってもあれこれ途中のものを入れてる段階で、 最終的には確定した一つのものにする >>160 ファイルごとの状態、 というのがよく分からんけど あるファイルの編集履歴を見たいなら git log とか git blameとかで見れるよ >>160 もしかして、 fast forward merge ばかりしてるとか? merge時にmasterブランチに履歴が混ざるのが嫌だと言う話なら以下を参考に https://qiita.com/nog/items/c79469afbf3e632f10a1 git config --global --add merge.ff false git config --global --add pull.ff only というか それ以前にブランチすら作ってないのかも? >>161-163 いろいろ親切に回答をしていただいて申し訳ございません。 SourceTeeeを使っていることを書いていませんでした。 なので、CLIのほうはまだちんぷんかんぷんです。ごめんなさい。 でも、でてきた各用語についてはこれから勉強させて いただきます。 ちなみに実際にやっていきたいのは、 [構成図]フォルダ内にある、物理ネットワーク.xlsxや論理ネットワーク.xlsx などの各ファイルのバージョン履歴がファイルごとに見れるようにしたい。 それがSoueTreeでどのようにできる(表現される)のか試しに始めた次第です・・ >>164 遥か昔、バージョン管理ツールは、ファイル単位で履歴を管理する方式から始まったんだけど、 不便だったので、特定のディレクトリ以下の複数のファイルの状態をまとめて履歴管理する方式に取って代わられた ファイル単位で履歴を見る方法は用意されてると思うけど、SourceTreeはよくわからん この辺が参考になるかな? https://teratail.com/questions/12039 「未コミットの変更状態」が作業ディレクトリに残った状態で 他人がコミットを進めたブランチをpullしてくると 作業ディレクトリはどうなるの? >>166 pullすることで更新されるファイルが作業ディレクトリで未コミット状態なら、 pullの途中のマージでエラーになる ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる