タグ

運用に関するryochackのブックマーク (6)

  • git commit --allow-empty を使った WIP PR ワークフロー - Qiita

    先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の(親コミットと差分がない)コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何? Work In Progress Pull Request の略です。 Github に Pull Request (以下、PR と表記)という機能があるのは皆さんご存知だと思います(知らない方はググってください)し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン

    git commit --allow-empty を使った WIP PR ワークフロー - Qiita
  • git-flowでもgithub flowでもない、Git本家推奨のワークフロー

    このドキュメントは git.git (訳注: Gitプロジェクトのgitリポジトリ) それ自身で使われているワークフローの要素を書きとめ、 それを使いたいと思わせることを意図しています。 多くのアイデアが一般に適用できますが、 より少人数が参加する小さなプロジェクトで 完全なワークフローを必要とするのは稀です。 私たちはクイックリファレンスのためにひとまとまりの ルール をとりまとめ、 文章でそれぞれのルールへの動機を与えます。 言葉通りにとらないようにしてください; 重視すべきなのは、この文書のようなmanページの記述よりも あなたがそうすべき理由の方です。

  • A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind

    git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日語のがたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful

    A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
  • 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 この記事では、私のいくつかのプロジェクト仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

    A successful Git branching model を翻訳しました
  • テストファーストなGitワークフローについて - kazuhoのメモ置き場

    Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス(の部品)やオープンソースプロジェクトです。 まず、以下の2点を原則として考えています。 origin masterを壊さない origin masterの(1st parentをたどるツリー)にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ

    テストファーストなGitワークフローについて - kazuhoのメモ置き場
    ryochack
    ryochack 2014/02/04
    漠然とコードを書いてしまわないようにするために、トピックブランチの最初のcommitを「failするテスト」にする
  • Gitの運用ルール、フローを考えてみた

    徐々にGitに移行しつつあるのですが、複数人数(チーム)でGitを使った場合の運用ルール、ワークフローというものを考えてみました。 Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい! 原則 masterで作業しない。ブランチを作って作業する。 ブランチでは1機能もしくは1バグのみ作業する。 ワークフロー 準備 ローカルのmasterに移動する $ git checkout master ローカルのmasterをリモートと同期する $ git pull origin/master masterから、作業用のブランチを作成する。 $ git checkout -b branchname master ブランチ名は担当者名と作業名をスラッシュで結合したものとする。 例: taro/featurename, taro/bugname コーディング コード

  • 1