大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
git clone時のmirrorとbareの違い | exMedia
みなさん、こんにちは。自称Gitが得意なまるりんです。 Gitリポジトリを移行する際は通常以下のようにやります。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSITORY> $ git push --mirror <DESTINATION_REPOSITORY_URL> しかしリポジトリのバックアップをmirrorではなくbareでとっている場合(git clone --bare <SOURCE_REPOSITORY_URL>)、そのリポジトリを移行してよいのか気になります。 結論として、リポジトリが保管している内容物はmirrorとbareでまったく同じなため移行しても問題ありません。 mirrorとbareはリモートリポジトリが更新された後の同期作業の点で異なります。どのような違いがあるのかを見ていきます。 mirror
windowsにgit-filter-repoをインストールする - Qiita
インストール windowsのpython 3.10.x をダウンロード＆インストールする https://www.python.org/downloads/ git-filter-repo をダウンロードする https://github.com/newren/git-filter-repo/ ※ルートの「git-filter-repo」だけで大丈夫だと思います 「2」でダウンロードした「git-filter-repo」の一行目の記述を変更する #!/usr/bin/env python3 ↓ #!/usr/bin/env python gitのサブプログラムのパスを確認する 確認コマンド: git--exec-path 「3」で変更した「git-filter-repo」を「4」の位置にコピーする コマンドを確認する git filter-repo
【Git LFS】OpenCV for Unityをpushしようとして怒られた人が見るページ - Qiita
$ git push origin master Enumerating objects: 3189, done. Counting objects: 100% (3189/3189), done. Delta compression using up to 12 threads Compressing objects: 100% (3179/3179), done. Writing objects: 100% (3180/3180), 512.99 MiB | 2.70 MiB/s, done. Total 3180 (delta 1425), reused 0 (delta 0) remote: Resolving deltas: 100% (1425/1425), completed with 5 local objects. remote: warning: File Assets
git lfs migrate で Git-LFS 移行したときのメモ - 戸袋に手を引き込まれないように
Mercurial(Hg)からGit移行移行したついでに、ほぼ1GBとかあるリポジトリ*1をGit-LFSに移行した際のメモです。 Git-LFSを扱えるサービスとしてはBitbucket CloudよりもGitlab.comの方が制限が緩かったので、そちらへの移行も同時に行いました。 ja.confluence.atlassian.com gitlab.com 作業環境: Windows 10 + Git for Windows(+Git Bash,Git LFS) 0. BFGを使わなかった理由 1. Bitbucket Cloud から --mirrorでクローン 2. git lfs migrate info による事前調査 3. git lfs migrate import 実行 4. Gitlab.com へ --mirror でプッシュ 5. 参考資料ほか 0. BFGを使わ
個人的PCまわりセットアップまとめ - Qiita
これは何 備忘録も兼ねて、PCのセットアップで自分のやることをまとめてみました。 随時更新していく予定です。 VS Code VS Codeの環境設定 setting.jsonに下記を追加します。 内容はコメントで書いているので、詳細は省きます。 { "editor.fontSize": 12, // フォントサイズを変更 "editor.guides.bracketPairs": true, // 対応している括弧にガイドを表示する "editor.minimap.renderCharacters": false, // ミニマップに実際の文字を表示しない "editor.renderControlCharacters": true, // 制御文字を表示する "editor.renderLineHighlight": "all", // 現在の選択行をハイライトする "editor.r
git-secretsを使用してAWSアクセスキーのコミットを防ぐ方法の紹介 | DevelopersIO
CX事業本部Delivery部のアベシです。 この記事ではgit-secrets使用してAWSアクセスキーのコミットを防止する仕組みの導入方法について紹介します。 弊社の以下のブログにあるような実際の出来事では、アクセスキーが流出してから10分程度でマイニングに不正利用されてます。※ 弊社作業による流出ではありません。 【実録】アクセスキー流出、攻撃者のとった行動とその対策 このように、アクセスキーは流出するとすぐに利用されてしまうほど狙われやすい認証情報となっています。 このような被害を無くすために、AWSを使う方には是非今回のような対策をしていただけたらなと思います。 git-secretsについて git-secretsに登録したパターンに合致するシークレット情報が、コードに含まれていないかチェックできます。 GitHub - awslabs/git-secrets 実装方法の概要
異なるgitリポジトリ間でもcherry-pickはできる - Qiita
（最初に修正を導入したリポジトリ内で） git remote add TO_FIX_REPO {これから修正を導入したいリポジトリのURL} git fetch TO_FIX_REPO git checkout -b TO_FIX_REPO-master TO_FIX_REPO/master git cherry-pick {master上の修正コミットのSHA1} git push TO_FIX_REPO TO_FIX_REPO-master:master （上記を修正を導入したいリポジトリの数だけ繰り返す） これならかなり機械的に処理できるから、だいぶ楽になるんじゃないだろうか。まぁだからといってコピペが横行して良いというわけではないが。 ちなみにgit push TO_FIX_REPO TO_FIX_REPO-master:masterってのも結構ポイント。ローカルのブランチ名とリモ
git cherry-pickで特定のコミットのみを適用する | Gitテックラボ | SMART プログラミングとサイト構築のウェブマガジン
git cherry-pickはローカルリポジトリに登録された任意のブランチのコミットを適用します。 IDが657150dのコミットを適用 git cherry-pick 657150d 例として、developブランチの１つ前のコミットのみをmasterブランチにコミットします。 ・欲しいコミットがあるdevelopブランチに切り替える git checkout develop ・最新の2件のコミットを確認 git log -oneline -2 602f68d Bファイル削除 657150d Aファイル追加 ・masterブランチに切り替える git checkout mater ・特定のコミットのIDを指定 git cherry-pick 657150d リモートにあるブランチをcherry-pickしたい場合、まずはfetchしてローカルリポジトリにコミットを取り込みます。 git
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
デフォルト以外のポートや秘密鍵を指定してgitにsshで接続するには？ - まじめにゆいがどくそん
例えば、以下の状況で運用しているgitリポジトリに接続するとします。 リモートサーバー：repository.example.jp リモートリポジトリのディレクトリ：/path/to/repository/repo.git ユーザー名：hoge 接続方法：SSH ポート：22222 この場合、次のコマンドを実行することでリポジトリにアクセスできます。 git clone ssh://hoge@repository.example.jp:22222/path/to/repository/repo.git ここで、SSHログイン時にパスワード認証ではなく鍵認証している場合、秘密鍵のファイル名がデフォルトの「id_rsa*1」であるならば、上記のままでアクセス可能です。 しかし、運用上の都合で秘密鍵が「id_rsa」以外にも複数存在している、なんてことありがちですよね？ 秘密鍵が複数存在している
GitのリモートリポジトリのURLを変更する - 祈れ、そして働け ～ Ora et labora
概要 git remote add origin 〜でタイポして間違ったURLを登録してしまったり、中央リポジトリが引っ越してしまった場合に、リモートリポジトリのURLを変更する方法です。 構成 git-core @1.7.6.1_1+doc+pcre+python27 git-flow @0.4.1_0 URLの変更方法 $ git remote set-url <リポジトリの名前> <新しいリポジトリのURL> 作業ログ 変更前のリモートリポジトリの確認 リモートリポジトリのURLはgit remote -vで確認できます。 $ git remote -v origin git+ssh://repos.tetsuyai.com/var/git/buzzbuzz.git (fetch) origin git+ssh://repos.tetsuyai.com/var/git/buzzbuz
[git]ローカルブランチがどのリモートブランチを追跡してるのか確認する方法 - dackdive's blog
githubのリモートブランチと対応するローカルブランチってどれだっけ？ という時に確認する方法。 ここに書いてあります。 git - Find out which remote branch a local branch is tracking - Stack Overflow git branch -vv とすると * master 93e4e9f [origin/master] READMEを修正 のように[]内に追跡中のブランチが表示されます。 たいていはリモートブランチ名とローカルブランチ名を揃えているので 問題はないのですが、 リモートとローカルでブランチ名を変えている場合、 または作業ツリーに複数ブランチある時に 「そもそも追跡ブランチってどれだっけ...？」 という事を確認するのに便利です。 （ちなみに） ローカルブランチが特定のリモートブランチを追跡するように設定するには
![[git]ローカルブランチがどのリモートブランチを追跡してるのか確認する方法 - dackdive's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a6e12004609f875c02ac97ee65343400775aada/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712615374%2F12921228815714339984%2F1645799953)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - spoiledcat/git-for-unity
WSL に標準でインストールされている git においてブランチ名を表示する方法 - Qiita
Git で 削除したファイルのログを見たい時 - Qiita
Git LFS で次のエラーメッセージが出たときの一発対処法：Encountered 3 file(s) that should have been pointers, but weren't: - Qiita
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
gitのcore.autocrlfなんて滅びればいいのに。
gitで差分が出続ける現象の解決法 - Qiita
