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 綴り間違い治すだけとか 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の途中のマージでエラーになる Gitは間違いなく開発を不便にしている 自分の足跡を強制的に残すことを余儀なくされているから そうすると自分の変更の差分を勝手にチェックしてくるやつが でてきて「この余計なファイル何?」とか「この変更何?」とか 「削除して」「コミット取り消して」言い始めて何回も 自分の作業が無駄になる。 自分の作業や時間をムダにしないためのツールなのに。 コンフリクトが発生したから取り消すんじゃない。 バグが実際に起きたか取り消すわけじゃない、 単に「監視」されて、監視したやつにとって「不可解だと思ったから」 それだけの理由で何度もコミットを取り消したりファイルをごちゃごちゃ 編成したりを余儀なくされる。 バックアップ要ファイルとかtmpとかコメントアウトとかインデントとか コーディング規約とかちょっとでもお気に召さなかったらいくらでも もとに戻せるんだから「戻せ」となる。 こんなことなら一度加えた変更は二度と戻せないほうがマシかもしれない。 ソースコードもペーパー大好き日本人の感覚で言えば 稟議書のごとく書式チェックされる。 ちょっとでも書式が崩れていたら(問題なく動いたとしても) すぐ差し戻される。 日本人は救いがないくらい馬鹿すぎる、なんだこの情弱国家は。 他人が読めない糞コード書くからやり直しさせられてるんだな gitが品質向上に役立ってることが分かりました Jenkins と GitBucket との連携に関する問題が解決できず質問しました。 具体的には、GitBucket のリポジトリに push したとき、Jenkins ジョブが自動的に起動するようにしたいのですが、 そのジョブが自動的には起動しません。 GitBucket のリポジトリの Service Hooks の設定で [Test Hook] ボタンを押すと、HTTP ステータスコード 200 が帰ってきます。 また、同設定ページの [ Which events would you like to trigger this webhook?] で [Push] にチェックを入れています。 この状態でも、GitBucket のリポジトリに push しても Jenkins のビルドが起動しません。 しかし一方で、Jenkins のジョブは Multibranch Pipeline ですが、 GitBucket のリポジトリに push した後、Jenkins のジョブの [Scan Repository Now] を実行すればジョブは起動します。 つまり手動では問題なく起動するということです。 原因として何が考えられるでしょうか? (Git とJenkins のどちらのスレに質問するのが適切かわからず、 とりあえず賑わいがあるこちらに質問しました) >>177 スレチ jenkins側のプラグインの問題っぽいね 何使ってるか知らんけど 悪いことは言わんからGitter行け >>178 Jenkins のプラグインを調べてみます。 ありがとうございました。 >>179 pushならGitBucketプラグインでも連動できることは確認してるよ >>177 http://int128.hatenablog.com/entry/2016/10/04/230243 http://int128.hatenablog.com/entry/2016/10/06/224444 この辺の話じゃなかろうか 最近のGitBucketでは問題無いと言う話も聞くけど、うちじゃどこかのバージョンからか 上手く動かなくなって、原因探るのもめんどうだからポーリングに変更しちゃったわ Jenkins側のPluginがAPIアクセス時のアドレスにポート番号まで含めて自由に設定出来れば解決出来そうだが…… ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ git config --global user.name "xxxx" git config --global user.email "yyyy" としたんだけど、何もメッセージが出ない。 念のため、xxxx の文字列をローカルディレクトリで検索してみたけど どこにも記録されてないみたい。エラーが起きてるのにエラーメッセージが出ない? git config --global --list ローカルで探すつもりなら git config --local hoge.hoge fugafuga GIT SVNでSVNのリポジトリのtagsにGITのtagを反映させるのはどうしたいいんでしょうか? GITだけ(SVNは入れてない)で開発していてtagをつけた後にリモートにdo commitしてもtrunkに入ります。 >>187 svnのtagは実質ブランチで、gitのtagと全然違うから無理。 git-svnでsvnからgitへの移行時もsvnのtagはbranch扱いだし、方法は無いと思う。 >>190 無理ですか SVN入れてる人に頼んでみます なんでこんな分かりにくくて複雑で使いにくいものが流行ってるの? もっとシンプルで簡単なものでいいじゃん。 プロジェクトメンバーのほとんどのヤツが良く理解してないのに 使わされるからめちゃくちゃになる・・・ めっちゃ便利なんだが?? 分かってる人が分かってない人にちゃんと教えるべきでは? 御社の教育体制を見直すべきでは? >>192 どんなのが判りやすいと思う? っていうかgitの前はどうしてたん? git の特徴は、直接リポジトリへ保存しないこと 一旦、自分のPC 内に保存して、そこで少し待つことができる。 その後しばらくしてから、リポジトリへ保存する 流行ったのはGithubの影響が大きいだろうね 実際、GoogleのPerforceとかFacebookのMercurialとかGitを否定して他のバージョン管理システム使ってるところも多いけど、一番数の多い中間層でブームになってこの状況なんだと思う gitが流行ったのは大手がこぞって使ってるからだよw 大手っていうのはプロジェクトの話ね 大手プロジェクトはだいたいgit 大手のオープンソースプロジェクトがGithubに移行したってこと bitbucket なら、5人以下のメンバーなら、プライベートでも無料 水銀はいいと思うんだけど、なかなか流行らなかったな mercurialが性に合うし hg-gitが優秀だから 裏側でmercurial使ってgithubに投げ込んでる 神様 汝へ git rm --cached hoge.txt すると gitの管理下から外れ、ローカルのファイルは残るけど、pushするとリモートからは削除されちゃうのだけれども、削除されずにgit管理化から除外する方法 を教えてもらえますように。 git rm --cached hoge.txt すると gitの管理下から除外され、ローカルのファイルは削除されずに残るけど? >>208 神出現w ローカルには残るけど、statusみると deleted: hoge.txt になっているので、pushするとリモート先からは削除されちゃうのです。 >削除されずにgit管理化から除外 どういう状態? >>210 環境依存する設定ファイルをgitで管理していたのだけれど、それをgitの管理から外すために、 ・git rm --cached で除外(ファイルは削除いたくない) ・.gitignore に追加 ・commitしてリモートへpush ・別環境でそれをpullすると、除外したファイルが消えてしまう これを削除されないようにするのはどうすれば良いか、、というご相談です。 よかったか 値段がきついけど年に1冊ペースででるからなぁ うわぁ、いい本と聞いて見に行ったけど、あれ買う勇気も 読む勇気もないわ。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 QHYQI M$とは大違いだな >さらに、追加のセキュリティレベルとして、これらのリリースでは、問題のある.gitmodulesファイルを含むリポジトリへの >pushesを拒否する。これは、次のことを意味する。 >ホスティングサイトが悪意のあるコンテンツの拡散を防ぐことで、古いクライアントを使っている顧客を保護します。 >>225 ここで述べられてるいくつかの脆弱性・修正のうち、 https://www.infoq.com/jp/news/2018/06/git-vulnerability-2.17 NTFSに関するものはこれだけでは? > 修正された脆弱性の2つ目は、NTFSファイルシステムを使用するレポジトリに > 特有の脆弱性であり、攻撃者がランダムなメモリ内容を読み取れるように > NTFSパスの健全性チェックを欺くことができる。 つまり、あんたの引用したそれはNTFSとは関係ない Linuxにも影響がある脆弱性 こういう記事を見てもMSを批判することは、かっこいいことみたいだね。 GitHubからGitLabへ移行しよう ttps://qiita.com/flmil/items/89ca07fa976546365c49 > きっかけは、Microsoftは2018年6月4日(米国時間)に、 > GitHubを(約75億ドルで)買収すると発表したことだ。 放射脳みたいなものだね 昔ちょっと失敗したからっていつまでも原子力はダメだと言うのはばかばかしい Microsoftも確かに悪い時期はあったけど今はユーザーや開発者にとってすごくいい会社だよ >>229 原子力は問題ですね、特にビジネスロジックの中にリスク管理が全く含まれないところが 原子力も保険に入る必要があるのですが、その保険を定義できない常況なのです >>229 原発でマスゴミの可笑しなところは 事故前(もんじゅとか美浜とかの時代)は少量漏れただけであれほど危ない危ないって騒いでたのに 事故が大きくなると何も言わなくなったこと 今も騒ぎ続けてないと可笑しいんだが 発狂して死んでもいいレベル どうです?原発問題とMSのgithub買収にはなんの関係もありませんが、 こうやって原発問題を批判すると、なんてことでしょう?MSがひどい会社に 見えてきませんか?これが話術というものです。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる