10年後、プログラムを動かし続けるために。伊藤淳一が考える「良いコミット、悪いコミット」 2025年1月6日 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」（技術評論社）などがある。 keyboard_arrow_down はじめに keyboard_arrow_down コミットが役立つシナリオ４パターン keyboard_arrow_down コラム：業務で使われるプログラムの寿命はとても長い keyboard_arrow_down 良いコミットの条

はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所

1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

GitHubでは削除されていたりプライベートに設定されていたりするフォークやリポジトリに誰でもアクセスでき、さらにその動作が欠陥ではなく仕様通りであるとオープンソースセキュリティ企業のTruffle Securityがブログに投稿しました。 Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co. https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github GitHubでの一般的なワークフローとして、「新しいフォークを作成する」「コミットする」「フォークを削除する」というものを考えてみます。 この時、削除したはずのフォークの中身を誰でも確認できてしまうとのこと。

VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 Git管理下にあるファイルをリネームした場合、 git log や git diff はそれをいい感じに処理してくれます。具体的にどういう動作をするか見てみましょう。 確認環境： /tmp/repo$ git init Initialized empty Git repository in /private/tmp/repo/.git/ /tmp/repo$ seq 100 > seq.1 /tmp/repo$ git add seq.1 /tmp/repo$ git commit -m 1 [master (root-commit) f9b660f] 1 1 file changed, 100 insertions(+) create mode 100644 seq.1 /tmp/repo$ git mv seq.1 seq.2 /tmp/repo$ git commit -m 2

スラッシュ コマンドについて スラッシュ コマンドを使用すると、テーブル、タスクリスト、コード ブロックなど、より複雑な Markdown を簡単に入力できます。 スラッシュ コマンドは、そのスラッシュ コマンドがサポートされている issue、pull request、またはディスカッションの任意の説明フィールドまたはコメント フィールドで使用できます。 スラッシュ コマンドを使用する スラッシュ コマンドは、コメント フィールドにコマンドを入力し、プロンプトに従うことで使用することができます。 複雑な Markdown をコメントに挿入するには、次のいずれかのコマンドを入力します。 コマンド説明

ラブグラフ 開発インターンの arawi です。 今日は僕の大好きな GitHub CLI から認証の話をしていきます。 GitHub CLI は超便利です！今すぐ入れよう！ TL;DR gh auth login で GitHub CLI を認証できる その過程で SSH key が必要なら GitHub CLI が作ってアップロードしてくれる GitHub CLI とは GitHub CLI は GitHub 謹製のコマンドラインツールです。 CLI 上で Repository, Issue, Pull Request への操作など、様々なことを行なうことができます。 超便利なので今すぐ入れるべきです。HomeBrew なら以下のコマンドで入ります。 詳しくはこちら：https://docs.github.com/ja/github-cli/github-cli/about-githu

Create useful .gitignore files for your project by selecting from 571 Operating System, IDE, and Programming Language .gitignore templates

歴史改変、してますか？ 私は歴史改変が大好きで、毎日 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コマンド4つをまとめました。 git fetch -p -pを付けることで、削除されたリモートブランチのリモート追跡参照が削除されるようになります。 例えばリモートリポジトリでbranchAが削除されると、git fetch -pによりローカルリポジトリ上のorigin/branchAが削除されます。 ※ git fetch --pruneも同様です ※ git pull -p/--pruneでプルする際に行われるフェッチにも適用できます git log --oneline コミットハッシュが短縮され、コミットログが1行で表示されるようになります。 ※ git log --abbrev-commit --pretty=onelineも同様です 表示例: git logの場合 commit cmhash2commithash

始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -

本書ではGitHub Organizationをセキュアに運用する方法について解説します。 GitHubは大変便利なサービスで、個人利用のみならず組織で活用されるケースも多いです。しかしGitHubの初期設定は利便性重視であり、セキュリティ対策は利用者による明示的な設定が必要です。 本書では意外と日本語でまとまった情報がない、Organizationレベルのベストプラクティスを体系化しています。GitHub Organization管理者はもちろんのこと、ソフトウェア開発者にも有益な情報を提供します。

株式会社ゆめみの Android の採用コーディング試験を公開しました 会社の採用試験どうしよう、、と悩んでいる採用担当の方がいましたら、ぜひご活用ください レビューできる人がいないという場合には、ぜひ弊社までご相談いただけたらと思います。 なんで公開したの？ 主に応募のハードルを下げるのが狙いです どんな試験なのか分かっているだけで、だいぶ気が楽になりますよね また、逆に無茶な応募が減るということもあるのではとも考えています。 どんな試験？ ざっくり説明すると メチャクチャなコードを改善してください というものです 詳しくはリポジトリの README をご覧ください。 ※ 新卒か中途かによって必須課題が変わる点にはご注意ください。 公開しちゃって大丈夫なの？ 誰かが良い解答を公開したら、それを真似すればいいんじゃ？ そもそもどれが良い解答なのかを判断しなければなりません。 どれが良い解答

originがhttps://github.com/[username]/[reponame]というgithub上で管理しているリモートリポジトリだとする。 ここで誰かが間違えて、必要な変更を失ってしまうようなgit push -f origin masterをやってしまった場合の話。 8cec0cではなく1e6753の状態に戻したいが、1e6753は誰のローカルにも存在しなく、github上でもタグや名前が付けられてないのでfetchしてくることが出来ないとする。 https://github.com/[username]/[reponame]/commit/1e6753 にアクセスすれば、1e6753がどんなコミットであったか分かる。 ここでは、1e6753が255番目のMerge Pull Requestだと分かったとする。 直接、masterにpushするというような運用をしていな

Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...

技術面以外で採用担当者の心証が爆上がりする知識ってな～んだ？ 答えはチーム開発のお作法です！ ここではGit Flowを利用したブランチ管理の手順を紹介していく。 GitHubだけで完結するように組んでいるから、GitHubのレポジトリもレビュー対象になっている採用試験対策に◎。 こんな人を対象にしているよ どこかの採用試験を受けるために、 GitHubでのブランチ管理方法 ブランチの種類と使い方 チーム開発のお作法 を知りたい人。 特にfwywdの一次採用試験を受ける人は必見。 前提知識 以下の知識があれば「なんじゃこりゃ」とならず読めるよう想定して執筆している。 GitHubとは何か知っている人 「コミット、プッシュ、マージ、プルリクエスト」をざっくり理解している人 Visual Studio Codeの基本操作を知っている人 使用するモノ一覧 GitHub Git Flow GitH

$ git clone https://github.com/username/repository.git Cloning into 'repository'... Username for 'https://github.com': username Password for 'https://username@github.com': remote: Password authentication is temporarily disabled as part of a brownout. Please use a personal access token instead. remote: Please see https://github.blog/2020-07-30-token-authentication-requirements-for-api-and-git-opera