Products Featured Developers Product Managers IT professionals
Products Featured Developers Product Managers IT professionals
要約 : 私たちは、React.js と Flux、それに他のいくつかのライブラリを用いて HipChat の Web クライアントを根本的に再構築し、素晴らしい結果を得ました! 是非試してみませんか? HipChat がアトラシアンに加わったときのクライアントは、Web、Adobe Air (Windows、OS X、Linux)、iOS、そして Android アプリの 4 つでした。HipChat チームが最初に掲げた目標のひとつが、Air クライアントを OS X、Windows、Linux のネイティブデスクトップクライアントに置き換えることでした。私たちは (その当時は) 小さいチームだったためしばらくはこの仕事で手一杯でした。このように最高のアプリケーションを提供することに集中した影響で、Web クライアントに対しては私たちが行った様々な開発の成果を反映させることができません
私のブログを頻繁に読んでくださってる皆さんは、私がどれだけ Docker に夢中かご存知ですよね。それから Git にも。今日は、そんな私の興奮が伝わるようなお知らせがあります。Docker の自動ビルドが Bitbucket に統合されました! Docker とは何か? 単純に言えば、Docker はプロビジョニングとデプロイの自動化分野における次の大物です。Docker では、OS、データベース、環境変数、start/stop スクリプトなど、アプリケーションを実行するのに必要なあらゆるものを定義することができます。そして、その定義をテキストファイルに保存することで、イメージを再利用、更新、共有できます。 Docker を使用すると、アプリケーションや環境を修復するよりも楽に (安くという意味で) 作り直すことができます。ここまでですでに開発者の皆さんは、ローカルワークステーションに対
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか?これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか?それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか?( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
ささいなことに悩まされずに、あなたの時間を 開発者として 費やせることは素晴らしいだろうと思いませんか?当社の最新リリース* により、かつては退屈だったソフトウェア管理を過去のものにします。当社のツールは、かつてないほどにうまく統合されています。開発フローを通じて作業者をガイドするためのベストプラクティスが組み込まれています。連係により、課題作成やコーディング、マージにいたるまであなたの仕事を簡単にします。ご覧になって確信してください。 開発タスクに集中しましょう。コードを書き込む作業に戻りましょう。あなたを必要としています。 統合の詳細を見る * 要件 JIRA 6.1+, Stash 2.8+, Bamboo 5.0 + および SourceTree 1.7+ ブランチを JIRA から直接作成する ブランチモデルは Git ワークフローの中核です。しかしブランチタイプが沢山ある場合、
Products Featured Developers Product Managers IT professionals
Eliminate duplicate support tickets & clunky email lists Halt the flood of support requests during an incident with proactive customer communication. Manage subscribers directly in Statuspage and send consistent messages through the channels of your choice (email, text message, in-app message, etc.) Display the status of each part of your service Control which components of your service you show o
An update to customers, stakeholders, and shareholders on our mission to unleash the potential in every team.
あなたが git をコマンドラインで使っていようと、SourceTree などのツールから使っていようと; また、コードを Bitbucket にホスティングしていようと、Stash で会社のファイアウォール内側にホスティングしていようと、もしあなたが私のようであれば git がリリースされたときはいつでもパーティーをするでしょう – ウィンク –。 Git ユーザーにとってスムーズなアップグレード方法 git 1.8.3 がリリースされました。もちろん、これは最新バージョンへのアップグレードを意味しています。これは比較的、簡単であるべきです: もし OSX 上で homebrew を使用している場合は単に brew update && brew upgrade git とタイプするだけ (OSX 上で .gitignore を解析中に、直前に発見されたバグにより、 homebrew はア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く