|DMM inside
今日からはじめるGitHub ~ 初心者がGitをインストールして、プルリクできるようになるまでを解説 エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ソースコードの管理はできていますか? ファイルを修正するときに、修正前のソースコードをhoge.php.bakのようなバックアップファイルとして残し、開発環境をゴミだらけにしていませんか? エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ここではGitの詳細な仕組みには触れません。GitやGitHubを利用したことのない人が、Gitを
概要 Git・GitHubを利用したシンプルで強力なワークフローであるGitHub Flowを図にまとめました。 GitLabでも利用可能なFlowです。GitLabの場合は Pull Request を Merge Request に読み替えてください。 前提 実際にGitHub Flowを実践したことはありません。(2014/06/12時点) これからチームで導入予定で、メンバーとワークフローを共有するために図を作成しました。 ワークフローの誤りなどご指摘いただけると幸いです。 アクティビティ図をベースに作成してありますが、厳密な記法よりも 相手に伝わればいいかな、という点を重視しています。 基本原則 masterブランチは 常時デプロイ可能 である 機能追加、バグフィックスなどは 説明的な名前のブランチ をmasterから作成する 機能追加の例: add_user_notice (ユ
はじめに さまよえるアラフォー男子 @artifactsauce です。 突然ですが、弊社は「外資就活ドットコム」というWebサービスを開発・運営している会社です。サービスイン当初はイケイケガンガンで高速開発・高速リリースをうたっていましたが、開発者が増えるにしたがって様々な問題が発生してきました。今回はプロダクトのリリースにまつわる問題を解決するために弊社で採用した開発ワークフローについて紹介します。 どんな問題が起こっていたのか? Capistranoによる自動デプロイは実現していた我々ですが、それですべてがうまくいったわけではありませんでした。具体的には以下の様な問題が発生していました。 デプロイできる環境を用意するのが面倒である。 各デプロイ担当者がデプロイツールをインストールする必要がある。 デプロイツールを更新していない場合には失敗する。 デプロイ対象サーバーにデプロイ担当者の
【2015/07/16 追記】優れた dotfiles を設計する - TELLME.TOKYO この記事では書かなかった全体のロジックについて書きました Dotfiles Driven Development dotfiles とは Unix 系 OS で俗に言う設定ファイルのことです。.vimrc や .zshrc など、設定ファイルの多くは隠しファイルとしてファイル名の頭にドットがつくことからそう呼ばれています。 ほとんどのエンジニアは CLI 環境での開発は避けては通れないものに思います。CLI 環境は「黒い画面」として敬遠されがちで、CLI になると格段に作業効率がダウンする人も少なく無いです。その作業を効率化するキーとなるのは、設定ファイルの習熟度にあると思います。GUI 開発環境と比べてこちらはテキストベースでカスタマイズできるため、究極まで自分好みに合わせることが可能です。
元々GitHubのAtomエディタのために開発されたデスクトップアプリ作成用フレームワーク「Electron」。HTML/CSSといったWeb系技術を使って、クロスプラットフォームのデスクトップアプリを開発可能なため、多くの開発者の注目を集めています。 本日紹介する「Photon」は、このElectron用の便利なコンポーネントを多数収録したUIツールキットです(GitHub、Hacker News)。 ツールバー、タブ、ナビゲーション、リスト、ボタン、フォーム、テーブルといった、GUIアプリ作成に必要なさまざまなコンポーネントを、アプリケーションに素早く組み込むことができます。コンポーネントの見た目もOS X風でクールです。 以下ご紹介。 バー ヘッダーとフッターを組み込むことができます。 バーとアクション バーにボタンを設置してアクションを定義することもできまうs. バーとタブ タブを
ある日、 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 に沿って開発する 基本
今回のソリューション:【GitHub(ギットハブ)】 〜「GitHub」でソースコードを社内・社外に公開し、オープンなコラボレーションを実現した事例〜 数々のサービスを生み出し続けるエンジニアリング集団、株式会社サイバーエージェント。そのエンジニアリング文化の中心には、「GitHub」を活用したオープンなコラボレーションがある。 同社ではプロダクトのソースコードは可能な限り全社公開すると同時に、 「スターインセンティブ制度」というリポジトリのスター数に応じたインセンティブを与える制度により、自身の書いたコードを社外へ公開することを推奨している。 ▼そもそもGitHubって何?という方はこちらの記事もどうぞ! チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】 ソースコードを可能な限り公開していくという流れは、ITベンチャーのみならず世界的大企業にも派生
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request(プルリクエスト)機能を使ったことはありますか? GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork(コピー)してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
今年もHTML5 Minutesに登壇してきました。こんにちは、先生です。 当日は「フロントエンド開発スピードをあげるための環境を作ってみた話」をしてきました。 今回はその環境を使ってみるまでの手順を書いていきたいと思います。 必要なものをインストール NodeJS Gulp WebPack Bower PhantomJS NodeJSとGulpのインストールは過去の記事「Gulp.js入門 – コーディングを10倍速くする環境を作る方法まとめ」をご覧ください。 WebPackのインストール WebPackはさまざまな形式のモジュールを静的なファイルにまとめて出力してくれるツールで、拡張性が高く最近好んで使っています。 WebPack http://webpack.github.io/ インストールはnpmを使って簡単にできます。 npm install webpack -g ※ macは
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。(色んな使い方があります) 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった!まさにこれだ!と思いました。 よし、コードレビューをしよう! 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい! search_word_arrays = param
git clone https://github.com/kakakikikeke/cookbooks-jpackage.git したときに git add git commit で最後の git push でエラーになる ■出るエラー error: The requested URL returned error: 403 Forbidden while accessing https://github.com/kakakikikeke/cookbooks-emacs.git/info/refs fatal: HTTP request failed ■解決作成 git remote set-url origin https://kakakikikeke@github.com/kakakikikeke/cookbooks-jpackage.git git push -u origin ma
お疲れさまです、trebyです。 もうだいぶ日付が変わりそうな勢いですが、Git Advent Calendar 2014の23日目を担当させていただきます。 Gitを業務で使い始めて早2年、だいぶ慣れてきた感じがありますが、それをアウトプットする機会があるかといえばなかなかありません。せいぜいたまに同僚に聞かれるくらいでなんかもったいない感じがあります。 そこで今日は私個人がgitを使って仕事をする上でどういうフローしているかなーということを改めて文字にアウトプットしてみたいと思います。ご参考にしていただくなり、ツッコミしていただくなりしていただけますと幸いです。 なお、本投稿において想定するツールはGit、ホスティングサービスはGitHubですが、多分その他のサービスでもいけるのではないかと思います。 開発準備 「新しくチームに配属された!」等のシチュエーションを想定しています。 開発
サイバーエージェントの平木さん(@Layzie)、原さん(@herablog)、紫竹さん(@79yuuki)との共著で、「Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール」という本を執筆しました。 10/24、インプレスジャパンさんから発売予定です。昨日無事校了との連絡がありました。 どんな本?「Web制作者のための***の教科書」シリーズに連なる本で、エンジニア以外の人にもGitHubを使ってもらうための入門書です。Gitの基本的な概念と使い方、CUIとGUIでの操作、GitHubの機能とユースケースなどを、やわらかくわかりやすく紹介しています。 詳細は発売してからのお楽しみ…ですが、バージョン管理なにそれ?黒い画面怖い!な人でもGitHubを使ったチーム開発に参加できるよう、わかりやすく解説しています。ご期待ください! 執筆に至った経緯GitHub勉強会
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
{"serverDuration": 17, "requestCorrelationId": "f12953c41087422ba55291f4cd3ff3b9"}
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く