ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
デザインワークをGitに含めるべき? 含めないべき? - Qiita
「プログラマ業界」であればコンパイラの多くがオープンソース化されていますが、デザインツールはAdobeを筆頭に今もほとんどがプロプライエタリなツールです。そのことが、原理原則に沿うのを難しくしています。 複製不可能な部分に価値を置くという文化的な面 ツール開発にコストがかかるという金銭的な面 もあって、ツールがオープンに向かうことは当面なさそうです。Blenderという例外はありますが、GimpやInkscapeは実質プログラマだけのためのツールになっています。そういえば、Fireworksのオープンソース化嘆願はどうなったんだろう...? ツールが有料 デザインツールはときに高額です。また、セットアップに割く時間も「見えない」コストです。残念なことにインストールも自動化されていません。caskも使えません。$ npm installでは片付かないのです。また、アップグレードの問題もありま
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
千亿体育登录|首頁欢迎您
受疫情影响，所有客户下单前需与客服确认好送货事宜方可下单。近期中沙，轻体砖价格波动较大，各商家货源不稳定，请在下单水泥商品后在订单中备注您对沙子、轻体砖的需求，平台会寻找优质的卖家为您发货。
WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記 (はてなBlog)
分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在
grunt-releaseでversionを上げられる男になろう - Qiita
弊社の大先輩、mashさんがpull-req送っていたのを偶然見て、 grunt-releaseというプラグインの存在を知りました。 dry run support by mash · Pull Request #29 · geddski/grunt-release これが、npmやbowerにがんがんライブラリを置いている自分には、 めちゃくちゃべんりでした! bowerでライブラリ公開するハードルを下げることにもなる、 と思うのでちょっと紹介してみます。 grunt-releaseとは geddski/grunt-release grunt-releaseは、git管理しているライブラリの versionアップ時の作業を自動化してくれる gruntプラグインです。 具体的には、 設定ファイルから、現在のversionを取得 次に使うべきversionを計算 (semver形式) そのv
知らないと現場で困るバージョン管理システムの基礎知識
知らないと現場で困るバージョン管理システムの基礎知識：DevOps時代の開発者のための構成管理入門（3）（1/3 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は構成管理に不可欠ともいえるバージョン管理について、ブランチ機能を中心に紹介。SubversionからGitへの移行事例も。 いまさら聞けない「バージョン管理」とは 第3回目となる今回では、構成管理において「過去のある時点の状態をどのように復元するか」を実現するために不可欠ともいえるバージョン管理とバージョン管理システムについて紹介します。 「集中管理方式」と「分散管理方式」 バージョン管理システムとは、ファイルに対して「誰が」「いつ」「何を
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
RhodeCode
RhodeCode 1.3.6 Released Posted on May 19th, 2012 | Read more RhodeCode 1.3.5 Released Posted on May 13th, 2012 | Read more RhodeCode 1.3.4 Released Posted on March 29th, 2012 | Read more RhodeCode 1.3.3 Released Posted on March 3rd, 2012 | Read more Casino Security: Real Vs. Fake Chips Unveiled Posted on June 7th, 2024 | Read more RhodeCode is a fast and powerful management tool for and GIT with
Unity 3.5でバージョン管理をする
およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。 ■Unity 3.4以前の場合 そんな暗黒時代のことは忘れましょう。 ■Unity 3.5以降の場合 Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの ボッタクリ バージョン管理システムを使う以外に、好きなバージョン管理システムを使ってUnityのプロジェクトをバージョン管理することができるようになりました。これを使わない手はありません。まず
msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ - てっく煮ブログ
git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit（Git for Windows） がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin は UTF-8 な日本語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けの GUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪い Windows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
デザイナーが RailsとGitのことを少し知ってると色々捗る
The document contains a series of dates from 2011-6-22 repeated many times. Between some of the dates are short phrases such as "Don't Repeat Yourself" and "Convention over Configuration". The overall document does not appear to have a clear purpose and consists primarily of a date repeated with occasional unrelated text fragments.Read less
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ごりゅご.com