20 Git Command-Line Tricks Every Developer Should Know
20 Git Command-Line Tricks Every Developer Should Know Git is an essential version control tool for developers. Although GUI tools can simplify some tasks, mastering the Git command line offers deeper control, flexibility, and speed. Here are 20 Git command-line tricks that every developer should know to streamline their workflow. 1. Set Global Configuration Ensure your commits are tagged with the
Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
時間がかかっていた git status を Trace2 で計測しながら10倍速くした話 - Mirrativ Tech Blog
環境 改善前 改善前計測 untrackedcacheを使った高速化 file system monitorを使った高速化 サブモジュールをオフにして高速化 Appendix: Gitバージョンアップ実験結果 まとめ We are hiring! こんにちは。バックエンドエンジニアのshirakawaxです。 Mirrativのバックエンドリポジトリのgit statusが遅かったので1.941秒 → 0.173秒に改善した話を書きます。 環境 Apple M1 Max メモリ 64 GB macOS Sonoma 14.4 $ git -v git version 2.39.3 (Apple Git-146) 改善前 私の環境では改善前のgit statusは1.941秒かかっていました。 頻繁に実行するコマンドではないですが、若干ストレスになっていました。 $ time git sta
難しいGitコマンドは、仕組みから理解してみよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらはLife is Tech ! Advent Calendar 2016 22日目の記事です。 自己紹介 こんにちは！先日GitHubのIDがha1fha1fからha1fになりました、はるふ(@_ha1f)と申します。 Life is Tech ! では、主にiPhoneコースのメンター・講師をしています。 本記事について Gitについての記事は、世の中に多くあります。 gitコマンドの使い方 gitの仕組み gitを用いたプロジェクト管理・運用 subversionなどとの比較・歴史 など、テーマが色々有ると思いますが、本記事で
git-cherry-pickを掘り下げる - idesaku blog
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
tigでgitをもっと便利に！ addやcommitも - Qiita
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
超絶便利なGitクライアントのtigのすすめ - Qiita
mainビュー m mを押すとmainビューが表示されます。 tigの起動時にも表示されるビューです。いわゆるgit treeのビューです。 enterでそのコミットの詳細を見れたり、C(shift+c)でcherry-pickしたりできます。 statusビュー s sを押すとstatusビューが表示されます。git statusのビューです enterでファイルの変更内容を見れたり、stage/unstage(add/reset)をしたりできます。 refsビュー r rを押すとrefsビューが表示されます。branch, tagsなどが一覧されます。 enterでmainビュー(git tree)が見れたり、C(shift+c)でcheckoutしたりできます。 logビュー l lを押すとlogビューが表示されます。git logです。 enterでそのコミットのdiffが見れたり
Gitのコミットの裏側で起こっていること - LIVESENSE ENGINEER BLOG
はじめまして。１ヶ月でエンジニアになろうとした山浦です。 先日Gitのことを突っ込んで調べる機会があり、Gitの仕組みって面白いねということを同僚に話していたら「面白いね。ところでGitって実装できる？実装できないと分かったとは言えないよね？」となぜか煽られるということがありました。 そうか、実装できないと分かったとは言えないのか、それも一理あるかもしれない。そう思い、Gitの仕組みを実装できるレベルまで掘り下げて調べてみました。 今回は実装はしないものの（過度に記事が複雑になるので）、Gitの根幹である git add コマンドと git commit コマンドの裏側で起こっていることを紹介します。 差分かスナップショットか？ ここで早速クイズです。 コミットで保存されているのはソースコードの差分でしょうか？スナップショットでしょうか？ 今回の記事の中で解説していきますので、少し考えなが
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
異なるgitリポジトリ間でもcherry-pickはできる - Qiita
（最初に修正を導入したリポジトリ内で） git remote add TO_FIX_REPO {これから修正を導入したいリポジトリのURL} git fetch TO_FIX_REPO git checkout -b TO_FIX_REPO-master TO_FIX_REPO/master git cherry-pick {master上の修正コミットのSHA1} git push TO_FIX_REPO TO_FIX_REPO-master:master （上記を修正を導入したいリポジトリの数だけ繰り返す） これならかなり機械的に処理できるから、だいぶ楽になるんじゃないだろうか。まぁだからといってコピペが横行して良いというわけではないが。 ちなみにgit push TO_FIX_REPO TO_FIX_REPO-master:masterってのも結構ポイント。ローカルのブランチ名とリモ
「追跡ブランチ」って言うのやめましょう - Qiita
TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか？ origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡する**リモート追跡ブランチ (remote-tracking branch)**である origin/master はローカルの ma
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
マージとリベース | Atlassian Git Tutorial
git rebase コマンドは、初心者は避けるべき Git の魔法の呪文であるという評判を得ていますが、実際には、慎重に使用すれば開発チームの作業を非常に容易にしてくれます。この記事では、git rebase を関連する git merge コマンドと比較し、典型的な Git ワークフローにリベースを組み込める可能性のあるすべての機会を特定します。 git rebase で最初に理解すべきことは、git merge と同じ問題を解決するということです。これらのコマンドは両方とも、変更を１つのブランチから別のブランチに統合することを目的に設計されています。ただし、実現する方法は非常に異なっています。 専用ブランチの新しいフィーチャーで作業を開始した後で別のチーム メンバーが main ブランチを新しいコミットで更新すると、何が起きるかを考えてみましょう。答えは、フォーク済み履歴が作成される
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
第1話 リポジトリを作ってコミットしてみよう【連載】マンガでわかるGit ～コマンド編～ - itstaffing エンジニアスタイル
Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。4月のイベントでは、Gitの基礎の基礎をお伝えしましたが、この連載コラムでは、「Git コマンド編」をマンガで解説します。 Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。今回は、ある程度のGUIでならGitは使えるけれど、コマンド操作は苦手という方のために、主人公のわかばちゃんがカンタンなGitコマンドを実践していきます。みなさんも一緒に操作してみましょう！ 【筆者】湊川 あいさん フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』『わかばちゃんと学ぶ Webサイト制作の基本』『運
大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog
ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全ブランチから文字列検索・全コミットから文字列検索 - Qiita
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
how to use git through a proxy
GitHub - extrawurst/gitui: Blazing 💥 fast terminal-ui for git written in rust 🦀
