結局 Git のブランチ戦略ってどうすればいいの？ - Qiita
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
CopilotChatとNeovimでGitの効率を上げる
LazygitでCommit Messageを作成する 最近Git Commit MessageをCopilotChat.nvimに生成してもらっているのですが、その際の便利設定を紹介します。 CopilotChat.nvimについて詳しくは以下の記事を参照してください。 これは何をしているかというと ftplugin/gitcommit.luaにCopilotChatの設定を追加 gitcommitのバッファが開かれた時にCopilotChatを自動で起動 こうしておくことで shell commandでgit commitを実行するとNeovimが立ち上がる CopilotChatが自動で起動してCommit Messageを生成してくれる c-yで生成されたCommit MessageをBufferに貼り付ける。気に入らなかったら <leader>cで再生成 :qqでBufferの保
より良い Git コミットメッセージを書こう - Qiita
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
コミットログを楽に整形できるlazygitの紹介 | ランサーズ（Lancers）エンジニアブログ
QAチームのいさな(@isanasan_)です。今回は筆者のお気に入りのツールをご紹介します。 モチベーション 先週コードレビューについての記事を書きました。 ジョインから1ヶ月経ちコードレビューで気を付けていることをまとめた こちらの記事の中でrebaseを使ってコミットログを整形することがレビューコストの低下に繋がると書きました。 しかし筆者はgitをcli上で使いこなすのはそれなりに難しいものだと感じており、特にinteractive rebaseは初学者にとって非常にとっつきにくい機能だと思っています。 そこで、今回は筆者が愛用しているgitのクライアントツールであるlazygitを紹介します。本稿ではハンズオン形式でgitの歴史改変の操作を説明していきます。尚、ハンズオンの題材に使ったコードは動作確認などはしていません。本題とは関係ないので細かいツッコミは無しでお願いします。 #
git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba
git-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can
Popular git config options
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
【Git】新規ローカルブランチ作成時に自動でFirst Commitを行う for Four Keys
この記事は GMOアドマーケティング Advent Calendar 2023 5日目の記事です。 皆さん、お久しぶりです。GMOアドマーケティングのGood!Apps開発担当のharuです。 最近、弊社の開発部ではFour Keysを導入し、開発者体験や生産性の向上に注力しています。今回は、Four Keysの計測に必要な処理の一部を自動化しましたので、その詳細についてお話しできればと思います。 Four Keysとは まず、Four Keysについて簡単に説明します。 Four Keysは、GoogleのDevOps Research and Assessmentチームが提唱した、ソフトウェア開発チームのパフォーマンスを評価するためのフレームワークです。このフレームワークは以下の4つの指標で構成されています。 デプロイの頻度: 本番環境へのリリースの頻度を示します。頻繁なリリースは、ア
『GitUI』を使ってターミナルからでも直感的なGit操作を｜NAVITIME_Tech
こんにちは、みみぞうです。 ナビタイムジャパンで『システムや開発環境、チームの改善』を担当しています。 今回はターミナルで動くGitクライアントツール『GitUI』を紹介します。 本稿は以下のいずれかに当てはまるような方をターゲットにしています。 ターミナルで動くGitクライアントツールを探している方 NeovimからシームレスにGitの操作をしたい方 Windowsで使えるGitクライアントツール探しに困っている方 ℹ️ Neovimは、Vimをベース拡張性を考慮してモダンな技術で作られたプロダクトです。 GitUIとは『GitUI』はターミナル上でもGUIのように快適なGit体験を提供するOSSのツールです。 GitUI provides you with the comfort of a git GUI but right in your terminal extrawurst/gi
CHANGELOGの悩みを一発解決！git-cliffの使い方からカスタマイズまで📚
はじめに CHANGELOGを自動生成するツールは多種多様です。Conventional Commitsに対応したコミットメッセージから生成するもの、GitHub上でのリリースやタグ付けまで行うものなどがあります。 CHANGELOGを自動生成する際には、バージョンタグに対応したコミットメッセージを基にしてくれると便利です。コミットメッセージを適切に付けるだけで、後はツールにお任せできます。ただし、いくつかの懸念点が存在します。 懸念点 1: チキンエッグプロブレム CHANGELOG自動生成ツールは便利ですが、一つの大きな問題があります。それは、Gitのタグとコミットメッセージを基にCHANGELOGを生成するため、タグを作成する前にはCHANGELOGが存在しないという点です。この状況は「チキンエッグプロブレム」に類似しています。具体的には、新しいバージョン（卵）がリリースされる際には
bun.lockbのVersion管理をGitでどうやる？問題
はじめに bun installで生成されるBunのロックファイルはbun.lockbというバイナリファイルである。 公式を読むと性能向上のためにバイナリ化していることがわかる。 Why is it binary? In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles. 困ること まさにこのツイートの問題で、Git管理したいのにバイナリが出力されるのは不便で、どうしよう? と実際の本番利用では困るだろう。 解決方法 案1. git diffで差分確認する 公式のページを読むと、どうやら設定追加でgit diffができるらしい。 bun install request g
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある（Splitting a subfolder out into a new repository - GitHub Docs）。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
言語が違う複数のリポジトリをmonorepoへ移行した話
割とよくある構成かなと思いますが、私たちは主に "ドキュメント管理の難しさ"と"共有リソースの管理コスト"、"分業制によるチーム内の分断" に課題感を持っていました。それぞれの問題とそれらが解決されどのようになったかを詳細に見ていきましょう。 抱えていた問題とMonorepo移行後 私たちが抱えていた問題がmonorepo移行によってどのように解決されたかをまとめます。 ドキュメントが分散して探しにくい問題 Before プロジェクトに関するドキュメントが複数のリポジトリに分散するためにドキュメントの検索性や一覧性が低下しており、私たちのプロジェクトについて知りたい人が情報を探すのが難しい問題がありました。他方で、私たち自身も、どこに情報を残すかで迷うことも少なくありませんでした。 After プロジェクトに関する情報が1つのリポジトリに集約されたため、ドキュメントの探しやすさが向上しまし
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Gitの内部構造をよく理解して、うまく使おう【基本の仕組みを解説】
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
Gitを作ってみる（理解編） - Qiita
はじめに 都内でひっそり見習いエンジニアをしている@noshishiです。 addしてcommitするプログラムの作成を通じて、Gitを内部から理解しようという記事です。 前書き 昨年末、Gitの記事を書いて、理解できたなら作れるのではと思いったったのがこの記事の出発点です。 これを機に新しいプログラミング言語にも触れてみて、いろいろ学べたらと思いRustで今回挑戦しました。 （この時は、新たなことを同時に取り組み絶望すること知る由もない著者でした。軽い気持ちで手を伸ばした自分をしばきたいです。。。） 実際に作成した（継続開発中ですが）リポジトリは、こちらです。 ※一応ローカルでの一直線の開発はできそうな程度までは作成できました。コードのしょぼさはご容赦ください。 この記事だけでは説明しきれない部分があることをご容赦ください。 もちろん、間違い等あれば、ぜひコメントいただけると幸いです。
lazygitでどのくらいlazyになれるか試してみる - Qiita
TUIキテますね（しらんけど）！lazydocker、lazygit、最近ではlazynpmとか見かけるようになりました。GUI製はOSSじゃないことが多いですし、概ねキーバインドやカスタマイズ性が良くないことが多く、一方TUIはマウスを使いたくないlazyな人たちが作る代物なのでそのへんは良く考慮されてるなぁと感じます！ というわけで日々使うgitツールをlazygitに乗り換えてみて感想を書いてみたいと思います。 背景 ちなみにこれまではfugitive.vim → forkと渡り歩いてきました。fugutive.vimはvimからgitを扱えるというものなのでブランチ操作（特にinteractive rebase）などにおいては不便に感じており、一年ほど前からforkを使ってきました。forkはUIがとても洗練されていますがキーバインドが十分とは言えず、どうしてもマウス操作が多くポチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSが予告なしに「CodeCommitによるGitの提供」を取りやめ 他のサービスへの影響は？
gitでstashが面倒なあなたにautostash
なぜファイルの末尾に改行を入れたほうが良いのか - Qiita
