Bitbucket x TrelloでターダーでWikiとIssueTrackingとタスク管理と。 - Qiita
とりあえずお金無いし、個人的 or 少数でやるなら十分だと思うし自分はこうしてる 結論から先に書くと ソース管理 => Bitbucket Issue Tracking => Bitbucket ドキュメント管理 => Bitbucket Wiki タスク管理 => Trello IssueのTrelloへの転送 => zapier 以上である。 さて。導入も簡単なのでサクッと紹介 導入手順 手始めに これらのサービスで使うメールアドレスだけは準備しましょう。 Gmailなんかでいいでしょう。え？増やしたくない？ YourAdress+ForProject@gmail.com とかもうエイリアス使えばいいよ。 Bitbucket導入 https://bitbucket.org/ ここに行くともう書いてありますね。 Get started for free free。なんていい響きなんでしょ
DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い
両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者（以下、Dev）と運用者（以下、Ops）の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは（DevOpsの概念と同じく）、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
Repositories access control with apache mod dav svn and mod perl - Redmine
Repositories access control with apache, mod_dav_svn and mod_perl¶ Table of contentsRepositories access control with apache, mod_dav_svn and mod_perlOverviewEnabling apache modulesApache configuration for Subversion repositoriesTesting the configuration:optional LDAP Authentication Apache configuration for Git repositoriesApache configuration for Mercurial repositoriesGotchas Overview¶ In this doc
第3回 SVKとSubversion | gihyo.jp
2回に渡ってSubversionの使い方、Subversionとバグ管理システムとの連携について説明してきました。今回から、分散したSubversionのリポジトリを一元管理するSVKについて説明します。SVKはリポジトリの一元管理だけでなく、単体でも個人のバージョン管理の機能を提供しています。 SVKって何？ Subversionからいくつかの派生プロジェクトが生まれました。派生プロジェクトの１つに、2003年から開発が始まったSVKがあります。SVKは複数のバージョン管理システムのリポジトリを統一的に扱うためのツールです。リモートリポジトリとして、SubversionだけでなくCVSやPerforceなど、複数の種類のバージョン管理システムをサポートしているため、これらの違いを意識せずに操作できます。 SVKの一般的な作業フローは図1のようになります。まず、複数のサーバ上にあるリポジト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンセプトから理解するGitコマンド