大学サークルのイントロ用資料です Gitに入門します resetやrevertも入れたらよかった気がしています
大学サークルのイントロ用資料です Gitに入門します resetやrevertも入れたらよかった気がしています
｢これは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です(
GitHubは、これから新規に作成されるリポジトリのデフォルトブランチ名が「main」になると発表しました。これまでデフォルトブランチ名は「master」でした。 既存のリポジトリにはこの変更は適用されませんが、年内にも既存のリポジトリでもデフォルトブランチ名の変更を可能にする予定だと説明されています。下記は「The default branch for newly-created repositories is now main」からの引用です。 Existing repositories are not impacted by this change. Later this year, you'll be able to rename the default branch for existing repositories for your user, organization, or
git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo
JITからのコペルニクス的転回か 筆者はサプライチェーンのコンサルティング会社に属している。コロナ禍以前と以後では、問い合わせの内容が異なっている。以前は、「働き方改革」「人工知能（AI）／RPA（Robotic Process Automation）の活用」といったテーマが多かった。 それがコロナ禍以後は、「働き方改革」はピタリとなくなった。それまで遅々としてテレワークなどは進まなかったのに、コロナ禍では背に腹は代えられないと、議論や手法論をすっ飛ばしてただちにテレワークの実践が進んだ。この日本人の火事場の転換力には感心した。一方でAIもRPAも現実的な応用に限界があると企業が感じたのか、次のデジタル・トランスフォーメーション（DX）にテーマが移っていった。 そして、コロナ禍以後に増えたのがコスト削減の相談や、在庫に関わる相談だ。コロナ禍が始まった直後はコスト削減についての相談が多かった
SlackメッセージからGitHub issueを作成するSlackアプリです。Flow情報をStock情報に変換することで価値ある行動につなぐことができます。issueをTODO管理として活用したい人にもおすすめです。
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
より良いコミットメッセージを残すことは 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://
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
はじめに はじめまして、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 もちろん自分でいいアイディアだと思っているから実装している
分散型バージョン管理システムの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
チーム開発におけるコミットメッセージの書き方についてアウトプットします。 コミットメッセージに正解はありません。 組織によって最適な手法は異なるため、参考のひとつにしてください。 要点 フォーマット :Emoji: Title / Reason / Specification / Issue 項目 Emoji - 内容・種類をひと目で分かるように Title - タイトル（概要） Reason - このコミットをする理由 Specification - 言い訳ではなく、このコミット内容になった意図や仕様など Issue - 対応するIssue 作業内容はコードを見ればわかるので、「概要」「変更理由」「意図・仕様」を簡潔にまとめる。 例 コミットメッセージを書く理由 そもそも、コミットメッセージを書く理由は以下の通りです。 ひと目でどんなコミットなのか判断するため 簡潔にコミット内容を説明す
開発者「すみません、なんかnpm iとかnpxコマンドがうまくいかなくて…」 ワイ「でたー、cb.apply is not a functionって書いてません？」 開発者「書いてます」 ワイ「ちょっと見てみますね」 ワイ「……これはnpm入れなおしたほうが早そうですね…」 ｶﾀｶﾀ… ワイ（うーん…なぜ未だにnodistで消耗しているのか…😨） TL;DR nodistはもうやめよう 選定するときは、まず選定基準を決めよう 関連技術の特徴を洗い出そう それらが自分たちの環境にどれくらいマッチするかで比較しよう Windowsならfnmがオススメ1！ ※ バージョン管理ツールがなんだかわからない方は「Node.jsのバージョン管理ツールとは」からお読みください。 うわっ…私の現場、nodist使いすぎ…？ Node.jsの利用が本格化してきたころ、私の周りでは圧倒的にnodistが流行し
ホームソフトウェアLinus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス Linus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス 2023 2/22 LinuxおよびGitを開発したLinus Torvalds氏が、Gitのマージに関して直々にアドバイスしていた事がわかり、注目を集めています(Phoronix)。 Linus Torvalds氏のGitマージに関する実践的なアドバイスは「もしマージのことを説明できないのなら、やらないことだ。これは本当に簡単なことです。マージの理由を説明しないままマージすることは絶対に許されない」というものです。 Linus氏はマージに対するコメントが十分に含まれていないプルリクエストを発見し、我慢の限界を突破し
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい
アメリカにおける黒人差別問題が再び大きく話題となる昨今だが、プログラミング界隈でもGitのデフォルトブランチ名である「master」が奴隷制に基づくものであるとして「trunk」に変えようという動きが上がっているらしい（outsider reflex、blacklist/whitelist master/slave に関する情報集め）。 特に大きな話題となっているのは、GitHub公式のCLIツールが、デフォルトブランチ名を「master」から「trunk」に変える変更を行った話である。この件についてのissueは反対意見も出ていたものの、管理者の一存で5月27日にマージされており、今後利用者に大きな影響を与えることになるとみられる。 なおGitでは「slave」は使われておらず、Gitの「master」は奴隷と関係ない「master」ではないかという意見もあるが、Gitの「master」
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
TL;DRGitHubからgitプロトコル(git://github.comで始まるURL)でgit cloneする設定になっている人が居たらSSHプロトコル(git@github.comで始まるURL)を使うように設定変更しましょう wez/weztermという端末エミュレータを知って、使ってみようかと思い、ドキュメントに従ってbrew tapしたときのことでした。次の様なエラーが発生して、tapできません。 $ brew tap wez/wezterm ==> Tapping wez/wezterm Cloning into '/opt/homebrew/Library/Taps/wez/homebrew-wezterm'... fatal: remote error: The unauthenticated git protocol on port 9418 is no longer
まだまだ 2022 年の振り返りが終わらないぜということで今日は dotfiles の振り返り。dotfiles はその変遷を見ると面白いので、毎年やろうと思い早速やっていきたい。 ちょっと前に M2 の MBA 買って、dotfiles を一新した。 これが今の dotfiles だ。 https://github.com/sadnessOjisan/dotfiles コンセプト 自分は Mac しか使わない が、WSL 環境も持ってるのでシェル周りの環境は移せるように作っておく（原神しかしないけど・・・） make all だけでセットアップが完結する 手作業はしない なるべく標準に準拠し、プラグインやライブラリへの依存を減らす。入れる場合も単体で剥がせるものを選ぶ。 シンボリックリンクを貼って、dotfiles の変更が即時に反映されるようにする .config など XDG に準拠
はじめに こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIシステムの運用及び監視を担当しております。 FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。 これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。 なぜサーバーレスを採用したのか FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在
こちらはエムスリーAdvent Calendar 2024 13日目の記事です。 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、長年運用されてきたレポジトリをgitを使って発掘する上で使っている道具を紹介します。 福岡タワー（ふくおかタワー）は、福岡県福岡市早良区のシーサイドももち地区にあるランドマークタワー（電波塔）。本文には関係ありません。 帳票環境 レポジトリからDBテーブルの使用箇所を探す スケジュール設定だけ消される gitレポジトリ考古学 ファイルが消えたコミットを知りたい ある記述が消えた(追加された)コミットを知りたい あるテーブルが使われているバッチを探したい 大量にgit grepしたい git grepの結果がEUC-JPでもUTF-8でも正しく日本語を出力する まとめ We are hiring! 帳票環境 弊社には「
環境構築 以下の手順で構築していきます． 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のビル
2024-08-28 GOTOOLCHAIN=auto時にはtoolchainディレクティブに指定したものより新しいGoがインストールされていても戻るわけではないという話を追記しました。 Go言語では半年に1回メジャーリリース（マイナーバージョンの更新）がやってきます。ちょうどこの8月にGo 1.23がリリースされたばかりです。Go言語のメジャーリリースは最新2つ分までサポートされるポリシーであることがhttps://go.dev/doc/devel/releaseに書かれています。現在であればGo 1.23やGo 1.22はサポートされており、Go 1.21はサポートが切れているということです。 また、サポートされているバージョンでは、不定期でマイナーリリース（パッチバージョンの更新）がやってきます。バグ修正や脆弱性対応がメインですね。 Goがリリースされると、Goでアプリケーションを作
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 個人開発の場合はそんなに意識することがないGitですが、チーム開発においては重要な役割を果たします。 はじめのうちは構造が見えず混乱するかと思いますが、流れをイメージ出来ればそんなに難しいものではありません。 これを見れば開発に必要なGitコマンドとリポジトリの構造、Githubでの管理手順を理解し開発の現場で実践できるようになります。 そもそもGitとは？ 変更履歴を記録・追跡するための分散型バージョン管理システムである。 ざっくりいうとファイルのバージョン管理が簡単にできるツールといえます。 目次 Gitを理解するための基
GitHubがSubversionのサポート終了を発表、2024年1月8日まで。その後は全面的にGitに注力予定 GitHubは、GitHub.comとGitHub Enterprise ServerにおけるSubversionのサポートを、今から約1年後の2024年1月8日で完全に終了することを明らかにしました。 We'll be removing Subversion support from versions of GitHub Enterprise Server after January 8, 2024. Learn more here: https://t.co/djXDh1QCzh — GitHub (@github) January 23, 2023 Subversionは、プログラムのソースコードを管理するシステムもしくはその仕組みの名前で、クラアイント／サーバ型のアーキ
いま急速にユーザー数が増えているVisual Studio Code（VSCode）。人気の高さゆえ、ほかのテキストエディタからの乗り換えも進んでいますが、その反面、新世代エディタ特有の高機能さがハードルになっていることもあります。本書は、そのハードルをなくすことを目指した「やさしい、役立つ解説書」です。VSCodeを使ってみたい／使っているユーザーが、もっと便利に使いこなせるようになることを目指し、基本からカスタマイズ、効率アップにつながる操作方法、さらにVSCodeが標準サポートしているGitの使い方まで丁寧に解説しています。
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
「今すぐ薬が必要だ！」→届きます!? 東海道新幹線で「荷物輸送」スタート JR東海とジェイアール東海物流は2024年2月15日、東海道新幹線を活用した荷物輸送サービス「東海道マッハ便」を開始すると発表しました。 東海道新幹線で荷物輸送サービスが始まる（画像：写真AC）。 JR東日本の「はこビュン」などと同様、新幹線を活用した「貨客混載」のひとつとして、法人向けの即日荷物輸送サービスをスタートさせます。「安全・正確・高速・高頻度で揺れが小さいという特性を活かし、速達性に優れた高品質で環境負荷の小さい荷物輸送サービス」だということです。 具体的には、東京～名古屋間、東京～新大阪間において「こだま」の11号車にある業務用室を活用。1回あたりおおむね段ボール40箱分（3辺合計120cm換算）まで輸送可能だそうです。1日最大の設定可能本数は、東京～名古屋間で26本、東京～新大阪間で22本となります。
バージョン管理システムについておさらい Gitというのはバージョン管理システムで広く世の中に使われています。あのLinuxの大元を作ったLinusさんが2週間で作ったっていうのは有名な話です。 hyoshiok.hatenablog.com だいたい、バージョン管理システム自体が一般の人々にとってはなんじゃらほいですよね。プログラマーが主に使います。プログラムって、どんどん修正していきますよね。で、修正したら機能が追加されたり動きが良くなったりするのですが、たまにとんでもないバグが埋め込まれていたりします。で、aaa.prgというソースコードを作っていて、aaa.prg.20200418とかってファイルを作ったりして古いソースコードファイルのバックアップを取ったりすると、そのうちバックファイルだらけになったり、バックアップを戻したタイミングで戻るべきではないものまで戻ったりして、現場は大混
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
GitHubがコマンドラインでのGit操作時の認証方式のひとつである、パスワード認証を廃止すると発表しました。同サービスは2020年11月にREST API利用時におけるパスワード認証を廃止し、二段階認証などのトークン認証に移行しており、今回の発表はその範囲を拡大した形となります。 Token authentication requirements for Git operations - The GitHub Blog https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ 近年、GitHubは二段階認証やサインインアラート、デバイス認証、WebAuthnへの対応など、トークンを基盤としたセキュリティ機能の向上に力を入れてきたとのこと。トークンは「ユーザーごとに固有」「いつで
Architecture Decision Records(ADRs)は、アーキテクチャ上の意思決定をドキュメントとして残す方法の1つです。Release It!の著者であるMichael Nygardのブログによって広まり、ThoughtWorks社のTechnology Raderでも「adopt」になっています。
こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないように思われたので、この記事が事例の一つとして参考になれば幸いです。 Release Please Relea
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,
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 60 週目の記事です！2年間連続達成まで 残り 46 週 となりました！ 「モジュラーモノリス」はここ数年で広く普及してきました。実際にモジュラーモノリスを取り入れた開発事例を多く見かけるようになりました。当記事では改めてモジュラーモノリスの起源を遡り、また、さらにその先に進むためにどのような準備をしておくべきかを軽くまとめてみます。 モジュラーモノリスとは モジュラーモノリスの起源は 2018 年頃 「モジュラーモノリス」という言葉の正確な起源は把握していませんが、Simon Brown が GOTO Conference 2018 で行った講演がその起源の一つかもしれません。この講演は、モジュラーモノリスの概念をわかりやすく説明しており、その後、多くの企業がこれに注目するきっかけとなりま
数千万行に及ぶLinuxカーネルのコードのうち、どんなときにどこのコードを読めばいいか、そのときに何を手がかりにすればいいか、などについてお話します。 本記事は、TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 「カーネルコードの歩き方」というタイトルでお話しする武内覚と申します。ふだんはsatと呼ばれています。社会人1年目から15年ぐらいカーネルの開発とサポートをずっとやってきました。今も必要に応じてカーネルソースを見ています。 本LTで学べるのは「Linuxのカーネルソースの読み方についての勘所」です。直接読んでいくというより、もう少しメタな
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEフロントエンド開発センターの玉田です。新春を名乗るにはすこし遅いですが、昨年開催した「UIT新春Tech blog」を今年も開催します！ 本日から5日間4日間、フロントエンド開発に携わるUITのエンジニアが毎日持ち回りで記事を公開します。ぜひ最後まで見に来てください。 Monorepo フロントエンドにおけるMonorepo toolは、大規模なフロントエンド開発を効率よく管理する手段として、ここ数年で普及が進みました。LernaやNx、npmやyarnのWorkspace機能など、すでに皆さんも使っている例があるかもしれません。 Monorepoを実現するツールはいくつかありますが、どのツールも共通して以
$ git log --name-status --author="$(git config --get user.name)" | grep -E '^(A|M|D)\b' | awk '{ print $2 }' | sort | uniq git logの最後にディレクトリ名を入れると、そのディレクトリ以下のファイル一覧を取得することができます。昔書き捨てたスクリプトがあった気がするんだけどどこにやったかな〜というときに便利です。どうぞご利用ください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く