gitworkflowsの補足(0) - 補助的解説など
gitworkflows(7)日本語訳の補助記事です。 Gitのワークフローというと、git-flowやgithub flowが有名ですが、実はGitプロジェクト本家で使われているワークフローがGit付属のマニュアル gitworkflows(7) に記載されており、Gitとともに配布されています。 このワークフローはシンプルなルールで覚えやすく、かつ参加人数に対してスケーラブルで便利なのですが、日本語訳が存在しないからか、あまり話題に登ることが少ないように思います。そこで今回日本語に翻訳しました。(CopyrightはGit本体と同じです。) なお、gitworkflows(7)が他のワークフローよりも優れている、というわけではありません。このマニュアルの冒頭にも書かれていますが、プロジェクトごとに最適なワークフローは異なるので、自分のプロジェクトに使えるエッセンスを抽出して応用するのが
gitworkflows(7)を図解したスライドをアップしました
前回に引き続き、こちらも会社の読書会でGit関連本の番外編として実施したgitworkflows(7)の解説資料（の加筆修正版）です。 マニュアルからすると講義用にかなりつまみ食い的な内容になってます。 副読本的な位置づけでマニュアルを読むのも良いかなと思います。 Gitの布教などにお使いください。 講義した感触だと、やはり少しややこしいワークフローだと感じるようです。 確かにGitの動きにある程度慣れてないと理解しづらいですし、スライドでは最終的な機能リリース直後だけ見るとシンプルなコミットグラフなんですが、途中のnextが混じった図は結構カオスです。 ただ、「ステージング環境は便利そう」という感想もありました。 Q and Aに出てきていますが、プロジェクトの状態や開発スピードによっては master と pu (使い捨て統合ブランチ)だけ、とか、 master, master-pu,
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Git workflow
システムの技術的負債にどう挑むか？～『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策～
GitHub Flow (Japanese translation)
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで git-flow についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチを master ではなく develop から開
GitHub Flow – Scott Chacon
Issues with git-flow I travel all over the place teaching Git to people and nearly every class and workshop I’ve done recently has asked me what I think about git-flow. I always answer that I think that it’s great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner.
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
リポジトリ×2+pullの運用が良いと個人的には強く思う - しげぽん日記
gitってリポジトリを分散管理できる。 なので共有リポジトリでもcloneを作ってしまえば、branch作り放題、addし放題、commit作り放題。 それがgitの良いところだと思っている。 でもgitを使って複数人で作業をする時って、実は気をつけないとわけわからなくなる。 というのは、共有するものの単位に自由度が高いから。 相手のリポジトリにpushで押しつける事もできるし、勝手にpullしてきて自分のリポジトリをいじっちゃう事もできる。 きっちり整理しないとどのリポジトリのどのブランチが最新なのかわからなくなる。 そこで以下のようなポリシーのもとでリポジトリを運用すればうまくいくんじゃないかな？と空想した事があるので紹介する。 実際に運用しようとしてあっさり却下されたという悲しいものだけど。 リポジトリは必ず2つ一組で運用する 1つは自身の開発用 もう1つは自身の開発した内容を他者に
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git - Branching Workflows
Endpoint® | Real Estate Closings, Title Insurance, and Escrow
Git branch strategy for small dev team
Git workflow for small teams
git-flowでもgithub flowでもない、Git本家推奨のワークフロー