Git でファイル名やディレクトリ名の大文字/小文字を変更する方法
Git で管理しているプロジェクトで フォルダ名の大文字小文字を変更しようとしたら うまくいかなくて悩んだのでメモ。 素直にこうやると % git mv yebisu/ Yebisu/ 何かおこられた。 fatal: renaming 'yebisu' failed: Invalid argument ディレクトリじゃなくてファイルでやるとわかりやすい。 fatal: destination exists, source=duvel.jpg, destination=Duvel.jpg 「移動先にはファイルが存在するよ」ということでおこられます。 Mac のファイルシステムでは、 大文字小文字の違いがあっても同じものと見なされるんですよね。 Linux なら問題ないと思うんだけど。 ファイルの場合 -f オプションで解決。 % git mv --help OPTIONS -f, --for
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
BFG Repo-Cleaner by rtyley
Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala View project on GitHub $ bfg --strip-blobs-bigger-than 100M --replace-text banned.txt repo.git an alternative to git-filter-branch The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history: Removing Crazy Big Files Removing Passwords, Creden
Git LFS を使っていてクローンが遅すぎる時
Git LFS を入れて大量の画像などを Git 管理にしている場合、clone が重くて重くてエラー連発したりして泣きそう、という状態になったので調べました。 git-lfs の処理を飛ばして後からダウンロードする git-lfsは大容量のファイルを扱うもので多量のファイルを扱うものではない – Qiita 上記ページにあるように、clone 時に git-lfs の処理を飛ばして後から git-lfs のファイルをダウンロードすると良さそうでした。 具体的には次のような形で頭に GIT_LFS_SKIP_SMUDGE=1 を付けて git clone して、 GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/○○/○○.git git clone が終わったら git lfs fetch で確認し、 git lfs fetch 最後に
【Git】リモートからの取得とリモートへの反映で行っていること(fetch,pull,push) - Qiita
fetchはリモートの「情報」を取ってくるだけ、 pullは情報を取ってきて、さらに実データをローカルに反映する。 という理解でした。 でも、fetchで何やら情報を取得している様子なのに、その後行ったpullでは何も情報が取得されない。 ということが有ったので、fetchって一体何をしているの？ということで調べてみた。 まずはブランチについて ブランチの種類 ローカルブランチ ローカルで開発するときにcheckoutで開いてコミットしていくお馴染みのもの。 ローカルで作成したブランチは、pushすることでリモート追跡ブランチにも反映される。 リモート追跡ブランチ ローカルに保持している、クローン元リポジトリのブランチを取り込んだもの。 反映はfetchやpullコマンドを実行したタイミングであり自動取得はしないので、 いつの間にかリモートリポジトリ側と不一致になっていたということも有る。
Trunk Based Development
One line summary A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. * main for the Git community since 2020 (master with unsavory connotations before) Sh
git rev-parseを使いこなす - Qiita
こんにちは！ Gitを使っているとプログラムからGitのメタ情報を取りたい！ってこと、よくありますよね？ でも、 git status をgrepしたりしていませんか？？ git rev-parse から取れる情報もたくさんあるんですよ！ というわけで git rev-parse のちょっと凝った使い方を説明します。 そもそも git rev-parse ってなによ？ Pick out and massage parameters とのことです。 ちなみに、Google翻訳によると「選ぶとマッサージパラメータ」って出てきました。 つまり、(与えられたモノが)何なのかを明らかにすることと、(gitの)パラメータを出力することができるやつってことです。（雑）
誤って削除した git stash を戻す | DriftwoodJP
git stash drop や clear の間違いを戻します。 最近、まじめに branch をまたぎながら開発を進めていて、git stash を使うようになりました。 Git – 作業を隠すgit stash すると、変更内容がスタックに保存されます。 作業完了後、git stash drop などで削除します。 ここで間違った場合の復旧方法。 スタック削除の手順スタックを確認。 % git stash list stash@{0}: WIP on feature/issue#2: 3232ce5 fix: install bug stash@{1}: WIP on feature/issue#2: 4364647 update: config files
gitignore に書くべきでないものは gitignore_global へ - Qiita
TL;DR github/gitignore にあるか github/gitignore - Global にあるかで判断 gitignore_global とは 自分一人の環境のみに存在するようなファイルをプロジェクト内の .gitignore ファイルに書き込むのは賢いとはいえないし, 気持ちが悪い そこで自分のPC上でのみプロジェクトの特定のファイルを ignore する事ができるのが gitignore_global git config --global core.excludesfile ~/.gitignore_global とか .gitconfig ファイルいじって有効化が必要 参考: グローバルで.gitignoreを適応する http://qiita.com/katsew/items/5cade12fa743a2f31f25 使い方は .gitinore と同様に ~
git diff や git status での日本語の文字化けを防ぐ (core.page, core.quotepath)
git diff での文字化けgit diff の出力に日本語が含まれているときに、下記のように２桁の数値ばかりの表示に文字化けしてしまうことがあります。 $ git diff diff --git a/README.txt b/README.txt index 0005c4e..5d6ea9c 100644 --- a/README.txt +++ b/README.txt @@ -1 +1 @@ -<E3><81><82><E3><81><84><E3><81><86><E3><81><88><E3><81><8A> +<E3><81><8B><E3><81><8D><E3><81><8F><E3><81><91><E3><81><93>
githubとgh:eを間違えないためのgitサブコマンドを作った - Qiita
https://github.com/Hi-king/git-confedclone を作りました。 普段会社ではgithub enterpriseを使っているのですが、OSSの仕事でgithubの方にコミットする事もしばしばあります。さらに業務以外のgithubレポジトリにコミットする事もしばしばあるので、ここで問題となるのが、プライベートなプロジェクトに会社のメールアドレスでコミットしてしまう事件です。 configを明示的に書かないとリモートにpushできない設定 git config --global user.useConfigOnly true しておくと、環境変数からemail取ってきて勝手に使っちゃう事がなくなるので、各レポジトリ毎に明示的に git config user.email xxxx@yyyy する必要が出るので、事故らなくなります。( see http://q
リポジトリごとに user.name や user.email の設定を強制する - Qiita
社内やオープンソースのプロジェクトに並行して参加していると、gitconfig の user.name や user.email をリポジトリごとに切り替えたくなることがある。リポジトリを作るたびに git config user.name "My Name" すればいいのだが、 user.name が存在しないか空文字列だと環境変数 NAME の値を暗黙的に使う仕様になっているため、設定をうっかり忘れてしまうとなかなか気づけない。名前やメールアドレスを間違えたまま何度もコミットしてしまうと修正が厄介である。 Git 2.8以上 最近の Git で設定忘れを未然に防ぐには git config --global user.useConfigOnly true を実行する。これを設定するとユーザー情報について環境変数を暗黙に参照することがなくなる。グローバルな gitconfig で use
リモートリポジトリのブランチを一気に削除する - Qiita
リモートリポジトリのブランチを削除したい もう使わないので整理。 マージ済みのやつは問答無用で削除。 マージ済みでないやつは、開発中のブランチは削除しない。 ***リモートの削除なので、削除されるブランチを一旦確認してから実行してください。*** 作業の前後でfetchして最新にしつつ $ git br -a | grep origin/ | wc -lとかすれば削除されているのが確認できる。 以下のマージ済/未マージの分け方は、わかりやすいから分けているだけ。最初の一覧はgit br -aとかで一気に指定してもOK 環境 Mac 手順 追跡ブランチを最新にする リモートリポジトリ（ex. originリポジトリ）のマージ済みブランチを削除 1. マージ済みの追跡ブランチ一覧 2. originリポジトリの追跡ブランチ一覧 3. master、HEAD（よくわからん）を除く 4. orig
gitリポジトリをshallowに変換 - ゲームエンジニアな日々
環境 git-1.7.4 $ git clone --depth=1 https://hoge.com/hoge/hoge.git とかでリポジトリをshallowクローンできるのは知っていたのですが、通常のリポジトリを簡単にshallow化する方法を発見したのでメモメモ。 $ git clone https://hoge.com/hoge/hoge.git hoge $ cd hoge $ git log --oneline | wc -l 540 $ du -sh .git 144M .git hogeは架空のリポジトリです。普通にcloneしたらこのリポジトリは540コミット、144Mほどの容量でした。 んで、shallow化します。 $ git fetch --depth=1 $ git log --oneline | wc -l 2 $ du -sh .git 144M .git
Git for Windowsでシンボリックリンクを扱えるようにする - Qiita
概要 Git for Windowsはデフォルトでシンボリックリンクが扱えないようになっています。しかしそれではUnix系OSとリポジトリを共有して開発する場合などで不便なため、Unix系OSと同等にシンボリックリンクを扱えるように設定します。 内容としては、↓の元ネタを整理・補足するようなものとなります。 元ネタ：Symbolic Links · git-for-windows/git Wiki 元ネタ2：Git for Windowsでのシンボリックリンク | OPC Diary ↑のページの日本語による解説 確認した環境 Windows 10: build 14986.1001 Git for Windows: 2.11.1.20170208 Polsedit: 1.0.0.5 事前準備：一般ユーザにシンボリックリンクを作る権限を与える Windowsでシンボリックリンクを作成するに
Gitのコミットメッセージを後から変更する方法をわかりやすく書いてみた | 株式会社グランフェアズ
Posted by OOHASHI on Mar 2nd, 2017 こんにちは、ひさっしーです！ 今回は、久しぶりにGitネタです。 Gitを使っている方のあるあるかと思いますが、急いで作業している時にコミットメッセージを書き間違えたままcommitしてしまった！なんてことありますよね。 また、グランフェアズではBitbucketで課題を発行してタスクをこなすことがあるので、コミットメッセージに「refs #25」などをつけてコミットを該当の課題と関連付けたりするのですが…これを書き忘れたり、間違えて違う番号にして関連付けをミスったり…ということもあったりします。 コミットメッセージを書き間違えた！ 課題との関連付けをし忘れた！ そういった迷えるうっかりさんを救う、「コミットメッセージを後から変更する方法」を今回はご紹介します！ 【初級編】直前にコミットしたメッセージを変更する 例えばこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでファイル名の大文字・小文字の変更を検知するようにする - Qiita
https://www.freia.jp/taka/blog/windows-native-ssh-client/index.html
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳）
横着で神経質な私とあなたに贈るgit add -p - Qiita
