GitHub Actions： みなさんが開発し、GitHubで実行 | The GitHub Blog
先日のGitHub Universeで、ワークフローの自動化とカスタマイズを可能にする新機能、GitHub Actionsを発表しました。アプリケーションとサービスの設定は、開発サイクルの多くを占め、かなりの時間と労力を必要とします。GitHub Actionsは、オープンソースの原理をワークフローの自動化に当てはめており、着想から開発まで皆さんが使っているツールを組み合わせて1つのワークフローにします。プロジェクトで必要なアクションは、GitHub上でコードを扱う場合と同じように、作成することも、シェアすることも、見つけることもできます。 Actionsの詳細はこちら Universeでの発表に先立ち、お客様やシステムインテグレーター、オープンソースのメンテナーのグループにGitHub Actionsを試験的に公開したところ、わずか数週間で、数多くのGitHub Actionsを作成して
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
Git ワークフロー | Atlassian Git Tutorial
現在、Git は最も普及しているバージョン管理システムです。Git ワークフローは、Git を使用して一貫性のある生産的な方法で作業を行うためのレシピや推奨事項のようなものです。Git ワークフローによって、開発者や DevOps チームは一貫性を持って Git を効果的に活用できます。Git では、ユーザーは変更を柔軟に管理できます。Git は柔軟性を重視しているため、Git を操作するための標準化されたプロセスはありません。Git で管理するプロジェクトにチームで取り組む場合は、変更をどのように適用するのかについてチームで完全に合意することが重要です。チームの認識を統一するには、合意した Git ワークフローを作成または選択する必要があります。公開されている Git ワークフローの中に、チームに適したものがあるかもしれません。ここでは、このような Git ワークフロー オプションをいく
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識
いまさら聞けない、成功するブランチモデルと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の概要を紹介します。 効率的にバージョ
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
ワークフロー機能のカスタマイズ方法 - Natural Software
Trac Lightning 2.0.0 の目玉機能である、ワークフロー機能のカスタマイズ方法を Oかもと さんより教えていただいたので早速試してみた。 実は Trac Lightning の Wiki に変更方法が書かれていたオチ＾＾； http://localhost/trac/SampleProject/wiki/TracWorkflow ここに書かれているテストフェーズの追加と遷移の制限を追加してみた。 変更前と変更後のフローはこんなカンジ（可視化方法はこちらを参照）。 変更方法 http://localhost/trac/SampleProject/wiki/TracWorkflow ここの｢例: ワークフローにテストを追加する｣を見ながら試行錯誤すれば大体わかると思う。 基本的には trac.ini (SampleProject なら C:\TracLight\projects
Trac Lightning 2.0.0 Beta3 - Natural Software
Trac Lightning 2.0.0 Beta2 の不具合の解消を試そうと思ったら、Trac Lightning 2.0.0 Beta3 がリリースされていた＾＾； ＃仕事が速い！ 早速インストールしてみたらちゃんと動いた！！ ＃ユーザもちゃんと admin とかになってる。 Wiki がなんだか質素になってる＾＾； メインの改善点は管理ツールの使いやすさが多いので、管理画面を開いてみた。 パーミッション管理がチェックボックスで見やすい ユーザ管理も一覧がわかりやすい プロフィールには写真も入れられるっぽ ユーザグループの設定はここでするんだね Subversion のアクセス権設定が直感的になってとてもウレシイ で、恐らく一番のウリであろう、ワークフロー機能のカスタマイズ方法が未だわからず＾＾； 見過ごしてるのだろうか？？ ワークフローの変更もできました:) 管理側としては管理方法が
ワークフローを可視化する - Natural Software
ワークフロー機能のカスタマイズ方法の前に、ワークフローを下図のように可視化する方法を示す。 Trac の下記サイトにワークフロー機能のカスタマイズ方法が記述されているが、その中に気になる一文があった。 http://localhost/trac/SampleProject/wiki/TracWorkflow ワークフローを作成・編集するのに contrib/workflow/workflow_parser.py が役に立つかもしれません。 contrib/workflow/workflow_parser.py は GraphViz が理解でき、ワークフローを視覚化するための .dot ファイルを作ることができます。 以下に例を示します (インストールパスは環境により異なる場合があります) 。 cd /var/local/trac_devel/contrib/workflow/ sudo .
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
GitHub Flow (Japanese translation)
A handy workflow image for newbie mercurial users (secretGeek.net)
yinwm / hgflow / wiki / Home — Bitbucket