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 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が流行ったのは大手がこぞって使ってるからだよｗ 大手っていうのはプロジェクトの話ね
大手プロジェクトはだいたいgit 大手のオープンソースプロジェクトがGithubに移行したってこと bitbucket なら、5人以下のメンバーなら、プライベートでも無料 水銀はいいと思うんだけど、なかなか流行らなかったな mercurialが性に合うし hg-gitが優秀だから
裏側でmercurial使ってgithubに投げ込んでる 神様
汝へ
git rm --cached hoge.txt すると gitの管理下から外れ、ローカルのファイルは残るけど、pushするとリモートからは削除されちゃうのだけれども、削除されずにgit管理化から除外する方法
を教えてもらえますように。 git rm --cached hoge.txt すると gitの管理下から除外され、ローカルのファイルは削除されずに残るけど？ >>208
神出現ｗ
ローカルには残るけど、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がひどい会社に
見えてきませんか？これが話術というものです。 単なるアレルギーでgitlabに移行する奴は、ロクに技術選定出来ないだろうし、一緒に仕事したくない gitlabはオープンソースにする理由がなく
逆にソースを外部に預けることができない
政治的な理由がある場合に
社内サーバーにインストールして使うものだろう ローカルなリポジトリならなんでもいいからgitlab固有のメリットではないかな
gitlabは多機能だから他のサービスを乱立しなくても開発環境を作れるのが便利(jenkinsやめてgitlab-ciなど)
あとはブランチのアクセスコントロールは便利だと思う
本当はSVNみたいにサブディレクトリ単位でアクセスコントロールしたいけど… オンプレミスでやるにしてもGitBucketのローカルインストール版とか使った方がgit単独より便利だぜ >>242
今流行りの異世界転生物ラノベやな
に作者の
「あー、人生やり直してー、今の記憶を持ったまま、レベルMAXでやり直してー」
という願望からスタートする妄想やで 単にどこまで戻るかっていうより
失敗したとこまで戻ってやり直しても
それ以降の上手く行ってる部分はそのまま継続したいっていう
みんなが持ってる願望 Git で使っている、SHA-1だけど去年位からそろそろやばいっていう感じになってきて、
object_id っていう感じで切り出しを進めていたんだけど、次の2.18 でほぼ外出しできる模様。
次の次ぐらいで、SHA-1を置き換える動きが加速するかもね。 ハッシュアルゴリズムの脆弱性が出たとき既存レポジトリは
どうにかできるんだろうか？
githubの人に会ったときに聞いとけば良かった 指定したハッシュ値を持つオブジェクトって、もう簡単に作れるのかな？ 2.18が出る直前になって、MLに "security: potential out-of-bound read at ewah_io.c |ewah_read_mmap|"
って、セキュリティバグほどではないけど、少しやばいのが見つかって、2.18のリリースが少し遅れている模様。 gitの開発グループではハッシュ値をobject_id に切り出しているんだけど、
それ以外にもMLに "Kill the_index part 1, expose it" っていうメールが
投げられて、index を隠蔽しようという動きも出てきている。 https://public-inbox.org/git/20180609205628.GB38834@genre.crustytoothpaste.net/T/#t
> To summarize my view, I think my ordered preference of hashes is
> BLAKE2b, SHA-256, and SHA3-256.
だって。SHA3-256.とかになるのかなー Introducing Git protocol version 2
Friday, May 18, 2018
https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html
git 2.18 から protocol v2 の機能が入ってきた模様。
1) Server-side filtering of references
2) Easy extensibility for new features like ref-in-want and fetching and pushing symrefs
3) Simplified client handling of the http transport githubを手に入れたMSがgitにまで手を入れてくるってことだな。
まずgithubを対応させる。そしてgitの拡張プラグインを作る
git本家に対応を迫る >>257
サーバーサイドで処理するgitコマンドが増えるって話だよ なにを？ 俺はこれからのgitが
どうなるかって話をしただけだが？
今起こってる何かの話じゃなくて MSって以前からgit に積極的じゃん
MicrosoftがWindowsのコードリポジトリをGitに移動
https://www.infoq.com/jp/news/2017/07/microsoft-windows-git
Visual Studio のgit 対応とかもやってるし。
それから、↓のJohannes SchindelinもMSの人だよね。
https://git.github.io/rev_news/2018/05/16/edition-39/ gitがWindowsのAPIに対応しないでmsys依存で動いてた期間が長かったからねえ あとVSのgit対応はAndroidStudioに比べて酷く見劣りする >>266
今時のIDEなら、ソースの編集画面で、行が修正されてたかどうか表示があるよね？
AndroidStudio はこれがカレントブランチのHEADから修正されてるかどうかを表示してくれる
最新バージョンだと、この修正されてるかどうかの表示から、行の固まりを直接コミットできたりする
add -p がソースの編集画面でできるってことね
全体的に、ソースの編集が、ファイルを編集するのじゃなくて、コミットを編集するイメージでできちゃうのがいい VSは、ファイルシステム上のソースを編集するIDEに、レポジトリを操作する機能を追加しただけ
Android Studioはレポジトリ上のソースを直接編集するIDEになりつつある
前者が一周遅れているのを酷く見劣りすると表現した
後者はニッチなんかじゃなくて、これからIDEの基本的機能になるよ この辺どうでもいいって言ってる奴は、コミットする時statusやdiffで確認とかしてなそう
gitignoreも適当で何でもかんでもコミットに突っ込むタイプ >>275
>>267みたいな機能は、>>274みたいな奴には必要ない機能だからね
逆にコミットを丁寧に作りたい奴にはとても便利な機能 糞みたいなコミットでプルリク投げんなよ
買ってもらったGithubが泣いてるぞ ■ このスレッドは過去ログ倉庫に格納されています
