GitHub で共同開発をしている場合、GitHub Actions を使用して継続的なデプロイを行っていることが多いかと思います。 例えば Git タグを使用して、そのタグ作成をフックに自動で Production へデプロイといった運用が考えられます。 ただ、そういった運用は、運用自体が簡単ではあっても、セキュリティに難があります。 業務委託等の社外エンジニアが開発に参加している場合、そのレポジトリに対して Write 以上の権限が必要になります。 すると、Git タグを作成する権限もあるわけで、そうなると、社外メンバーが Production デプロイを勝手に行えてしまいます。 そういったことを防ぐために、Production デプロイ自体に承認機能を付けることができます。 それを、GitHub Actions と GitHub Environments という機能を組み合わせること
ツイッターでポロっとつぶやいたのだけど、ここでも記事をば。 某プログラマが34年前に発売された某有名ファミコンゲームのソースをgitに公開したので、以下にリンクを置いておく。 GitHub - omuanko/nnjhtrkn: Famous Ninja game for NESFamous Ninja game for NES. Contribute to omuanko/nnjhtrkn development by creating an account on GitHub. 某プログラマからの箴言は以下。 ■某プログラマ ちなみに びるど とおりますうご(www act65 を cpm86 エミュで 試してみた ソース見られるの恥ずかしい いまさらおそいか ちなみに act65は つけてないよ どっかで ひろってね ところで、イマドキな方には全く理解できないことがいろいろあるだろう
2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
上記の例の場合、変更した箇所が近いため同じhunk（変更の塊）として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ！というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの？という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識：Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）（1/2 ページ） 数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、ブランチ管理の課題と効率的にバージョン管理できる5つのブランチモデルと、ブランチの管理を簡単に行えるツール「git-flow」について。 Gitなどの次世代のバージョン管理ツールの特徴として、ブランチの機能を高度に活用できるという利点があります。Gitのブランチを生かしたツール・フローとして「git-flow」「GitHub Flow」が注目を浴びていますが、本連載では数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、git-flowの概要を紹介します。 効率的にバージョ
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
触れるのがこわくてずっとGitを避けて来ました。ですが、使わなければならない状況に追い込まれたので初心者ながら少しずつコミットしたりしながらGitの使い方を学んでいたらGitってもしかして楽しいかも!!って思うようになり、もっとGitの事を学びたくて色々勉強出来る資料やサイトを集めていて情報がたまって来たので、ここでまとめていつでも見れるようにしたいと思います。 Gitの仕組みを優しく教えてくれるスライド 素敵なスライドがありましたのでご紹介させていただきます。 うん、見やすい!見やすいよー!! Gitを勉強出来るサイト サルでもわかるGit入門 サルでもわかるGit入門 世界一わかりやすく説明しているサイトです。僕でもわかりました。 Learn Git Branching Learn Git Branching ゲーム感覚で勉強したい時はこちら。このサイト自体がすごい 笑 Gitコマンド
経営本部部門に異動して開発環境の整備に専念 アプリケーションやサービスの開発、あるいはWebサイトの制作などにおいて、欠かせないツールとなっているのがバージョン管理システムです。とくに多人数で開発を行う際、いつ誰がどのファイルを編集したのかをすばやく把握できる、あるいはファイルに加えた変更履歴を簡単に参照できるといったメリットを持つバージョン管理システムは、プロジェクトを円滑に進めるうえで極めて有用です。 サイバーエージェントのアメーバ事業では、このバージョン管理システムとしてApache Subversion（SVN）をメインで使っていましたが、エンジニアの間から「Git」を使いたいという声が高まり、それに応える形で「GitHub Enterprise」を導入、2013年4月から本格的に運用を開始しています。この導入プロジェクトを主導した奥田順子氏は、そもそものきっかけを次のように説明し
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
GitにはA successful Git branching modelと言われるブランチ運用フローが知られています。 内容の詳細はこちら 原文 A successful Git branching model » nvie.com 翻訳 見えないチカラ: A successful Git branching model を翻訳しました でこのフローを補助するツールとしてgit-flowというのがあります。 GitHub - nvie/gitflow: Git extensions to provide high-level repository operations for Vincent Driessen's branching model. git-flowの使い方はこちらが詳しいです。 A successful Git branching model を補助する git-flow
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
HubFlowとは HubFlow: GitFlow For GitHub HubFlowはGitHubリポジトリでGitFlowを便利に使うためのGitコマンド拡張です． gitflowをforkして開発されています．datasift/gitflow · GitHub 今の時点では，大幅に便利になるというものではない感じです． git hfのようにサブコマンドhfを用いたコマンド体系なので，gitflowと併用できます． さらに，gitflowを利用している既存のリポジトリに対してもgit hf initで上書きすれば使えます． 使い方 なんか新しい図が出てますが，流れはGitFlowとほとんど変わりません． リモートブランチとfork元のブランチに対する操作が用意されていないGitFlowに対して，HubFlowでは用意されているという点が異なります． 便利になったところ git hf
さくらのVPS+Jenkins+github+rails3の続編。 ゴールは、githubにpushすると、さくらのVPSで動いているJenkinsがgithubから最新ソースひっぱってRobolectricのテストかけた上に、apkを作るところまで。 プロジェクトの作成 mavenプロジェクトにしてみた。 ユーザーの作成 以前作ったやつで兼用。 SSH key コレも兼用しようと思ったらダメだった。１リポジトリにつき１keyだそうで。 https://help.github.com/articles/error-key-already-in-use Once a key has been attached to one repo as a deploy key, it cannot be used on another repo. If you're running into this
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
