コードベースのどのへんを触ったことがあるかを一覧する - 見返すかもしれないメモ
今所属してるチームに入ってから1年が経った。開発してるサービスのコードベースの中でも、「このへんはわりと土地勘がついてきたな」という場所と「ここはまだ全然わからん」という場所が混在している感じになってきた。 自分がまだ触ったことないのはどのあたりかを知りたかったので、今までの自分のコミット数をファイルごとに見れるようにしてみようと思った。調べてもそういうツールは見つからなかったので、作った。 ファイルの履歴 ファイルのコミット履歴を出力する: git log ファイル名 リネーム前の履歴も欲しい: git log --follow ファイル名 しかし --follow つけると、ファイルをコピーしてからちょっと編集したやつも同一ファイルと見做されてしまうので、それをなるべく避ける*1: git log --follow --find-renames=100% ファイル名 そのコミット履歴を
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
分散VCSのモデル、あるいはPijulについて | κeenのHappy Hacκing Blog
先日、Pijulという分散VCSについて知って、それについて調べてみたら少し面白かったのでメモ。 DVCSで一番有名なのは間違いなくGitだろう。あれは分散グラフ理論木モデルに基いているらしい。ベースになったモデルがあることに驚いたが、調べても出てこなかった。 Gitは高速で信頼性が高い一方、コミット同士をチェーンのように繋げてしまうので柔軟性を欠き、例えばCherry Pickなんかがやりづらい。 あるいはリモートのmasterを取り込まずにローカルのmasterにコミットすると互いに独立した変更であっても一旦remote masterをマージしないとプッシュ出来ず、コミットグラフが汚れてしまう。 また、CUIが直感的でなく、理解しづらいという声もある。それはこういう皮肉にも現れている まあ、言われてみれば私もこのスライドを見てようやく理解した。 他のVCSにも色々特色はあって、歴史は神
git rebaseが捗るオプション紹介 - madokaのブログ
git rebaseでfixupやsquashをよくつかうわたしが出会って感動したオプションたちを紹介してこうと思います。 rebase.autostash git rebase を行うとき、編集差分がある状態では実行できないため、stashして下さいてきなコメントが出てやり直しとなってしまうのが、なんとも面倒臭いと思うのです。 これを払拭するのがautostashです。 git rebase を実行した際に自動でgit stashを行い、rebaseの作業に移ります。そして、rebase作業が終わった際にはstashしたものを戻すgit stash popまでを自動でやってくれるというものです。ぜひ、おすすめしたい、、！ rebase.abbreviateCommands git rebase -i で作業するとき、毎度出てくるこの画面。 pick 5f818fa edit file p
ファイルの表示 - GitHub Docs
GitHub で、リポジトリのメイン ページに移動します。 クリックして、表示したい行の履歴のファイルを開きます。 ファイルの内容の上にある [Blame] をクリックしてください。 このビューには、1 行ずつのリビジョン履歴とコミットごとに区切られたファイル内のコードが表示されます。 各コミットには、作成者、コミットの説明、コミット日が一覧表示されます。 特定のコミットの前にあるファイルのバージョンを表示するには、 をクリックします。 または、特定のコミットの詳細を表示するには、コミット メッセージをクリックします。 生コード ビューに戻すには、ファイルの内容の上にある [コード] をクリックします。 マークダウン ファイルを表示している場合は、ファイルの内容の上にある [プレビュー] をクリックして、Markdown の書式設定が適用されたビューに戻ることもできます。 [変更履歴] ビ
Git で特定の行が追加/削除されたコミットを探す - BattleProgrammerShibata
ソースコードを追いかけていると、昔ここにあった、なかったというコードについて思いを馳せる必要があり、どのコミットで、どういう経緯で追加/削除されたのか知りたいという場面に出くわすことがある。 この場合、次のコマンドで検索文字列に掛かるコミットを検索することができる。 $ git log -S "検索文字列" -S については、次の Git Log Searching の項で解説されている。 git-scm.com Git Log Searching Perhaps you’re looking not for where a term exists, but when it existed or was introduced. The git log command has a number of powerful tools for finding specific commits by
gitのdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
Highlights from Git 2.23
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
git gone: stale なローカルブランチのクリーンアップ · eed3si9n
2018-09-15 / git GitHub の pull request を中心に作業していると、やたらといらないブランチがローカルに溜まってくる。本稿では、このいらないローカルブランチを掃除する方法をみてみる。 基本的に 2つの戦略があると思う: “master” ブランチを選んで、そこにマージ済みのものを削除する GitHub 上で既にブランチは削除されている前提で、リモートの “origin” にはもう無いローカルのブランチを削除する Erik Aybar さんの Git Tip: Deleting Old Local Branches というブログ記事は第2の方法をとっている。 This just helped clean up 150+ old local branches for me this morning, so I thought I should share! #
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0-beta.2 Summary As an open-source maintainer, squash feature branches onto master and write a standardized commit message while doing so. The commit message should be structured as follows: <type>[optional scope]: <description> [optional body] [optional footer] The commit
Commit together with co-authors
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
意外と知らないIntelliJ IDEAのGit管理機能いろいろ（´-`） - Qiita
新卒２年目の大久保です。（´-`） IntelliJ IDEA使い始めて結構経つんですが、未だに機能を活用しきれてないなと感じます。。（´-`） 特にGit周りに関しては知ってると便利な機能いろいろあるので、学習も兼ねていくつかピックアップしてまとめてみました。（´-`） 例で使用しているコードの言語はScalaです。 Annotate機能 現在表示されてるファイルの各行の最終更新日と更新者を確認 ファイルの行番号とかの横にGitのコミット情報を表示できます。 git blameとほぼ同じですね。 ＜やり方＞ 行番号が表示されてるとこを右クリック -> [Annotate]選択 コミットの差分を表示 Annotateによって表示された行を選択することで、そのコミットにおける各ファイルの差分を表示できます。 ＜やり方＞ 行番号が表示されてるとこを右クリック -> [Annotate]選択 -
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
本の虫: GCCのgit移行が難航中
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hub-sync(1) - Fetch git objects from upstream and update local branches.
GitFinder - git client with Finder integration
GitHub - rhysd/git-brws: Command line tool to open repository, file, commit, diff, tag, pull request, blame, issue or project's website in browser for various repository hosting services.
http://erikaybar.name/git-deleting-old-local-branches/
