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
コンフリクトが確定しているときにこっち側のファイル全面採用!ってやるほうほうないですかね? masterで暫定対応をちょこちょこしてリリースしたあと ブランチで根本治療を図ったら全面書き換えになっちゃった、みたいな場合です。 >>10 ours/theirsは知りませんでした! ありがとうございます。 githubであるリポジトリをフォークしてローカルにクローンしてブランチを作って作業してます。 フォークしたリポジトリのブランチを破壊してしまいリセットもうまくいかなかったので 壊れたブランチをローカル・リモートともに削除して 新しく同名のブランチを作成してリモートに反映させて ローカルのブランチを削除して フォーク元のリポジトリから元のブランチをチェックアウトして そのトラック先を新規作成したフォーク先のリポジトリのブランチに変更して 強制プッシュしました。 見た目問題なさそうなんですが何かおかしいところがないでしょうか? フォークした時点でローカルもリモートも自分のものになってるんだから気にすんな 新人プログラマです。 現在私の参加しているプロジェクトでgitを使っているのですがどうも使い方がおかしい気がしてます。(新人なので私のほうがおかしいのかもしれないが) 以下現運用状況です リモートリポジトリをクローンしてそれをさらにコピペでIDEのワークスペースに移し、ファイルを編集・追加する。 差分をwinmergeでローカルリポジトリにコピー そしてリモートへプッシュ こんな感じです。 私はクローンして作ったローカルリポジトリのワークツリーをIDEのワークスペースとして使うのではないかと思い混乱しています 皆さんの意見をお聞かせください >>15 > リモートリポジトリをクローンしてそれをさらにコピペでIDEのワークスペースに移し この段階で、ローカルには二つのクローンされたファイル群になるんじゃないの? 君が入る会社を間違えるからそういう低レベルな職場にぶちこまれる きっとそういう環境では何も技術的にレベルアップできないからいるだけ無駄だよ 転職を考えた方が良い >>16 すみません。少し説明不足であることに気づきました。 クローンしたローカルリポジトリのワークツリーのフォルダだけをコピペしてIDEのワークスペースに入れています。.gitフォルダなどはコピペ対象外なのでクローンが2つではないのです。 どうも手順書がgitのワークツリーのことをリポジトリとは全く別の作業用のフォルダという理解で書かれているようなのです。書いたのは富士通の人ですが >>17 やっぱこれは低レベルな現場なんですかね… 転職は入社したときから常に頭の片隅にあるのですが… コミットは神聖な手続きなのでローカル履歴はzipでやりなさいという教えでは? >>18 手順書書いたやつに指摘してみて、変わらない・逆切れするようなら転職go。 そのくらいとんちんかん。 読んだ感じ富士通に常駐してる人じゃないのか?だったら文句言っても無駄 AWS上のローカルリポジトリをmac等からssh接続し、source treeで管理することは可能なのでしょうか。 実際に試せばわかることなのですが、あいにく手元に実践できる環境がないので、教えていただけると幸いです。 どうやってるのかわからんけど マウントしてたらローカルと同じ扱い それ以外はリモート >>24 お察しの通り弱小常駐です。ましてや1年目の新人なので富士通の人に直接言う機会すら無さそうです 転職は入社初日から考えていますが… gitの開発ML見てたら、ライナス降臨でバグに文句言ったら、 速攻でPeffがパッチ投げていたのはワロタ 2.14が出てから、開発MLにメモリーリーク関係のパッチがいろんな人から大量に投稿されている。 全部取り込まれるかどうかはわからないが、2.15 はメモリ開放漏れが大幅に減る予感。 tortoise git でブランチ名を変更する方法ってある? >>30 それ使ったこと無いけどブランチ作って元のを必要なら消すだけじゃないの ブランチ作る機能の無いgitクライアントなんてあるわけないよね? コメントどうもありがとう >>31 その一手間が面倒だからあればなーと思って ログのグラフを見ながら作業できたら便利なんよね >>32 ちょっと探してみます そんなのが必要になるほどブランチの名称変更って頻繁に使うものかな? 誰かに教えてもらった 「ここをコメントアウトするといいですよ」 をブランチを作ってコミットとか とりあえず一気に最後まで実装したのをコミット、 そこで似たような名前でブランチを作っておいて 最後のコミットをやり直しながらちょっとずつコミット、 途中でこれは別のブランチにも先にマージして使いたいので ブランチを作ってそれだけまとめるか とか なんぼでも思いつくけど、、 ブランチはいっぱい作るけど名前変更ってのはあんまりしないな 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されてない部分が表示されました ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる