はじめに CHANGELOGを自動生成するツールは多種多様です。Conventional Commitsに対応したコミットメッセージから生成するもの、GitHub上でのリリースやタグ付けまで行うものなどがあります。 CHANGELOGを自動生成する際には、バージョンタグに対応したコミットメッセージを基にしてくれると便利です。コミットメッセージを適切に付けるだけで、後はツールにお任せできます。ただし、いくつかの懸念点が存在します。 懸念点 1: チキンエッグプロブレム CHANGELOG自動生成ツールは便利ですが、一つの大きな問題があります。それは、Gitのタグとコミットメッセージを基にCHANGELOGを生成するため、タグを作成する前にはCHANGELOGが存在しないという点です。この状況は「チキンエッグプロブレム」に類似しています。具体的には、新しいバージョン(卵)がリリースされる際には
Author Taylor Blau オープンソースの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: En
simple-git を使って、TypeScript による自動化事例を記事に致しましたが、TypeScript による cli のフレームワークを主に説明していたり、方向性が微妙なポストだなぁと反省…。 こんにちは、高崎@アノテーション です。 はじめに 我々が行っている作業におきまして、手動でファイルを更新することや環境を整備することは少なくありません。 以前から手を抜いて少ない工数で効率よく、かつ人為的ミスを削減することを生き甲斐としておりまして、手動でファイル操作をするものがあれば、以前ですと Linux のターミナル上で作業していたこともあり bash シェルで自動化を行う方法はないか、を常に考えていました。 ファイルの変化を見る場合はgitを使ってローカルでリポジトリを組んでみたり、結果の文字列を捏ねて諸々処理する時には、シェルを実装するに当たって欠かすことのできないawkやs
この記事は GMOアドマーケティング Advent Calendar 2023 5日目の記事です。 皆さん、お久しぶりです。GMOアドマーケティングのGood!Apps開発担当のharuです。 最近、弊社の開発部ではFour Keysを導入し、開発者体験や生産性の向上に注力しています。今回は、Four Keysの計測に必要な処理の一部を自動化しましたので、その詳細についてお話しできればと思います。 Four Keysとは まず、Four Keysについて簡単に説明します。 Four Keysは、GoogleのDevOps Research and Assessmentチームが提唱した、ソフトウェア開発チームのパフォーマンスを評価するためのフレームワークです。このフレームワークは以下の4つの指標で構成されています。 デプロイの頻度: 本番環境へのリリースの頻度を示します。頻繁なリリースは、ア
はじめに bun installで生成されるBunのロックファイルはbun.lockbというバイナリファイルである。 公式を読むと性能向上のためにバイナリ化していることがわかる。 Why is it binary? In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles. 困ること まさにこのツイートの問題で、Git管理したいのにバイナリが出力されるのは不便で、どうしよう? と実際の本番利用では困るだろう。 解決方法 案1. git diffで差分確認する 公式のページを読むと、どうやら設定追加でgit diffができるらしい。 bun install request g
「Radicle」はGitリポジトリをP2Pで共有できるオープンソースソフトウェアで、ユーザーが独自のノードを実行するためサードパーティーに依存したり検閲を受けたりすることなく他人と協力して開発を行う事が可能です。そのRadicleの開発者がニュースサイト「Hacker News」のコメント欄に出現し、ユーザーのさまざまな疑問に答えました。 Radicle: sovereign code infrastructure https://radicle.xyz/ Radicle: Open-Source, Peer-to-Peer, GitHub Alternative | Hacker News https://news.ycombinator.com/item?id=39600810 Q:P2Pはバズワードとして使用されて以来非常に幅広い意味を持つようになってしまったので、ここではどういう
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 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"方式が好きになれません。どんなに巨大なプルリクエ
I spent a lot of time walking this weekend thinking about the reaction from our industry to my last blog post. We’ve been called evil; I was called an IBM exec who was installed to turn Red Hat closed source — and that’s only the “nice” stuff. So let’s clear things up. My name is Mike McGrath, and I’m the Vice President of Core Platforms Engineering at Red Hat. I’ve been here for 16 years, and bef
はじめに先日、関わっているプロジェクトで使っている macisamuele/language-formatters-pre-commit-hooksを長らくアップデートしていなかったのでアップデートした。 すると内部で使用しているフォーマッタのバージョンも上がり1フォーマットに微妙な差が出てしまった。 なにも考えずに差分をcommitしても良かったが、コードのフォーマット変更のコミットを追加してしまうと、後々 git blame で本来の変更コミットが追いづらくなってしまうのは避けたかった。 そこでプロジェクトに以下のような .git-blame-ignore-revs ファイルを導入することで解決した。 # This is a file used by GitHub to ignore the following commits on `git blame`. # # You can a
Open SourceHighlights from Git 2.44The first Git release of 2024 is here! Take a look at some of our highlights on what's new in Git 2.44. The open source Git project just released Git 2.44 with features and bug fixes from over 85 contributors, 34 of them new. We last caught up with you on the latest in Git back when 2.43 was released. To celebrate this most recent release, here is GitHub’s look a
GitHub CopilotにはCLIがあるのを思い出して、コマンドの実行結果をそのままプロンプトに渡すと、文脈に沿った仕事をお願いしやすいんじゃないか、と思って、試してみた。 git stashをよく使うのだけど、一覧になっていると、何がstashされているかわからないので、stashの保存時に、内容を要約してもらう、というタスクを試してみる。 なんらかのCLIにdry-run機能をつけている途中で、git stashしたいとする。 index f1f5a2f..dd70bf5 100755 --- a/cli.js +++ b/cli.js @@ -19,6 +19,10 @@ command } else { command.help(); } + }) + .arguments(['dry-run']) + .action(async(file) => { + console.lo
Some companies use an isolated network or even the complete lack of a network as a security measure to protect from unauthorized access. Working on these systems can be a struggle but it is still possible, and perhaps even more important, to use a proper version control tool like Git. By design Git works quite happily with no remote repository. You can branch, stage, and commit files just like nor
はじめに 組織で開発を行っている皆さんは普段からPull Request(PR)を作っていますよね?(決めつけ) masterブランチに直接pushしている方も中にはいるかもしれませんが、会社やチームで開発を行っていると、PRを作成する頻度は高いのではないかと思います。 そしてPRを作成する際には、その説明文を書く必要があります。 コードだけを読んで修正意図が伝わればいいですが、そうはいってもすべての背景をコードベースで伝えるのには限度があります。 しかし、だからといって修正の背景や詳細を、開発者自身が客観的な文章で伝えるのは簡単なことではありません。 そこで、この記事ではgit diffとChatGPTを組み合わせて、自動的にPRの説明文を生成する方法をご紹介します。 How to make PR? 繰り返しになりますが使うのはgit diffコマンドとChatGPTだけなんです!(お昼
Scott Chacon's FOSDEM 2024 talk on Git Tips and Tricks. Scott talks about: 00:00 - Introduction 01:06 - About Me (well, Scott Chacon) 02:36 - How Well Do You Know Git? 05:09 - Our Agenda 06:25 - Some Helpful Config Stuff 09:42 - Oldies But Goodies 16:22 - Some New Stuff (You May Not Have Noticed) 23:48 - Some Big Repo Stuff / Monorepo Stuff 33:29 - Some New Github Stuff 35:54 - GitButler 36:50 -
Note: This post stirred up some interesting discussions on HackerNews and Lobste.rs. SQLite stores data in binary. If you run cat mydb.sqlite, you'll see a bunch of gibberish that doesn't resemble structured data at all. If you want to track changes and updates to a database using Git, you won't be able to see full diffs by default. You'll see that the file has changed, but not what changed exactl
こんにちは! 株式会社OGIX クライアントエンジニアのY.Kです! (弊社については最後に紹介があるのでぜひ見てください) みなさんはGit GUIツールを使用していますか? 私はGit触り始めての頃にコマンドラインツールでのGit操作していた所、先輩にGit GUIツールの使用を勧められました。 最初はコマンドラインでの操作と比べて段違いで操作しやすい!!!と感動していました。 ですが最近になってGit GUIツールでのできないこと、ツールならではのデメリットなどに気が付いたのでGit GUIツールについて簡単に紹介しようと思います。 Git GUIとは? GUI(グラフィカルユーザーインターフェース)は、ユーザーが直感的に操作できるグラフィカルなインターフェースのこと。 マウスやタッチパネルなどの入力デバイスを用いて、ウィンドウやアイコン、メニューなどを操作でコンピュータプログラムの
まずは結論 Gitに不慣れなうちは、何か操作をする前にとりあえず git status を打ちまくりましょう。 エラーでトラブっている時だけでなく、うまくいっている(と思っている)時も含めてです。 それがミスを未遂にとどめたり、困ったときの指針になったりします。 想定読者 Gitの基本は一通り学習済みだけど、以下のようにコマンド操作にはまだ自信がない人。 トラブルが起きたらとりあえず git reset --hard HEAD で初期状態に戻してやり直してる ググって出てきたコマンドを打って雰囲気で解決してるけど、あまり理解できてない PRをレビューしてもらうとき、Gitの操作起因で間違った状態になっていることの指摘を多く受けたり、その解消に時間を費やしがち git status が役立つ事例紹介 ここからは、後輩の指導などでも発生した事例をもとに、どこで git status を使ってい
Linux Daily Topics Linux 6.8リリース、メインラインのGitオブジェクト数はまもなく1000万に Linus Torvaldsは2024年3月10日(米国時間)、「Linux 6.8」の正式版を公開した。通常のカーネルサイクルと同様に開発期間に約2ヵ月、7本のリリース候補版を経ての公開となる。 Linusはリリースにあたって「いくつかの作業に行き詰まりはあったが、リリースを予定より遅らせる理由は何もない。Linux 6.8はすべての点で平均的なリリースで、新しいファイルシステムやアーキテクチャの採用はない。目立つことといえば、Gitオブジェクトの数が1000万未満となる最後のメインラインカーネルになることくらいかな。オブジェクトの数は999万6,000個に達しており、linux-nextツリーではすでに超えている。もっともすばらしくキリが良い数字という以
The open source Git project just released Git 2.45 with features and bug fixes from over 96 contributors, 38 of them new. We last caught up with you on the latest in Git back when 2.44 was released. To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time. Preliminary reftable support Git 2.45 introduces preliminar
All of us - software engineers - use git every day, however most people only ever touch the most basic of commands, such as add, commit, push or pull, like it's still 2005. Git however, introduced many features since then, and using them can make your life so much easier, so let's explore some of the recently added, modern git commands, that you should know about. Switch New since 2019, or more pr
EngineeringOpen SourceHighlights from Git 2.42Another new release of Git is here! Take a look at some of our highlights on what's new in Git 2.42. The open source Git project just released Git 2.42 with features and bug fixes from over 78 contributors, 17 of them new. We last caught up with you on the latest in Git back when 2.41 was released. To celebrate this most recent release, here’s GitHub’s
TL;DR 最近チーム内で、mergeではなくrebaseを推奨する動きが出てきたので、この機会に rebase の動きをちゃんと理解しておこうという足跡です。 merge の動きを確認する まず、merge_aというブランチを作成し、一つコミットを作ります。 次にmerge_bというブランチを作成し、一つコミットを作ります。 再びmerge_aブランチに戻り、一つコミットを作ります。 ここで、merge_aにmerge_bをマージします。 すると以上のようにマージコミットが作成され、コミットの時系列の順にブランチが並びました。 rebase の動きを確認する まず、rebase_aというブランチを作成し、一つコミットを作ります。 次にrebase_bというブランチを作成し、一つコミットを作ります。 再びrebase_aブランチに戻り、一つコミットを作ります。 ここで b をベースにリベー
はじめに Git Advent Calendar 2023 3日目の投稿です。よろしくおねがいします。 前々回、前回を通じて以下のコマンドが使えるようになったと思います。 git init git add git commit git branch git checkout git merge 内部でどんな動きがされてるか気になったので、今回は↑のコマンドを実行した時に.gitフォルダの中がどのように変化するか観察したいと思います。 やること 下の感じで進めていきます。 リポジトリ(A)を作成 ⬇ リポジトリ(A)の.git内でgit initして.gitを管理するリポジトリ(B)を作成 ⬇ リポジトリ(A)の方でGitのコマンドをいろいろ打ってリポジトリ(B)で差分を観察 Gitリポジトリを2つ使っているので、切り替えがわかりにくい箇所があると思いますがご容赦ください 準備 「git/s
Ubuntu Weekly Recipe 第792回GUIのGitクライアント、GittyupでGitの勉強をする 今回はオープンソースでマルチプラットフォームなGUIのGitクライアント、Gittyupを紹介します。 Git初学者向けのGUIクライアント あなたはプログラマーです。Gitも突っ込んだことは検索しないとよくわからないものの、普段遣いする範囲では手に馴染んたツールとなっています。 そんな中、同じチームに中途採用の新人が配属されることになりました。プログラムに関する知識はあるものの、Gitについては経験がないらしく、説明してくれと上長から言われてしまいました。 そんな人に説明できるほど詳しいわけではないんだけどな……と思いつつ、クライアントOS(もちろんUbuntu)で動作するGitクライアントを探し始めました。長期的に考えればgitコマンドを覚えてもらうほうがいいに決まっ
Next.js(最新version)でChatGPTのCloneアプリを作成してみた。(Gitで確認できます)PythonJavaScriptVue.jsReactChatGPT ChatGPTをゼロから作ってみた 作成したアプリの画像 下記でアプリを実際に動かせるのでよかったら確認してみてください。 ChatGPT-Clone-AppのURL プロジェクトはGitで管理してますので、クローンして使ってみてください。 chat-gpt-clone-appのGithubリポジトリのURL 自己紹介 お久しぶりの投稿です。本業と個人の仕事で忙しく1年振りの投稿になります。 株式会社DYMのエンジニアをしております、永松です。 普段はインフラはAWSを使い、Python(FastAPi), Golang(net/http), PHP(Laravel), TypeScript(Nuxt.js or
Are you sure? Debugging with Git? What are the tools that comes on your mind when someone say “debug”? Let me guess: a memory leak detector (e.g. Valgrind); a profiler (e.g. GNU gprof); a function that stops your program and gives you a REPL (e.g. Python’s breakpoint and Ruby’s byebug); something that we call a “debugger” (like GDB, or something similar embedded on the IDEs); or even our old frien
Gitの包括的な解説書。本書ではVCS(バージョン管理システム)の使用経験があるソフトウェアエンジニアを対象に、分散型バージョン管理システム「Git」の使い方を、リポジトリの内部やブランチの状態を示す図を多用しながら丁寧に解説します。開発時によく使われるサブコマンドだけでなく、トラブルシューティング時に使用するサブコマンドも幅広く解説します。Gitのサブコマンドの使い方だけではなく、Gitリポジトリの内部構造についても解説するので、読者はGitをより深く理解できるようになるでしょう。 賞賛の声 監訳者まえがき まえがき 第I部 Gitの思考法 1章 Git入門 1.1 Gitのコンポーネント 1.2 Gitの特徴 1.3 Gitのコマンドライン 1.4 gitコマンド入門 1.4.1 Gitを使う前の準備 1.4.2 ローカルリポジトリの操作 1.4.3 共有リポジトリの操作 1.4.4
Doc: use "an SQL" instead of "a SQL" Although which is correct depends entirely on whether you pronounce SQL as "ess-que-ell" or "sequel", we have standardized on the former in our user-facing documentation, so use the correct article according to that pronunciation. Discussion: https://postgr.es/m/CAApHDvp3osQwQam+wNTp9BdhP+QfWO6aY6ZTixQQMfM-UArKCw@mail.gmail.com
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く