はてなブログ | 無料ブログを作成しようハリイカの焼売と中華炒め ハリイカをよく、見かけるようになりましたよ。生け簀で、泳いでいたものを一杯購入しました 立派な大きな墨袋や肝は冷凍保存して 柔らかな身は季節のお豆、お野菜と合わせて中華の炒めものに。新鮮なにんにくの茎は刻み、香り高く食欲そそられますね 下足はミンチにし…
Polling must die: triggering Jenkins builds from a git hook
As I keep saying, polling a repository from Jenkins is inefficient; it adds delay on the order of minutes before a build starts after a commit is pushed, and it adds additional loads. It is much better instead to do push-notification from the repository. In this post, I’m going to explain how to do this for Git, which brings this on par with Subversion. The previous best practice of doing this is
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
How to configure Git post commit hook
As mentioned in "Polling must die: triggering Jenkins builds from a git hook", you can notify Jenkins of a new commit: With the latest Git plugin 1.1.14 (that I just release now), you can now do this more >easily by simply executing the following command: curl http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository> This will scan all the jobs that’s configured to check out the s
Jenkins + git: "tell me who you are" error, why does it need to tag?
Just installed Jenkins in Ubuntu 12.04 and I wanted to create a simple build that just clones a project and builds it. It fails because it cannot tag. It cannot tag because it errors out saying "tell me who you are" apparently because I didn't set git settings UserName and UserEmail. But, I should not need to set those, Jenkins is going to just clone the repository, why does it need the credential
Jenkinsで1つのジョブで複数のGitリポジトリをビルドする方法 - wadahiroの日記
Jenkinsのジョブ1つに対して複数のGitリポジトリを登録してビルドする方法について調べたのでメモ。簡単にできると思いきや意外とハマってしまった。。。 確認した環境 Jenkins 1.456 Jenkins Git Plugin 1.1.16 Jenkins Multiple SCMs plugin 0.2 Jenkins Git Pluginのみではできない!? まずはJenkins Git Pluginの設定のみでできないか試してみたのだが、残念ながらこの方法は失敗。一応設定方法を紹介すると以下の通り。 ジョブの設定で、ソースコード管理システムにGitを選択しつつ、Repository URLにGitリポジトリのURLを設定する。 さらに、Repository URLの下にある追加ボタンをクリックするとRepository URLの入力項目を増やすことができるので、ここに別プロジ
remote に branch を push し、remote から clone したリポジトリの branch を変更して push する - basyura's blog
ローカルで作成した branch は remote に push しないと他の人から見えない。remote から clone したリポジトリは何もしなければ master ブランチしか見えない(ように見える)。 remote に branch を push し、remote から clone したリポジトリの branch を変更して push するまでの操作。 ローカルにリポジトリを作成する $ mkdir sandbox $ cd sandbox/ $ git init Initialized empty Git repository in /repos/sandbox/.git/ $ touch README $ git add . $ git commit -m "first commit" [master (root-commit) d31404a] first commit 0
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Movable Type のコード管理についてまとめてみました-Six Apart ブログ｜オウンドメディア運営者のための実践的情報とコミュニティ
やっと暖かくなってきて桜もチラホラと咲き始めましたね。こんにちわ、シックス・アパートの高山です。 さて、今回はMovable Type に限らずですが、開発の根幹と言えるコード管理についてお話をしたいと思います。 ご存じの方も多いかと思いますが、Movable Type は現在 github 上で開発が行われています。（セキュリティ・フィックスの際には、社内のgitサーバでひっそりと開発が行われます。）gitに移った事を期にブランチ管理のやり方も変えています。 ちなみに、現時点でのブランチはこうなってます。 % git branch -a remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/develop-backuprestore remotes/origin/feature-assetdr
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How can I push a specific commit to a remote, and not previous commits?
How do I clean up my Github fork so I can make clean pull requests?
php-webdeveloper.com
Jenkins users - multiple git repos in one job
http://blog.inouetakuya.info/entry/20120826/1345979787
こわくない Git
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
gitで複数のコミットを1つにまとめる | Webシステム開発／教育ソリューションのタイムインターメディア
はじめてのgit - IDEA*IDEA 〜 百式管理人のライフハックブログ