A static site to replace the pullreminders app after it is shut down.
GitHubダイスキー! ということで、知った時に「おっ!」と感じたGitHubに関する事項を選出してみました。 あなたに「おっ!」と思ってもらえたら幸せです。 1.入れておくと、意味を持つファイル名がある。 README.md README.mdは有名ですよね。リポジトリのトップにREADME.mdという名称でマークダウンを入れておくと、GitHubで解釈されて表示されます。 それ以外にも、あるのです。意味のあるファイル。 ISSUE_TEMPLATE.md トップか、.github/というフォルダにISSUE_TEMPLATE.mdという名のファイルを入れると、GitHubでIssueを作った時にこのファイルの内容が入ります。書くべき項目を羅列しておくとルール化できていいですよね。 それ以外にも PULL_REQUEST_TEMPLATE.md を入れておくと、Pull request
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の3つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ
Chris DiBona was worried everything would end up in one place. This was a decade ago, before the idea of open source software flipped the tech world upside-down. The open source Linux operating system was already running an enormous number of machines on Wall Street and beyond, proving you can generate big value---and big money---by freely sharing software code with the world at large. But the ope
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
Bitbucket – 無料のプライベートリポジトリが魅力https://bitbucket.org/ 無料でプライベートリポジトリを無制限につくることができる。 プライベートリポジトリは5人までは無料で利用できる。GitHubクローンではないが、個人や数人で利用するだけならBitbucketのサービスだけでまかなえるのでおすすめ。オンプレミス製品は有償での提供。 Gitea – Go製セルフホスト型のGitHubクローン2016年にver1をリリースした期待の新星です。別途記事を書いてますので、詳細はそちらをどうぞ。 https://hiroki.jp/gitea Go製のためマルチプラットホームでさくっと動きます。DockerやVagrantの提供もしているため動作させるまでのハードルが低いです。 全文検索機能はありませんが、主要な機能は搭載されています。 GitPrephttp://
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー! javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
ローカルで GitHub を構築! Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた GitLab とは GitLab は Git リポジトリを簡単に管理できるツール Gitolite をブラウザから管理できるようにする Ruby アプリケーションです。 GitHub のオープンソースクローンと呼ばれることから分かるように、UI が GitHub とめっちゃ似ています。 GitHub みたいなサービスを使いたい!だけど Public はアレだなということもあると思います。そんなときに便利です。 社内 GitHub として使うケースが主なユースケースだと思います。 しかもすべてローカルだけで作ることができるので、ローカルマシンにインストールすれば、構築後はネットワークなしで GitHub 的な環境を使うことができます! そんな GitLab を Mac
About removing sensitive data from a repository When altering your repository's history using tools like git filter-repo or the BFG Repo-Cleaner, it's crucial to understand the implications, especially regarding open pull requests and sensitive data. The git filter-repo tool and the BFG Repo-Cleaner rewrite your repository's history, which changes the SHAs for existing commits that you alter and a
Twitter - ripienaar http://twitter.com/ripienaar/status/28788028764 (大意:ロンドンE14近辺にいるDevOps(開発者兼システム管理者)タイプの人で、フルタイムで働ける人を探しています。GitHubのユーザ名とブログのURLを私まで送ってください) 「GitHub」は、いまやIT関係者で知らぬ者はいないくらい有名になった、ソースコード(ソフトウェアの元になるプログラム)のホスティングサービス。 最近見かけるオープンソース系のソフトウェアは、かなりの割合でこのGitHubを使っている。いま439,000人が登録しているそうで、世界じゅうのITエンジニアがここにアカウントを作り、自分で書いたプログラムを公開したり、他人のプログラムをいじって自分のバージョンを公開している。 IT人材の求人で「GitHubのユーザ名とブログのU
Honza Pokorny - 7 ways Github has changed the open source world http://honza.ca/2011/03/7-ways-github-has-changed-the-open-source-world/ いまやオープンソース・プロジェクトの大半が利用しているGitHub(ギットハブ)。このGitHubがオープンソースの世界をどう変えたか、7つのポイントがあげられている。 1. Force projects to include a good README 良いREADME(説明文書)を含めるよう、プロジェクトに強制した 2. Unified place for all your projects 自分の全プロジェクトを一箇所にまとめられる 3. Code discussions コードによる対話がやりやすくなった 4.
人材の移動の激しいスタートアップ業界にいながらも殆どの従業員が辞めないことが話題となっている、ソーシャルコーディングサービスGithubのCEO、Tom Preston Werner氏が「イノベーションを起こすためのGithubの哲学」について先日のOpenCoSFというイベントで語った。 「イノベーションとは新しく何かをはじめることだ、たとえ他の人がそれをクレイジーだと思っていても」サンフランシスコはイノベーションを起こすには最高の場所だ。何か新しいことをすることはリスクだ。何が起こるかわからない。イノベーティブになるには勇気がいる。 他の人が「こんなもんクレイジーだ!」って言ったとしてもこれをやるぞという強い意思が必要だ。実際にスタートアップはとても高い確率で失敗する。でもサンフランシスコの文化ではたとえ失敗したとしてもまったく問題ないんだ。 実際にたくさんの起業家が失敗しているし、新
リポジトリだけじゃ終わらないGitHubの魅力に迫る Gitリポジトリの「GitHub」が最近注目を浴びています。Gitを使っていなくても、ほとんどの人は名前くらいは聞いたことがある人は多いと思います。今年の3月に、あるサンプルアプリのソースコードがGitHubに公開されたというニュースが話題になり、GitHubの知名度が日本でも高まりました。なぜ話題になったかというと、そのサンプルアプリが日本のダンスグループ「Perfume」が踊っている姿のモーションキャプチャデータを使ったものだったのです。 Gitは強力なツールですが、Gitというキーワードが先行しているので、GitHubのことを「Gitリポジトリが使えるWebサービス」くらいにしか感じてない人も見掛けます。 しかし、一昔前は貧弱だったGitHubのIssue(チケット)機能も最近のバージョンでは大幅に強化され、GitHubは情報共有
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く