水風呂のすゝめ 毎日めちゃくちゃに暑い。 ここ数年「およげ!たいやきくん」のように昼間は太陽とオフィスビルとアスファルトの三方向から押し寄せる35℃オーバーの熱に挟まれ、夜になっても最低気温が27℃くらいまでしか下がらない。そんな理不尽な東京鍋の中の暮らしが毎年のことにな…
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 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 trigger a build remotely from Jenkins? How to configure Git post commit hook? My requirement is whenever changes are made in the Git repository for a particular project it will automatically start Jenkins build for that project. In Jenkins trigger build section I selected trigger build remotely. In .git directory, hooks directory is there in that we have to configure post commit file. I am
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リポジトリを登録してビルドする方法について調べたのでメモ。簡単にできると思いきや意外とハマってしまった。。。 確認した環境 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の入力項目を増やすことができるので、ここに別プロジ
ローカルで作成した 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と共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
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 に限らずですが、開発の根幹と言えるコード管理についてお話をしたいと思います。 ご存じの方も多いかと思いますが、Movable Type は現在 github 上で開発が行われています。(セキュリティ・フィックスの際には、社内のgitサーバでひっそりと開発が行われます。)gitに移った事を期にブランチ管理のやり方も変えています。 ちなみに、現時点でのブランチはこうなってます。 % git branch -a remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/develop-backuprestore remotes/origin/feature-assetdr
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く