SlackメッセージからGitHub issueを作成するSlackアプリです。Flow情報をStock情報に変換することで価値ある行動につなぐことができます。issueをTODO管理として活用したい人にもおすすめです。

みなさまこんにちは！Staffing Div.＆ICT Div.神谷（@kamipoo_）です。 日頃、Shopifyの構築・運用のご依頼を多くいただいておりまして、ありがとうございます！ 社内でもECチーム＆ICT Div.でShopifyの勉強会を積極的に行っています。 今回はさまざまな案件に携わらせていただく中でテーマの開発フローを試行錯誤してできてきたものを一度書いてみたいと思います。 実現したいこと ・Shopifyストアは本番環境のみ ・GitHubでバージョン管理を行いたい ・GitHubでmainブランチにプッシュと同時に公開される状態は避ける （本番環境上でテスト後公開したい） ・Shopify CLI for themesを使ってローカル環境で開発する 前提 ・Shopifyストアは作成済み ・GitHubのアカウントは登録済み ・Shopify CLI for the

Fork is getting better and better day after day and we are happy to share our results with you.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン

2016年12月17日(土)、松江テルサ4階にて開催された松江Ruby会議08に参加しました。初の島根！初の松江！ キッカケは、フルタイムRubyコミッター採用までの道のり | Money Forward Engineers' Blogという記事が松江Ruby会議スタッフの目に止まり、僭越ながらゲストスピーカーにお招きいただきました。 許可を得る前にプルリクしよう、とは About pull requests - User Documentation プルリク = GitHubのPull Requestという機能です。GitHubはGitのRepositoryをホスティングするサービスで、Pull Requestを使うことで、そのRepositoryの本筋の歴史に対してある時点で分岐した歴史を統合する提案が出来ます。 『許可を求めるな謝罪せよ(Don’t ask for permissi

実際にGitLFSを使ってみようということでGitHubで試してみました。 まずはgit-lfsのインストールから。gitはインストール済みとします。MacならHomebrewで簡単に入れられます。 $ brew install git-lfs 適当なGitリポジトリを作成し、GitLFSを有効にします。 $ mkdir git-lfs-test $ cd git-lfs-test/ $ git init $ git lfs install GitLFSで管理するファイルを指定します。 $ git lfs track *.jpg あとは普通にファイルをコミットしてpushすれば該当のファイルが自動的にGitLFSに保存されますし、git-lfsがインストールされている環境であればcloneしたりpullしたりすると自動的にローカルにもファイルの実体がダウンロードされてくるので普通にリポジト

結論 ここに書いてある 注意事項 だいぶ懐かしい記事ですが…突然、「Diffに表示しないなんてGitHubの価値を損なうものだから記事を非公開にするべきだ」というご指摘をいただいたので、念のため追記。 Diffに表示しない、ってことは当然PRにも見えません。 レビューされない怪しいコードが紛れ込むリスクを抱えることになります。 せいぜい自動生成分だけを非表示にして、CIの中で再生成、差分が出ないチェックを入れるなど、ガードの手は考えておいたほうが良いでしょうね。はい。ご利用は計画的に。 背景 mockeryだったり、swagger-codegenだったり、go-bindataだったり… GitHub上に自動生成されたコードを載せている場合、PRやcommitの詳細画面でDiffが邪魔になることがあります。 .gitignoreでそもそも自動生成コードをリポジトリに載せない generate

Windows版のIntelliJ IDEAのTerminalでbashが使えるようにしてみました。 試したのは以下の環境です。 Windows10 Git 2.10.2 bashはWindows版のGitに入っているものを使用します。 1.Settings->TerminalのShell pathに <Gitをインストールしたフォルダ>¥bin¥bash.exe を指定します。 2.alt+F12でTerminalを開くと、あっさりとGit bashが起動しました。 ただし、このままだと日本語の処理がうまくいかない所がありました。 lsコマンドで日本語のファイル名が正しく表示できない コミットコメントに日本語を入力すると文字化けする(Editorはvimを使用） 3.これを回避するため、システム変数にLANG=ja_JP.UTF8を追加します。（変更したらWindowsの再起動が必要です

自分のチームではコミットログにIssue番号を書くルールにしていますが、IntelliJのVersion ControlのコミットログからIssueを開けると地味に便利なので設定してみました。 1.Settingsの Version Control -> Issue Navigationを開き、+アイコンをクリックする JIRAとYoutrackは専用の+アイコンがあるので簡単に設定できるようです 2.コミットログからIssue番号を抜く正規表現とIssueのURLを設定する Issue ID　コミットメッセージからIssue番号を抜く正規表現を記述する。 Issue link　Issue番号の部分を$nで可変にしたURLを指定する。$0はマッチした全体が、$1～はグループの抽出結果が入ってきます（普通に正規表現が使えるというだけです） 3.Log画面のコミットメッセージのIssue番号の

変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 ```diff:余談...diffのシンタックスハイライト初めて使ったけど良い感じですね $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty message aborts the commit. On branch commit-v You are currently bisecting, started from branch 'test-git-bisect'. Changes to be committed: >

I bring user-generated content to static sites User-generated content are typically the Achilles heel of any static site — a blog commenting platform, a reviews section or a voting system are just a few common examples. To implement these on a static site, developers often resort to third-party services that inject content into pages through JavaScript embeds or iframes. I keep your content where

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

みなさん、連日 GitHub をブラウジングしてると思うんですが、より快適にブラウジングできる拡張機能を紹介したいと思います。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー