タグ

developmentとgitに関するgriefworkerのブックマーク (11)

  • Semantic Commit Messages

    semantic-commit-messages.md Semantic Commit Messages See how a minor change to your commit message style can make you a better programmer. Format: <type>(<scope>): <subject> <scope> is optional Example feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Examples: feat: (new feature for the user, not a

    Semantic Commit Messages
  • ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)

    https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン

  • git-flow cheatsheet

    About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt

    griefworker
    griefworker 2014/10/08
    パッケージ製品の場合はGithub FlowよりGit Flowの方が向いてそう。
  • git による分散作業パターン | GREE Engineering

    分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o JavaC++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

    git による分散作業パターン | GREE Engineering
  • Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社

    質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか?これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか?それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか?( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vimEmacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git

    Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
    griefworker
    griefworker 2013/11/26
    masterにマージする前にコミットを1つにまとめているからrebase派になるんだろうか。
  • ChangeLog を支える英語

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    ChangeLog を支える英語
    griefworker
    griefworker 2013/09/30
    これ参考にして、少しずつコミットログを英語で書いていこう。
  • GitHub Flow (Japanese translation)

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub Flow (Japanese translation)
    griefworker
    griefworker 2013/08/19
    Github Flowシンプルでいいね。自分が普段やってる開発フローに似ている。
  • 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok

    チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

    「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
    griefworker
    griefworker 2012/02/20
    Pull Requestされたときにコードレビューやリファクタリングするやり方はいいね。
  • GitHub人気レポジトリランキング Best50 全解説 - 方向

    GitHubで人気レポジトリのランキングが公開されているようなので全解説してみました. どれも素晴らしいものばかり! あなたのプログラミングライフを快適にしてくれるライブラリがきっと見つかるはず!! rails rails 9835 watching Ruby on Rails. 説明不要だよね! フルスタックWebフレームワーク jquery jquery 8710 watching JavaScriptライブラリ.これも説明いらないよね! node joyent 8572 watching 旧名node.js.昔の名前の方が通りがいいです.JavaScriptエンジンのV8用のノンブロッキングIOな何か.主にWebサーバ/アプリケーションに使われる. html5-boilerplate paulirish 6998 watching HTML5とかのテンプレート集.ただし公式ページのデ

    GitHub人気レポジトリランキング Best50 全解説 - 方向
    griefworker
    griefworker 2011/08/25
    FlowやLinkedInで使われているbackboneを試してみたい。
  • GitHubへpull requestする際のベストプラクティス - hnwの日記

    みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、

    GitHubへpull requestする際のベストプラクティス - hnwの日記
    griefworker
    griefworker 2011/05/30
    フォークして、自分のリポジトリで作業して、Pull Requestを送るのが定石なのかな。
  • Gitを使った開発・運用フローの紹介

    私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介&考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが1人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に

    Gitを使った開発・運用フローの紹介
    griefworker
    griefworker 2011/05/25
    Gitoriousを使う。マスターブランチやリリースブランチを作って運用する。
  • 1