builderscon2017の発表資料です。 https://builderscon.io/tokyo/2017/session/182ba13a-ccd5-4ddd-9565-c4e20df1d871
![Oss貢献超入門](https://cdn-ak-scissors.b.st-hatena.com/image/square/30f01b55c7fac24ffc638396662cd1f200b96e79/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Foss-170805064011-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
ProductA whole new GitHub Universe: announcing new tools, forums, and featuresToday I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the people building the future of software. It’s an… Today I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the peopl
Gitter is a chat and networking platform that helps to manage, grow and connect communities through messaging, content and discovery. Built on Matrix Matrix.org is an open network for secure, decentralized communication. There is a variety of clients are available. Learn more Simple to start Sign-in with GitHub/GitLab/Twitter and start chatting, with End-to-End Encrypted messaging. Markdown and La
ProductIssue and Pull Request templatesIt's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contributors share the right details… It’s hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contribut
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな?」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。
既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSIT
.gitignore し忘れて他人に見えちゃマズいファイル(パスワードをベタ書きしたファイルや AWS_SECRET_ACCESS_KEY を書いたファイルとか)を git commit しちゃった!そんなときは すればすぐ何もなかったことにできます。 が!そこで気付かずに GitHub へ git push してしまった!こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、パスワードの書き換えやトークンの無効化を施しましょう。 (この時点でもう
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部(2015/07/18現在分)調査してみた。 github APIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。 AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。 AWS用 aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
経緯 個人的にgit commit -m " うっ、英語でなんて書けばよいんだろう。。。。ってなることが多くて、GitHubの公式の検索ってソースコードは検索できても、コミットメッセージをリポジトリ横断的に検索したいなんてことはできないんですよねぇ。まぁネイティブな人にはそんなこと思いもしないのかも知んないですが。調べてみたらGitHub APIでコミットメッセージ取れるようなので、現場のリアルな生の文例を集めて検索できるようにすればよくね?ということで勉強がてら作ってみたので、需要あるか分からないけど同じこと思ってた人のために晒す。 作ったもの http://commit-m.minamijoyo.com/ 使い方 テキストボックスにキーワード「fix bug」などを入力してSearchボタン押すと検索結果が表示される。以上。 機能の補足説明 キーワードはスペース区切りでAND検索になる
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
米Googleは3月12日(現地時間)、開発者向けにAPIなどを提供したり、オープンソースプロジェクトをホスティングするサービス「Google Code」を来年1月に閉鎖すると発表した。同日、新たなプロジェクトの作成はできなくなった。 Googleは2006年、オープンソースプロジェクト支援を目的にこのサイトを開設したが、その後、GitHubやBitbucketのようなプロジェクトホスティングサービスが立ち上げられ、多数のプロジェクトがそれらのサービスに移行していった。Googleは、Google Code上のプロジェクトに占めるスパムや悪質なものの率が高まってきていることも閉鎖の理由の1つだと説明する。 Google自身は既に、昨年10月に同社のAPI群のGitHubへの移行を開始し、Google Code上のプロジェクトを凍結している。 Google Code閉鎖までのプロセスとして、
Windows上でGitを使う Windows 8を使っていて、ソースコードを社内のStash(企業向けGit製品)にアップする必要が出てきたので、GitHub for Windowsを導入してみました。 今回はGitHub for Windowsによる下記タスクに関してご紹介していきたいと思います: GitHub for Windowsのインストール GitHubへの接続 GitHub for Windowsのオプションの変更 GitHubのレポジトリをCloneする レポジトリを様々な方法で開く ローカルレポジトリにファイルをcommitする(GitHub for Windows編) ローカルレポジトリにファイルをcommitする(PowerShell編) 共有レポジトリにファイルをpublish/syncする(GitHub for Windows編) 共有レポジトリにファイルをpus
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く