Introducing security alerts on GitHub
ProductSecurityIntroducing security alerts on GitHubLast month, we made it easier for you to keep track of the projects your code depends on with the dependency graph, currently supported in Javascript and Ruby. Today, for… Last month, we made it easier for you to keep track of the projects your code depends on with the dependency graph, currently supported in Javascript and Ruby. Today, for the o
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
先日開催されたAWS Summit Tokyo 2017、わたしもいくつかセッションを聴講してきたのですが、「DevSecOps on AWS - Policy in Code」というセッション1にてgit-secretsというツールが紹介されていました。 awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories これ以外にも、いくつかのセッションで言及されていたと思います。 git-secretsのことは以前から聞いてはいたのですが、自分自身があまりコードを書く環境にいなかったので、良くないとは思いつつも今まであまり気にしていませんでした。 ただ、AWSアクセスキーの漏洩が原因と思われる話を聞く機会はなかなか減りませんし、考えてみれば自分でも、AWSクレデ
GitHub Flavored Markdown Spec
This formal specification is based on the CommonMark Spec by John MacFarlane and licensed under 1Introduction 1.1What is GitHub Flavored Markdown? GitHub Flavored Markdown, often shortened as GFM, is the dialect of Markdown that is currently supported for user content on GitHub.com and GitHub Enterprise. This formal specification, based on the CommonMark Spec, defines the syntax and semantics of t
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
GitHubがDGitによって信頼性，可用性，性能を向上
GitHubがDGitを密かにロールアウトした。DGitは“distributed Git”の略で，GitHub使用時の信頼性，可用性，性能の向上を目的としてGit上に構築された，分散型の新しいストレージシステムだ。 DGitは，独自に選択された３つの異なるサーバ上に，すべてのリポジトリのコピーを３つ保持することでGitの分散性を活用する，アプリケーションレベルのプロトコルだ。このシンプルなアーキテクチャには信頼性や可用性，性能面で直接的なメリットが数多くある，とGitHubには述べられている。 リポジトリをホストしている３つのサーバが相互に独立していると仮定すれば，それらがすべて同時に使用できなくなる可能性は極めて低い。 ユーザの要求を３つのサーバ間でロードバランスすることが可能。要求の主体は参照であるため，３つのサーバ間での同期は必要なく，すぐに処理することができる。これにより，台数通
GitBucketのユーザインターフェースの変更について - たけぞう瀕死ブログ
2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。 それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。 1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。 2点目については（ユーザインターフェースに関する権利については諸説あるようですが）、GitBucketが「GitHubク
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
GitHub おじさん スターターキット - Qiita
この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の３つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ
GitHub にパスワードとかセンシティブなファイルを push してしまったときの対処法 - Qiita
.gitignore し忘れて他人に見えちゃマズいファイル（パスワードをベタ書きしたファイルや AWS_SECRET_ACCESS_KEY を書いたファイルとか）を git commit しちゃった！そんなときは すればすぐ何もなかったことにできます。 が！そこで気付かずに GitHub へ git push してしまった！こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、パスワードの書き換えやトークンの無効化を施しましょう。 （この時点でもう
GitHub - fluent/fluent-logger-java: A structured logger for Fluentd (Java)
Fluent Logger for Java Overview Many web/mobile applications generate huge amount of event logs (c,f. login, logout, purchase, follow, etc). Analyzing these event logs can be quite valuable for improving services. However, collecting these logs easily and reliably is a challenging task. Fluentd solves the problem by having: easy installation, small footprint, plugins, reliable buffering, log forwa
slf4j+fluentd - kinjouj.github.io
まぁタイトルで分かるようにslf4jで送出されるログをfluentdにぶん投げるネタ fluentd.conf <source> type forward </source> <match slf4j.**> type file path fluentd.log </match> まぁ単純に build.gradle apply plugin: "java" apply plugin: "eclipse" repositories { mavenCentral() } dependencies { compile "org.slf4j:slf4j-api:1.7.5" compile "org.fluentd:fluent-logger:0.2.11" } slf4j-apiとfluent-loggerなライブラリが必要なので(ry StaticLoggerBinder.java slf4
GitHubのリリース機能を使う - Qiita
Release機能について GitHub上で開発したソフトウェアをそのままGitHub上で配布したい場合や、リリースごとのChangelogの見せ方をこだわりたい場合には、GitHubのリリース機能を使用することが出来ます。 Release機能の使い方 前提 自分のGitHubリポジトリを持っていること Gitリポジトリにtagが付けられていること Releasesページ GitHubのリポジトリのページにあるReleasesページへのリンクには、今まで付けたタグの一覧が表示されています。 自分がリポジトリのOwnerであれば、このReleasesページの右上に、Draft a new releaseというボタンが表示されております。 (Collaboratorの場合にも同様に出るかは分かりません…) Edit releaseページ Draft a new releaseボタンを押すと、下
GitHub を Maven 公開リポジトリにする (Gradle 編) - bluepapa32’s Java Blog
最近は Gradle がとってもお気に入りなので プラグインの開発も少しずつ行っているのですが、 折角作成したプラグインやライブラリも Maven リポジトリで公開しないと利用しづらいので どこか公開できる場所がないか探していたところ Github を Maven 公開リポジトリにする という記事を見つけたので ソース管理と合わせて GitHub に Maven リポジトリを作成することにしました。 ただ無料版だと300MB しか利用できないので容量がちょっと心配だったのですが id:kimukou_26 さんのアドバイスによりあまり容量を気にする必要はないことがわかったので GitHub にしました。 それによく考えてみれば そもそも 300MB もコードが書けるほど時間に余裕はないですし... 上記の記事では Maven が使われていましたが、今回は Gradle を利用することもあり
GitHubで複数アカウントを使う場合のSSH configファイルの設定
GitHubにsshでアクセスする場合、使用する鍵ファイルをsshのconfigファイルに指定していると思います。GitHubの仕様上、複数のアカウントを使うと必然的にSSHの鍵もそれぞれ用意することになるわけですが、そうなると github.com という1つのホスト(というかドメイン)に対して複数の設定が必要になります。この設定方法についてのメモです。 これはGitHubに限った話ではなく、任意のホストに対して複数のssh鍵(やその他の設定)を使い分けることができます。 以下の状況を仮定しますアクセスするホスト(またはドメイン)github.com設定するアカウントとそれぞれの鍵ファイルへのパスfoo アカウント~/.ssh/github_foo_rsahoge アカウント~/.ssh/github_hoge_rsa.git/config の設定[remote “xxx”] 内のurl
GitHubのissueをカンバン形式で管理できるサービス4選 - テクスタ
GitHubのissueでタスクを管理しだすと最終的にかんばん形式でみたくなりますよね。 そんなときに便利なGitHubのissueをかんばん形式で表示してくれるサービス。 基本的にどれも機能にそこまで差異はないですが、課金体系などが微妙に違います。 Waffle.io GitHubのpublicリポジトリ、privateリポジトリなら無料で使える。 GitHub Enterpriseで利用する場合には有料なようです。 Waffle.io · Work Better on GitHub Issues HuBoard GitHubのpublicリポジトリなら無料、privateリポジトリは有料です。 但しソースコードが公開されているので、自分でホスティングすれば無料です。 HuBoard - GitHub issues made awesome. Zube publicリポジトリは無料。 p
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸGitGitHub Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 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 に沿って開発する 基本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories
Git・Githubに隠された便利な機能
GitHub - sndyuk/logback-more-appenders: Extra appenders for Logback.
