git diff で特定のパスの差分は表示しないやり方のメモ。 git diff コマンドは任意のコミット間での差分を表示するコマンドでこんな感じに使える。以下の例は差分が多くなるので --stat オプションを指定して差分があるファイルの名前だけ表示している。 $ git diff --stat 2d5ff09^.. README.md | 21 +++++++++++---------- README_ja.md | 21 +++++++++++---------- api.go | 18 ++++++++++-------- graph.go | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------- pixel.go | 45 +++++++++++++++++++++

How atomic Git commits dramatically increased my productivity - and will increase yours too Atomic: of or forming a single irreducible unit or component in a larger system. Also available on my blog. Knowing VS Actually Knowing I remember when my first mentor told me about Test-Driven Development. A great methodological approach to software engineering. It took me just a few minutes to understand

ホームソフトウェアLinus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス Linus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス 2023 2/22 LinuxおよびGitを開発したLinus Torvalds氏が、Gitのマージに関して直々にアドバイスしていた事がわかり、注目を集めています(Phoronix)。 Linus Torvalds氏のGitマージに関する実践的なアドバイスは「もしマージのことを説明できないのなら、やらないことだ。これは本当に簡単なことです。マージの理由を説明しないままマージすることは絶対に許されない」というものです。 Linus氏はマージに対するコメントが十分に含まれていないプルリクエストを発見し、我慢の限界を突破し

歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p

チームで共通のフックスクリプト(Git hook)を使っています Gitでバージョン管理されたスクリプトをフックスクリプトとして実行するために core.hooksPath の設定を利用 core.hooksPathを変えたことを忘れると .git/hooksにフックスクリプトを追加したのに動かない！ということになるので注意が必要 サービス開発グループの石川です。 今回のブログでは、チームで共通したGit hookのフックスクリプトによってコミット前のチェックをしている話をしようと思います。 Git hookとは？ Gitで特定のアクションが発生したときにカスタムスクリプトを実行する方法です。 詳細: https://git-scm.com/book/ja/v2/Git-のカスタマイズ-Git-フック 利用しているフックスクリプト 「git commitコマンドを実行した際、変更されたファ

1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git

Gitには、リポジトリに含めたくないファイルを指定できる .gitignore というファイルがあります。 通常は、これ自体リポジトリにコミットされ、チームで共有されます。 この.gitignoreファイルに、 .DS_Store(Mac環境で自動的にOSが生成するファイル)や、.swp(vimが一時的に生成するスワップファイル)など個人環境に依存するファイルは指定すべきではない、という話をツイッターで見かけて気になりました。 筆者は、これまで、こういったファイルを積極的に指定するようにしていたからです。 .DS_Storeなどを入れるべきでない理由 .gitignoreに.DS_Storeやなどを指定すべきでない理由として上げられているのは、vimのユーザーが参加したら.swpを、 VS Codeユーザーが参加したら.vscode、Windowsユーザーが参加したらThumbs.dbとい

npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes

Gitのコミットメッセージの書き方 Gitのコミットメッセージの書き方は、多くのwebサイトや書籍では2行目を空行とする、と説明している。 Git ではコミットメッセージの形式に関して制約はありませんが、1 行目にコミットの全体的説明を 50 字以内で記述し、2行目は空白行とし、3行目以降に変更内容の詳細を記述するのが標準的な形式です。 Atlassian Gitチュートリアル The git commit Commandより GitHubのOS X用クライアントでは、そもそもコミットメッセージの2行目に何かを書くことはできない。では、書くとどうなるのか。 実践 リポジトリを新規に作成し、README.mdを作成した。そしてコミットメッセージを以下のように記述して、コミット。 プラグインか何かの働きかと思うが、2行目が注意色になっていて、あからさまな警告を感じるが、何もエラーメッセージを吐

これは本当にとても便利なgitのログ機能なんですが、 `git log -L :関数名:ファイル名` でその関数の履歴が見れます https://t.co/wcul1OYr0W

複数のバージョンの並行開発でDBスキーマが異なる場合、DBの接続先切り替えが非常に厄介。 そこでdatabase.yml内では式展開できることを利用し、 以下のようにするとgitブランチ名に応じて接続先を変更することが可能になる。 default: &login username: root password: hogehoge adapter: mysql host: localhost encoding: utf8 reconnect: true pool: 5 development: database: db_<%= branch = `git symbolic-ref --short HEAD`.chomp if branch == 'master' 'master' elsif branch.start_with?('fix_') 'fix' elsif branch.star

この記事で説明したGitの話には、私の誤解が含まれています。コメントまで見てください。（EFSにリポジトリを置くと遅いのは本当。） 先日教えてもらったのですが、Amazon EFSというめちゃくちゃ便利に見えるサービスがあります。 複数のEC2インスタンスで共有できるストレージ 事前に容量を決める必要がない（使ったら使った分だけ増えていく） 要するにNFSで、EBSと違って複数のEC2インスタンスから共有できるのが特に便利に見えます。具体的に言うと、SideCIでgit cloneしてきたリポジトリを保存して共有するのに最適に見えます。（見えました。） SideCIでは、Gitリポジトリの操作を抽象化したサーバの開発を現在進めていて、 git cloneして欲しいリビジョンをgit archive git diffして変更された行を特定 などの操作をWeb API経由で実行できるようになり

概要 やむを得ない事情でgitアカウントが複数あり、会社用アカウントと個人用アカウントなどを分けたいケースがあると思います。 そういったときは、会社用アカウントで作業するフォルダと個人用アカウントで作業するフォルダを分け、gitconfigの includeIf で このフォルダ配下ならこのアカウントを使うよ という設定を書いてあげるとよさげです。 ベースとなるgitconfigを作り、分けたいアカウントの数だけ[user]だけ描いたgitconfigを作ってincludeIfで参照するといい感じだと思います。 ベースgitconfig 省略 # workフォルダの時会社用gitアカウントに切り替え [includeIf "gitdir:~/project/work/"] path = ~/.gitconfig-work # otherフォルダの時は個人用アカウントを使用する [inclu

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

GitExplorer: Find the right git commands you need without digging through the web