たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita
追記 先日外部向けに、この記事の内容に追加補足などを加えて発表しました。動画のアーカイブ、資料も公開しましたので、もし動画の方がわかりやすい方はこちらをオススメします。 注意: 動画の質疑の中で、 github のリリース機能が、アノテートタグを使っていると明言してしまいましたが、間違いです。gitのデータ上はただの軽量タグで、 release の内容は軽量タグに紐づく形で、 github のアプリケーション上で管理されているはずです。 はじめに 調べてもう1年放置していた内容なんですが、アドベントカレンダーで重い腰を上げました。 Gitの内部の仕組みを知りたい（動機） 毎日使うといってもいいGitですが、どうやって履歴を管理してるんだとか、よくわからないまま使っているのが急に怖くなりました。 Gitを触り始めで、よく以下のような疑問が沸くと思います。 どうやってGitは履歴を管理してるん
Commits are snapshots, not diffs
EngineeringCommits are snapshots, not diffsGit has a reputation for being confusing. Users stumble over terminology and phrasing that misguides their expectations. This is most apparent in commands that "rewrite history" such as git cherry-pick or git rebase. In my experience,… Git has a reputation for being confusing. Users stumble over terminology and phrasing that misguides their expectations.
A new hash algorithm for Git [LWN.net]
Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! The Git source-code management system is famously built on the SHA‑1 hashing algorithm, which has become an increasingly weak foundation over the years. S
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer
Bring your monorepo down to size with sparse-checkout
CommunityOpen SourceBring your monorepo down to size with sparse-checkoutGit 2.25.0 includes a new experimental git sparse-checkout command that makes the existing feature easier to use, along with some important performance benefits for large repositories. This post was written by Derrick Stolee, a Git contributor since 2017 who focuses on performance. Some of his contributions include speeding u
gitのdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
Git(Hub)+CircleCI+Slack で実現する静的コンテンツ配信システム - BASE開発チームブログ
BASEでエンジニアリングマネージャーを担当している加賀谷です。普段は採用に携わったり、1on1での経験学習の促進などを通じて、個人と組織のアウトプットが大きくなるようにサポートする仕事をしています。また、サービス開発に関わる体験を良くしていくこともしています。その中で今回は、静的コンテンツのCI/CDでしていることを紹介したいと思います。 静的コンテンツのホスティング 静的コンテンツは、サーバサイドでリクエストに応じてレスポンスする内容を作成しないデータです。主に、サイト内で使う画像、CSS、JS、ランディングページなどのHTMLファイルになります。これらのファイルはよく、AWSのS3に置いてホスティングして前段にはCDNを配置し、Webブラウザの同時接続数を考慮してサービスとは別のホストに分散したりしますが、BASEでもそうしています。 静的コンテンツ用のGitリポジトリを用意 CSS
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
GitHub のプルリクで blame する ghpr-blame.vim つくった - はやくプログラムになりたい
先日 kazuho さんが git blame でプルリクを表示するスクリプトをつくってらっしゃって，便利そうだったので Vim プラグインをつくってみました． ファイルの各行がどのプルリクで変更されたかを確認し，気になるプルリクはその場で詳細を確認することもできます． github.com 使い方 インストールはお好みの Vim プラグインマネージャを使うなどしてください． 1. ファイルを開いて :GHPRBlame を実行 :GHPRBlame を実行すると裏で git-blame が走り，カレントバッファのファイルの各行のプルリク情報を git blame --line-porcelain で引っ張ってきます． 引っ張ってきた情報を元にカレントバッファの左に細長い一時バッファが開き，そこに各行に紐付いたプルリク番号が表示されます（プルリクに紐付いていない行は何も表示されません）．
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
Oh, shit, git!
Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem. So here are some bad situations I've gotten myself into, and how I eventually got myself
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
gitでファイルの一部だけコミットから無視する - Qiita
やりたい事 ファイルやディレクトリは.gitignoreに指定すれば良いが、 ファイルの一部分(特定の行など)だけ無視するにはどうすれば良いのか? 例えば認証が必要なProxy環境でgitを使用する場合は以下のプロキシ設定が必要だが、 パスワードを含む部分だけはリポジトリにはコミットしたくない。 [core] quotepath = false autoCRLF = false : [http] proxy = http://username:password@proxy.sample.jp:8080 [https] proxy = http://username:password@proxy.sample.jp:8080
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
Atlassian "logo" after pushing to bitbucket
2024 Developer survey is here and we would like to hear from you!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社会で生き残るためのgit
Commit message will never die
Gitでブランチを作るのを忘れてmasterにコミットしてしまったときの対処法 - Qiita
Git Page Time-Machine
git configをプロジェクトによって使い分ける - Qiita
