え？まだ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
はじめに ファイルの末尾には改行を入れたほうが良いのでしょうか。 「ファイル 末尾 改行 POSIX」等で調べると、規格の観点から改行を入れた方がいいという話が出てくるのですが、今回はgitの仕組みの観点からも改行を入れたほうが良いという話をします。 GitHub上での末尾改行の警告 例えば末尾に改行のないこんなファイルが有るとし、commitしてGitHubにpushすると以下のような表示になります export function hello(name: string) { return `Hello, ${name}!`; }
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
設計ドキュメント腐る問題、 Git管理で運用してみた 本当のところ 2023.12.5 真野隼記 ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣ - Qiita
｢これは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です(
git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo
より良いコミットメッセージを残すことは 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の使い方しくじり先生~こんな使い方はするな~
はじめに はじめまして、yasuda_naoto と申します。 未経験から WEB エンジニアとして活躍するために RUNTEQ というプログラミングスクールで学習しています。 概要 RUNTEQ ではミニアプリ作成会というものがあり、2023 年の 8 月に青春をテーマにたくさんのアプリが投稿されました。 その際に、愚かな私は「面倒だからgit add .してそれらを一気に commit して push すればええやろ」という、プログラマにあってはならないめんどくさがり精神で作ったアプリをリモートリポジトリに push してしまったのです。 その際に起きた悲劇を再現します。 更に、同じ轍を踏まないように、それを防ぐ方法と、もしあなたが同じしくじりをしてしまったら、そこから立て直す方法をご紹介します。 要点 細かく add & commit しなかったばかりに push が途中で進まなくな
混乱を引き起こしがちな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
環境構築 以下の手順で構築していきます． Overleaf-Workshopの拡張機能をVScodeに入れる Latex-Workshopの拡張機能をVSCodeに入れる Latex-Workshopの設定を変更 texliveをインストール +α Grammarlyの拡張機能をVSCodeに入れる Grammarlyの設定を変更 1, 3, 5はVSCodeの拡張機能で検索すれば一瞬で出てくるのでスキップ． Latex-Workshopの設定を変更 Latex-Workshopの設定を変更します．以下を設定から変えましょう．cmd+,で設定のタブが開けると思います． Latex-workshop › Latex › Recipe: Default - first + lastUsed onSaveでtexソースをビルドするときに、デフォルト設定のfirstのままだとpdflatexのビル
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
サマーズが第二次トランプ政権の危険性について深刻な懸念を表明している。 以下は12/20ツイート。 The @FT's Unhedged asked me about the macroeconomic implications of a second Trump term: When you have a president who challenges the results of elections and brags about what he could do in one day as a dictator, it is not something that can be completely relied on. That is a profound threat to our long-run prosperity, and therefore short-run asse
カーネルコードの歩き方 ‐ ソースコードを読むための勘所を知る
数千万行に及ぶLinuxカーネルのコードのうち、どんなときにどこのコードを読めばいいか、そのときに何を手がかりにすればいいか、などについてお話します。 本記事は、TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 「カーネルコードの歩き方」というタイトルでお話しする武内覚と申します。ふだんはsatと呼ばれています。社会人1年目から15年ぐらいカーネルの開発とサポートをずっとやってきました。今も必要に応じてカーネルソースを見ています。 本LTで学べるのは「Linuxのカーネルソースの読み方についての勘所」です。直接読んでいくというより、もう少しメタな
手順書作成の未来（の 1 つの形）を Visual Studio Code の Extension にみたという話 | DevelopersIO
はじめに システム運用においては、なんらかのリソースを作成や削除したり、設定値を変更したりとさまざまな変更作業が発生します。その際、なんらかの手順書（Markdown や Excel 等）を準備して、作業をすることが一般的だと思います。 本記事では「変更手順の作成」と「その手順を実施する」という 2 点にフォーカスして、これらを支援する Visual Studio Code（以下、VS Code）の Extention をご紹介します。 なお、本 Extention は Azure でのみ使用可能な点にご注意ください。 補足: 手順書がどうあるべきかについては多くの意見があるため、この記事では触れません。 この辺りについては、運用設計ラボ様の素晴らしいスライドがあるので、末尾の参考資料にリンクしておきます。 Azure CLI Tools について 今回ご紹介するのは、Azure CLI
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 HEAD state”, “fast-
My VSCode Config
Hi fellow devs, For my first post, I'm just documenting my VSCode configurations here for posterity's sake or just for my reference later. Keep in mind that this list is going to be language agnostic and more so utility/aesthetic suggestions (though these are inevitably tied to what languages I work with, so take that as you will). Please feel free to suggest any good extensions that I've missed o
WordPressの小ネタ集 - Qiita
この記事は、「CMS Advent Calendar 2023」の21日目の記事で、WordPress に関してもしかするとあまり知られていないかもしれない事を、とりとめもなく独断でまとめたものです。 特に、ここ数年 WordPress に触れておらず、今の WordPress はどうなっているのか? という事を知りたい方向けの情報も少し盛り込んでいます。 クラシックエディターはいつまで使えますか ? Classic Editor プラグインの説明には、この記事を書いている時点で「Classic Editor は公式な WordPress プラグインであり、少なくとも2024年まで、または必要なくなるまでの間、完全にサポート・保守されます。」と記載されています。 それでは2025年以降、クラシックエディターが使えなくなる可能性があるのでしょうか ? 自分は、クラシックエディターは残り続ける
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜファイルの末尾に改行を入れたほうが良いのか - Qiita
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
20231206_設計ドキュメント腐る問題、Git管理で運用してみた本当のところ
非同期開発体制を支えるドキュメント文化 / YAPC::Hiroshima 2024
より良い Git コミットメッセージを書こう - Qiita
Overleaf+VSCode+GitHub+etcな執筆環境を整える
トランプは良いこともするのか？ - himaginary’s diary
Confusing git terminology