Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
Gitlab-flowの説明 - Qiita
Gitlab-flowのグラフ Gitlab-flowのブランチ説明 feature/hotfixは機能開発、不具合対応ブランチです masterはメインのブランチ pre-production(オプションブランチ)はリリース前のテスト用(git-flowで言うreleaseブランチ) productionはリリース済みのコード置き場 Gitlab-flowの流れ 機能開発 機能開発するとき、masterブランチからfeature/NAMEブランチを切って開発進む 開発が終わったらfeatureブランチからmasterにMerge Requestを作成します。 masterをステージング環境へデプロイして、確認する プリプロダクションへデプロイしたい場合、masterブランチからpre-productionブランチへのMerge Requestを作成します。マージ済みになるとデプロイする
iOS開発におけるgit flow - Qiita
iOS開発の際にgithub flowからgit flowへ移行したのでまとめておきます。 git flowとは git flowとは、Gitの機能であるブランチを活用したGitの開発手法でもあり、ツールの名前でもあります。 git flowは、役割ごとにブランチを使い分けます。 各ブランチの役割 master AppStoreで配布中の最新バージョンと同じです。 配布バージョンごとにタグを切ります。 develop 開発ブランチです。 developブランチからIssue毎にfeatureブランチを作成し、開発を進めます。 次期バージョンの要件を満たしたらreleaseブランチを作成します。 feature developブランチからIssue毎に作成します。 対象Issueの開発が終わるとdevelopブランチにマージします。 developブランチにマージしたタイミングで対象のfea
なぜdevelopブランチは必要なの？
「Gitのブランチ構成どうしましょうか？」 「とりあえずdevelop切ってやっていきますね。」 そのdevelopブランチ本当に必要でしょうか。 developブランチだけ使われていて、masterが全く使われていなかったりしないでしょうか。 よく聞かれるブランチ戦略としてはgit-flowやGitHub Flow、、GitLab Flow等があります。 git-flowにおいてはdevelopやhotfix、releaseといったブランチがありますが、GitHub Flowにはmasterブランチと機能開発ブランチの2つしかありません。GitLab Flowはmasterを中心に開発を行い、productionブランチを安定させていくスタイルです。 実際に新しいプロジェクトを始めるとしたら、どの構成が良いのでしょうか。 今回はカウルを開発するにあたり採用したブランチの構成とその背景につ
iOSアプリ開発のGit運用 · hikarock blog
iOSアプリはリリースサイクルが長くなりがちなので、GitHub Flowではなく、git-flowを参考にしたフローを使っている。 仕事もプライベートもこのフローで今のところ問題はない感じ (複数人開発含む)。 各ブランチの役割 基本的に普通の git-flow と変わらないけれど、AppStore がからむとこを中心に説明します。 master 現在AppStoreで配布中の最新バージョンと常にイコール release リリース準備ができたらdevelopから分岐する。AppStoreでリリース申請通過後にリリース完了した時点でmasterとdevelopにマージする。リリース前にrelease上で変更があった場合は適宜develop featureにマージする。 リリース後にタグを打つのを忘れずに。git tag -a v1.0.1 -m 'my version 1.0.1' dev
アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blog - LINE ENGINEERING