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 subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
transitive.info - git svn 使い方
git svn 使い方 svn のログを見る svn リポジトリのログを見るには git svn log とする。 subversion のリポジトリを git svn で複製する git svn clone svn://example.com/svn/repo とすると subversion のリポジトリを git で扱うことができる。 標準のレイアウトを持つ subversion リポジトリの場合は -s オプションをつける。 git svn clone -s svn://example.com/svn/repo 標準ではないサブディレクトリの svn リポジトリをクローンする git svn clone に -T でトランク、-b でブランチ、-t でタグのサブディレクトリを指定する。 git svn clone -T TRUNK -b BRANCHES -t TAGS svn://
チームが Git を使っていなくても Git を使う: git-svn をうまく使うコツ | Atlassian Japan 公式ブログ | アトラシアン株式会社
私はアトラシアンに入社する前、バージョン管理システムとして Subversion (SVN) を使用している多様なプロジェクトに携わってきました。私はすでに Git へ移行して数年経っていたので、可能な限り Git を利用したいと思いました。 そして幸運にも、git-svn を使うことができました。Git-svn は、パワフルな Git ツールセットの快適な使用感を手放すことなく、Subversion リポジトリとやり取りができるすばらしい完全なソリューションです。そして、それには知っておくと便利な点がいくつかあります。この投稿では、すでに git-svn の知識が少しあり、git-svn を使用して SVN とやり取りする方法を知っている人を対象に話を進めていきます。 ここでは、SVN と連動して Git を快適に使用し続けるために、私が自ら調べて学んできたワークフローに統合する必要のあ
git-ignoreというコマンドを書いた話 - ( ꒪⌓꒪) ゆるよろ日記
git-ignore add みたいのが欲しい— azu (@azu_re) August 24, 2014 ちょろっと書けそうだったので書いた。 yuroyoro/git-ignore · GitHub Demo Installation PATH通った場所においてくれ curl -sL https://raw.githubusercontent.com/yuroyoro/git-ignore/master/git-ignore > ~/bin/git-ignore Examples `git ignore add "pattern"`で、.gitignoreへ追加する。 $ git ignore add '*.log' .gitignoreから削除するには、`git ignore remove "pattern"`を実行する。 $ git ignore remove '*.log' a
とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
gitworkflowについての雑感 - 放牧日記
誰得UNIX-Blog: git-flowでもgithub flowでもない、Git本家推奨のワークフロー http://t.co/WC3NmN0Yy3 @troter の熱い解説を待とう— V (@voluntas) 2014, 2月 2 振られたので。詳しい内容はリンク先をどぞー。 gitworkflow 日本語訳 git reset 特徴的というか、僕が「やっぱgitらしいなー」と思ったのは、git reset <branch>を積極的に利用している点です。 gitworkflowでは4種類の統合ブランチを用意していますが、そのうち2種類が使い捨てのブランチというのが面白いです。 maint - メンテナンスリリースはここから。時折masterへマージする。 master - 機能リリースはここから。 next - 使い捨て。機能リリース(masterからのリリース)後にgit re
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
Web制作者のための実践Git | 第1回 適切な履歴の作り方
上記の例の場合、変更した箇所が近いため同じhunk（変更の塊）として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表
git でリモートリポジトリを clone する際、特定のブランチだけ取ってきたい - oogatta のブログ
$ git clone -b [branch] --single-branch [remote-repository]でした。 古い文章だと $ mkdir test $ cd test $ git init $ git remote add [remote] [remote-repository] $ git fetch [remote] $ git co [branch]って書いてるのもあるけど、これだと remote tracking branch がリモートリポジトリにある全ブランチ分できてしまうのに対し、 --single-branch ではその時 -b で指定したブランチ分のみできる。 --single-branch で clone すると、それ以降の git fetch [remote] でも --single-branch した時のブランチだけが fetch されて来ます。
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
pull request を利用した開発ワークフロー
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
Git ライフを快適にする知られざるコマンドたち
Git 初心者〜中級者に向けて、目立たないけど便利なコマンドを紹介します。
チーム開発に必要なGitコマンドを神速で習得しよう！
すみません、タイトルは釣りです。書籍『入門git 』と『もっと早く知りたかった！ Gitが鬼のようにわかるスライド厳選7選』、『Gitがこわくて触れられなかったけど、このスライドで理解出来るようになったよGitサイトまとめ』紹介のスライドを読んで、理解したことをまとめるためにこの記事を書きました。今までは個人でしかGitを使っていなかったので、チーム開発に必要なGitコマンドを少しでも理解できるように頑張ります！ (05/13 08:45) githelpを追加 🐡 Gitの基本的な開発スタイルについて From イラストでわかる！git入門の入門 Gitの基本的な開発スタイルは次のとおりです。 (1) gitの開発ではローカルで使う個人リポジトリとチームで使う共有リポジトリを用いる (2) 共有リポジトリに push すると個人リポジトリのこれまでのコミット内容を送れる (3) pul
git push 前に自動でテストを回そう - tomykaira makes love with codes
2013-07-14 git push 前に自動でテストを回そう git git push する前にテストを回しわすれ、 pull request が CI にはねられて悲しい思いをすることが多かったので、忘れないように自動化した。 git には pre-push hook が 1.8.2 から導入された。 以前 temporary なコミットが含まれる場合、push をやめるというのを作ってとても重宝した。 git-now したコミットの誤送信をふせぐ - tomykaira makes love with codes テストを回すのはチェックに時間がかかるけど、それで円滑な開発と綺麗なコミットグラフが促進されるなら、30秒ほどまつ価値はあると思う。 .git/hooks/pre-push の内容は次のような感じ。以前のに足したところから、関係なさそうなところを消したので、余計なものが混
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.d-wood.com/blog/2014/05/22_6257.html
GitHub - FredrikNoren/ungit: The easiest way to use git. On any platform. Anywhere.
