僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
AWSチーム社内勉強会「git-flow」レポート | DevelopersIO
こんにちは、虎塚です。 先日、git-flowをテーマに社内勉強会を行いました。講師役は、AWSチームの都元さんにお願いしました。 クラスメソッドではお客様向けにクラスメソッド・メンバーズというサービスを運営しています。このサービスの会員向けポータルサイトの開発で、Gitとgit-flowを採用しています。そこで、メイン開発者である都元さんにgit-flowの概要を話してもらって、皆で聞こうということになりました。 いつもはAWSコンサルティング部のメンバーで実施している勉強会ですが、今回はテーマが開発寄りなので、AWSソリューション部の人たちにも参加してもらいました。AWSソリューション部は、システム開発を中心に行っている部署です。 上は秋葉原オフィスの会場です。札幌オフィス、上越オフィス、リモートワークのメンバーも、Googleハングアウトで接続して開催しました。 それでは、勉強会の内
iOS/Androidアプリ開発の現場で訊いてみた！Eight編 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? iOSアプリ開発者に最近の開発スタイルを訊いてまわる「iOSアプリ開発の現場で訊いてみた」待望の5社目に行ってきました。 今回はEightという名刺管理アプリを開発されているSansan株式会社！Android版のEightアプリはGoogle play 2014年のベストアプリに選ばれたこともあり、今回はAndroidアプリ開発についても訊いてきました。 訊いてきたこと インタビューに応じてくださったのは@hedjirog（主にiOS担当）、@Gazyu（主にAndroid）のお二人です。 今回のインタビュアーはユビレジ編でインタビュ
ChatOps時のブランチ運用戦略(実装 / コードレビュー / 関係者確認 / 自動テスト / デプロイを円滑に行う) - Qiita
*1 CircleCIによって、GitHub上の該当ブランチに変更があった場合に、自動でデプロイされる環境になります。 Hubotの擬犬化 ここでは、Hubotを擬犬化して、ロボットではなくワンコとして扱っています。本投稿の挿入画像でも、Hubotではなくwankoとして表示されているので留意してください。 実装からリリースまでの流れ ①masterからブランチを切って、実装 新規ブランチをmasterから切り、実装を行います。 ②仮コードレビュー[WIP]の実施（任意） 実装が終われば、検証環境へデプロイして関係者確認を行いますが、これの前にコードレビューを行います。ただしここでのコードレビューは必須ではありません。 この段階でのコードレビューが推奨されるのは以下の場合です。 修正が大規模なとき 検証環境での確認が終わり、masterにマージする際にレビューが入ります。ここでレビューに引
Bakusoku Iterations Tokyoで話したりrebuild.fmで話したりしました - Islands in the byte stream (legacy)
Mobile First Development at COOKPAD ブランチングモデルの話で、頻繁にデプロイするweb appではgithub-flowを、リリース間隔が長いmobile appではgit-flow（を簡略化したもの）を使ってるという話です。このへんはウェブかアプリかというよりは、kazuhoさんの指摘するように配布形態に依存するというのが実際のところでしょうね。 s] つまり、web appでもリリース間隔が1~2週間なのであればgit-flowを採用するほうが安定した開発ができると。その後 develop ブランチなんてオワコン という議論もありましたが、一概に何がベストとはいえないのでそれぞれのプロジェクトのそれぞれの時期によって最適なブランチングモデルを検討するのがいいと思います。 Rebuild #45 Rebuild 45: Remembering WSDL
その後の俺のオレオレgit-flow〜deployment手法とgit運用 | おそらくはそれさえも平凡な日々
http://togetter.com/li/673629 こういうふうにまとめてくださっていたのですが、自分なりの考えの補足など。 上記でも言及している、「俺のオレオレgit-flow」というエントリにも書きましたが、この運用で進めてみて結構良かったなーと思っている。その辺に関しては以下のツイートしたりした。 masterでQA通してからreleaseブランチにマージしてdeployって感じすなー。 — songmu (@songmu) 2014, 5月 30 ゲームだと画像内の文字の表記間違いとかをやらかすだけで、その事後対応でプログラマの稼働が下手すりゃ一日飛ぶので、master直deployは怖いので、並列でreleaseブランチを走らせて、そっちにマージしつつdeployしてる。 — songmu (@songmu) 2014, 5月 30 masterからreleaseへのマー
GitHub を用いた開発フロー テンプレート - ペパボテックブログ
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識：Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）（1/2 ページ） 数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、ブランチ管理の課題と効率的にバージョン管理できる5つのブランチモデルと、ブランチの管理を簡単に行えるツール「git-flow」について。 Gitなどの次世代のバージョン管理ツールの特徴として、ブランチの機能を高度に活用できるという利点があります。Gitのブランチを生かしたツール・フローとして「git-flow」「GitHub Flow」が注目を浴びていますが、本連載では数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、git-flowの概要を紹介します。 効率的にバージョ
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
SSSSLIDE
はてなブログチームの開発フローとGitHub（前編）。GitHub Kaigi 2014
hitoyam.com
GitHub Flow (Japanese translation) Latest version is here: https://gist.github.com/Gab-km/3705015