Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
環境とやりたい事 Windows10でcygwinのgitでcommit実行時のエディタをサクラエディタにしたい。 cygwin上のgitではデフォルトのエディタがvimとなっているが日本語入力し難いし使いづらい。 ちなみにcygwin上のgitとは別でmsysgitをインストールしてはいるが設定は競合しておらず別設定。 方法 cygwinのパス設定の関係上、エディタ実行用のスクリプトを作成する。 スクリプトを配置する適当なエディタ作成。 $ mkdir ~/script/スクリプト作成 $ cygstart ~/script/git_editor.shこんな感じ。 3行目のエディタパスは環境に応じて変更。 オプションの「-c65001」はUTF-8で開くという意味みたい(多分) このスクリプトの注意点として改行コードはLF、文字コードはUTF-8としておかないと、何なら実行時に挙動がおか
対象 意識低い人 これから始めたいけどなんかgit使ってる人怖いって人 操作 これだけは覚えとけって操作 コミット これができないとお話にならないので 以上 これ以外は使いながら覚えればおk (リモート使うんならpull/pushも必要かもね) ツール 意識高い人「gitはコマンドライン叩いてナンボ」 - 最初はコマンドとかほっとけばいいよ とりあえずオススメのGUI系 Windows GitExtensions http://gitextensions.github.io/ Mac SourceTree http://sourcetreeapp.com/ Linux 意識低い人がLinux使ってるはずないので省略 WindowsにもSourceTreeあるけど、UIが英語なので意識低い人は日本語化されてるGitExtensions使っとけ 「WinもMacも使うんだよ!」って人はSour
徐々にGitに移行しつつあるのですが、複数人数(チーム)でGitを使った場合の運用ルール、ワークフローというものを考えてみました。 Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい! 原則 masterで作業しない。ブランチを作って作業する。 ブランチでは1機能もしくは1バグのみ作業する。 ワークフロー 準備 ローカルのmasterに移動する $ git checkout master ローカルのmasterをリモートと同期する $ git pull origin/master masterから、作業用のブランチを作成する。 $ git checkout -b branchname master ブランチ名は担当者名と作業名をスラッシュで結合したものとする。 例: taro/featurename, taro/bugname コーディング コード
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
Git、Mercurial、Bazaarはオープンソースの分散バージョン管理システムで、どれも人気がある。特にGitとMercurialはもともとはLinux Kernelの開発のために作られた歴史からしても、ライバルと言える関係だ。LinuxやAndroid OSではGitが採用されたが、MercurialもOpenJDKやNetBeans、Xen、Python等で採用されている。 SVNから分散バージョン管理システムに移行を検討している所は多い。日本だと濱野氏がGitのメンテナをやっているせいかGitに人気が集中しているようだ。しかし気軽に分散バージョン管理システムを導入したいソフトウェア開発チームには、あえてMercurialを勧めたい。 1. SVNからMercurialに移行するべき8つの理由 取り扱いが楽で、今すぐ移行できる事がMercurialを導入するべき理由だが、もう少し
開発組織、プロジェクトの特性で大きく左右されるのが構成管理なので、バージョン管理ツールはその都度選択しなければならないのが現状です。 選択の前提 開発組織またはプロジェクトで標準化された構成管理(バージョン管理)環境が存在していない 開発支援環境(構成管理)に開発組織またはプロジェクトが十分な資金投入をする意思がない これは構成管理環境を専任スタッフが構築し、個々のプロジェクトへの適用・運用をサポートするというあるべき姿が取れていない組織でのバージョン管理ツール選択を考えるということを意図しています。 Subversionで対応可能か否か(分散の必要が本当にあるのか) 分散バージョン管理が話題になっていますが、実績/情報/対応ツール/日本語対応を考えるとSubversionが最有力候補です。そこで、Subversionでは構成管理上困ることがプロジェクトの特性上あるかを見極めます。 リポジ
12/17 に開催された、分散バージョン管理勉強会に参加して、会社で運用している Git と Hudson を連携させた構成の紹介をしてきました。 会場に行くまでの話とか、他の人の発表の話とか、その他諸々は別エントリにまとめるとして*1、このエントリでは自分の発表に関連するところを書きます。 分かり難いことこそ美徳 (Git は玄人向け?) という話があったんですけど、あー、うー。なかなか反論難しい感じですよねw もちろん分かりにくくしようと思って分かり難くなっているわけではないです。 要は何を取って何を捨てるか、という話で、Git では速度をとって他のものを捨てているイメージ。 ハッシュわけわからん、って人はそれなりにいて、自分も「Mercurial のリビジョン番号とハッシュ併用スタイルいいよなー」とか思っていたんですけど、 @bleis リビジョン番号でどこそことか言われても相手と自
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は本人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト(仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
the Hg-Git mercurial plugin This is the Hg-Git plugin for Mercurial, adding the ability to push to and pull from a Git server repository from Mercurial. This means you can collaborate on Git based projects from Mercurial, or use a Git server as a collaboration point for a team with developers using both Git and Mercurial. The Hg-Git plugin can convert commits/changesets losslessly from one system
Dulwich is a Python implementation of the Git file formats and protocols, which does not depend on Git itself. All functionality is available in pure Python. Optional C extensions can be built for improved performance. Dulwich takes its name from the area in London where the friendly Mr. and Mrs. Git once attended a cocktail party. Testing happens on CPython 2.X where X >= 6 and on recent versions
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く