You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
みてねではデザインデータの管理にGit LFSを使用しています。 昨年から運用を開始したのですが、データ管理が改善され、フローも安定して回って来たので紹介します。 Git LFSとは？Gitで画像などのバイナリファイルを扱うための拡張機能Sketch, Photoshop, IllustratorなどのデザインデータもOKGitHubの単一ファルの上限である100MBを超えたデータサイズのファイルを扱えるファイルサイズの上限が変わる以外は通常のGitと同じです。 Git LFS 事前準備・設定リポジトリの作成github.comでデザイン用のリポジトリを作成します。 用意できたらリポジトリのSettingsでLFSを有効にするだけです。 みてねでは現状 2 data packs（月10ドル）使っています。 Storageが足らなくなっても Purchase more からポチるだけなので楽
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
以前、われわれは、いかにして変更点を追うかという内容で発表しましたが、 その時書き忘れてたことの補足的な記事です。 GitHubでのChangeLogの扱いについての話 このスライドは、ChangeLogから詳細を追う方法を知ることで、転じて分かりやすいChangeLogを書くことができるようになるのではという話でした。 スライドでは、ChangeLogの追い方としてBabel 5.3.0を例としてどうやって、このChangeLogから詳細を見ていくかについて話していました。 このBabelのChangeLogの問題点としては、変更点については書かれているのですが具体的にどういう変更だったのか、また関連するIssue/Pull Requestへのリンクがないため、ChangeLog単体では詳細がわからないという問題があったので例としていました。 Babelを例に見ると、変更した内容を1行の
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか？私はダメです。ごめんなさい。（´・ω・｀） WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model（有志の方による日本語訳）にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
今から1年ほど前に、自分でお気に入りのブログ環境を構築する記事が話題になっていて、それを読んだ時から、自分用のブログ環境を作りたいと思っていた。 俺の最強ブログ システムが火を噴くぜ - てっく煮ブログ 俺の最強ブログシステムも火を噴いてたぜ - Webtech Walker 当時はそれどころではなかったこともあって、なかなか着手できずにいたんだけど、今年の7月頃から作り始めて、最近そこそこ希望通りの形になったので、まだやり残しはたくさんあるけれど、一旦ここで一区切りということでその内容を記事にしてみる。 この手の話では静的なブログツールが主流で、当時はJekyllやOctopressが流行っていて、最近ではMiddlemanを使うのが流行りつつある印象。でも自分が作ってみたかったのは、Webサービスを開発するのと同じフローで、ブログも更新できるようにするというもの。そのフローとは、表題の
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
A successful Git branching model » nvie.com git-flow によるブランチの管理 - O'Reilly Japan Community Blog git-flow cheatsheet Git flowの活用事例 git-flowというものを使うらしいのでちょっと調べてみたなど - ゆうなんとかさんの雑記帳的な。 git flowとgithub flowざっくりまとめ | KentaKomai Blog Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）：いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - ＠IT ボブとアリスのgit-flow(和訳) - hidecheckの日記
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
> ls ~/bin ab.rb* gita* pod2pdf* check_config.sh* gitolite@ repo* cpan-chm.pl* hakobe-pmsetup* reposh.rb* cpan-tags.sh* hatena-tags* ri* cpan-update.sh* icssh.scpt screen* cron_minicpan.sh* icssh.sh* subl@ efm_perl.pl* irb* testrb* fork.sh* lingr-ircd.pl* time_bell.rb* forwarding.sh* list_config.pl todo_progress.rb* gistp@ memo* touch_pm* git-branch-recent* memo.rb* tov* git-grep-submodule* myd.sh
We’re getting things ready Loading your experience… This won’t take long.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
