あまり知られていないGitのTips - アジャイルSEを目指すブログ
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット（push 前にログメッセージを整えています）を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で（ｒｙ と、そんな感じで出来た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
text.ssig33.com - UTF-8-Mac と git によって発生する問題に打ち勝った。
UTF-8-Mac と git によって発生する問題に打ち勝った。 これまで僕は仕事では主に Linux マシンを用いていたのだけど、先日 MacBook Air の 11 インチのやつを買ったのでせっかくだしこれを仕事に使いたくなった。 ところで Mac OSX ではファイル名は UTF-8-Mac という素敵な文字コードで記録されており、一般的には NFC で符号化されているのに、こいつは NFD で符号化されている。 極簡単に説明すると、濁点と半濁点が分かち書きされている、つまり が という文字を か + ゛ として記録されている。 これでどのような問題が発生するかというと Linux 上で mkdir test cd test touch がぎぐげご git init git add -A git commit -m test というふうにして作ったリポジトリを Mac に clo
WordpressをGitで管理する - Tatsuquito
Wordpressそのものやインストールしたプラグインは頻繁にアップデートされるので、割とまめに対応しなければならない。また、カスタマイズする箇所が増えて来ると、どこを変えたか？わからなくなってくるので、バージョン管理の仕組みを入れてコードを管理したほうが良い。 バージョン管理の中ではGitが一番簡単そうなので、いろいろ調べてみたが、意外とWordpressの管理に使っている情報が少なかった。やってみると簡単にできる上、お客さん向けにステージング環境を提供するのに便利なので、自分の環境の作り方をまとめてみる。 自分の開発環境を図にするとこんな感じ： Macbookの上で走らせているVMWareにUbuntuで開発環境をたて、そこでWordpressのカスタマイズをしている。カスタマイズの対象となるWordpressのコードはCoresever上にあるGitのリモートレポジトリに格納され、U
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
gitosis - Git リポジトリ群の管理とアクセス制御 vol.1 - openbooth
gitosis - Git リポジトリ群の管理とアクセス制御 vol.0 の続編です。 前回のエントリでは、Git リポジトリの管理に対する不満と、それを少し改善してくれる gitosis を簡単に紹介をしました。このエントリでは gitosis のインストール編ということで話を進めていきます。 基本的に Hosting Git repositories, The Easy (and Secure) Way のエントリと同様です。本家の方が安心という人はそちらのエントリをどうぞ。 サーバ/クライアント(ローカル)両方で作業する必要があるので、識別しやすいように以下の表記をします。 サーバ作業のプロンプト表記 remote% クライアント(ローカル)作業のプロンプト表記 local% また、サーバアドレスを便宜上 remote-name.com とします。 まずは Git リポジトリをホ
PukiWiki 【FrontPage】
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
tig – コマンドラインGitブラウザを入れてみた。 « わすれないように.
Tig provides a simple command-line yet visual interface to Git. http://www.gitready.com/advanced/2009/07/31/tig-the-ncurses-front-end-to-git.html Mac Ports や Ubuntu, Debian では、コマンド一発でインストールできるようなので、試しにDebian (lenny) なサーバーに入れてみた。 インストールはいつもの手順で (ルート権限で) aptitude update aptitude install tig これだけでインストール完了。 cd /path/to/git/repo tig Gitリポジトリに移動して、tigコマンドを打つと、ログ一覧が表示される。 一覧の中からみたいコミットを選択すると（Enter）画面が分割さ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bayashi.jp
bayashi.jp
http://blog.yuku-t.com/entry/20110427/1303868482
[git 1.6.0.2] submoduleを使おう！その1：add, status - satoko's blog - s21g