An update to customers, stakeholders, and shareholders on our mission to unleash the potential in every team.
FishEye/Crucible 3.8: performance and patch upload improvements - Atlassian Blogs
An update to customers, stakeholders, and shareholders on our mission to unleash the potential in every team.
gitで未追跡（untracked)なファイルもまとめて退避(stash)する - Qiita
stash便利ですよね git stashを使えば作業中のファイルを一旦退避させておいて、別のブランチで作業し、その後また戻ってきて再開するってことができますね。 $ git branch * original hogehoge master # 作業中のファイルを一旦退避 $ git stash # 退避できたか確認してみる $ git stash list # ブランチ変更 $ git checkout hogehoge $ ~hogehogeブランチでなんか開発作業~ # ブランチを元に戻す $ git checkout original # 退避を元に戻す $ git stash pop でもstashってtrackedなファイルだけなんでしょ・・・・ git stashだと追跡してる(tracked)なファイルだけを退避してくれます。 なので追跡してない(addしてない）ファイル
図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
Gitのコミット単位で動的にDockerイメージをデプロイするプロキシサーバpool
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Gitのコミット単位で動的にDockerイメージをデプロイするプロキシサーバpoolというソフトウェアがあります。 poolとは poolは、WebアプリとDockerfileをGitで管理している場合に、コミットidをサブドメインとして（ http://<commit-id>.pool.dev/ ）poolにアクセスするだけで、そのGitレポジトリのコミット時の状態でWebアプリのDockerイメージをデプロイし、Webアプリのポートへとリバースプロキシして、Webアプリのレスポンスを返します。もちろん、コミットidをキーに複数の状態にどんどんアクセスできます。（mod_mrubyのユースケースを調査していてたまたま見つけました）。 このp
ワークフローを強化した「Git 2.1」がリリース | OSDN Magazine
Git開発チームは8月15日、オープンソースの分散型バージョン管理システム「Git 2.1」をリリースした。2系初のメンテナンスリリースとなり、ワークフローや性能が改善されている。 Git 2.1は5月末に公開された2.0に続くもので、ユーザーインターフェイスとワークフロー関連、性能などの強化が行われている。 後方互換性のない変更点として、gitが呼び出すページャを指定するLESS環境変数のデフォルト設定でlessに与えるオプションが「-FRSX」から「-FRX」に変更された。これにより、端末内で1行に収まらないような出力は折り返して表示されるようになる。 また、core.preloadindex設定変数のデフォルト値が「有効」となり、マルチコア環境を活用できるようになった。コメントメッセージでカスタムコメント文字を特定するcore.commentCharでは「auto」設定が可能になって
git grepの代わりにgit agを使う - その手の平は尻もつかめるさ
git grepが便利なので，同じ感覚でag (The Silver Searcher)を使ってみたいという話です．何事も速いほうが良い． 前提 ぶっちゃけagは，デフォの状態で.git/以下の内容や.gitignoreに書かれてるファイルやディレクトリなんかを検索の対象から排除するのであんま旨味は無い． 方法 以下のエイリアスを張る *1．もちろんconfigファイルを直で編集しても良いです． $ git config alias.ag '!git ls-files | xargs ag'git ls-filesを使って，gitで管理されているファイルの一覧を持ってきて，xargsを使ってagに渡してやるという感じ． 実際僕はこれで十分なんですが，表示と挙動をgit grep(1)っぽくしたい場合は以下のようになるでしょう． $ git config alias.ag '!git ls-
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
gitで特定のタグのshallow repositoryを作る - Qiita
最新のコミットだけcloneしてくるときにgit clone --depth=1としてshallow repositoryを作ったりしますが、最新ではなく特定のタグを取ってきたいときに。 追記2/27 コメントでこんな方法もあるという情報が。 --branch -b Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to branch instead. In a non-bare repository, this is the branch that will be checked out. --branch can also take tags and detaches the HEAD at that commit in t
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
Partial clone with Git and Mercurial
Is it possible to clone only one branch (or from a given commit) in Git and Mercurial? I mean, I want to clone a central repo but since it's huge I'd like to only get part of it and still be able to contribute back my changes. Is it possible? Like, I only want from Tag 130 onwards or something like that? If so, how?
WIPブランチをPull Requestする運用をためした - bouzuya.hatenablog.com
最近はWIP(work in progress)ブランチをGitHubにPull Requestするようにしている。 GitHubのPull Requstの仕様としてブランチ名で追跡している(?)ので、後からブランチにコミットを追加してもきちんとPull Requestページにも追加されるし、git rebaseなどでコミットをひとつにまとめても問題ない。 そこで作業中(WIP)のブランチをとりあえずPull Requestするのがこのやりかた。 Pull Requestを作業完了してから実施すると、途中で指摘すれば修正できたけど作りきってしまったものをいまさら修正できないといった状況になることがある。コーディングに限らず、一般的な話としても、作業前や作業中に進捗を報告したほうが良いのと同じ理屈で、作業中のものでもPull Requestしておけば、それが見える可能性が増える、と。 例を書
コミットログに開発を駆動させよう - assertInstanceOf('Engineer', $a_suenami)
この記事はGit Advent Calendar 2013の6日目の記事です。 前日は @DQNEO さんの「Gitが連想配列記憶装置であることを低レイヤーな操作を通して体感しよう！」でした。 はじめに 実は僕は昨年のGit Advent Calendarで次のような記事を書きました。 rebaseのすすめ この記事はこれの続編です。上記記事をご存知ない方はまずはそちらをお読みください。 コミットログに開発を駆動させるということ この業界にはxDDと呼ばれるプラクティスが多いですね。 TDD（テスト駆動開発）、BDD（振る舞い駆動開発）、ATDD（受け入れテスト駆動開発）、TiDD（チケット駆動開発）など。 僕はGitのコミットログも開発を駆動する力があるのではないかと思っており、今回はそれについてご紹介したいと思います。コミットログ駆動開発（CDD）とでも名付けましょうか？笑 理想のコミ
BitbucketとSourceTreeを使った弊社のGit運用指針 | オガリア 技術ブログ
こんにちは。オガリア開発チームの粂です。 弊社ではBitbucketとSourceTreeを使ってGitリポジトリを運用しています。他社の取り組みを参考にしつつ、日々試行錯誤しながらではあるのですが、ある程度運用指針のようなものができてきたので、2013年11月時点での弊社のGit運用指針を本記事でまとめておこうと思います。 前提：フロントエンドツールとしてSourceTree、リモートリポジトリはBitbucketを利用する GitHub Flowを採用する 基本的にはGitHub Flowに則ってmasterブランチとtopicブランチのみで運用しています。 masterブランチに直接pushしない 過去に本ブログでも書きましたが、Bitbucketでは任意のブランチにpushできるユーザ・グループを制御できます(AdministrationのBranch managementから)。
Atom Git Integration - r7km/s
Atomを使っていて、ファイル一覧やステータスバーの色が変わっていることに気付いたことはあるだろうか。 こいつの正体はGitだ。 Atomは標準でGitレポジトリを管理する機能を備えていて、Gitの一般的な操作は勿論それに関連した様々な機能を備えている。 今回はAtomのGitに関連する幾つかの機能を見ていきながら、それらがどういう風に動くのかを説明していこうと思う。 Git API 最初に言っておくと、この記事で触れるパッケージと機能は全てAtomのCore Git API上に実装されている。 atom.projectというグローバルにアクセスできるオブジェクトがgetRepo()というメソッドを持っており、 これが現在のプロジェクトのGitレポジトリを返すようになっている。 これを使えば、ファイルの状態や変更点など現在のレポジトリの状態を調べられる。 この機能には、git-utilsと
git と mercurial の diff を美しく表示するために必要なたった 1つの設定 (原題: diff-highlight 1.0.0 をリリースしました) - Hack like a rolling stone
Git の diff を美しく表示するために必要なたった 1 つの設定 #git にインスパイアされて作り始めた diff-highlight にあれこれ手を入れ、1.0.0 として正式リリースしました。 diff-highlight と git-contrib/diff-highlight の違い 差分の中で +/- の行数が一致していないときのハイライトの扱い git-contrib/diff-highlight での表示 +/- の行が一致していないとハイライトされません。 diff-highlight では、マッチする行を認識してハイライトします。 +/- の行数が一致しても、文字単位でのハイライトをしてくれないケースがある git-contrib/diff-highlight での表示 差分の 1行目同士を比較しているため、pager の行がハイライトされていません。 diff-
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitで既にmasterにマージされている使用済みブランチを消す方法 - Qiita
Webクリエイターのためのファイル管理コラボレーションツール｜universions
http://blog.inouetakuya.info/entry/20130602/1370173582