[B! git][development] hush_inのブックマーク

ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)

https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。ベースパターンソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターンメインラインイン

hush_in 2020/06/23

リンク

Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO

開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。この記事の英語版も書きました。前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。ガイドライン定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid

hush_in 2020/04/09

リンク

「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。戦略ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースするなぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。失敗パターンその1: 巨大PRパターン失敗パターンその2: 新機能リリースブランチパターン失敗パターンその1: 巨大PRパターン新機

hush_in 2017/08/08

リンク

最近のgitを使った開発フローについて - その手の平は尻もつかめるさ

最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです．なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン