はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む（コマンドなし） ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
📚 本書について【無料公開中】 Gitの内部の仕組みを徹底的に丁寧に解説する本です。 「Gitはいかにバージョンを管理しているのか？」 「コミットはスナップショットと聞いたことがあるものの、どういう意味？」 「操作時にエラー表示をネットの記事を参考に対応しているけれど、実はよく分かっていない...」 といった疑問をすべて解決する基礎力を身につけることができます。 Gitの仕組みを理解することで、普段使いのツールとしても、より効果的に利用できるようになるほか、データ構造やアルゴリズムの学習用途としても楽しめるような構成になっています。
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
Oh My Git! は、バージョン管理ツール git の使い方を学ぶためのゲームです。 中央にgitツリーのグラフが表示され、手元にはgitコマンドを表すカードが配られます。 カードを使わずに右側のターミナルでコマンドライン操作することも可能。お題で出てきた課題を満たすためのカード/コマンドを正しく実行すると、右側の達成項目が緑に反転し、すべて達成すればそのレベルはクリアです。 commit を指定し、そこにカードを捨てることでカード上のコマンドを適用。 levels にあるステージ一覧から、好きな項目について遊ぶことが可能です。 カードを使っても解けますが、コマンドラインで解くと右端のボックスを黄色にすることができます。 ソースコードは GitHub で公開されていて、バイナリ版も Windows, MacOS, Linux 向けに提供されています。 テキストファイルで新たなlevel
「mise」ってすごい使いやすいんですよ。 miseとは GitHubリポジトリの説明書きに 「dev tools, env vars, task runner」 と書かれているrust製のcliツールです。 この記事ではmiseヘビーユーザーの私が推したい生産性の上がる機能を紹介するので、miseを初めて知った人も、知ってるけど使ってないって人も、ぜひ一読してみてください。 ちなみに最近話題になりやすいAIツールのcliパッケージなどもmiseで管理できたりします。 推したい機能はこれです！ ① タスクランナー（私が推したい機能No.1） 私はmiseにおいてはタスクランナーが一番便利な機能だと思っているので最初に紹介します。 タスクランナーはmise.tomlによく使うスクリプトをタスクとして定義しておいて、mise runコマンドで実行する機能です。 ※設定ファイルはグローバルで有効
Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき
もくだいさん🇯🇵 365おじさん @mokudai 仕事でWordをめちゃくちゃ使うんだけど、Gitみたいなソース管理、バージョン管理できないかなぁ やりたいのは差分比較なんだよなぁ Wordなので文章の追加削除だけじゃなく、スタイルの適用、セクションの変更など全部比較したい。 。。。世の中には無さそうだなぁ もしあればだれか教えて！ #m365jp 2024-08-21 11:33:14 もくだいさん🇯🇵 365おじさん @mokudai セクションのスタイルを正しく使うと、「特定のセクション（中表紙とか）にはページ番号付けない」とか設定できるんですけど、さぼって白いオブジェクトで隠すやつがいるので、こういうのも駆逐したい。 pic.x.com/yotudzzdn0 2024-08-21 12:29:05
追記 先日外部向けに、この記事の内容に追加補足などを加えて発表しました。動画のアーカイブ、資料も公開しましたので、もし動画の方がわかりやすい方はこちらをオススメします。 注意: 動画の質疑の中で、 github のリリース機能が、アノテートタグを使っていると明言してしまいましたが、間違いです。gitのデータ上はただの軽量タグで、 release の内容は軽量タグに紐づく形で、 github のアプリケーション上で管理されているはずです。 はじめに 調べてもう1年放置していた内容なんですが、アドベントカレンダーで重い腰を上げました。 Gitの内部の仕組みを知りたい（動機） 毎日使うといってもいいGitですが、どうやって履歴を管理してるんだとか、よくわからないまま使っているのが急に怖くなりました。 Gitを触り始めで、よく以下のような疑問が沸くと思います。 どうやってGitは履歴を管理してるん
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
いいからgit使え もうファイル名に日付とか「最終」とか付けるな．文字しか書いてないWordファイルとかExcel方眼紙とかはこの際目をつぶる．それはもう仕方ない．だがファイル名によるバージョン管理だけは駄目だ． まずGitHubにアカウントを作れ．そんな名前も知らない会社のウェブサービスは使いたくないだって？お前Word使ってるだろ． それからSourceTreeをインストールしろ．そんな名前も知らない（略）お前Trello使ってるだろ．使ってない？今すぐ使え． よし，準備は出来たな． 新しい仕事を始める時，まず何をする？そう，空のフォルダを作るよな．ちょっと待った．今後は手元のコンピュータ上に空のフォルダを作るんじゃなくて，GitHubに作るんだ．GitHubに作るフォルダはリポジトリと言うぞ．リポジトリはただのフォルダじゃなくて，ファイルの履歴を管理できるんだ．うっかり全世界公開して
この記事はNuco Advent Calendar 2022の7日目の記事です はじめに 株式会社Nucoでエンジニアをしている@noshishiです。 今回は、ついついその場限りのコマンド実行で乗り越えがちなGitを、コマンドを使わず理解するための記事を書こうと思います。 Gitとは バージョンを管理し、作業を分散する Gitは、分散型バージョン管理システムと呼ばれるソースコードの管理システムの1種です。 Gitは、ファイルの変更履歴（バージョン）を記録・追跡することで、過去と現在のファイルを比較し、変更点を明らかにすることで、円滑に開発作業を進めるためのツールです。 また、一度に複数の開発者がファイルを編集できるシステムなので、作業を分散して行うことができます。 Gitを使うということ まず、みんなで共有できる保存場所（以下、リモートリポジトリ）にあるファイルなどを、手元のパソコン（以
公式ドキュメントには以下のように書かれています。 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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
概要 Junio C Hamanoさんに興味を持って調べていると、Linusさんが書いたGitの初版は1244行ということが分かりました。Gitの初版について、軽く行数の確認とビルドチャレンジをして、あまり調べずに動かしながら機能を推測してみました。 はじめに Highlights from Git 2.39 の冒頭で登場するcommit数が一番多い方「Junio C Hamano」さんを知らなかったので調べてみました。 gihyoのインタビュー記事が面白かったです。Junio C HamanoさんはGitのメンテナで、LinusさんからGitのメンテナを引き継いだすごい方だということを知りました。 このgihyoのインタビュー記事の中で「MLで流れてきたGitのコード行数は1244行だった」というところが気になりました。調べてみると、2020年にTwitterでRui Ueyamaさんへ
20190425 JJUG ナイトセミナー
はじめに Claude Code、GitHub Copilot、Cursor など、様々な AI ツールが同時に複数のタスクを並行して処理することを可能にしました。しかし、従来の Git ワークフローでは、ブランチ間の切り替えによる作業の中断や、複数のタスクを同時進行する際のコンフリクトが課題となっています。 そこで注目されているのがGit Worktreeです。この記事では、Git Worktree の基本概念と使い方を紹介します。 従来の Git ワークフローの課題 ブランチ切り替えの問題点 従来の Git ワークフローでは、異なる機能やバグ修正を行う際にgit checkoutやgit switchでブランチを切り替える必要がありました： # 機能Aの開発中... git add . git commit -m "WIP: 機能Aの途中" # 緊急のバグ修正が必要 git switc
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
Claude Codeを使い始めて4ヶ月になりますが、使い方も日々アップデートされていく感覚があります。この記事は、2025年8月末時点でClaude Codeをどのように使っていたか、具体的な手順を中心に備忘録としてまとめたものです。まずは考え方を共有してから、具体の話をする構成となっています。 使い方の型を決める Claude Codeを使用していると期待通りの挙動を引き出せず、延々と試行錯誤してしまうことがあります。しかし、実装タスクで集中するべきはツールの使い方ではなくタスク本来の内容であるため、なるべく使い方の型を決めてその通りに動かしています。 私の場合、型をつくるために以下のサイクルを回しました。 普段の開発フローを整理して、改善できそうな箇所を見つける Clade Codeを使うことでどのように改善できそうか調査をしたり、試作をつくって検証する 実際の開発フローに組み込んで
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！ プロローグ 先日、弊社のとある案件内での会話です。 熟練エンジニア（以降「熟練」と表記）：GitHubのプルリクが来てたからコードレビューしておいたよ。 若手エンジニア（以降「若手」と表記）：ありがとうございます。助かります。 熟練：他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの？ 若手：いや、他の人のプルリクは見てないですね。。 必要ですかね・・？ 熟練：必要だよ。昔はそういうのやりたくて
Metaが10年間にわたり開発・使用してきたソースコード管理システム「Sapling」がオープンソース化されました。Git互換で基本的なコマンドは類似しており、すべてのコマンドがシンプルで使いやすいように設計されているとのこと。Saplingは2022年11月15日から一般向けに公開されています。 Sapling: Source control that’s user-friendly and scalable https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ MetaはSaplingについて「ユーザビリティとスケーラビリティを重視した、Metaで使用されているソース管理システム」と紹介。GitやMercurialのユーザーにとって基本的な概念の多くがなじみのあるものであり、
設計ドキュメント腐る問題、 Git管理で運用してみた 本当のところ 2023.12.5 真野隼記 ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT
こんにちは！株式会社AI Shift で Web フロントエンドエンジニアをしている辰川です！ 今回は、筆者が愛用している Git の TUI ツールである lazygit について紹介します。 Git 操作、こんなことで困っていませんか？ git add して git commit して git push ...。 日々の開発で繰り返す、この一連の Git 操作。 ターミナルでのコマンド入力は素早い反面、少し特殊な状況になると急に難解な呪文のように感じられますよね。 かといって、GUI ツールに切り替えるのも万能ではありません。 キーボードから手を離し、マウスに持ち替えて何度も画面をポチポチする作業は、集中力を削ぎますし、キーボード中心の操作フローに慣れていると、かえって面倒に感じることも少なくないです。 「ターミナルの速度感」と「GUI の視覚的な分かりやすさ」。 もし、この 2 つの
大学サークルのイントロ用資料です Gitに入門します resetやrevertも入れたらよかった気がしています
こんにちは、SODAのSREチームのDucと申します。 GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。 背景 私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。 それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。 毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。 GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。 参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。 Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記： OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(
Java's OOM and k8s' OOM 遭遇した2つのOOMと対策 ~ Launchableでの事例 ~ / JJUG 2025 Spring
コンフリクトしても、もう怖くない！ Gitの基本操作やリカバリーを体験しながら学ぶ、Git＆GitHubの実践的入門書。 本書は、Git＆GitHubをハンズオン形式で解説する入門書です。 いまや9割以上の開発者が使うツールになった「Git」。 でも、たくさんのコマンドや黒い画面、エラーやコンフリクトが怖い、そんな気持ちはありませんか？ 本書は、Gitで挫折しがちな「エラー」や「コンフリクト」をあえて引き起こして、その直し方を解説します。 「どうすれば直るのか」「どうしてそういう挙動になるのか」ということを、手を動かしながら体験することで今度こそGitがわかる、そんな1冊です。 ■本書の特徴 ・つくって、壊して、直して学ぶ - 基本操作を学ぶ：ローカルリポジトリでadd、commit、logなどの基本操作を学ぶ - コミットを取り消す：resetコマンドの--soft、--mixed、--
SlackメッセージからGitHub issueを作成するSlackアプリです。Flow情報をStock情報に変換することで価値ある行動につなぐことができます。issueをTODO管理として活用したい人にもおすすめです。
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
より良いコミットメッセージを残すことは 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://
はじめに はじめまして、yasuda_naoto と申します。 未経験から WEB エンジニアとして活躍するために RUNTEQ というプログラミングスクールで学習しています。 概要 RUNTEQ ではミニアプリ作成会というものがあり、2023 年の 8 月に青春をテーマにたくさんのアプリが投稿されました。 その際に、愚かな私は「面倒だからgit add .してそれらを一気に commit して push すればええやろ」という、プログラマにあってはならないめんどくさがり精神で作ったアプリをリモートリポジトリに push してしまったのです。 その際に起きた悲劇を再現します。 更に、同じ轍を踏まないように、それを防ぐ方法と、もしあなたが同じしくじりをしてしまったら、そこから立て直す方法をご紹介します。 要点 細かく add & commit しなかったばかりに push が途中で進まなくな
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く