GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita
hub(1) を使うと簡単にできる。 追記1: コメント欄より。 Issue を Pull Request にすると label が外れる（Pull Request には label がつけられないので） Asssign 状態は変化しない 追記2: この機能は hub コマンドの master ブランチでは削除されている（おそらく次期リリースで無くなる） GitHub も将来 API (v4) からこの機能を無くすつもりのようだ。参考 例: pullreq ブランチから master ブランチに対して Pull Request を送りたいが、その際に既存の Issue#123 にコードを添付したい $ git checkout -b pullreq $ commit; commit; commit; $ hub pull-request -i 123 https://github.com/
古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 - 学習する機械、学習しない人間
直前のコミットをやり直したいときは、git commit --amend を使うと可能だ。そして、さらに昔のコミットをやり直す(書き換える)ときは、git rebase -i を使う。 git rebase -i を使うと、引数にとったコミット以降のコミット系列に対して、コミットの書き換え、削除、統合を行うことができる。 次の課題をこなすことを目標としながら、git rebase -i の動作を追っていこう。 課題「最新のものから古いほうへ3つ分のコミット(HEAD, HEAD~1, HEAD~2)のログメッセージを書き換えたい」 git rebase -i の起動 まず、変更したいコミットで一番古いものより一つ古いものを引数にして、git rebase -i を実行する。この場合は HEAD~3 である。 $ git rebase -i HEAD~3 すると、エディタが rebase コ
あなたが知らない git svn の世界 | Act as Professional
みんながいまだにsvnを使い続けるので、自分だけでもgitを使って幸せになってやる。って人のためのガイド。ツールや環境がsvnでがっちりつくられているとしかたないですねー。という状況の人向け。そこまでしてgitを使うのは早いし柔軟だから。マージもサクッと終わるし。 git svnって？svnをリモートリポジトリとして、ローカルではgitを扱うためのもの。gitインストールすれば大抵はいってるけど、macportsだったらこんな感じでインストール。 $ sudo port install git-core +svn gitローカルリポジトリをつくるgitは分散リポジトリなので、まずはローカルにリポジトリを持つところからスタート。 $ git svn clone -s http://svn.server/path/projectこれでsvnリポジトリのcloneをローカルにつくる。これでmas
git svn rebase で conflict したときの解消手順 - 日曜プログラマがダラダラ書く
メモ。 $ git svn rebaseしたときに、自動的にマージできず、 CONFLICT (content): Merge conflict in path/to/conflicted_fileWhen you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/trunk: command returned error: 1 こんなメッセージが出たときの解消手順。 status を確認するとこん
git-svnでリモートリポジトリのブランチにコミットする - walf443's blog
ふつうに使ってるのですが、そういえばメモしてなかったなーと思い、なんとなくメモしておく。 ちょっとBKなんですがもっとスマートなやり方はないものか。。。 $ git checkout -b working_branch $ git svn info # => trunkのURLになる # 何かしら作業する $ git commit -a $ git commit -a $ git commit -a # svnにremote branch 作る $ git svn branck new_remote_branch # svn copy trunk branch とほぼ同様 $ git checkout new_remote_branch -b worknig_branch_remote $ git svn info # => branches/new_remote_branchのURLが出
「VC（バージョンコントロール）パッケージの基礎」(菅原泰樹) — ありえるえりあ
「VC（バージョンコントロール）パッケージの基礎」(菅原泰樹) 「Emacsのトラノマキ」連載第七回「VC（バージョンコントロール）パッケージの基礎」 Emacsのトラノマキがなんと連載7回目をむかえてしまいました．思った以上にEmacsを覚えたいという人が多いということなんでしょうか．すばらしい世の中です．さて，今回はEmacsのVC(バージョンコントロール)パッケージについて書いていきます． ※本稿はEmacs23のVCについて書いています．Emacs22の場合はキーバインドが違っていたり，機能がなかったりする場合があります．そんなときは各自describe-bindingsするなどして臨機応変に対応するようにして下さい． VCとは VCはEmacs上で各種バージョン管理システムを統合的に扱うパッケージです．Emacs23ではRCS, CVS, Subversion, Git, Mer
2010-04-13 - Ruby 開発者のための git 講座 - ChangeLog 編
不定期連載の git 講座ですが、今日は Ruby を開発する人のための tips っぽいです。 git-merge-changelog Ruby で git を使ってローカルで開発していると、ChangeLog が毎回衝突して面倒です。ChangeLog の 衝突なんて冒頭でしか起きないのだから、それ専用の merge driver を書けばいいだけの話なのですが、書くのも面倒なので探すとすでに git-merge-changelog というものがあるようです。というわけで、入れてみたら便利だったのでここに紹介します。 FreeBSD の人は devel/git-merge-changelog に入りました。 依存関係 DEPENDENCIES に依存関係は書いてあるのですが、一つずつ調べるのも面倒でしょうし、この日記の読者はすでに CRuby のビルド環境は整えているでしょうからその差
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
gitサーバーをubuntuに構築してgit://からアクセスできるようにする手順メモ - AorBorF
gitサーバを自宅のubuntuマシンに立てたのでその手順をメモ ubuntuにgitをインストール sudo apt-get install git-core ubuntuにローカルリポジトリを作成 一応ubuntuマシンは完全なサーバではなく、開発マシンとしても使用するのでローカルにリポジトリを作成する。 mkdir -p /home/amacou/repos/tstrepos cd /home/amacou/repos/tstrepos git init touch init git add . git commit -m "init" ubuntuに公開用リポジトリの作成 sudo mkdir /var/repos cd /var/repos git clone --bare /home/amacou/repos/tstrepos ./tstrepos.git touch tstr
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
TDDでFluentdのフィルタプラグイン書いてgemにできるようにしてみた #fluentd - ぽにくすじゃないだいありー
fluentd, プラグイン, 開発Fluentdのプラグインって割と簡単に開発できるので、ローカルで動かす程度ならさっくり作るのもありなんだけど、gem化もかなり簡単でした。参考にしたのは id:tagomoris さんの fluentdのためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場。わかりやすい！実際にやってみていくつか気づいた事をまとめる セットアップまずは上記記事に従ってセットアップを行う。もちろん名前は自分が開発したいプラグイン名を元に書き換えていくことになる。 bundle gem fluent-plugin-hogehoge する時には、要らないファイルがステージングされてる元々 bundle gem で作成されるファイル構成と fluent-plugin でのファイル構成は違うため、bundle gem した時点で既に git
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
＠IT：Linux Kernel Watch 5月版 BitKeeperからgitへ、ソースコード管理ツール大変更（2/2）
5月版 BitKeeperからgitへ、ソースコード管理ツール大変更 上川純一 日本ヒューレット・パッカード株式会社 コンサルティング・インテグレーション統括本部 2005/5/31 FUSEをユーザー権限でどう扱う？ 先月でも紹介した、ユーザー空間のアプリケーションでファイルシステムを提供するFUSE（Filesystem in Userspace）を利用すると、ファイルシステムを一般ユーザー権限でマウントできるようになります。 便利そうな機能ですが、問題がないわけではありません。例えば「/tmpに何か別なものをマウントできるようになるのはまずいのではないか」という意見がありました。FUSEの用途としてsshfsなどが考えられているため、一般ユーザーがマウントしたとしても、ほかのユーザーは見ることができない機構が必要だ、という意見も出ています。また、ユーザーがファイルを作成でき、適当な権
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
github に登録する公開鍵ファイルを id_rsa.pub じゃない名前で使いたい→ ~/.ssh/config で解決 - @kyanny's blog
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git flowの活用事例
Git でローカルの変更を元に戻す - present
http://www.machu.jp/posts/20100705/p01/