[B! Git] fuyu77のブックマーク

squash and mergeしか使ってないけど全く困ってない

こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ

fuyu77 2023/12/01

git

リンク

綺麗なコミットログを作りたいときのgitテクニック - Qiita

これは何僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。初めからコミットを綺麗に書きながら開発ができれば良いのですが、にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていくコミットを作成する git rebase

fuyu77 2023/10/24

git

リンク

Why does git produce a merge conflict when lines next to each other are changed?

fuyu77 2023/10/10

リンク

Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba

「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。しっかり書きたいとき僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと

fuyu77 2023/06/05

git

リンク

コミットメッセージ規約「Conventional Commits」を導入してみよう！ / Let's use Conventional Commits

PHPerkaigi 2022 のレギュラートークで使用したスライドです。 https://fortee.jp/phperkaigi-2022/proposal/8acc191a-7625-4dad-afc3-3f52025e6e6b https://www.youtube.com/watch?v=-npgdvGAnlU

fuyu77 2023/03/12

git

リンク

Linus Torvalds 氏の理想の git 運用と GitHub

Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません少し古い記事になるが、 Linus Torvalds 氏の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない︵後述︶が、別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とするgit の開発フローを考察した上で、整理してみたい。 Linus 氏の理想結論からいうと、﹁意味あるコミットを作れ﹂﹁コミットを大事にしろ﹂という思想が伺える。では﹁意味あるコミット﹂﹁大事にされたコミット﹂とは何なのか。筆者な

fuyu77 2023/03/07

git

リンク

git gcの自動実行はいつ行われるのか - $shibayu36->blog;

gitを使ってるとたまにgitgcが走る。これがどういうタイミングで実行されているか調べたので軽くメモしておく。Gitでは時々auto gcが走るGit - Book を見ると、以下のように書かれている。Git は時々 "auto gc" と呼ばれるコマンドを自動的に実行します。大抵の場合、このコマンドは何もしません。もし沢山の緩いオブジェクト︵パックファイルの中にないオブジェクト︶があったり、あまりに多くのパックファイルがあると、Git は完全な︵full-fledged︶gitgcコマンドを開始します。さらに、auto gcは普段は何もせず、特定の条件を満たすと実際にgcするとも書かれている。繰り返しますが、これは通常は何も行いません。約 7,000個もの緩いオブジェクトがあるか、または50以上のパックファイルがないと、Gitは実際にgcコマンドを開始しません。これ

fuyu77 2023/02/28

git

リンク

Gitの驚愕の真実：1億行のファイルに1行追記するとレポジトリ容量が200MB増える[※補足あり] · DQNEO日記

１億行のファイルに１行追記するだけでレポジトリ容量が２倍になった以前の記事「Gitレポジトリはパッチの集積ではなくてスナップショットの集積である。」を確認するために、１億行のファイルを作って実験してみました。結果は、なんと１行追記しただけでレポジトリ容量が200MB増加し、サイズが２倍になりました。実験手順空のレポジトリを作る１億行のファイルを作ってgit addしてgit commit コミットするそのファイルに１行だけ追記してgit addして git commitする空のレポジトリを作る $ git init １億行のファイルを作る１億行のファイル(１から1億までの数字が書かれたファイル)を作ります。 $ seq 1 100000000 > numbers.txt この時点で、ワーキングツリーとレポジトリ容量を調べてみます。 $ ls -lh 合計 848M -rw-

fuyu77 2023/02/28

git

リンク

Linus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス | ソフトアンテナ

ホームソフトウェアLinus Torvalds氏、Gitのマージに関し﹁マージについて説明できないのならやらないほうがいい﹂ゴミだからとアドバイス Linus Torvalds氏、Gitのマージに関し﹁マージについて説明できないのならやらないほうがいい﹂ゴミだからとアドバイス 2023 2/22 LinuxおよびGitを開発したLinus Torvalds氏が、Gitのマージに関して直々にアドバイスしていた事がわかり、注目を集めています(Phoronix)。 Linus Torvalds氏のGitマージに関する実践的なアドバイスは﹁もしマージのことを説明できないのなら、やらないことだ。これは本当に簡単なことです。マージの理由を説明しないままマージすることは絶対に許されない﹂というものです。 Linus氏はマージに対するコメントが十分に含まれていないプルリクエストを発見し、我慢の限界を突破し

fuyu77 2023/02/23

git

リンク

Git submoduleを使ってマルチリポジトリなMonorepoを管理する

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を実現するツールはいくつかありますが、どのツールも共通して以

fuyu77 2023/02/22

git

リンク

Git fails to revert: Found a swap file "COMMIT_EDITMSG.swp"

fuyu77 2023/02/21

リンク

Conventional Commits type for merge conflicts

fuyu77 2023/01/12

リンク

Conventional Commits

Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意スコープ]: <タイトル> [任意本文] [任意フッター] あな

fuyu77 2023/01/05

Git

リンク

angular/CONTRIBUTING.md at main · angular/angular

fuyu77 2023/01/05

Git

リンク

Conventional Commits

Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer

fuyu77 2023/01/05

Git

リンク

Semantic Commit Messages

semantic-commit-messages.md Semantic Commit Messages See how a minor change to your commit message style can make you a better programmer. Format: <type>(<scope>): <subject> <scope> is optional Example feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Examples: feat: (new feature for the user, not a

fuyu77 2023/01/05

Git

リンク

Gitのコミットメッセージの書き方（2023年ver.）

本記事のモチベーション約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、﹁今の僕はこうコミットメッセージを書いているよ﹂というのをまとめました。Gitを使う環境開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変

fuyu77 2023/01/05

Git

リンク

大学の情報工学科はGitを教えませんが、それで実務ができるのでしょうか？企業は大学で習わなくても自分で勉強しており、入社したらGitは当たり前に使える人間が欲しいですか？

回答 (13件中の1件目) 社会に出てすぐ役立つスキルを教える大学は﹁職業訓練校﹂です︵暴言︶大学の情報工学科の役目を図で表してみましょう。まず、横軸は分野・ジャンルを表します。世界全体はもっと広いものですが、画面の横幅には制限があるのでご勘弁を。縦軸は一般から専門までの、専門性の高さを表します。一番下の層は﹁常識﹂です。だれもが持つべき知識や能力です。この常識をなるべく埋めようと、長い年月をかけて義務教育が行われます。下から二番目の層は﹁スキル﹂です。社会で付加価値を生む専門性です。例えば、IT・財務・外国語・プレゼンテーション・交渉術・チームマネジメント・・・等...

fuyu77 2022/12/01

Git
Quora

リンク

SVNを捨ててGitを使うべき5つの理由 - Qiita

まえがき私はGit好きの人間です。もっと言えば、Gitを愛している︵Git Lover︶と言ってもいいくらいです。そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。そんなわけで﹁会社にGit/GitHubを導入するための説得する﹂という目的でこの記事を書こうと思います。Gitの良さってなんだろう？実は私もこれまで強く意識して考えたことはありませんでした。Gitを使い出したら、それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。そういう意味では、Gitって中世における自動車に近いものがあるのかもしれません。その時代、移動手段といえば馬が普通であり、自動車などが普及するとは誰も考えなかったわけです︵たぶん︶。それが今で

fuyu77 2022/11/23

Git

リンク

特別な理由なしにgit-flowを新規採用するべきではない - Qiita

私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない例えばすでに何年もgit-flowでうまく回せてるよ、などどのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべきさて、 git-flow は 2010年1月「A succ

fuyu77 2022/07/11

Git

リンク

はてなブックマーク

タグ

関連タグで絞り込む (8)

Gitに関するfuyu77のブックマーク (106)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス