Jujutsu（jj）完全ガイド：Gitを超える次世代バージョン管理システムの実践活用法
Jujutsu（jj）完全ガイド：Gitを超える次世代バージョン管理システムの実践活用法 はじめに Jujutsu（ジュジュツ、通称jj）は、Googleのエンジニアによって開発された次世代のバージョン管理システムです。「Gitと100%互換性がありながら、より使いやすい」という一見矛盾した目標を見事に実現しています。 本記事では、Jujutsuの基本概念から実践的な活用方法、さらにはAIツールとの並列開発まで、包括的に解説します。 目次 なぜJujutsuなのか？5分で分かる革新性 30秒で始めるJujutsu Gitユーザーが最初に知るべき5つの違い 実践：日常開発でのJujutsu活用法 コンフリクト処理の新しい考え方 GitとJujutsuの併用パターン AIツールとの並列開発 アーキテクチャ解説（上級者向け） よくある質問と移行ガイド なぜJujutsuなのか？ Gitの問題を解
git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 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のdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
Spring Boot Gradle Plugin を使ってビルド情報をアプリケーションに埋め込む
Gradle で管理されている Spring Boot アプリケーションのバージョン情報などをアプリケーションコードから動的に参照できるようにするためのメモです。 ビルド情報を Spring Boot アプリケーションに埋め込む 具体的にやるべきことは リファレンス にも書かれているとおり、以下の 2 つだけです。 Spring Boot Gradle Plugin を利用する build.gradle ファイルに以下を記述する 試しに、上記設定を記述した状態で ./gradlew bootBuildInfo を実行すると、build/resources/main/META-INF ディレクトリ配下に以下のような、バージョン番号などビルドされる (された) アーティファクトに関わる内容の build-info.properties ファイルが生成されます。 build.artifact=s
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Gitでcommitやpushを忘れることありませんか？git-remindはそういう｢忘れ｣を防ぐためのツールです - Qiita
うっかりGitのコミットやプッシュを忘れてしまうことはないだろうか？ git-remindはそんな(僕のような)忘れっぽい人のためのツールで、Gitリポジトリの状態を監視して、git commitやgit pushがなされていないリポジトリを見つけ教えてくれる。 主な機能 git commit/git pushしてないリポジトリの一覧機能 複数のGitプロジェクトを横断して、コミットされていないファイルがあるリポジトリや、コミットはされているけどgit pushがまだされていないリポジトリを見つけ出して一覧にしてくれる。 デスクトップ通知 未コミット、未プッシュのリポジトリを一覧できる他に、それらのリポジトリがあればデスクトップ通知で教えてくれる機能もある。macOSの場合、通知センターに表示される。試したのはmacOSだけだが、git-remindの内部実装としてはgen2brain/b
アクセスキーのコミットを抑止できて安全便利な awslabs/git-secrets - kakakakakku blog
GitHub で awslabs のリポジトリを眺めてたら git-secrets という便利なツール（シェルで実装されてる）を発見した． どんなものかを簡単に説明すると，アクセスキーなどを誤ってコミットすることを Git の hooks を使って未然に防ぐツールで，誤って GitHub に push してしまったために，AWS を不正利用されてしまった，みたいな事故もたまに聞くし，そういうのを防ぐことができる．非常に良かったので，一部のリポジトリに git-secrets を設定した． github.com インストール make install でも良いけど，Mac なら brew が使える． $ brew install git-secrets インストールすると git secrets コマンドが使えるようになった． $ git secrets usage: git secrets
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめに ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、こ
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
トピックブランチ内の変更を無視してgit bisectする方法 - kazuhoのメモ置き場
merge commitについては1st parentのみをたどりながらgit bisectしたいことってありますよね？ (参照: テストファーストなGitワークフローについて - kazuhoのメモ置き場) そういうとき、1st parent以外に属するcommitをgit bisect skipするの、どうやったらきれいに書けるのかなと思ってたのですが、以下のやりかたが一番よさげ。 $ git bisect skip $(comm -23 <(git rev-list HEAD | sort) <(git rev-list --first-parent HEAD | sort)) thanks to: ひろせ３１ on Twitter: "@kazuho comm -2 -3 <(cat A|sort) <(cat B|sort) とか？", Masakazu Takahashi on
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Emacsパッケージ特集 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? バージョン24から入ったpackage.elにより、プラグインの導入が格段に容易になったEmacs。そこで、ELPA互換のリポジトリの一つであるMELPAのダウンロードTOP50+αのパッケージについてまとめてみた。 （ランキングに関しては2014/3/26時点の情報を使用） それ単体で便利というよりも、有名なパッケージの依存関係でダウンロードされるライブラリもあるので注意。 ちなみに、個人的なオススメパッケージは、auto-complete、helm、flycheck、undo-tree、zenburn-theme、expand-re
gitの新人研修でtigを使うことをおすすめする理由 - Qiita
はじめに ４月まで残すところ２ヶ月と迫り、新卒などを対象とした新人研修の準備が始まっている頃かと思います。 新人研修の中でgitを教える際に、筆者はtigの活用をおすすめしています。 講師の立場からすれば、短い時間に高効率でgitの本質を伝えることができます。 研修生の立場では、tigを利用して簡単で直感的にgitリポジトリを閲覧・操作することができます。 tigを使うとどうしてそうなるのか、いくつかの理由を以下に紹介します。 セットアップが簡単ですぐ使い始められる tigは依存関係が少なくポータブルな実装でありインストールが簡単です。 会社から提供する開発サーバーであっても、社員ひとりひとりが所有するPCやMacであっても、 yumやbrewなどのパッケージマネージャから少ない手順でインストールすることができます。 一例: CentOS6.4にgit tigインストールと使い方 - Qi
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
git reset --hard HEAD を安全にした - 永遠に未完成
昨日、git reset --hard HEAD してしまって大変なことになった話を書いた。私は普段これを cancel と言う名前に alias して使っている。 [alias] # 中略 cancel = reset --hard HEAD しかし前回のようなことがまたあってはたまらない。人間はミスするものだ。 alias があって実行しやすいのが問題なのだろうか? いや、割とよくする操作*1だし、alias しなくても使うだろう。 てことで、cancel が安全になるようにしてみた。 [alias] # 中略 cancel = !git commit -a -m 'Temporary commit for cancel' && git reset --hard HEAD~ 一旦コミットしてからそのコミットを消す。こうしておけば最悪 git reflog から元に戻せる。特にコミットす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git checkoutを禁止してgit switch & git restoreを強制する養成ギブス git-switch-trainer - Qiita
[git]リモートで削除されたブランチがローカルに残っている時、一括で削除する方法 - Qiita![[git]リモートで削除されたブランチがローカルに残っている時、一括で削除する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/07a378b4c7b9456949fc961433e8c4e65feb0a51/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGODc0OCUyRnByb2ZpbGUtaW1hZ2VzJTJGMTQ3MzY4MTEzOD9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmYmc9RkZGRkZGJmZtPXBuZzMyJnM9ODJmNGUwNjJmZDcwZmRkYmMwNDYxYjc3N2FkZWZkYTY%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D34f139e0ff71658602cda2488217def5%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCZ2l0JTVEJUUzJTgzJUFBJUUzJTgzJUEyJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgxJUE3JUU1JTg5JThBJUU5JTk5JUE0JUUzJTgxJTk1JUUzJTgyJThDJUUzJTgxJTlGJUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUIzJUUzJTgzJTgxJUUzJTgxJThDJUUzJTgzJUFEJUUzJTgzJUJDJUUzJTgyJUFCJUUzJTgzJUFCJUUzJTgxJUFCJUU2JUFFJThCJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJTg0JUUzJTgyJThCJUU2JTk5JTgyJUUzJTgwJTgxJUU0JUI4JTgwJUU2JThCJUFDJUUzJTgxJUE3JUU1JTg5JThBJUU5JTk5JUE0JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9N2JlZGIxOWFiZDk4ZDJlZDUwZTBjODRhZjU3NTM3OTk%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBrX2tpbnVrYXdhJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9OTUyZDQwMzRlMmVlMzJlNGQ0MjAzZGQ0NTI0MmE0NmU%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D55b140fd8c231bed4d87d483d0caac78)
Jenkins git plugin 爆死事例集
