はじめに 突然ですがみなさんはgit blameしてますか? 私は毎日git blameしています! git blameした結果、その差分をコミットしたのは過去の自分と知るのは日常茶飯事です。 git blameはコードリーディングの強力な味方ですが、LinterやFormatterをコードベース全体に適用すると、差分の情報がそれらで上書きされてしまい情報量が減ってしまいます。 そのような場合はgit historyで歴史を遡るしかないのでしょうか? いいえ、git v2.23から追加された--ignore-revオプションで指定したコミットをblameから除外することができるようになりました。 git blame --ignore-revの使い方 --ignore-revにコミットハッシュを渡すとそのコミットはblameから除外されます。 # コミットハッシュは架空のものです $ git
こんにちは、SWETでCI/CDチームの前田( @mad_p )です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
Products Featured Developers Product Managers IT professionals
偉大なリポジトリの一部だけを利用したい Gitで特定のファイルやディレクトリだけcloneしたい おそらくあなたがやりたいのは Sparse checkout ではないでしょうか 先人の情報によれば「とりあえず普通に clone する」という例が多いのですが、ファイル数が多い場合など、すべてを clone したくない場合もあります。 そのような場合は下記のようにして sparse checkout を有効にします。 リポジトリの内、必要となるのはコンパイルされたヘッダファイル 1 つだけ ということがそれなりにあるので sparse checkout ができるとそういう時に便利そうだ。 ただ、調査した感じでは大規模なリポジトリの一部だけを利用するという用途の場合、 sparse checkout と submodule を組み合わせる必要があるらしい。 わからないことは 1 つずつチェック
A long-standing objection to making bulk changes to code using automated tools (e.g. to conform to a given code style) is that it clutters the output of git blame. With git 2.23, this does not have to be the case anymore! In this post I will start by explaining the value of git blame and how commits with style changes in bulk can be problematic. If you already understand this problem and just want
はじめに 今年もアドベントカレンダーはじまりました! この記事はHamee Advent Calendar 2018の1日目の記事です。 Hameeのエンジニア(一部デザイナー)が自分の興味あるテーマについて書いていきます。 毎年一緒に参加して盛り上げてくれる皆さんに感謝です 本題 さて本題ですが、常々思っていたんですがgitの差分を表示する時に「違う、そうじゃない」ってなることが多々あり、何とかしたいと思ったので調べました サンプルコード 言語はなんでもいいんですがとりあえずPHPにしておきます。 例えば以下のコードがあったとしましょう。 <?php class Test{ public function hoge(){ return 'hoge'; } public function moge(){ return 'moge'; } }
git diffで1行にデータが詰まっているJSONをいい感じに差分表示する方法 jqをインストール $ brew install jq Gitの属性を付ける(*.jsonにマッチするファイルはdiffの前にjsonフィルタを通すように) $ echo "*.json diff=json" >> .gitattributes または $ echo "*.json diff=json" >> .git/info/attributes jsonフィルタを設定 $ git config diff.json.textconv "jq -S ." あとは普通にgit diffすればOK git diffではなくて単純に2つのファイルの差分を見たいだけならばjson-diffを使うといい $ npm install json-diff $ json-diff original.json modifie
Supercharge Git within VS Code — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more GitLens — Supercharge Git in VS Code Supercharge Git and unlock untapped knowledge within your repository to better understand, write, and re
git diff は色んな場面で本当によく使うんですが、できることが多いだけに全然覚えられずに毎回調べてしまいます。 なので、場面ごとに使えるコマンドを一覧でまとめてみました。 先にワークツリーとインデックス【Gitの基本】- サルでもわかるGit入門を読んでおくと、ここに書いてある diff について理解しやすいと思います。 git pull する前にリモートとの変更点を見る git pull をする前にローカルの最新コミットと pull 先のリモートリポジトリとの変更点が見たいときはこのコマンドで見れます。 ここでいうリモート名は origin とかそういうやつです。 git push する前にリモートとの変更点を見る 上記のコマンドは、こんな感じで逆にもできます。
git で管理しているプロジェクトの中に他の git プロジェクトを混ぜる方法を書きます。例えば私の lispコンパイラ tamacola では、abcsx という別のレポジトリにあるアセンブラを使っているんだけど、これをライブラリとして使いたい。しかも単にコピーするだけじゃなくて、もしも abcsx を変更した時に、その変更点を元のレポジトリにも反映したい。そんな状況です。 そこで役立つのがサブマージツリーという仕組みです。普通 git では二つのプロジェクトを混ぜて一つのレポジトリを作りたいとき、一つのディレクトリに二つのプロジェクトが混ざってしまいます。サブマージツリーを使うと、ライブラリとして使いたい方のプロジェクトをサブディレクトリとしてマージする事が出来ます。 サブマージツリーを使った作業ツリーの作り方。 まず、あなたはとある git レポジトリ上で仕事をしているとします。ab
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
Backlogチームのnabe_です。もっぱら仕事はJavaとScala、最近の趣味は Go言語 です。今回、 Go言語 で nulab/go-git-http-xfer という Git ライブラリ を書いたので紹介させていただきます。 役割 動機 仕組み 使い方 試用 まとめ 役割 このライブラリを使うと、GitのリモートリポジトリへHTTPでアクセスするためのサーバーを作ることができます。HTTPアクセス自体は、BacklogやGithub等のGitをホスティングしているサービスであれば概ねサポートしているので、普段あまり気にすることはないかと思いますが、独自にGitを運用している場合、リモートリポジトリの前に clone、push、fetch 等で発生するHTTP通信を捌く仕組みを、なにかしら用意しなければなりません。 動機 私自身まだまだGoのニュービーなのですが、兎に角手を動か
こんにちは@a_suenamiと申します。 これはGit Advent Calendar 2012の22日目の記事になります。(なんか日付を間違えてしまっていたらしく1日遅れてしまいました。。ごめんなさい。) Gitは非常に強力な機能を数多く有しているバージョン管理システムですが、rebase機能は間違いなくその最たるもののひとつでしょう。 今回はrebaseについて書いてみようかと思います。 rebaseとは そもそもrebaseとは何でしょうか。コマンドのマニュアルについては以下のようになっています。 http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html 要するに、ローカルリポジトリに作成された一連のコミットがリモートリポジトリのHEADの子孫となるようにコミットの履歴を再構成する行為のことです。 rebaseの
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか? 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く