IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Posted on Sat Feb 06 23:13:35 +0900 2010 by nabeken 使用中のGitリポジトリからあるディレクトリ以下のみを含む新しいリポジトリを作成する方法を検討しました。 twitterでつぶやいたところ、 @n_iwamatsu さんに git-commit-tree というコマンドを教えてもらいました。(参考: http://twitter.com/n_iwamatsu/status/2304942015) このコマンドは引数に tree-ish と親コミットオブジェクトの commit-ish (optional)、そして標準入力からコミットログを取りそれらに紐付いた新たなコミットオブジェクトを作成し、その commit-ish を標準出力へ出力します。 ここで、Gitにおけるディレクトリの扱いについて復習です。ディレクトリはGitではTreeオ
Posted on August 30th, 2009. I've been hanging out in the #mercurial and #bitbucket channels on freenode a lot lately, and I've noticed a topic that comes up a lot is "how does Mercurial's branching differ from git's branching?" A while ago Nick Quaranto and I were talking about Mercurial and git's branching models on Twitter and I wrote out a quick longreply about the main differences. Since then
git には「stage(ステージ)する」という概念があります。あるいは「index」と言い換えてもいいかもしれません。 簡単にいうと「stageする」=「特定の変更内容をindexに登録する」=「次回コミットに含めるようgitに指示する」ということなのですが、この概念は今まで主流だった CVS や Subversion といったバージョン管理システムにはありませんでいした。 長年CVSを使っていて、その考え方に凝り固まっていた私は、gitを使い始めてしばらくはstageやindexの概念を理解できなかったので、今回ここで紹介することにしました。 このstageとindexを覚えると「ひとつのコミットには、その主題となる変更と無関係な変更を含めない」という「バージョン管理システムを使う上で重要なはずなのに、つい疎かにしてしまいがち」なポリシーを簡単に実践できるようになります。 今回stag
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
ども。自分のサイトを復旧させるのが面倒なため会社のブログに本のレビューまで乗せようという魂胆の村瀬です。 週末に「入門GIT」を読んだのですがこの本は git ユーザーはもちろんのことその他すべての開発者が必読の本だなぁと感じたので紹介しておきます。 この本です。 この本は現在の git の開発者でありメンテナーである濱野氏によって書かれた git の入門本です。 ただの入門本にあらず しかし入門本だから最初はよくあるようなチュートリアルのような記事からはじまるのだろうと思っていると最初から面食らいます。 最初に書かれているのは git がどのようにデータを記録し、どのように履歴をたどれるようになっているかというまさに git 自体の基本が書かれているのです。 僕個人は二年近く git を使用してきているため自分の知識の確認のような感じで読み進められましたが、初めての方はすこしむずかしいか
Git を使うなら GitHub で決まりだと思うけど、GitHub は BTS がないし、Git じゃなくて Mercurial を使いたかったので、Mercurial 版 GitHub がないか探してみた。 そのうちにいろんなリポジトリサービスが見つかったので、紹介してみる。 #sourceforge.net とか rubyforge.org とかでも repository hosting を提供してるけど、ほとんど使われてないっぽい。 GitHub (Git) http://github.com/ Ruby on Rails が使ったことから一気にブレーク。Rails ユーザは皆ここを使う。 Issue Tracking System がないので、Lighthouse.com と併用することが多い。 Wiki が利用可能 Bitbucket (Mercurial) http://ww
07:41 pm - ようやくgit本が出る 昨年末から書いていたgit本がようやく校了となって、印刷所に入稿というところまでこぎつけた。先月の半ばに、Swicegoodの翻訳本がオーム社から出て、いまこれが Amazon.co.jp でかなり売れているようだが、紛らわしいことに書名が全く同一である。せめて一方が「入門Git」でもう一方が「Git入門」ででもあれば良かったのだろうが。ボクの本の方は、今月の19日頃から書店に並ぶことになっている。 もうだいぶん前のことになってしまったが、Swicegoodの原著はボクも技術監修したもので、内容に間違いもなくて良く書けた本にまとまっていた。日本語版を出すときに最近のgitに合わせた加筆更新が行なわれたのか、原著のままの内容なのかは知らない。一番手のSwicegoodに始まり、Loeligerと、先月出たChaconと、洋書では今まで三冊のgit
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2009/04/28 米グーグルは4月24日、ソフトウェア開発プロジェクトのホスティングサービス「Google Code」で、これまでのSubversionに加えて分散バージョン管理システム(DVCS)の「Mercurial」のサポートを開始すると発表した。現在はプレビューリリースで、一部のプロジェクト利用者に提供。一般リリースに向けて、いくつかの課題を解決していくという。Google Codeでは、Mercurialサポートのために、一般のMercurialがオブジェクトの保存に使うOSネイティブのストレージに代えて、グーグルの分散データベースシステム「BigTable」を使うように書き換えたという。 DVCSとしては、MercurialのほかにGitやBazaarが知られている。従来からある中央管理型のバージョン管理システムに比べて、分散開発がやりやすいことから、普及が進んでいる。例え
分散バージョン管理Git/Mercurial/Bazaar徹底比較:ユカイ、ツーカイ、カイハツ環境!(3)(1/5 ページ) Subversionとは一味違う「分散バージョン管理」とは? 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion(以下、SVN)と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式(または、集中型)のバージョン管理システムと分散管理
はじめに † gitの個人的によく使いそうなコマンドをまとめてみました。自分用チートシートです。 よく使うコマンドは ../コマンドの省略(alias)設定をする方法にて省略形を作っておくと便利です。 各コマンドの詳細は git (コマンド名) --help すると記載があるのでそれ見てもらったら早いと思われます。 ↑ 前提 † 変更したファイルをコミットするときは、 [ローカル]→(addコマンドする)→[インデックスに入る]→(commitコマンド)→[リポジトリに入る] という状態の推移に注意して下さい。 gitでは「コミットしたいものをaddすると一旦インデックスに入るので、次にインデックスに入れたものをcommitでリポジトリにコミットする」と私は理解をしましたが、本来の用途とは別かもしれないです。 ※TODO: 概念の背景を後で調べる ※Subversionように「addでファ
Rubyで遊んだ日々の記録。あくまで著者視点の私的な記録なので、正確さを求めないように。 Rubyと関係ない話題にはその旨注記しているはず。なので、一見関係無いように見える話題もどこかで関係あるのかもしれません。または、注記の書き忘れかもしれません... 年 月 ◆GitとGitHubを使ってみる _ Linusのバカ発言はどうかと思う。 SubversionはSubversionで素晴らしいし、作ってる人たちは絶対バカじゃないよ。焦点の当て所が違うというだけだよね。 _ が、それはそれとして、Git(とGitHub)が提供するワークフローは非常に素晴らしい。それは認めよう。 というわけで、重い腰を上げてGitを触ってみることにする。 _ ではまずGitのインストールから。 _ うちはWindowsで、まあそうすると当然のようにcygwinでバイナリ配布があるわけだけど、cygwinのシェ
Git のリモート・リポジトリーでブランチを操作する方法についてメモ。 リモート・リポジトリーに新しくブランチを作成する リモート・リポジトリー foo に新ブランチ bar を作る方法。git push コマンドを使う。 $ git branch master * bar $ git push foo bar カレント・ブランチの名前を git push に渡すと、リモート・リポジトリーに同じ名前のブランチが新しく作られる。 ブランチの名前を変えたい場合? 「ローカル・ブランチ名:リモート・ブランチ名」の書式でブランチを指定する。例えば、上の例で (bar ではなく) hoge ブランチをリモートに作る場合はかうなる。 $ git push foo bar:hoge この「bar:hoge」の部分を refspec と呼ぶそうな。 リモート・リポジトリーのブランチを削除する リモート・リ
Git % ./configure --without-tcltk % make % sudo make install % git config --global user.email higepon@xxxx.com 初期設定 % mkdir spon % git init % git add ./tools.mosh.sls % git commit -m 'first commit' % git remote add origin git@github.com:higepon/spon.git % git push origin master 変更と反映 # ファイルを変更して % git commit -a % git push origin master 共同編集 github のプロジェクトの編集で Collaborator にメンバー追加すると共同編集できる。 higepo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く