トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
Github Actionsでgitのブランチ運用ルール違反に気付きやすくする - Qiita
はじめに 本番リリース用ブランチへのマージ前に、検証用ブランチにマージして動作確認するという運用ルールになっているケースは比較的多いかと思います。 しかし本番リリース用ブランチへのPR時に、本当に検証用ブランチにマージ済みかどうかレビューでチェックという運用だと見逃しが発生する可能性があるし面倒ですよね。 そんな不便を解消するために作ったアクションを紹介します。 何が出来るの？ pull_requestイベントのアクションとして実行することで、指定ブランチにマージされていなかったらコメントで指摘してくれるようになります。 使い方 masterブランチへのPR時に必ずstagingブランチにマージされていることを検証したい場合の設定例。 name: Check merged on: pull_request: branches: - master jobs: check-staging: r
Git-flow ～Gitのブランチモデルを知る～ | バージョン管理システム入門(初心者向け)
はじめに Gitのブランチを活用できていますか？ Gitが人気を博している理由のひとつには、手軽に使えるブランチの存在があります。ブランチを効果的に使えなければ、Gitの真価を発揮することはできません。しかし複数人での開発で、特になんの決まりもなくブランチを使っていると、無秩序にブランチの作成やマージが行われ、リポジトリが混沌としてきます。 こうした問題を解決するために、「ブランチモデル」というブランチ管理方法が考案されました。 今回紹介するのは、Gitのブランチモデルのひとつである「git-flow」です。 ブランチモデルの中では比較的歴史が長く、git-flowをサポートしているツールも数多くあります。やや複雑なモデルではありますが、ツールを使うことでブランチの操作をある程度自動的に行うことが可能です。コマンドを覚えて流れをつかんでしまえば、それほど難しいことではありません。実際にやっ
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
【初心者向け】gitのbranch運用入門【git flow もどき】 - すこしふしぎ．
どうもこんにちは．1000chです． facebookのおすすめ言語診断したらrubyがでてきました． ふだん蛇使いなのですが，宝石商としてのスキルも磨くべきなのでしょうか． いまんとこrubyのインタラクティブシェルの起動方法も知らないレベルなんですけどね． さて，最近チームで開発することが多々あり，ビギナーながらだんだんとgitをつかった開発に慣れてきました． 慣れるにつれ，なかなかわからなかったチーム開発におけるブランチの運用方法が見えてきた気がします． ということで今回は初心者がgitを使う際一番最初にぶつかるであろう壁，ブランチ運用の仕方をgit-flowをベースにまとめます． 自分のような初心者向けということで，後ろにチュートリアル形式でまとめておこうと思います． 対象としてはgit commitはできるけどgit branchが怖い人，目指すところは を こうすることです！
masterを基本とするって話とGithub flowがいいじゃんって話 個人メモ
きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm 現代のGitでどこまでできるのかためしていないけど、5年前くらいまではGitでのログ表示というのは大量のブランチをいいかんじにフィルタリングする能力というのがなくて、大量のブランチでもいいかんじにやるのはMercurial一択だった。GitはGUIにしろなんにせよリッチなフィルタをあきらめている 2019-10-25 22:14:12 きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm 仕事はシンプルな方がいい Gitではブランチを野放図にできない となると、master一本にいかによせるのかというのがキモになるっていう。 で、それでこまらないというか。 で、master一本がうまくいかないときは(同一タイムゾーンでの)仕事が下手な可能性を示すシグナルになるんだよ。 2019-10-25 22:18:14
【GitHub】少人数のチームで開発するときのGitHubのブランチ運用Flow - Qiita
概要 少人数のチームでGitHubを用いてプロダクト開発するときのブランチ運用フローについて． GitHub Flowを参考にシンプルさと運用のしやすさを重視している． チームの全員が6つのルールを守るだけで，masterが綺麗な状態で保たれる． 全体像 6つのシンプルなルール 1. master は本番環境にデプロイされているバージョン 2. develop はテスト環境にデプロイされているバージョン 3. feature ブランチ（作業ブランチ）は develop から分岐する 4. feature ブランチは頻繁に push する 5. pull-request（PR）で develop にマージする 6. マージされた feature ブランチは削除する 実際の作業例 1. develop からある機能を実装する作業ブランチを作る
Quipper の Monorepo な Web アプリ開発における Git 戦略 - スタディサプリ Product Team Blog
Rails Developers Meetup 2019 の自社スポンサーセッションはいっそ休憩室にすればいいのでは? と言い出した Web dev の @mtsmfm です。お弁当や神授業、そして Quipper からは 3 名が登壇しましたが、発表は楽しんでいただけましたでしょうか。 僕は自分の発表 を @jeremy さんが聞いてくださったり、キーノートでは Rails 6 で入ったパッチを紹介してもらったりして感無量です。 この場を借りて Rails DM の開催に尽力された @yhirano55 さん他みなさまには感謝を述べたいと思います。本当にありがとうございました。 今日は、Quipper における Git ブランチ と Kubernetes を組み合わせた、開発から本番デプロイまでの流れを紹介したいと思います。 流れ ざっくりとした概要としては Git flow をアレンジ
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～｜ハイクラス転職・求人情報サイト AMBI（アンビ）
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～ コードレビューによって解決される問題とは？そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは？ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏（にしみ・まさひろ／@mah_lab）です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか？ 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
続・開発環境のツール周りをちょっと快適にした話 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！パンダ大好きエンジニア、宮原です。 前回（開発環境のツール周りをちょっと快適にした話）の記事では、チームで導入した開発支援ツールについて、どんなツールがあるのか、どんな考えで導入したのか、というところをご紹介しました。 開発支援ツール導入後はコードの品質も上がって（潜在バグの低減、保守性の向上）、快適に開発ができるようになりました。現在はCIサーバによる監視も実現できており、もっと開発が快適になりました！ 今回は、CodeIgniterというPHPフレームワークに各開発支援ツールをどのように導入し運用しているのか（CIサーバを活用したツール実行方法）をもっと具体的に紹介していきたいと思います。 目次 リポジトリ（ディレクトリ）の構成 各ツール用ディレクトリの詳細 PHP Coding Standards Fixer PHPMD PHPLOC PHPCPD phpDocument
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回記事「たった3つで共存できる、Git／GitHubとSubversion（SVN）の連携、移行に関する基本操作」では、Subversionとの連携や移行について解説しました。 本連載の最終回となる今回のテーマは「Git／GitHubのワークフロー」です。幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。 git-flow 「git-flow」はVincent Driessen氏の「A
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用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書かず、ブランチ戦略とリリース管理についてだけ述べよう。 以下では、
アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitのブランチ戦略
プロジェクトメンバーが必ず押さえておくべきマナー～ブランチ戦略の基本