GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー
もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー 2014.02.26 | この方法お勧めです！ | 覚えておきたい どもどもパープルことメガネこと大串です。 最近なにかと涙もろくなりまして、ちょっと身近な人のBlogとか読むだけでも熱いものがこみ上げたりしています。こういうことって今後も増えていくんでしょうね。母親がやたらめったらテレビに向かって泣いていたのも頷ける今日このごろです。 さてGitHubシリーズですね。前回は GitHubをつかって共同開発！ サイトのデザインリニューアルしました !という記事を書きました。もちろん今も共同開発は続いておりまして、次のマイルストーンは月末を予定しております。達成率は25%ですが、なんとなかるでしょう。。。たぶん。。おそらく。 そしてきょうの本題ですね。タイトルの通り、FTPをやめてgitでファイルの送信受信もして
ウェブデザインにおけるセマンティック・バージョニング
アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。 セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が: 失われる: メジャー 失われない新機能の追加: マイナー 失われない修正: パッチ 数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず
僕たちが行き着いた、シンプルで簡潔なGitの運用方法 - テクノロジーと広義のデザイン！
Gitを使い始めて１年以上たちます。最近、Gitを使ったプロジェクト運用方法が自分なりに固まってきたので公開します。かなりシンプルなので、ある程度Gitに慣れていれば十分に運用可能だと思います。 僕たちが理想とするヒストリーGitを使った開発の成果物、それは開発のヒストリー（履歴）そのものです。このヒストリーが論理的に正しく、かつ、簡潔で理解しやすいものを目指すというのが大方針となります。その方針のなか、現時点で僕たちが理想だと考えているのが、以下の図のような履歴がリモートブランチに残ることです。このヒストリーには２タイプのブランチが存在します。 リリースブランチ … 次期リリースバージョンに向けて進んで行くブランチ。チケット１枚について１つのコミットが良い。 フィーチャーブランチ … チケット１枚について１つ切られるブランチ。機能を実装する際に小刻みにコミットしたログが残っているため、後
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
