なぜぐるなびはGitLabを選択したか - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。ヨガをはじめたあたぎです。メイン業務はレストラン検索の開発です。 みなさんGitをお使いかと思いますが、そのホスティングはどのように行っていますでしょうか。 弊社ではここ1年くらいGitLab Community Editionを使用しています。世間ではGitHubがデファクトスタンダードになりつつありますが、何故あえてGitLabなのか？その理由について説明します。 主に ちょっぴりセキュリティ周りがきつい会社 うなるようにお金が出せるわけじゃない会社 で働いている人には参考になるかもしれません。 GitLab前史 GitLabを導入する前はこの2つを使っていました。 Rhodecodeの無償版 Backlog(有償契約)のGitリポジトリホスティング機能 前者は機能が限られていて無償版の開発が停止していること、後者はPull Requestの機能が足りなかったことによって困
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
SVN から Git へ：進行中の開発に影響を与えずに Git へ移行したアトラシアンの方法 ― 技術的側面 | Atlassian Japan 公式ブログ | アトラシアン株式会社
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 22 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Technical Side" このポストは、エンタープライズ開発のバージョン管理を Git に切り替えることに注目した連載記事（全三回）のうちの第二回目として、 Dr.Dobb's で紹介されました。最初の記事では、 今日、これほど多くのチームが切り替えを決断している理由 について議論しました。今回の記事では、アトラシアンが行った Git への切り替えにおける技術的な側面に焦点を合わせています。 この三部からなるブログシリーズでは、アトラシアンが行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
