Git勉強中☆ローカルで作業ブランチを作成しリモートへPushするまでの手順
先日、867さんのブログに登場した、Git勉強中のうっかりチカちゃんです！Granfairs内ではチカッパの愛称で呼ばれています。 昨年末からGitの勉強を始めているのですが、 勉強開始直後、早速リモートのmasterブランチにローカルの作業ブランチをプッシュしてしまいました…。 このようなミスを犯してしまうのはGitの概念や仕組みをきちんと理解しきれていないことが理由です。 また、SourceTreeなどのGUIを使用すれば、自分がどのような操作をしようとしているか把握してなくても直感的に操作できてしまうためミスを犯しやすい…。 今回は、正しい手順を追って作業ブランチを作成し、リモートへプッシュするまでの工程をお伝えできればと思います。 私のようなGitお勉強中の方のお力になれば幸いです。 ※環境はWindowsです。 リモート上のmasterブランチからローカル上の作業用ブランチを作成
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
シンクロ・フードのブランチ運用フロー - シンクロ・フード エンジニアブログ
シンクロ・フードの五十嵐です。 今回は、私たちの開発フローについてお話したいと思います。 特にGitのブランチ運用については皆さん頭を悩ませる部分だと思いますので、弊社の紆余曲折した経緯も踏まえて公開します。 Gitへの移行を検討している方などの参考になれば嬉しいです。 リリース頻度 お話の前提として、弊社のリリース頻度を紹介します。 平日は、ほぼ毎日リリースをしています。一日数回リリースする日もあります。 月間で捌くチケット数（≒featureブランチ数）の平均は約170です。 それなりの規模になってきたため、開発フローの安定化や効率化は全体の生産性に直結すると考えており、現在も改良し続けています。 GitHub Enterprise の利用 バージョン管理はGitで行っており、GitHub Enterpriseを利用し、プルリクベースで開発を行っています。 全てのプルリクは必ずコードレ
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
複数リリースを持つソフトウェアの構成管理課題 - torutkのブログ
複数のプロジェクトで共通に利用するソフトウェア（フレームワークや共通ライブラリ）を管理する場合の構成管理上の課題を整理中です。解決手段の検討はまた別途・・・ 想定ケース 最初のプロジェクトでは、共通ソフトウェアはアプリケーションと一体で開発・構成管理されていました。 最初のプロジェクトリリース後、共通ソフトウェア部分は別のプロジェクト（複数）でも使用することが決まりました。 次のプロジェクトにおいて、共通ソフトウェアにも機能向上が必要と予想されます。 最初のプロジェクトで開発したシステムが運用・保守されている期間、共通ソフトウェアは不具合修正、マイナーな機能変更が発生します。 目標 共通ソフトウェアが保守地獄とならないよう、プロジェクト毎に別々に構成管理するのではなく、共通ソフトウェアを一元管理できる 運用・保守期間は、システムの安定性を最優先とするため、不具合・必要最低限の機能修正のみ適
Gitのブランチ運用でちょっと試行錯誤した話｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
先日の健康診断で即メタボ認定を受けて危機感を覚え、酒量と食事量を減らしつつありますが、まだ効果が表れていない下條です。このブログで定期的に体重を公開すればさらに意識が変わるかなと思いましたが、皆さんそんなものは見たくないと思いますので書きません。 さて、私は以前の会社ではソースコードのバージョン管理にSubversion的なものを使っており、弊社に入社してから本格的にGitを使い出しました。そこで最初に参加した受託Webサービス開発のプロジェクトにおいて、Gitを使ったブランチ運用についてちょっと試行錯誤した経緯をご紹介します。 GitHub Flowとの出会い Gitのブランチ運用の方法として有名なものとして、GitHub FlowとA successful Git branching model (O-Show 氏による日本語訳) （以後git-flowと記述）の2つがあります。私が弊
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 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
なぜ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ブランチを安定させていくスタイルです。 実際に新しいプロジェクトを始めるとしたら、どの構成が良いのでしょうか。 今回はカウルを開発するにあたり採用したブランチの構成とその背景につ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
