git-daily 的なブランチ方針がしっくりきました
ソースコード管理でのブランチの切り方を模索してきました。いったん落ち着いたので書き残しておきます。 前提条件は以下のとおりです。 iPhone アプリがアクセスするウェブAPIを開発する。 サーバサイドの開発者はふたり。大阪と東京。 他の案件とかけもち。 行き着いたところ Mercurial git-flow/git-daily に似たブランチ方針 機能追加、開発中機能のバグ修正: default ブランチから、XXX ブランチを切って機能追加/変更し、default へマージする。 リリース: default ブランチから、release/XXX ブランチを切って、ステージングでテスト/修正。終わったら、default と master へマージし、master の先頭を本番サーバにデプロイする。 リリース済不具合の修正: master ブランチから、hotfix/XXX ブランチを切っ
VCS package guidelines - ArchWiki
Version control systems can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases. Prototypes Use only the PKGBUILD prototypes provided in the pacman package (PKGBUILD-split.proto, PKGBUILD-vcs.proto and PKGBUILD.proto in /usr/share/pacman). Guidelines Package naming Suffix pkgname with -
DVCSのリンク集 - うさぎ組
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
SCM Boot Camp 2 in Tokyo に行ってきた - ぐるぐる～
今回は Git の講師として参加しました。 2 回目と言うこともあって、よりスムーズに進めることができたように思います。 個人的なもくろみ 今回参加して、SCM Boot Camp の DVCS イベントの部分はある程度パッケージ化したいと考えるようになりました。 まだ 2 回しかやっていませんが、DVCS (少なくとも Git) の効率的な習得のためのスキームというのが見えてきた感じです。 最終的には、講師が 1 人いれば小規模なイベントを開くことのできるところまで落とし込めるのでは、と考えています。 以下時系列順の雑多な感想や補足など 開催前 今回は、開催の準備として数回 Lingr によるミーティングを行いました。 資料の作成も段階的に行うことができたのでフィードバックを取り入れることができてとてもよかったです。 にも関わらず、 30秒前までずっと作り続けていたらしいので、たぶんあり
分散バージョン管理入門 (イラスト入り) - tcha.org
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DVCS workflows for Bitbucket | Bitbucket Cloud | Atlassian Support