はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
会社や学校の中にいる場合、インターネットへアクセスする際に、Proxy(プロキシ)経由でのアクセスとなるシーンがよく見られるのではないでしょうか。 その場合、イントラネット内から分散型バージョン管理システム(分散SCM)であるgitを使った外部アクセスは難しく、特にサーバ側がgit-daemonで稼動している場合は、gitプロトコル(git://)でのアクセスとなり、HTTP Proxy経由でのアクセスにはコツが必要となります。 ということで、Proxy越えにチャレンジしてみることにします。 Corkscrewのインストール まず、HTTP Proxyサーバを通してトンネリングできる「Corkscrew」を利用します。 # apt-get install corkscrew私は、Debian使いですので、サクっとaptでインストールしました。 そうではない場合も、他パッケージ管理システムで
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
■ [git] どの段階で混入したのか全く分からないバグが発生したので、git bisectを使ってみた 気づいたら、BiwaSchemeのmakeが通らない状態になっていた。 java -jar bin/yuicompressor-2.4.2.jar lib/biwascheme.js -o lib/biwascheme-min.js [ERROR] 16082:51:invalid property id [ERROR] 1:0:Compilation produced 1 syntax errors. 数日前までは通っていたんだけど、それから結構な回数コミットを行ったので、どれが原因なのか分からない。 でも大丈夫、こんな時こそ(存在は知っていたけど使う機会のなかった)git bisectを使うチャンスだ。 git bisectは、「OKなコミット」と「NGなコミット」の2点の間を二分
最近magit.elを使い始めたんだけど、diffの色が白黒だったので変えれないかなーと思っていたら、deffaceで定義されていたので変えてみた。次の設定を書いておくと追加した行が緑色になる。 (set-face-foreground 'magit-diff-add "green") ちなみにdeffaceは以下のように設定ファイルに書いておくと変えれるみたい。http://d.hatena.ne.jp/kitokitoki/20090816/p5を参考にした。 (set-face-foreground 'yas/field-highlight-face "coral") (set-face-background 'yas/field-highlight-face "black") (set-face-underline-p 'yas/field-highlight-face t)
emacs上でgit使う時におすすめのフロントエンドに、magitがあります。 NSEG Git勉強会 #3 - モーグルとカバとパウダーの日記 http://d.hatena.ne.jp/stealthinu/20101216/p1 magit導入して、普通に使えたのですが、pushが上手くいかないという問題が起きました。 自分は、githubにpushするときにパスフレーズを必要とするようにkeyを作ったのですが、パスフレーズ入力に対応する作りになっていないため、そこで止まってしまうのです。 しかし、ぐぐってみるとmagitのMLで2009年末にはそれに対応するパッチを書いている人がいました。 How to enter ssh passphrase when pushing remote branches - magit | Google Groups http://groups.go
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 本番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基本的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi
■ [rails] Rails3でrails newとgit initをまとめて行う方法 Railsのテンプレート機能を使う。 1. rails3_template.rbみたいなファイルを用意しておく puts "removing unneeded files..." run 'rm public/index.html' run 'rm public/favicon.ico' run 'rm public/images/rails.png' run 'rm README' run 'touch README.mkd' puts "checking everything into git..." git :init git :add => '.' git :commit => "-m 'initial commit'" puts "done." 2. $ rails new myapp -m
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 Git を使ってファイルを編集した場合、それをいったんインデックスに追加(add)してその後コミットってのが基本的な流れになる。なんかいろいろやってると、ちゃんと add したのかどうかわかんなくなることがある。 そういうときは status コマンド使えばいいんだけど、以前エントリ書いた zsh の vcs_info の機能を使うといい感じにプロンプトに表示できるようになるので紹介する。 zshrc の書き方 こんな風に zshrc に書いておけば OK。 autoload -Uz add-zsh-hook autoload -Uz colors color
【Emacs本を書きました】 gitはブランチが強力です。 ブランチは単なるポインタなので、gitではブランチの積極的な利用が推奨されています。 トピックブランチ特に「トピックブランチ」は便利なブランチ利用法です。 作業前に特定の作業用のブランチを切り、無事に実装できたらmasterにマージ(リベース)し、ブランチを削除する方法です。 トピックブランチを切ることで、現在の目標を明確にすることができます。 また、緊急の修正をする場合はあわてずに一旦masterに戻って修正し、再びトピックブランチで作業することができます。 トピックブランチについては http://progit.org/book/ja/ch3-4.html が詳しいです。 トピックブランチを作成するnewtopicとういう名前のトピックブランチを作成するには、以下のコマンドを使います。 $ git checkout -b ne
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く