Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
GitHub - chriswalz/bit: Bit is a modern Git CLI
bit is an experimental modernized git CLI built on top of git that provides happy defaults and other niceties: command and flag suggestions to help you navigate the plethora of options git provides you autocompletion for files and branch names when using bit add or bit checkout automatic fetch and branch fast-forwarding reducing the likelihood of merge conflicts suggestions work with git aliases n
令和時代のRubyコア開発 - k0kubun's blog
Ruby Core Development 2019というタイトルでRubyKaigiのCFPにプロポーザルを書いたのだが、 もう一つ書いた方の話が採択されたのでその話はしなかった。 さて、今日はRubyコア*1の開発がSubversionからGitに移った節目でもあったので、そっちのトークで言いたかったことの一部を記事にしておこうと思う。 Subversion → Git 移行 [Misc #14632] 去年くらいから @hsbt さんが cgit というGitフロントエンドを使ってGitリポジトリの準備を始め Misc #14632、ついに今日正式にcgitの方がupstreamになった。平成の時代でSubversionでのtrunkのRubyコア開発は幕を閉じた。 この辺を進めているのは主に @hsbt さんな中、僕がこれを偉そうに書いたり今回のRubyKaigiで壇上でアナウンス
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
Git Large File Storage
An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise. Getting Started Download and install the Git command line extension. Once downloaded and installed, set up Git LFS for y
Vulnerability announced: update your Git clients
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
GitHub で submodule ではなく subtree を使うべき理由
GitHub には、タグを打つとソースパッケージを自動的にリリースするという機能があります。スクリプト言語においては、それぞれの言語について一般的なパッケージ管理システム注1があるため、この機能を使うことが少ないかと思いますが、デファクトのパッケージ管理システムが存在しないC等の言語で書かれたプログラムや、単独で動作する管理用のスクリプトを GitHub で開発・配布する際には、本機能はとても便利なものです。 しかし、この機能は git-archive コマンドのラッパーとして実装されているため、サブモジュールのファイルが含まれないという問題を抱えています。この点は GitHub の人たちも認識しているものの、今のところ GitHub で独自に対応するということは考えていないようです注2。 私がこの問題を 知ることになったのは、picojson の issue で指摘を受けたからです。pi
develop ブランチなんてオワコン
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
Linux-Kernel Archive: [ANNOUNCE] Git v2.0.0
From: Junio C Hamano Date: Wed May 28 2014 - 18:31:24 EST Next message: Dave Chinner: "Re: [RFC 2/2] x86_64: expand kernel stack to 16K" Previous message: Bjorn Helgaas: "Re: [PATCH v3 10/15] thunderbolt: Add path setup code." Next in thread: Junio C Hamano: "Re: [ANNOUNCE] Git v2.0.0" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] The latest feature release Git v2.0.0 is now avail
ScaleOut | Supership
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
git send-email
git には send-email というメールを送信するコマンドがあります。 ただし、普通のメールを送信するのに使うというより、パッチを送る用途に使います。 パッチを自分のメーラーに貼りつけて送信してもいいのですが、 メーラーによっては、長い行を勝手に改行してくれたりして、パッチが破壊される可能性もあります。 リポジトリ管理に git を使っているプロジェクトだと、 git format-pach でパッチ生成 ⇒ git send-email で送信 とするのが手順的にも楽です。 オープンソースの開発にコントリビュートするのに必須ですね。 セットアップについてメモ。 git-core を入れただけでは、 git send-email コマンドはまだ入っていないかもしれません。 Ubuntu の場合は # apt-get install git-email でインストールできます。 (他
LinuxカーネルHack: git commitからgit send-emailでGMailアカウントを用いたパッチ送信まで - 佐野デジタル研究所
はじめてBtrfsにパッチを投げてみました。修正は単純で、メモリー確保後のチェックをより厳密にしただけです。Btrfsの開発コミュニティはBUG_ON撲滅に向けて動いているのに、BUG_ONを増やしてしまいました。http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg08420.html 現時点ではコードが取り込まれるかどうかはわかりません。リジェクトされるかもしれません。btrfs-unstableで取り込まれたら、メインラインへのマージはほぼ確実なので、今からワクワクです。リジェクトされたとしても、パッチ送信までの手順を踏めたのは大きいです。 で、今回は、参考までにパッチ送信までの流れを記録として残しておきます。 コミット まず、修正したコードをコミットする。 fixme@xr:~/btrfs-unstable$ git
Releasing to Linux kernel using patches and emails - OMAPpedia
[edit] How to submit patches OMAP platform linux mailing list linux-omap@vger.kernel.org can be used for patch submissions and discussions. Click here to subscribe to the list or/and get more information. We recommend the use of git-format-patch and git-send-email to generate and submit patches. More detailed information... Introduction: This page gathers some useful information for releasing (or
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
git を https 経由で使うときのパスワードを保存する - Qiita
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ギットクエスト
gitのhookでtags作成 - Qiita
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git-flowでもgithub flowでもない、Git本家推奨のワークフロー