@shiba_yu36 今日の話 はてなブログチームについて 開発フローの課題とその解決 Gitでおこった問題とか。 はてなブログチーム はてなブログのチームである。 5 engineeers 2 designers 170 PR per month 1300 commits per month 45 releases per months on GHE 開発速度を保てている 開発フローの問題発生開発フローの改善 タスク管理 レビュー リリース 開発の流れ issue登録 アサイン issueに対応するbranch作成 など ブランチ運用 master(本番と同一) develop(リリース可能ならmerge) feature branch(機能ごと) masterにdevelopをmergeし、developに各featureをmerge タスク管理 REDMINE GHのissue r
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
仕様や画面は現行バージョンと異なる可能性があります。 Backlogの最新版についてはこちらからご確認ください。 皆さんこんにちは。よく訓練されたIntelliJ IDEA信者の中村です。 最近はヌーラボメンバーも増えてきて、メンバー間でコミュニケーションを取る機会が今まで以上に増えてきました。私はエンジニアですのでソースコードで会話することもよくあるのですが、Backlogで管理しているソースコードに対して、もっと手軽にコミュニケーションを取りたいなとは常々考えていました。 というわけで、今日はBacklogのGit上のファイルを簡単に確認するためのTIPSを3つほど紹介したいと思います。 ファイルの特定箇所を選択してURLで共有 まずは、意外に気づいていない人もいるかもしれない、小ネタの紹介です。 Backlogにpushされたファイルは、Backlog上のリポジトリブラウザで表示する
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
I'm stuck behind a firewall, so I have to use HTTPS to access my GitHub repository. I'm using Cygwin 1.7.7 on Windows XP. I've tried setting the remote to https://username@github.com/username/ExcelANT.git, but pushing prompts for a password, but it doesn't do anything once I've entered it. https://username:<password>github.com/username/ExcelANT.git and cloning the empty repository from scratch, bu
Gerritを使っているが大きなcommitをpushするとなかなか反応がなくていまいちだなぁと思っていた。仕方ないのでGerritのプロセスにstraceでアタッチしてみるとひたすらディスクI/Oを繰り返している模様。しかも8kB単位で。 こら遅いな…と思ったのでいろいろ調べていたらJGitとやらの設定を変える方法が存在する事がわかったのでこいつをいじってみたら改善した。せっかくなのでここに晒しておく。 [core] packedGitWindowSize = 4m packegGitLimit = 12g streamFileThreshold = 1g packedGitWindowSizeはぶっちゃけ適当。RAMが48GBのマシンでjenkinsでGerritへのpushをまわしており、同時に3つのジョブを処理できるようにしているから1/3よりもちょっと少ない数字にpackedGi
GitListはGithubライクなGitリポジトリビューワーです。 Githubのリポジトリビューワーは日々進化しており、かなり格好いいと思うのですが、Githubにリポジトリがないと見られません（当たり前ですが）。しかしGitListを使えばあれに似たUIでリポジトリを閲覧できるようになります。 インデックスです。 リポジトリの中に入りました。ディレクトリブラウザになっています。 テキストコンテンツは内容が閲覧できます。 バイナリの場合はRawをクリックします。 コミット一覧です。 コミット詳細です。Diffも奇麗です。 解析結果です。拡張子ごとのファイル数も見られます。 フィード機能があります。 GitListは複数のリポジトリ、ブランチ、タグのサポート、コミットログ、差分表示、拡張子ごとのシンタックスハイライト表示、リポジトリ解析、フィード配信と言った機能があります。GitHubラ
旧版のレッスンは更新を終了しており、現状と異なる場合があります。サポートも終了しておりますので、最新版への移行をお願いします。
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ジット？俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？と思い、 今回はgit入門の入門、gitってなんだ？というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？私はあります…
Still need help? The Atlassian Community is here for you. Ask the community You can specify repositories at the following levels in Bamboo: global – repositories are available to all plans in Bamboo.plan – repositories are available to all jobs in the Bamboo plan.job – repositories are available to all tasks in the Bamboo job.The recommended approach is to set up linked source repositories at the
2012年05月08日 12:00 カテゴリ もうPSDは無くさない！デザイナー版GitHubのPixelapseはうっかりデザイナーの救世主！ Posted by takejune No Comments No Trackbacks ●この記事のターゲット ・iOSアプリのデザインをしている人・デザイナーと名のつく職種の人・仕事でpsd,pngファイルを作る人・その中でもうっかりした性格の人 つまりこんな人。 ●404 PSD Not Found 全国のPhotoshop使いの皆さんこんにちは。 気がつけば、1999年にPhotoshopを使い始めて13年くらい経ちますが何故でしょう？ PSDを無くしてしまうことがたまによくあります。 どこに保存したか分からなくなる、なんてことは今時流石にないんですが(spotlight超便利) よくやってしまうのが、別ファイルとして保存すべき時に上書
GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。 GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。 記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。 プルリクエストはなるべく早く起こす プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメ
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 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
April 12, 2023 New community features for Google Chat and an update on Currents Currents Google Chat Other Note: This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Google+ for users with personal Google accounts, please see this post. Last year, we announced plans to wind down Currents, to focus efforts on community exper
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
