GitHub EnterpriseをAWSで使おう – マネジメントコンソール編 | DevelopersIO
一つ一つ登録することも可能ですが、数が多いのでワイルドカード形式(*.<hostname>)でDNSに登録されることをオススメいたします。awscliで登録する場合は以下のようなJSONファイルを用意して先程と同じようにレコードセットを作成すればOKです。 { "Comment": "Create record sets for GHE", "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "_YOUR_A_RECORD_", "Type": "A", "TTL": 60, "ResourceRecords": [ { "Value": "_YOUR_GHE_PUBLIC_IP_" } ] } }, { "Action": "UPSERT", "ResourceRecordSet": { "Name": "r
これだけは押さえておきたいGitHub Flowの基礎 | Think IT（シンクイット）
連載第三回は「これだけは押さえておきたいGitHub Flowの基礎」と題して、GitHubを使う上での基本的な部分について解説したいと思います。 と言っても、Git自体の利用方法については既に書籍もたくさんありますし、Web上にも記事が多数ありますので、ここでは特に触れないことにします。これからGit自体を学習する場合に有用なリンク集は、下記のブログ記事にまとめてありますので参考にしてください。 GitHubのトレーニングに役立つリンク集 今回のこの記事では、GitHub Flowについて解説します。 GitHub Flowについて改めておさらい GitHub Flowというのは、GitHub社が提唱している効果的なワークフローのことです。この言葉は2011年に発表されたこの記事が起源だと思います。 当時Web上で話題になったGit Flowというワークフローに対して、もう少し簡単で理解
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
GitHub 入門 - Qiita
はじめに 現状 仕事ではSubversionを使用。仕事とは関係なく、プライベートでGitHubを使ってみたい。 GitHubに登録してみたはいいものの、1年くらい放置。 今さらですが、勉強のために、GitやGitHubについてまとめてみようと思った。（自分のメモ用でまとめたので、もし間違ってるところとかおかしいところがあったら教えていただけると助かります） Git とは バージョン管理を行うためのツール。 リモートリポジトリ(共有リポジトリ)とローカルリポジトリを使い分けて開発を行う。 2005年に誕生。もともとはLinuxカーネルのソースコード管理のために、リーナス・トーバルズによって開発された。 売り → 高速。作業時にサーバ接続が必要ない。等 GitHub とは Gitを利用した、リモートリポジトリ（共有リポジトリ）を提供しているwebサービス。 ご利用には登録が必要。無料プランの
チーム開発での github の protected branch と status check を使った安定的運用
はじめに 以前は github で直接的に git push --force を禁止する方法はありませんでした。誤った force push によりコミットが失われる事故を防ぐため、GitHub上の大事な中央ブランチをgit push --forceの恐怖から守るgit hookスクリプト のようなノウハウが用いられてきました。 最近では、protected branch の機能が導入・拡充され、通常の github の機能だけで安全に運用できるようになってきています。また、チームのリポジトリで時々必要となる、安定性のためにマージできる人を限定することもできるようになりました。 Protected branches and required status checks Protected Branches Improvements Update to Protected Branches
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
Github on BigQueryを使ってgoでよく使われるpackageを調べる - Qiita
Github on BigQueryとは Google Cloud Platform Blog: GitHub on BigQuery: Analyze all the open source code にあるように、Githubにある全てのオープンなソースコードに対してBigQueryからクエリがかけられます。すごい。 Goで使われているpackageを調べる 以下にあるサンプルに、よく使われるgoのpackageを調べるクエリが載っている。 GitHub Data | BigQuery | Google Cloud Platform 例ではTop10だが、30にしてやってみた。 以下のクエリ例では sample_xxxというデータを間引いた小さなテーブルを参照してますが、結果は sample_を取り除いたテーブルに対して実行しています。 クエリ SELECT REGEXP_EX
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
中の人に聞いたGitHub flowの本当の使い方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
GitHubとGitのおさらい
みなさん、はじめまして。GitHubの池田と申します。GitHubやTwitterのユーザーアカウントは@ikeike443です。GitHubではソリューションエンジニアという役割で、アジア・パシフィックを担当しています。我々GitHubは2015年6月に日本法人を設立しました。日本企業のソフトウェア開発の効率化のお手伝いをしています。 今回は数回にわたって、GitHubについて、その本質や我々が実現しようとしている世界観、また意外と知られていないGitHubの機能についてご紹介していければと考えています。 GitとGitHubとは何か 今さら感はありますが、ここで改めてGitおよびGitHubとは何かについて簡単におさらいしておきましょう。 よく混同されている方がいらっしゃるのですが、まずGitとGitHubは別のものです。 Gitは2005年にリーナス・トーバルズが開発した分散バージョ
GitHubのトレーニングに役立つリンク集 - ikeike443のブログ
※最初に断っておきますが、この記事はもちろん、このブログ全体もそうですが、私の個人ブログであって、会社の公式見解とは一切関係ありません 自分のチームや会社でGitHubを使いたいんだけど、チームメンバーにGitHubを使ったことのある人が自分以外いないよ、みたいなケースがあるかと思います。 そんな時に役立つリンク集を紹介しておきます。 英語のリソース GitHub Guides Mastering Markdown Mastering Issues Understanding GitHub Flow GitHub Training YouTube channel GitHub Services curriculum "Kit" GitHub for Developers GitHub for Everyone Pro Git 2 eBook GitHub Git Cheat Sheet P
GitHub の Dockerfile から Docker Image を自動ビルドする設定手順 - うなの日記
Docker Hub の Automated Builds を使うと、GitHub または Bitbucket の Dockerfile の変更を検知して、Docker Image を自動ビルドすることができます。 レポジトリへのコミットを検知して、Docker Hub の Docker Image を自動でビルドします。 タグやブランチの追加を検出して、自動でタグ・ブランチ名をTAGとした Docker Image を作ることも可能。 一通り設定を試してみたので、メモです。 unagenau/docker-jiji2 に配置している Dockerfile を自動ビルドするようにしてみました。 Docker Hub のアカウントがない場合は、こちらから作成してください。 1. Docker Hub のアカウント と GitHubアカウントとを連携させる まず初めに、Docker Hub の
Git(GitHub)おじさんに俺はなるBefore Git, After Git - karaage. [からあげ]
Git(GitHub)おじさん 何かを布教することをネットの一部では「**おじさん」というみたいです。最近、あまり得意ではないのですが、色々な事情で仕事でソフトをつくることが多くなり、その関係で何周か遅れでGitとGitHubを使うようになりました。そして、今頃その素晴らしさに感動して打ち震えている（大げさ）ので、私もGit(GitHub)おじさんになってみようかと思います。 といっても、私が今更Git(GitHub)の何が素晴しいかを語ったところで…というのもあるのと、何よりうまく伝えられる気がしないです。何故ならそもそも自分がまだそんなにわかってないし使いこなせてない。なので、今回はGit(GitHub)を少し使ってどのようなことが変わった（良いことがあった）のかという具体例をGit使用前(Before Git)、Git使用後(After Git)として列挙した後、オススメのサイトをま
![Git(GitHub)おじさんに俺はなるBefore Git, After Git - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/28b8f925dae6684301474074b14a9368d7a40a86/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F27c68e72678686607842b71f4625c45f6d087ee3%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fecx.images-amazon.com%252Fimages%252FI%252F51PjpAUHZBL.jpg)
フィードフォースではRubyのrpmをGitHubに自動リリースしています | feedforce Engineers' blog
皆様いかがお過ごしでしょうか。tjinjinです。もうすぐ2015年も終わりますね。皆様にとってステキな年になったでしょうか。私にとってステキな年だったので、来年はもっと熱い年にしていきたいなと思っているところです。 本日はRubyのrpmパッケージ作成を自動化しましたのでご紹介します！ ちなみにすでにRuby-2.3.0のrpmパッケージを作成しました！！！ https://github.com/feedforce/ruby-rpm/releases/tag/2.3.0 As Is 弊社内ではこれまでRubyの新しいバージョンがリリースされるたびに有志が、手動でパッケージを作成してGitHubのreleaseページに公開するという運用をしておりました。慣れればなんてことはないのですが、初めて行う場合は若干面倒だなという感じる作業でした。フローに起こすと下記のようになります。 Rubyのリ
Github で Fork してから Pull Request をするまでの流れ | けーこ in サンフランシスコ
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
こんにちは、freee でエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?（なぜこうしたか） こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を２つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR
静的HTML公開フローをサーバレスでDevOps！(Github,CircleCI,AWS S3) 前編 - Qiita
コーポレートサイトなどの静的サイトを、Github+CircleCi+S3webhostingでサーバレスDevOpsを実現。 主な利点 ・Github操作のみでデプロイを自動化。 ・サーバレスなのでサーバ運用不要。 ・**ステージングサイトには閲覧制限(許可IP制）**を設けることで、外部会社との連携も安全。 #構築内容 AWS S3 webhosting構築 Githubリポジトリ作成 静的ページを用意 HTML+CSS(bootstrap) CircleCIでのオートデプロイ オートデプロイテスト +αでフォームサイトはlambda,cognitoで実装 6は後編で掲載予定。 #想定フロー 各自ローカル環境でHTML編集。Githubで管理。 stagingブランチへのgit pushでステージングサイトへ自動デプロイ (ステージングサイトは自社サイトのみ閲覧可能） pullreqし
GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
GitHubの技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ
GitHub Classroom
GitHub Classroom Automate your course and focus on teaching Managing and organizing your class is easy with GitHub Classroom. Track and manage assignments in your dashboard, grade work automatically, and help students when they get stuck— all while using GitHub, the industry-standard tool developers use. Sign in and get started Make grading painless. Save time by using automated testing to grade a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
