コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
インストール方法 bat ripgrep, ripgrep-all fd, fselect starship exa, lsd, nat nushell navi, tealdeer delta hyperfine xsv, csview py-spy bandwhich, gping, ht, dog hexyl, bingrep broot tokei genact, globe, glitchcat monolith shellharden fnm, volta pastel gitui, onefetch, git-interactive-rebase-tool skim watchexec dust, diskonaut, dua-cli, dutree zoxide ytop, bottom, zenith mcfly sd, desed topgrade pueue proc
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
この記事は？ それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W
はじめに こんにちは、JAXA認定の宇宙ベンチャー企業、株式会社 天地人 (てんちじん) でエンジニアリングマネージャーをしている白井と申します。普段は天地人コンパス (Tenchijin COMPASS) のフロントエンドまわりの開発を行っています。 推し人工衛星はだいち4号です（昨年7月に種子島まで打ち上げを見にいきました） レビューを依頼したときにありがちなこと チーム開発を行う上で、Pull Request（以下PRと略します）ベースのコードレビューは当たり前になってきていると思います。 コードレビューは、他のメンバーにあなたのコードを見てもらい、フィードバックをもらうための重要なステップです。 しかし、レビューを依頼した際に以下のような状況に直面したことはないでしょうか？ 😇 レビュー依頼してしばらく経っても返信がなく、状況を質問してようやく 「あ、今から見ます」 と言われてし
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
February 16, 2024 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
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金（無料枠あり）です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中に
混乱を引き起こしがちなGitの用語まとめ
分散型バージョン管理システムのGitは2005年の登場以降シェアを伸ばし続け、2022年の調査では約94％のユーザーに利用されるほど一般的なツールとなっています。Gitにはさまざまな機能が搭載されていますが、その中で特に混乱を引き起こしがちな用語について、Gitを15年近く使用してきたというジュリア・エヴァンスさんが解説しています。 Confusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ ◆HEADと「heads」 HEADは現在チェックアウト中のブランチやコミットを指しており、「.git/HEAD」に保存されています。一方「.git/refs/heads」に保存されているのはブランチで、「heads」は「branches」と読み替えればOKとのこと。 ◆detached HE
Intro Chromium にコントリビュートするためには、ソースコードを理解する以外にも、もろもろ必要な周辺知識がある。 ドキュメントはかなり整備されている方ではあるが、そのドキュメントにたどり着くのが難しい場合もある。 レビュアーなどが親切に教えてくれるものをローカルにメモしているが、それも散らばってきたため、ここにまとめることにする。 まずは初期状態で公開するが、どんどん更新していき、長くなっても分割しないで追記を繰り返そうと考えている。 関連サイト 始めて取り組もうとすると、まずどこを見ればわからないところから始まる。 似たようないくつかのサイトがあり、使い分けがされているからだ。 code search https://source.chromium.org/chromium/chromium/src コードをインタラクティブに検索するためのサイト Workspace 風の U
発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR
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
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
WEBサービス開発歴7ヶ月目に突入しましたにこと申します。 先日、GithubにAWSアクセスキーをあげてしまいました。 その時は事の重大さをわかっておらず、言われるがままにコマンドをうち対処が出来たのですが、調べれば調べるほど「とんでもないことをしていた・・・！」ということがわかりました。 AWSで不正利用され80000ドルの請求が来た話 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 もう今後アクセスキーをあげることはないですが、愚かな人間なのでまた何らかを間違えてやってしまうかもしれません・・・。 二度とないことを誓いつつ、もし万が一やらかしてしまった場合、また同じようにアクセスキーをあげてしまったような方に向け、手順をしっかり残したいと思います。 まずはAWSのアクセスキーを無効化 ※2021/1/30追記 Githubの手順よりも先にAWSのアクセ
Sapling: Source control that’s user-friendly and scalable
Sapling is a new Git-compatible source control client. Sapling emphasizes usability while also scaling to the largest repositories in the world. ReviewStack is a demonstration code review UI for GitHub pull requests that integrates with Sapling to make reviewing stacks of commits easy. You can get started using Sapling today. Source control is one of the most important tools for modern developers,
はじめに よくQiitaでおすすめアプリとかの記事を見かけますが 逆に使わなくなったアプリの紹介記事ってなくね？ と思い今その勢いで本記事を書き進めています。需要があるかはしーらないっ。 本記事では、今年で4年目のエンジニアが作業効率を追い求める中で淘汰されていったアプリたちを紹介します。 ちなみに当方Macユーザです。 エディタ Visual Studio Code 3年目くらいまでは結構使ってました。 settings.jsonやkeybindings.jsonをdotfilesで管理してみたいなこともするくらいには使ってました。 が、何かのタイミングでvimに興味を持ち、vimを使いはじめてから徐々に使わなくなってゆきました。 vimに興味を持った最初の頃はVSCの拡張でvimがあったので、それを使ってました。 VSCでvimの操作を再現できる拡張です。 しかし vimと言えば学習コ
【30歳/完全未経験/独学】webアプリを作製しました【Golang, Next.js, MySQL, Docker, GitHub Actions CI, AWS Fargate on ECS】 - Qiita
完成物 ER図 画面遷移図 figma, 原寸画像 AWS構成図 ※備考※ GitHub Actions CIは構築済みです。 GitHub Actions CD, apiのprivate subnet化にも取り組んでいます。 EC2インタンスは通常時停止です。 技術選定理由 プログラミング、IT業界ともに未経験で着手し独学で作りました。 Go 比較対象：JAVA、Ruby、Python、PHP コンパイラ言語であり実行速度が高速である 静的型付けであり、コンパイル前にバグを発見しやすい 静的型付けかつ記述自由度が低いことから、以下２点を利点と考えた 開発を中長期まで続けた際にも、加筆・改修しやすい 他人のコードを読んだ際に学びやすい Javaも多少書いてみたが、簡素にかけるGoの方がしっくりきた SHOWROOM、IRIAM、Twitch、AbemaTVといった動画配信サービスにも採用さ
November 1, 2023 Hello! I’m slowly working on explaining git. One of my biggest problems is that after almost 15 years of using git, I’ve become very used to git’s idiosyncracies and it’s easy for me to forget what’s confusing about it. So I asked people on Mastodon: what git jargon do you find confusing? thinking of writing a blog post that explains some of git’s weirder terminology: “detached HE
The key to achieving world-class expertise in any skill, is to a large extent, a matter of practicing the correct way, for a total of around 10,000 hours — Malcolm Gladwell in Outliers I'm certainly not a world-class expert, but I have put my 10,000 hours of deliberate practice into programming. Here are 31 of my reflections on programming. These are reflections only about pure coding — no lessons
こんにちは、CX 事業本部 Delivery 部の若槻です。 今回は、Git で複数のコミットをまとめる方法を確認してみました。 ちなみに Git で行うこの操作のことを「スカッシュ（squash）」するとも言います。squash は「押しつぶす」とか「ぺちゃんこにする」という意味だそうです。 環境 $ vim --version VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 23 2023 22:12:29) macOS version - arm64 Included patches: 1-1544 確認してみた スカッシュしたいコミットが「連続する」場合と「連続していない」場合の 2 通りの方法を確認してみました。 連続するコミットの場合 まずは「連続する」複数のコミットをスカッシュする場合の方法です。 スカッシュ前の状態 次のよう
Gitコマンドって忘れがちですよね。 パッと引き出せるようにチートシートを作成しました。 初期設定 git init: 現在のディレクトリを Git リポジトリとして初期化する。 git config --global user.name "{ユーザー名}": ユーザー名を設定する。 git config --global user.email "{メールアドレス}": メールアドレスを設定する。 git config --global core.editor "{エディタ名}": デフォルトのエディタを設定する。 git config --global color.ui true: カラー表示を有効にする。 git config --global pull.rebase true: pullをする時にrebaseするかmergeするかを設定する。 git config --list: g
昔はこういうの結構やられてた気がするけど最近あんまり見なくなったのでやってみました。 タイトルは から借用しました。 注意点 プラグイン自体の説明はあまりするつもりはないので、GitHub の README を読むなり使ってみるなりしてみてください。 私は結構頻繁にプラグイン乗り換えるので 2022 春バージョンと思ってください。 私が言うのもあれですが、プラグインはいっぱい入れればいいというものではありません。ひとつひとつを使いこなすのが大事です。多ければそれだけ管理も大変です。 競合があるプラグインは比較して選定しているつもりですが、あくまでも私の趣味の範囲での選定となります。絶対的な指標があってこっちの方が優れているといった判断をしているわけではありません。 私の Neovim の使い方 使い方が違うと参考にならないことが多いため前提としてどういうふうに Neovim を使っているか
こちらはエムスリー Advent Calendar 2024 12日目の記事です。 こんにちは。エムスリーエンジニアリンググループ、コンシューマチームの園田です。 今年になって、かなり古い Rails を最新バージョンまでアップグレードしました。そのときの話です。かなりポエムに近い内容になっていますがご容赦ください。 特に何か変わったことをやっているわけではありませんが、あるあるを共感したもらったり、こんなことやってますという紹介だと思っていただければ幸いです。 システムの特性 社員だけが使える管理画面のサービスで、IP 制限と LDAP 認証がかかっています。 利用頻度はそれなりに高く、毎日オペレータが作業しています。また、Rails で実装されたバッチも多数あります。 なぜ古かったか 一部の機能で PostgreSQL 8.x を直接参照している処理があり、Rails 5 以上だと p
ワークフローを改善できるGitのヒント15選 #GitLab #Git - クリエーションライン株式会社
投稿者：Suri Patel 2020年で、Gitが誕生してから15周年を迎えました。Git Merge 2020での体験や、Gitフローの問題、最新のGit機能であるPartial Clone など、Gitの誕生と影響について今まで様々な投稿をしてきました。 Gitを使い始めたばかりの人であっても、コマンドラインを使いこなすレベルの人であっても、自分自身のスキルを自己研磨する姿勢は素晴らしいものです。そこで今日は、Gitを使用してワークフローを改善できる15の方法を紹介します。 1. Gitのエイリアス 日々のワークフローを改善できる最もインパクトのある方法の1つは、一般的なコマンドのエイリアスを作成し、ターミナルでの作業時間を短縮することが挙げられます。 次のコマンドを使うと、最もよく使われる Git コマンドである checkout 、 commit 、 branch のエイリアスを
GitHub演習
この講義ノートについて これは、理工学部の三年学部生向けのGit/GitHubを用いたソフトウェア開発演習のための講義ノートである。概ね一般的な記述となっているが、一部に大学のPC室特有の記述があるので、他大の方が利用される際は注意されたい。4回の座学、4回の実習の、計8回の講義/演習で学ぶ構成となっている。 なお、この講義ノートを元にした書籍が出版されている。 ゼロから学ぶGit/GitHub 現代的なソフトウェア開発のために はじめに 座学 バージョン管理とは 講義スライド バージョン管理システムとは バージョン管理システムの歴史 プログラミングができる人、できない人 Gitの仕組みと用語 講義スライド プロジェクト リポジトリとワーキングツリー コミット インデックスとステージング HEADとブランチ マージ コマンドラインの使い方 講義スライド シェルとコマンドライン Unixコマ
コミューンに今年の8月にエンジニアとして入社した角田です。 入社して3ヶ月、業務には慣れてきましたがシェルの設定は空っぽ、ターミナルも初期設定のままです。 また、ブログのネタにも困っていました。 これを機に先輩エンジニアたちのCLI環境についてインタビューを行い、それを参考に自分なりの最強CLI環境を作成したいと思います。 やること まずはコミューンのエンジニアにCLI環境についてインタビューをする。 それらをまとめて自分なりのいいところを組み合わせて最強のCLI環境を作成する。 1人目 部署 山芋チーム (commmune JP開発) 使用ツール VS Codeのターミナル zsh # ~/.gitconfig [alias] push-f = push --force-with-lease --force-if-includes [push] autoSetupRemote = tru
本質的なレビューの内容の前にケアレスミスで突き返されてしまう。 ちょっともったいないですよね。 これらを自分で気付ける方法はないかな？と思い、 「プルリクのレビュー前に気をつけるべきこと」 をまとめて自分でチェックするようにしました。 友人 から と意見いただいたので公開してみます。 また、友人が項目を足してくれてたりします。ありがとう プルリクエストを出すときに確認すること タイトルとコミット わかりやすい タイトル をつけよう ストーリーとか目的がわかるように名付けよう コミットにprefixを付けてみよう チームルールにもよるけど、prefix つけると目的がわかりやすい 参考: https://qiita.com/numanomanu/items/45dd285b286a1f7280ed 不要なコミットは入れていないか？ 自分のローカル用だけの変更は入ってないか コミットログを整理
Git 2.44のハイライト
オープンソースのGitプロジェクトは、新しく加わった34人を含む総勢85人以上のコントリビューターによる新機能の追加とバグ修正が行われたGit 2.44をリリースしました。前回 Git の最新情報をお伝えしたのは、2.43 がリリースされた時でした。 今回の最新リリースを記念して、前回から導入された最も興味深い機能や変更点を GitHub がいくつか紹介します。 マルチパックの再利用によるパック生成の高速化 GitHub との間でリポジトリをプッシュしたりプルしたりする時に Git の出力を詳しく見たことがある人1なら、出力の最後にpack-reused という数字が表示されていることに気づいたかもしれません： $ git clone git@github.com:git/git.git Cloning into 'git'... remote: Enumerating objects:
コミットを整理してみよう｜おだいり｜note
これは『フィヨルドブートキャンプ Advent Calendar 2020 Part 2』7日目の記事です。 https://adventar.org/calendars/5230 こんにちは！メンター枠の odaillyjp です。 今回は生徒の方々向けに「コミットを整理してみよう」という話をします。 コミット整理の重要性「Ruby で ls コマンドを作る」や「Sinatra を使って Web アプリケーションの基本を理解する」などの実装を必要とするプラクティスでは、生徒は実装したプログラムを Pull Request で提出し、メンターに確認していただいていますよね。 私はメンターの立場ということで皆さんの Pull Reqeust をレビューしていますが、実装されたコードを読んでいて、いつも「実装しないといけない機能が盛り沢山である中で、なるべく実装をシンプルにまとめようと頑張って
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
GitHub - martinvonz/jj: A Git-compatible VCS that is both simple and powerful
Jujutsu is a powerful version control system for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use. It is designed from the ground up to be easy to use—whether you're new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams. Jujutsu is unlik
初めてPullRequestを対応する前に知りたいGitのコミットについて - ANDPAD Tech Blog
こんにちは！2021年2月にアンドパッドに入社しました、エンジニアの浜田です。 私の経歴として入社前までチームでの開発をほとんどしてきませんでした。アンドパッドに入社して初めてチーム開発をするようになりました。 入社当初、私がPR(Pull Request)を対応する中で教えてもらったことや、他の方が教えてもらっていたことを社内向けに初めてPRを対応する前に知りたいことというタイトルで記事をまとめました。今回はその記事の内容からGitに関してまとめた4点を紹介させていただきます。 はじめに 1. コミットメッセージは1行目がタイトルで3行目から説明 2. 1コミットに複数の対応を混ぜない 3. コミットメッセージに有益な情報を残す 4. レビュー前にGitのコミット整理 まとめ はじめに アンドパッドではGitHub上で開発を進めています。PRのマージ条件の1つにレビュアーのApprove
Git履歴をgit resetとgit rebaseで管理する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: How I manage my git history | Binary Solo 原文公開日: 2023/05/26 原著者: Ayush 日本語タイトルは内容に即したものにしました。 Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 私は全般的に、どちらかといえば規則にうるさい方ですが、自分のプロジェクトでgit履歴を管理するときはこの性格が役に立ちます。以前の私はGitHubの"squash & merge"方式をしばらく使っていましたが、その後Chris Mooreからいくつかのコツを教わりました。 私は"squash & merge"方式が好きになれません。どんなに巨大なプルリクエ
Most developers are familiar with the standard Git workflow. You create a branch, make changes, and push those changes back to the same branch on the main repository. Git calls this a centralized workflow. It’s straightforward and works well for many projects. However, sometimes you might want to pull changes from a different branch directly into your feature branch to help you keep your branch up
warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebase git config pull.ff only # fast-forward only You can replace "git config" with "git config --global" to set a defa
modeling-how-to-learn.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会で話されていたこと イベント資料 イミュータブルデータモデルの極意～川島義隆さん～ 川島さんの問題意識～Division into cases～ Dataの場合分け EventとResourceの関係性 EventとResourceのサブタイプ Resource同士の関連付けをする際のコツ 記録として残すEvent, 残さないEvent ドメイン駆動設計とイミュータブルデータモデルの素敵な関係～増田亨さん～ イミュータブルについての厳格性 必ずイミュータブルにする際の設計パターン 増田さんがイミュータブルに拘る理由 ドメインイベントの観点から再考するソフトウェア設計～かとじゅんさん～ ドメインイベントとは ドメインイベントはなぜ有用か
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxメモ : あると便利かもしれないRust製コマンドラインツール - もた日記
2024年Gitワークフロー再考 | フューチャー技術ブログ
【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
レビューが爆速になる！レビュアーに優しいPull Requestの極意
綺麗なコミットログを作りたいときのgitテクニック - Qiita
Popular git config options
GitHub Actions のデバッグをローカルで行う
squash and mergeしか使ってないけど全く困ってない
rebase 教から脱退します - Qiita
Chromium にコントリビュートするための周辺知識 | blog.jxck.io
git commit --fixupを使いましょう - Don't Repeat Yourself
VSCodeでGitのコミットを楽に整理して、レビュワーに「コイツできる」と思わせよう。
git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba
AWSアクセスキーをGithubにあげてしまった時の対処方法 - Qiita
【作業効率化】4年目エンジニアが「使わなくなった」アプリを供養する - Qiita
Confusing git terminology
Reflections on 10,000 Hours of Programming
Git で複数のコミットを1つにまとめられる「スカッシュ」というテクニック | DevelopersIO
忘れがちなGitチートシート - Qiita
ワシの使っているNeovimプラグインは200個近くあるぞ
Rails 4.2 から 7.1 まで一気にバージョンアップした話 - エムスリーテックブログ
コミューンエンジニア的最強CLI環境を作ってみた - Commune Engineer Blog
うっかりな僕がプルリクエストを出す時に気をつけるべきことをリスト化してみた
モノレポ好きじゃない / morrita - Message Passing
How the GitHub CLI can now enable triangular workflows
Git 2.27 での git pull 時の warning について - Qiita
イミュータブルでゆこうに参加してきた - 天の月