Git LFS でうまく clone や pull ができないときにバイナリファイルのダウンロードをスキップする
こんにちは、kenzauros です。 Git LFS は Git で大容量ファイルを扱えるようにするものですが、不具合というか結構クセが強くて、正常に pull できなかったり、 push できなかったりすることがあります。 今回は 1GB 超の大容量ファイルがうまく pull できないリポジトリがあったので、その回避方法をご紹介します。 概要 発生したのは下記の環境です。ほぼすべて最新バージョンですので、ツールバージョンによる不具合ではないと考えられます。 GitLab 8.15.2 SourceTree 1.9.10.0 Git 2.11.0 Git LFS 1.5.2 いくつかの種類のエラーが発生するのですが、基本的に大容量のファイルがリモートにアップされたあと、git pull するときに起こります。下記は一例です。 $ git lfs pull Git LFS: (27 of
git switchとrestoreの役割と機能について - Qiita
先日8/16にGitバージョン2.23.0がリリースされました。 今回の目玉機能と言えば、新しいコマンド git switch と git restore ですね！ 本稿ではこちらの2つに絞ってどういう役割・位置づけの機能なのか英語ソースの引用も含めてご説明します。 TL;DR ブランチの変更は git switch ファイルの変更は git restore 今まで通り git checkout は使える 新機能は「実験的機能」なので今後変更の可能性あり 新機能が追加された背景 Highlights from Git 2.23によると、 git checkout に出来ることがあまりに多いため（ブランチ操作のほか、indexされたファイルの復旧、履歴上のファイルの取得など）、役割を明確に分けるためのコマンドが追加されたとのことです。 It turns out git checkout ca
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
[git] gitconfigで会社用アカウントと個人用アカウントを楽に使い分けする - Qiita
概要 やむを得ない事情でgitアカウントが複数あり、会社用アカウントと個人用アカウントなどを分けたいケースがあると思います。 そういったときは、会社用アカウントで作業するフォルダと個人用アカウントで作業するフォルダを分け、gitconfigの includeIf で このフォルダ配下ならこのアカウントを使うよ という設定を書いてあげるとよさげです。 ベースとなるgitconfigを作り、分けたいアカウントの数だけ[user]だけ描いたgitconfigを作ってincludeIfで参照するといい感じだと思います。 ベースgitconfig 省略 # workフォルダの時会社用gitアカウントに切り替え [includeIf "gitdir:~/project/work/"] path = ~/.gitconfig-work # otherフォルダの時は個人用アカウントを使用する [inclu
![[git] gitconfigで会社用アカウントと個人用アカウントを楽に使い分けする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b93b7191581244406063b2129d31854db1b647d8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ2l0JTVEJTIwZ2l0Y29uZmlnJUUzJTgxJUE3JUU0JUJDJTlBJUU3JUE0JUJFJUU3JTk0JUE4JUUzJTgyJUEyJUUzJTgyJUFCJUUzJTgyJUE2JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgxJUE4JUU1JTgwJThCJUU0JUJBJUJBJUU3JTk0JUE4JUUzJTgyJUEyJUUzJTgyJUFCJUUzJTgyJUE2JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgyJTkyJUU2JUE1JUJEJUUzJTgxJUFCJUU0JUJEJUJGJUUzJTgxJTg0JUU1JTg4JTg2JUUzJTgxJTkxJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1hMGQ3NDhjOWUyNTQzNWM5OGJjMzg2MGM5YzdjZTllYQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBBbmNpZW50X1NjYXBlcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2JkNDExZjQxOTBhODY2YWJkM2JhNWUxNWQ1MGU5YTI%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44KG44KB44G_%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D7fc2e1d75076d53ee1a09d9ae404281d)
Installation
Requirements git >= 1.8.3.1 Installing On all operating systems, once git-lfs is downloaded, git lfs install must be run. Each user that intends to use git lfs must run this command, but they only ever need to run it once. git-lfs can be disabled by running git lfs uninstall, in which case that user would have to run git lfs install again, before git-lfs features work again. Some users may wish to
GitLFSは遅いというイメージを払拭したい - Qiita
version https://git-lfs.github.com/spec/v1 oid sha256:4665a5ea423c2713d436b5ee50593a9640e0018c1550b5a0002f74190d6caea8 size 36 次に、git add の際に GitLFS のトラッキング対象としているファイルが含まれていれば、clean filter を介して GitLFS のストア先にある実際のコンテンツを更新し、そのコンテンツから算出したポインタファイルに置き換えます。 これにより、Git 上はポインタファイルだけが管理され、ローカルにはコンテンツそのものがあるという形を実現しています。 なるべく最新のバージョンにする できるだけ GitLFS のクライアントを最新のバージョンにしましょう。これはとても重要です。 1.0.0 だと push した時に壊れてしまう
git Untracked files(未追跡ファイル)を1発で消し去る
※この記事は、2014年06月06日に書きました。 ■まえがき 以前の状態に戻そうとした時に、 新規に追加したファイルがgit Untracked filesってずらーっと並んだりする事があるかもしれない。 stash、reset時に、前回のコミット時には無かったファイルがあると、未追跡ファイルとしてこのような表示になる。 もし、それらのファイルが余りにも多く、 もしも消し去ってもいいのなら、次のコマンドで吹き飛ばすのも手かと思います。 備考 もし、今の状態を一時保存して、また戻ってくるのであれば一旦コミットを行い、 戻ってきた時には、git reset --soft HEAD^して続きをするのもありだと思います。 細かい事を気にしないならgit add .、git commit --amendで追加をコミットに足していくとかでもいいかもしれません。 ■メモ git clean git c
個人的にコードリーディングがはかどったテクニックまとめ - Qiita
はじめに コードリーディングの重要性はそこらじゅうで語り尽くされてる感があります。 僕も地道にコードリーディングをしているのですが、いざやろうとするとハードルが高いことがままあります。そこで、個人的にコードリーディングがはかどったと感じたテクニックをまとめておこうと思います。 筆者環境の前提 ソースコードのバージョン管理は Git を使っている 開発 PC は Mac を使っている エディタは Vim を使っている ghq + peco で読みたいリポジトリに気軽にたどり着く 読みたいソースコードのリポジトリが増えてくると、ローカル環境でのリポジトリをどのディレクトリに置くか、またいざ読もうとするときにディレクトリを辿っていくのが煩雑になってきます。 そんな時、読みたいリポジトリに気軽にたどり着くことができれば、読むハードルが下がります。 僕は peco と ghq の組み合わせを使ってい
もし、異世界転生モノのチートスキルが「Gitコマンド」だったら【その１】 - Qiita
この記事のゴール 以下についてざっくり理解することができる（かもしれません）。 commitとはなにか checkoutとはなにか 本編 僕「好きです。付き合ってください！」 帰り道、僕は勇気をふりしぼって先輩にそう伝えた。 先輩はちょっと驚いた顔をした。 そのまま笑って、何かをつぶやく。 ーー僕は、横から突然やってきた暴走トラックに跳ねられたので、何も聞けなかった。 気がつくと、森の中にいた。 僕「ここは一体…？」 薄暗い森の中。 僕「そうか、僕、あの時…」 死んだのだ。 頭に霞がかかったかのようだ。思考がまとまらない。 しかし、僕はここが異世界なのだと、何故か瞬時に分かった。 周りを見渡すと、少しはなれたところに男が立っている。 フラフラとしたおぼつかない足取り。虚ろな瞳。痩けた頬。 明らかに憔悴しきっている。 男は虚空をしばらく見つめていた。 ……そして振り絞るような声で、こうつぶや
GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
アクセスキーのコミットを抑止できて安全便利な awslabs/git-secrets - kakakakakku blog
GitHub で awslabs のリポジトリを眺めてたら git-secrets という便利なツール（シェルで実装されてる）を発見した． どんなものかを簡単に説明すると，アクセスキーなどを誤ってコミットすることを Git の hooks を使って未然に防ぐツールで，誤って GitHub に push してしまったために，AWS を不正利用されてしまった，みたいな事故もたまに聞くし，そういうのを防ぐことができる．非常に良かったので，一部のリポジトリに git-secrets を設定した． github.com インストール make install でも良いけど，Mac なら brew が使える． $ brew install git-secrets インストールすると git secrets コマンドが使えるようになった． $ git secrets usage: git secrets
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
はじめに 先日参加したRails Developers Meetupの中で、「コミットの粒度がわからない問題」が少し話題になっていました。 「commitの粒度がわからない」すいません、私もです…！よく迷っちゃいます…！！！ #railsdm — まえとー (@maetoo11) July 20, 2017 commitの粒度がわからない問題、ある。（ほんとわからない） #railsdm — おおた (@ota42y) July 20, 2017 普段僕は感覚的に「それっ、ここでコミット！」とコミットしているんですが、具体的にどういうルールでやってるの？と聞かれると、きれいに明文化しづらいものです。 とはいえ、できるだけ明文化できるよう、模範解答を考えてみました。 この記事ではそんな「適切なコミット粒度」について解説します。 動画で明文化・・・！？ すいません、「明文化した模範解答」という
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
AWS BeanstalkにCakePHPのサンプルをGitでデプロイした - ブログ
BeanstalkでPHPをGitでデプロイできるそうなのでどんなことができるのかやってみました。 背景 以下のことを調査したかった BeanstalkでPHPのフレームワークの利用 利用した時の感触 Gitでのデプロイによって開発のサイクルを回しやすくしたい CakePHPでのサンプルアプリ作成手順 環境の設定などはこちらのブログを参考にしながら、以下の手順で行いました。 http://d.hatena.ne.jp/j3tm0t0/20120404/1333531368 手元にGitレポジトリ作成 CakePHPをダウンロードしてCakePHPのサイトに手順が載っているブログチュートリアル*1を作る Beanstalkの環境構築 AWSのレポジトリにPush 確認 ちょこちょこつまづきながらも、できました。Gitデプロイ便利ですね。 確認/少し工夫したこと Gitでの開発→テストを簡単に
.gitattributesによる改行コードの変換設定 - 理系学生日記
Git での改行コードの取り扱いについてきちんと調べたことがなくて、プロジェクトにおいては「みんなー! ただしく .gitconfig 設定してねー」という立場を取っておりました。 しかししかし、改行コード設定については、もはや個人の設定に正しさを求めるのではなく、リポジトリ単位に行う方がベストプラクティスのようです。 基礎知識 改行コードの取り扱いを面倒にしているのは、プラットフォーム毎に改行を意味するコードが異なることです。 プラットフォーム 改行コード Windows CR LF Linux/OS X LF Linux で作成され改行が LF で表現されたファイルがあるとします。これを、Windows で Checkout し、Windows 側で勝手に改行を CRLF で表現するようにしてしまうと、全行に差分が出てきてしまって、レビュー等が著しく大変になります。 このような状況を防
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bitbucket-syncを使ってサーバ自動化をしてみた
pipenvとGitとDockerを使ったPython開発フロー - Qiita
Encountered 1 file(s) that should have been pointers, but weren't · Issue #1939 · git-lfs/git-lfs
How to handle big repositories with Git | Atlassian Git Tutorial