Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
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を実現するツールはいくつかありますが、どのツールも共通して以
Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
Git で会社のリポジトリとかは自動で別のメアドを使うようにする - 宇宙行きたい
仕事でGit使うときとか普段とは違う会社のメアドでコミットとかしたいんだけど、cloneするたびに git config user.email とかするのメンドイよね〜 というかもうだいぶ有名な設定だと思うんだけどたまに知らない人いるので書いておくと includeif 使うと特定のディレクトリ以下のときに読み込む設定を変更できるので便利です。 で、ここまでは普通にGitのマニュアルにも書いてあるんだけど ghq と組み合わせると最高便利になるのでそのへんの設定を書いておきます。 といっても普通に設定するだけだけど .gitconfig には下記のように書いておいて [ghq] root = ~/src [includeIf "gitdir:~/src/github.com/launchableinc/"] path = ~/.config/git/launchable.inc ~/.co
VSCodeでよくあるgit操作をキーボードだけでする(tigみたいに）
私は普段VSCode + Neovim拡張を利用しています。 私自身似非vimmerなのですが、「vimの効率的なキーバインドで高速に業務を進める」という精神みたいなのものは凄く素敵だと思っています。 今回は私が頻繁に使っているgitの操作をキーボードだけで行えるようにショートカットを設定してみました（日々改善中です） VSCodeのGit機能って凄く便利 VSCodeのサイドバーに配置してくれているgitの機能凄く便利じゃないですか？ 編集したファイルや新規追加したファイルの差分を見れてとても便利です。 git add でステージングしたり、逆にステージングから戻したりという操作もマウス操作で簡単にできていいですよね。 コミットメッセージを入力してささっとコミットできるのも素敵です。 この辺りの操作をキーボードで行いたいと思ってキーボード設定を変更してみました。 keybinding.j
コードベースのどのへんを触ったことがあるかを一覧する - 見返すかもしれないメモ
今所属してるチームに入ってから1年が経った。開発してるサービスのコードベースの中でも、「このへんはわりと土地勘がついてきたな」という場所と「ここはまだ全然わからん」という場所が混在している感じになってきた。 自分がまだ触ったことないのはどのあたりかを知りたかったので、今までの自分のコミット数をファイルごとに見れるようにしてみようと思った。調べてもそういうツールは見つからなかったので、作った。 ファイルの履歴 ファイルのコミット履歴を出力する: git log ファイル名 リネーム前の履歴も欲しい: git log --follow ファイル名 しかし --follow つけると、ファイルをコピーしてからちょっと編集したやつも同一ファイルと見做されてしまうので、それをなるべく避ける*1: git log --follow --find-renames=100% ファイル名 そのコミット履歴を
WSL で Git の使用を開始する
Git は、最も一般的に使用されるバージョン管理システムです。 Git を使用すると、ファイルに加えた変更を追跡できるため、実行された内容の記録が得られ、必要に応じて以前のバージョンのファイルに戻すことができます。 また、Git を使用するとコラボレーションが容易になり、複数の人が加えた変更をすべて 1 つのソースにマージできます。 Git は Windows と WSL にインストールできます。 重要な考慮事項: WSL を有効にして Linux ディストリビューションをインストールすると、マシン上の Windows NTFS C:\ から分離された、新しいファイル システムがインストールされます。 Linux では、ドライブに文字が指定されていません。 マウント ポイントが指定されます。 ファイル システムのルート / は、ルート パーティション (WSL の場合はフォルダー) のマウ
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Token authentication requirements for Git operations
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
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
パーシャルクローンとシャロークローンを活用しよう
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
Git - Rerere
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
コミットを整理してみよう｜おだいり｜note
これは『フィヨルドブートキャンプ Advent Calendar 2020 Part 2』7日目の記事です。 https://adventar.org/calendars/5230 こんにちは！メンター枠の odaillyjp です。 今回は生徒の方々向けに「コミットを整理してみよう」という話をします。 コミット整理の重要性「Ruby で ls コマンドを作る」や「Sinatra を使って Web アプリケーションの基本を理解する」などの実装を必要とするプラクティスでは、生徒は実装したプログラムを Pull Request で提出し、メンターに確認していただいていますよね。 私はメンターの立場ということで皆さんの Pull Reqeust をレビューしていますが、実装されたコードを読んでいて、いつも「実装しないといけない機能が盛り沢山である中で、なるべく実装をシンプルにまとめようと頑張って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - initialcommit-com/git-sim: Visually simulate Git operations in your own repos with a single terminal command.
GitHub - koseki/git-object-browser: Browse raw git objects.
