これでmagit4というディレクトリが作られてgitリポジトリが初期化される 最初のコミット C-x C-fでindex.htmlを作成します。ファイルの中身 <html> <head> <title>Shizugit</title> </head> <body> <h1>Shizugit</h1> <p>Shizugitでは、参加者を募集しています。 最新の版管理システムgitについて熱く語り合いましょう。 </p> <address> <a href="mailto:magit@test.com">kzfm</a> </address> </body> </html> C-x C-sで保存します。 さて、ここでおもむろにM-x magit-statusと打つとmagit-modeのバッファーが開きます(下段)。 カーソルをindex.htmlにあわせてs キーを打つとステージングされま
バージョン管理狂の皆様におかれましては alias st='git status' などのエイリアスは当然定義されていることと思います。 うっかり Mercurial リポジトリの中で st を叩いてしまって fatal: Not a git repository などと言われ、ここで st つったら hg status に決まってるだろボケがとターミナルを叱責した経験も当然あることと思います。 泣く泣く gst と hst を定義したものの、3文字打つのがかったるくて枕を濡らしたことも当然一度や二度ではないことでしょう。 というわけでちょっと賢いエイリアスを定義できるやつを作りました。 Git リポジトリの中で st を叩いたら git statusになり、Mercurial リポジトリの中では hg status になる、そんな空気の読めるやつです。 no title こういう感じで使
Time to Read 2分 etckeeperと言うものがあり、要するに /etc 以下をリポジトリにして変更履歴を管理してくれる、大変大雑把と言えば大雑把なソフトウェアがあります。大雑把ですが、結構便利です。 インストール 1 sudo aptitude install git-core etckeeper そしたら、 /etc/etckeeper/etckeeper.conf と言う若干くどい名前の設定ファイルを編集。 1 2 3 4 5 # The VCS to use. #VCS="hg" VCS="git" #VCS="bzr" #VCS="darcs" Gitの他、MercurialやBazaarなんかが使えます。ただし、Subversionなどのような、中央リポジトリが必要なバージョン管理システムは使えませんね(ローカルにコミットしていくため)。 VCSを決めたら: 1
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね? 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします: $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
tomykaira/gitomb Milkode は数万のファイルでも軽々動く、ソースコード検索エンジンです(製作者は id:tuto0621 さんです)。 しかし、数万ファイルもあるリポジトリなんて管理しますか?普通。 ソースコードを検索する回数がもっとも多いのは、既存のライブラリの使い方がよくわからないときに、ドキュメントに乗っているメソッド名を手掛かりに検索して、望みの機能を発掘していくような時のはずです。いままで、ライブラリのコード検索をしようとおもったら、 ライブラリを落としてくる そのディレクトリに移動する git grep かなんか ヒットしたファイルをエディタで開いて、まわりを見回す 見付かるまで検索をくりかえす みたいなことをやっていました。milkode web を使うと、次のようになります。 ライブラリを落としてくる そのディレクトリに移動する milkode
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
自分で書いたelispの中で一番重宝しているもの. 以下のコードを適当なところ(init.elなど)に貼れば,C-;でそのプロジェクト内のファイルをanything絞りこみして開ける. (defun anything-c-sources-git-project-for (pwd) (loop for elt in '(("Modified files (%s)" . "--modified") ("Untracked files (%s)" . "--others --exclude-standard") ("All controlled files in this project (%s)" . "")) collect `((name . ,(format (car elt) pwd)) (init . (lambda () (unless (and ,(string= (cdr el
SubversionからGitへ移行するときに起こる問題についてちょっと語りました。
hub · the command-line wrapper for git gitコマンドだと、ローカルのgitをごにょごにょするに限られる。でも、gitユーザならgithub使ってるでしょ。github上でのリポジトリの作成もコマンドラインからやりたくなるでしょ。 Macには公式GUIクライアントがあって、そこからgithubコマンドを入れられたりもします。しかし、そのコマンドはGUIクライアントを起動するためのもの。GUIクライアントがあっても悪くないけど、CUIでできることをわざわざGUIでする必要もないですね。 hub インストール $ brew install hub その他のインストール方法は冒頭のリンク先を参照ください。 リモートリポジトリの作成 $ hub create コマンドひとつでgithub上にリポジトリを作ってくれる。もちろん、remotes/orignも設定し
defunkt/hub - GitHub github用にhubというgitのラッパーコマンドがあることを会社で教えてもらって 使ってみたら、当然の如くzshの補完が効かなくてコマンドの使い方もよく分からなかったので、 コマンド理解とzsh補完関数の書き方の勉強も兼ねて自分で作ってみた。 最初はhubコマンドの補完関数を作ってたんですが、利用方法としてaliasを充てて gitの代わりに使うことが推奨されており、そもそもgitのラッパーで gitコマンドの補完も出来ないと意味が無いので、gitの補完関数自体に 手を入れて、hubのカスタムコマンドも利用出来るようにした。 検証環境は下記 Mac OSX 10.7.3, Scientific Linux 6.1 git version 1.7.7.5 hub version 1.8.2 zsh 4.3.11, 4.3.12 /usr/loca
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。では、効率的に開発・運用・保守・管理を行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えば
github_id_rsa.pub とかを別につくって git コマンドにはそっちのペアを鍵ファイルとして使って欲しいんだけどうまくいかない。 $ export GIT_SSH="ssh -i ~/.ssh/github_id_rsa" $ git clone git@github.com:XXXX/XXXX # Permission deniedGitのリポジトリにsshでアクセスする | Hiroaki's blog をみて warpper つくってみたけどやっぱりだめ。こちらは ssh コマンドがヘンになるみたい。 $ echo '#!/bin/sh shift exec ssh -i ~/.ssh/github_id_rsa $*' > ~/bin/git-ssh $ export GIT_SSH=$HOME/bin/git-ssh $ git clone git@github.c
Emacs Advent Calendar の31日目です。 本来は26日目担当だったんですが、体を壊して最後に回してもらいました。 gitで管理されているelispをinstallするためのutilityとして書いたbundle.elを紹介します。 はじめに bundle.elはvundle.vim, neobundle.vimのEmacs版です。 Emacsにはauto-install.elやpackage.elといったelisp managerがあるのですが、githubなどにあるelispをvundleやneobundleのように扱いたかったので書きました。 機能 bundle.elはgithubやrepo.or.czなどのgit repositoryにあるelispを取得し、取得したelispへのload-pathを通します。 svn, hg, bzr repositoryはまだ
こんにちわ。債務者ことゆろよろです。家買いました。 さて、最近こんなまとめが話題になりました。自分もコメントしましたが、すごい情報量になってます。 これ知らないプログラマって損してんなって思う汎用的なツール #JavaScript #PHP #Ruby #Python #HTML - Qiita 【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 #PHP #JavaScript #Python #Ruby #HTML - Qiita で、自分のコメントにも書いたのだけど、基本的に仕事はターミナルでssh接続して、Vimでコード書いてるので、この辺の環境構築についてまとめてみた。最近Terminal.appからiTerm2に移行して、screenからtmuxに乗り換えたので、その辺も含めて導入方法を書いておく。 手元の端末はMBPでOSX Lionだけど、ほぼ同
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット(push 前にログメッセージを整えています)を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で(ry と、そんな感じで出来たgit-now の紹介 簡単な実行例 コマンド $ git now これで、版管理されているファイルのtmp コミットが作成できます。 コミットメッセージ例 [from now] Tue Dec 7 23:00:24 2010 diff --git a/hello.py b/hello.py index 51cff9f..9e84b86 100644 --- a/hello.p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く