タグ

SCMに関するlibero18のブックマーク (52)

  • msysGit(Git for Windows)がいよいよ公式に UTF-8 をサポート! - てっく煮ブログ

    git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit(Git for Windows) がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin は UTF-8 な日語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けの GUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪い Windows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す

  • 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok

    チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

    「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
  • 本当は怖い軽量チェックアウトの話 - methaneのブログ

    前回は、作業ツリー上でコミットすると、別の場所にあるブランチに新しいリビジョンが追加されるチェックアウトについて説明しました。 今回はチェックアウトの別の仕組みである軽量チェックアウト (lightweight checkout) について説明します。 軽量チェックアウトの使い方 軽量チェックアウトを使う方法は、通常のチェックアウトをするときに --lightweight というオプションを付けるだけです。 $ # /path/to/branch にあるブランチの軽量チェックアウトを workingtree に作成する $ bzr checkout --lightweight /path/to/branch workingtree軽量チェックアウトを使うときは、チェックアウト元のブランチは同じマシン上のものにしてください。 その理由と、軽量チェックアウトのメリットをこれから説明していきます

    本当は怖い軽量チェックアウトの話 - methaneのブログ
  • [bzr] チェックアウトとブランチの使い分け - methaneのブログ

    bzr が git や hg と大きく異なるのは、メインラインの概念とチェックアウト機能だと思います。 メインラインについては昨日の Advent Calnedar で wonderful_panda さんが解説してくれました。(ブランチのメインラインのイメージについてしゃらくさい話をするよ - wonderful_pandaの日記) 今日はチェックアウト機能について紹介し、通常のブランチとの使い分けを解説します。 チェックアウトとは チェックアウトとは作業ツリー、あるいは作業ツリーを作成するコマンドのことです。作業ツリーは常にどこかのブランチに紐づいています。 bzr のチェックアウトは、紐づくブランチが別の場所(別のディレクトリや別のサーバー上)にあってもいいところがユニークです。 $ bzr checkout lp:bzr-colo colo-co # colo-co は lp:bz

    [bzr] チェックアウトとブランチの使い分け - methaneのブログ
  • http://standing-shoebill.appspot.com/bzr-startup-guide/index.html

  • そういえば共有リポジトリについてちゃんと説明してナカタヨ - wonderful_pandaの日記

    SCMBCとかでも説明せずにはしょったんですが、Bazaarには共有リポジトリという仕組みがあります。DVCSとして運用するためには、この仕組みを使うのと使わないのとで快適さがまるで違うので、そろそろちゃんと説明しておきます。 DVCSとして運用していると、以下のような理由などで、どんどん新しいブランチを作ることになると思います。 複数の新機能追加やバグフィックスを並行してしなければならない うまくいくかどうか分からないけどちょっと試してみたいことがある なので、いかに簡単にブランチを切ったり切り替えたりできるかが、開発のリズムを保つためにも重要になるんですが、普通の(共有リポジトリを使わない)ワークスペース構成にしていると、新しいブランチを作るときに既存のブランチを丸ごとコピーしなければならず、時間がかかってしまいます。(もちろん、データサイズもその分大きくなります) それを解消するため

    そういえば共有リポジトリについてちゃんと説明してナカタヨ - wonderful_pandaの日記
  • フックを作ってみる。 - wonderful_pandaの日記

    Bazaarの特徴として、プラグインによって柔軟に機能を拡張できることが上げられます。 「フック」は、ほとんどのVCSが持っている、さまざまな処理の中に独自のチェックや処理を挟み込める仕組みのことですが、Bazaarの場合は、フックもプラグインとして実装します。 どんなフックがある? 以下のコマンドで、作ることができるフックの種類をリストアップすることができます。 bzr help hooksまた、以下のコマンドで、実際にシステムにインストールされているフックをリストアップすることができます。bzr hooks 実装してみる。 例えば、コミットメッセージに問題が無いかチェックをするためのフックを作ってみましょう。 Bazaarのプラグインディレクトリにtest_hookディレクトリを作成し、その中に __init__,pyというファイルを置きます。 このファイルに、フックの処理を実装します

    フックを作ってみる。 - wonderful_pandaの日記
  • 本当は怖いローカルコミット - wonderful_pandaの日記

    前にShibuya.TracとかOSCでBazaarについて話したときには、 Bazaarだったら、SVNみたいに集中型で運用しながら、必要に応じてローカルでコミットすることもできるよ みたいなことを言ったんですが、最近はちょっと、ローカルコミットってのは挙動にクセがあるから混乱の元だし、使わない方が良さそうだという結論に(僕の中では)なってます。ローカルでコミットしたい場合はちゃんとブランチ切ろうねってことで。 ということで、お詫びもかねて、ローカルコミットを使うとどうなるかというのをちょっとご紹介します。 Pending Merge まず、前提となる用語について。 Bazaarの作業コピーには、"Pending Merge"という状態があります。これは、ここの「ステップ2:分散型の導入」のあたりにある、「mergeを実行したけれど、まだcommitはしていないよ」という状態のことですね

    本当は怖いローカルコミット - wonderful_pandaの日記
  • TortoiseBazaarを軽快に使うためのちょっとしたTips - wonderful_pandaの日記

    TortoiseBazaarに限らず、Tortoiseファミリーのソフトを使うと、どうしてもシステムのパフォーマンスに影響が出てしまうんですが、そういう影響を最小限にするためのちょっとしたTipsです。 ※あくまで現状の実装ベースの話なので、今後状況は変わるかも。 作業コピーを一箇所にまとめる TortoiseBazaarは、アイコンオーバーレイの対象となる作業コピー内のファイルの変更を監視しているのですが、システム内に複数の作業コピーがあると、それらの共通の親ディレクトリを監視対象にするようになっています。 例えば、以下のようなフォルダ構成になっていると、"C:\DEVELOP"が監視対象になり、Bazaarとは関係のないtortoisehgやtortoisesvn配下のファイルの更新も拾ってしまいます。 C:\DEVELOP\tortoisebzr\trunk Bazaarの作業コピー

    TortoiseBazaarを軽快に使うためのちょっとしたTips - wonderful_pandaの日記
  • Bazaarで分散バージョン管理(作業編その1)

    Bazaarで分散バージョン管理(チェックアウト編)からの続き いよいよ実作業に入っていきます。 作業ツリーは前回チェックアウトしたものを使用していきます。 ●変更&追加&差分表示 まずは main.c にちょっと処理を追加し、Makefile も作成しました。 Makefile は初コミットした時と同じ手順で 追加 を行います。 この状態で main.c には !アイコン、Makefileには +アイコンが表示されます。 右クリックメニューから 差分 を選択しましょう。 すると差分ビューが表示されます。 追加された Makefile の全文と、main.c の変更点の周辺のみが表示されています。 また、Makefile 内の日語文字列が文字化けを起こしています。 そこで、下のエンコード設定を変更して日語を表示できるようにしましょう。 この場合、日語は Shift-JIS で書いてい

    Bazaarで分散バージョン管理(作業編その1)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(作業編その1)
  • Bazaarで分散バージョン管理(チェックアウト編)

    Bazaarで分散バージョン管理(共有リポジトリ作成編)からの続き 今度は前回作った共有リポジトリから作業ツリーを取り出しましょう。 ●チェックアウト 適当な空フォルダを用意します。 ここでは bzrworkspace2 というフォルダを用意しました。 まず、フォルダ内のなにもないところで右クリックし、 「Tortoise Bazaar」>「チェックアウト/ブランチ」を選択します。 表示されたウィンドウで「ブランチ元」に共有リポジトリへのパス( "\turnk" を含む)を入力します。 また、「作業ツリーを作成するローカルディレクトリ」にはエクスプローラで開いていたフォルダのパス + "trunk" が表示されているはずです。 これは、「ブランチ元」のパスの末尾のフォルダ名を勝手に付け加えてくれる謎のおせっかい機能の仕業です。 余計なフォルダを作成したくなければパスを修正して構いません。

    Bazaarで分散バージョン管理(チェックアウト編)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(チェックアウト編)
  • Bazaarで分散バージョン管理(共有リポジトリ作成編)

    Bazaarで分散バージョン管理(作業ツリー作成編)からの続き 前回作成した作業ツリー(リポジトリ)をチームで共有できるように、 Subversion のような共有リポジトリを作成していきます。 ※ 来はHTTPサーバ等の上に作成させたほうがいいと思いますが、 (やったことが無いので)ここではファイルサーバー等の上に作成していきます。 ●リポジトリ初期化 ファイルサーバーまたはDropbox等、チームで共有できる場所に空のフォルダを用意します。 ここでは bzrrepository というフォルダを用意しました。 まず、フォルダ内のなにもないところで右クリックし、「Tortoise Bazaar」>「初期化」を選択します。 表示されたウィンドウで「新規共有リポジトリを作成」をONし、 「リポジトリ内に作業ツリーを作成しない」をONして「OK」を押します。 すると、フォルダの直下に ".b

    Bazaarで分散バージョン管理(共有リポジトリ作成編)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(共有リポジトリ作成編)
  • Bazaarで分散バージョン管理(作業ツリー作成編)

    Bazaarで分散バージョン管理(設定編)からの続き Bazaarを使ってゼロから作業ツリー(リポジトリ)を作成していきます。 ●リポジトリ初期化 以下のような main.c と define.h ファイルを含む bzrworkspace フォルダをBazaarで管理できるようにしていきます。 まず、フォルダ内のなにもないところで右クリックし、「Tortoise Bazaar」>「初期化」を選択します。 表示されたウィンドウで「新たな単体ツリーを作成」がONになっていることを確認して「OK」を押します。 (「履歴中のすべてのリビジョンNoを保持する」は使ったことが無いのでよくわかりません) すると、フォルダの直下に ".bzr" という隠しフォルダが出現します。 これが作業ツリーのリポジトリの正体です。 隠しフォルダなのでエクスプローラの設定を変えないと見れません。 .bzr フォルダの中

    Bazaarで分散バージョン管理(作業ツリー作成編)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(作業ツリー作成編)
  • Bazaarで分散バージョン管理(設定編)

    Bazaarで分散バージョン管理(インストール編)からの続き インストールしたBazaarをマージやコミットができるように設定していきます。 設定作業 ●TortoiseSVNの設定 まずはTortoiseSVNの設定から。 エクスプローラの何もないところで右クリックメニューを表示し、 「TortoiseSVN」 > 「Settings」 をクリックします。 「General」のなかにある「Language」を日語にして「OK」をクリックします。 日語が選択肢にない場合は日語言語パックのインストールに失敗しているので、 言語パックのインストールをやり直してください。 もう一度設定メニューを開くと、メニューが日語化されています。 右クリックメニューをすっきりさせます。 この設定はお好みで 「コンテキストメニュー」の設定で、以下のようにチェックのON/OFFをします。 「オーバーレイハ

    Bazaarで分散バージョン管理(設定編)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(設定編)
  • Bazaarで分散バージョン管理(インストール編)

    バージョン管理システムBazaarのインストール・設定方法を記述していきます。 現段階ではTortoiseSVNを使ったことがある人を対象にしています。 Bazaarの公式サイト http://bazaar.canonical.com/en/ まず、BazaarはGit、Mercurialに比べて以下の点が特に優れています。 ・日語に対応している (モノによってはエンコードエラーは発生する可能性あり) ・空のフォルダをコミットできる (Git、Mercurialはフォルダを管理対象として見ていない) 3つのうち一番動作が遅いらしいですが、Subversionから最もスムーズに移行できるのがBazaarだと思います。(※Gitは使ったことがありませんが) 少し古い記事ですが、比較はこちらの記事が参考になるかと。 分散バージョン管理Git/Mercurial/Bazaar徹底比較 http:

    Bazaarで分散バージョン管理(インストール編)
    libero18
    libero18 2012/02/08
    Bazaarで分散バージョン管理(インストール編)
  • GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
  • git - 簡単ガイド

    アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト

  • Git/Github超入門:猿でもできるPull Request · DQNEO日記

    Git/Github初心者のみなさんこんにちわ! Pull Requestを送ってみたいけど、やり方がわからない? 間違ったPull Requesするのがこわくて躊躇している? もったいない! そんなみなさんに、Pull Requestを送るための最小の手順をご紹介します。 昨日ちょうどEthnaにPull Requestを1件送ったので、これを題材にして説明します。 以下、Githubのアカウント取得、gitのインストール、SSH鍵の設定は終わっているものとして解説をすすめます。 Pull Requesを送る最小手順 1.ブラウザでプロジェクト画面を開きます。 例:https://github.com/ethna/ethna 2.forkボタンを押します。 3.以下、自分のPCで作業 git clone git@github.com:DQNEO/ethna.git cd ethna

    Git/Github超入門:猿でもできるPull Request · DQNEO日記
  • Git初心者が絶対に覚えておくべきコマンド - idesaku blog

    Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる!massageじゃない、messageだ!マッサージを作ってどうする! 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi

    Git初心者が絶対に覚えておくべきコマンド - idesaku blog
  • Gitを使った開発・運用フローの紹介

    私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介&考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが1人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に

    Gitを使った開発・運用フローの紹介