GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
僕たちが行き着いた、シンプルで簡潔なGitの運用方法 - テクノロジーと広義のデザイン！
Gitを使い始めて１年以上たちます。最近、Gitを使ったプロジェクト運用方法が自分なりに固まってきたので公開します。かなりシンプルなので、ある程度Gitに慣れていれば十分に運用可能だと思います。 僕たちが理想とするヒストリーGitを使った開発の成果物、それは開発のヒストリー（履歴）そのものです。このヒストリーが論理的に正しく、かつ、簡潔で理解しやすいものを目指すというのが大方針となります。その方針のなか、現時点で僕たちが理想だと考えているのが、以下の図のような履歴がリモートブランチに残ることです。このヒストリーには２タイプのブランチが存在します。 リリースブランチ … 次期リリースバージョンに向けて進んで行くブランチ。チケット１枚について１つのコミットが良い。 フィーチャーブランチ … チケット１枚について１つ切られるブランチ。機能を実装する際に小刻みにコミットしたログが残っているため、後
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
