Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
gitの ".." と "..." の意味がコマンドで異なるらしいので図解した - Qiita
$ git log master..test --> git log ^master test C $ git log master...test --> git log master test ^B D C $ git log test..master --> git log ^test master D $ git log test...master --> git log test master ^B D C $ git diff master..test --> git diff master test -D +C B A $ git diff master...test --> git diff B test +C B A $ git diff test..master --> git diff test master -C +D B A $ git diff test...ma
#21 github-botで捗っている話、もしくはgit-subtree使ってみた - KAYAC Engineers' Blog
この記事はtech.kayac.com Advent Calendar 2014 の21日目です。 こんにちは、最近日にちの感覚がなくなっているいっちーです。 アドベントカレンダー駆動で何かつくろうと思ったんですが、そんな時間はなかったので、最近プロジェクトでやってみた取り組みをご紹介します。 背景・目的 僕は今現在Unityを使ったソーシャルゲームの開発に関わっており、 主にサーバサイドのプログラムを担当しています(もちろんPerl)。 Unity側ではサーバとのやりとりをBaalというAPIの定義書にもとづいて行っており、 サーバへのリクエストやレスポンスが形式にあっているかをチェックする機能があります。 例えば「Hogeというエンティティは整数型のFugaというフィールドを持っている」ということをBaalで定義すると以下のようになります。 // Baal定義の例 namespace
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
pre-commit
pre-commit A framework for managing and maintaining multi-language pre-commit hooks. Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer
Yelp: git hookのためのマルチ言語対応パッケージマネジャ - ワザノバ | wazanova
http://engineeringblog.yelp.com/2014/08/announcing-pre-commit-yelps-multi-language-package-manager-for-pre-commit-hooks.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Yelpでは、コードレビュー前にgit hookを利用してコードのチェックをしていますが、 プロジェクトごとにhookのbashスクリプトをコピペ/修正するのが面倒。 lintツールなどを利用するには、プロジェクトで使っている開発言語以外の言語用のパッケージマネジャーでインストールしなくてはいけないケースがある。 nodeのプロジェクトで scss-lint（Rubyで書かれている。）を利用する際、プロジェク
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.
pecoで最近更新されたブランチにcheckoutする - $shibayu36->blog;
昔、最近commitされたブランチをanythingライクに絞り込んでcheckoutする、というものをzawの時もpercolの時も実装していた。 zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog; ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog; 最近はpecoを使うようになったので、ほぼコピペで再実装した。 設定方法 git-recent-branches.zshのようなファイルを用意し、peco-git-recent-branchesとpeco-git-recent-all-branchesを実装する。 function peco-git-recent-branches () { local selected_branch=$(git for-each-ref --forma
とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
2014年、春のGit事情 - fujimuradaisuke's blog
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
git pullでファイルに変更があったら特定のコマンドを実行する。 - from scratch
最近ガッツリnode.jsのプロジェクトを行っているんですが、チームで開発しててよくあるのが、git pullした後にpackage.jsonやbower.jsonが変更されている事に気づかず、 そのまま起動してしまい、モジュールが足りてなくて動作しないって事です。 多分コレってnode.jsに限らずrubyとかperlとかphpとかpythonとか何でもあると思うんです。もうすぐ、2014年度です、運用でpullしてエラーが出たらnpm install/cpanm/bundle installしましょうとか言うのは辞めましょう。*1 git pullしたら変更されたファイルの一覧から 対象のファイルが変更されているかどうかを認識して、特定のコマンドを自動で実行するためのコマンド、hookinを作りました。 Getting started npmが入っているなら超簡単で、 $ npm in
Git 1.9 最新情報 | Atlassian Japan 公式ブログ | アトラシアン株式会社
皆さんが、DayZ の徹夜プレイで略奪しまくるのに忙しいのは承知していますが、少しお時間をください。今日ご紹介する内容はチェックするだけの価値があるものです。git ポイントリリースの最新版(1.9)がリリースされました! リリースノートの中で私の目を引いた点を紹介します。興味のある方は、早速リリースノートに目を通し、オタク心をときめかせる華麗さを堪能することができますが、私にも手伝わせてください! 最新版の説明に入る前に、これまでのリリース1.8.2、1.8.3、1.8.4、1.8.5 に関してもこれまで記事を書いてきましたので、ご紹介しておきます。巧妙な技や使える情報がたくさんあります。 全ユーザー向けアップデートの指針 アップデートするにはどうすれば良いか? 以下に取りかかるのに役立つ情報を挙げておきます: OSX 上でhomebrewを使用している場合は、brew update &
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2014 で「Git によるツール開発」というタイトルで話しました #yapcasia - 詩と創作・思索のひろば
入門書には載ってない Git & GitHub Tips
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/1.9.0.txt