GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
10分ではじめるGitBucket - Qiita
GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者：@matthewmccull Hashesについて 従来の CVCS （集中バージョン管理システム）のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS （分散バージョン管理システム）がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
GitBucket 1.0リリースしました - 新・たけぞう瀕死の日記
warファイルをサーブレットコンテナにデプロイするだけで利用可能なGithubクローン、GitBucket 1.0をリリースしました。 https://github.com/takezoe/gitbucket 当初の目標（6月末）からは少し遅れてしまいましたが、Gitリポジトリの作成、リポジトリビューア、Wiki、Issuesなどは一通り実装しており、なんとか実用に耐えうる機能は揃っているのではと思います。フォークやプルリクエスト、タイムライン、チーム管理、メール通知などまだまだ未実装の機能は多いですが、今後のバージョンアップで随時機能を追加していきます。 フレームワークとか 少し話は変わりますが、GitBucketはScalaで書かれており、フレームワークとして以下のものを組み合わせて使用しています。 Scalatra scalatra-forms（Play2のフォームのようなバリデーシ
プログラマがGitHubとどう関わっているのか垣間見て感じたこと | Act as Professional
関係各所の協力により実現した1日にとても感謝している@HIROCASTERでございませう。 スタッフとして協力してくれる仲間がいたり、突発LTやってくれたりなど、Agile渋谷のおなじみのの雰囲気がアウェイの銀座も垣間見れたのもよかったです。 1日暇になったからLTやりにきてくれる仲間がいたり、おもしろかった。 Book1st銀座コア店では、Web+DB PRESSを1冊ずつ持った人が7人以上並ぶという光景があったとか。 「The GitHub」イベント詳細発表！話題のあの人が登壇 #Agile渋谷 こちらのイベントのまとめです。 感想 個人的な感想としては、やはり感じていたとおり、GitHubを使いまくってる人とほとんど使っていない人にグッサリわかれてしまっているのかなと。 仕事じゃ使えないけど、プライベートだと使いまくってるなんて、ケースはあまり聞かない。 そして、GitHubを使って
自社に立てよう。クールでモダンなGitリポジトリビューワー·GitList MOONGIFT
GitListはGithubライクなGitリポジトリビューワーです。 Githubのリポジトリビューワーは日々進化しており、かなり格好いいと思うのですが、Githubにリポジトリがないと見られません（当たり前ですが）。しかしGitListを使えばあれに似たUIでリポジトリを閲覧できるようになります。 インデックスです。 リポジトリの中に入りました。ディレクトリブラウザになっています。 テキストコンテンツは内容が閲覧できます。 バイナリの場合はRawをクリックします。 コミット一覧です。 コミット詳細です。Diffも奇麗です。 解析結果です。拡張子ごとのファイル数も見られます。 フィード機能があります。 GitListは複数のリポジトリ、ブランチ、タグのサポート、コミットログ、差分表示、拡張子ごとのシンタックスハイライト表示、リポジトリ解析、フィード配信と言った機能があります。GitHubラ
入社2週間で書類1枚書かずに大きな決裁！グリーのスピード感：Rails Hub情報局：エンジニアライフ
「オレ、入社2週間で大きな決裁を通しましたよ！ まだ試用期間中だったのに（笑）」。JRubyのコミッターで、Rubyコミュニティで広く知られた大場光一郎さんに久しぶりにお会いしたら、ちょっと興奮気味にこうおっしゃるのですよ。具体的な数字は書けませんが、確かに、ふつうの企業なら1週間や2週間で決まるような金額ではありません。まして入社2週間の試用期間中の社員の提案です。 大場さんは2011年12月に、日本で5本の指に入る大手SIerを退職し、ソーシャル・ネットワーキング・サービス「GREE」を運営するグリーに入社したというではありませんか。そして、あまりの2社のスピード感の違いに驚いているというのです。Developers Summit 2012（通称デブサミ）が終わった後の飲み会でお話を伺ったのですが、水を得た魚とはこのことかというほど楽しそうに、新しい仕事上のチャレンジについて話をされて
GitHub からファイルを完全に削除 - mooz deceives you
なんだかヤバいものを GitHub にアップしてしまった人は、はやいとこ次のコマンドを打ち込みましょう。 git filter-branch --index-filter 'git update-index --remove file' HEAD git push --force --verbose --dry-run git push --force file には削除したいファイル名を。これで GitHub から file がコミットログ含めて完全に削除されます。 ただ、ここで安心するのは早計というものです。昨今のネット世界を掌握しているかの Google を忘れてはいけません。 試しにヤバいファイルの内容で検索してみると...... 見事に引っかかりました。キャッシュ怖い。 結論 見られて恥ずかしいものをアップロードする場合は、お金を払ってでもプライベートリポジトリにしましょう。
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub
github-cheat-sheet/README.ja.md at master · hail2u/github-cheat-sheet
Hatena Blog Development Flow
github を用いた開発フローテンプレート
More Git and GitHub Secrets
Log in with Atlassian account
Git and GitHub Secrets
GitHub - danlucraft/git.js: pure-Javascript Git implementation