Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
GitHub Actions 使ってみた感想 - mizchi's blog
やっときたので使ってみた。 CI マニアから見た GitHub Actions(Beta)の使い所 - くりにっき https://github.com/mizchi/frontend-gh-action-playground で素振りして挙動を確かめた後、会社の結構重めのリポジトリに突っ込んでみた。まだ 2 日目なので、実際そこまで経験値足りてない。 とりあえず困ったらここ読む GitHub Actionsのワークフロー構文 - GitHub ヘルプ 良い点 sue445 さんの記事でも書いてあるが、ジョブが 20 個まで並列になるので、並列に分解できるようなものに強い。 GitHub に完結してる点。checks タブで CI の結果が見える。 circleci.com/dashboard とか行かなくていい。外部 CI はアカウント取得やらリポジトリごとの設定やらなんやらもあるので、
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
GitHub でテキスト管理を行う GaaTS(GitHub as a Text Storage) について - Qiita
GitHub でテキスト管理を行う GaaTS(GitHub as a Text Storage) についてまとめてみました。 GaaTS とは？ GaaTS とは 「GitHub でテキストを管理しようぜ」 という考え方や取り組みのことです。 ここで「テキスト」とはテキストファイル全般を指します。例を挙げるとキリが無いですが、たとえばメモ、記録、日記、ブログや書籍の原稿、小説、あるいは（しっかり管理するまでもない個人的な）コードや設定ファイルなどがあります。 対象読者 本記事では以下の知識レベルを想定しています。 Git や GitHub を使っている、あるいは使っていた 「バージョン管理」「UI」「Markdown」といった IT 用語がわかる GaaTS の用途として以下を想定しています。 個人で テキスト管理を行う 複数人で共同作業する等の用途は想定しません ブログのように不特定多
GitHubのプライベートリポジトリをストレージとして活用したシンプルなメモサービスhubeditを作っている - Copy/Cut/Paste/Hatena
個人でGitHub有料プランの人しか使えないサービス作っている— k1LoW (@k1LoW) 2017年7月5日 スマートフォンのブラウザからでもメモが書けるサービス 自分はいつも簡単なメモ書きにはEmacsか、ブラウザを開いていたら wri.pe を使っていました。 wri.pe を使い始めたのは2013年からで、かれこれ4年使っていることになります。 wri.pe で気に入っているところは シンプル スマートフォンのブラウザからもストレスなく使える バックアップが自分がハンドリングできる場所に取れる（wri.peはDropbox） というところです。 いつでもどこでもブラウザがあれば雑にメモが取れるのが最高です。 ただ、ちょっと困っていることがあって wri.peは最近 ノートの検索機能が動かない （微妙に動いている！？） ノートの削除機能が動かない という状況が続いています。 これ
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
GitHub連携したJenkinsをサクッと構築したい - Qiita
求めるJenkinsおじさん Jenkins >= 2.0 基盤 AWS(使い慣れているので/ public ip あればなんでもいいです) AWS上の構成 EC2(publicにさらしたくない) + ELB(SSL終端させたい、ここでポート変換) の構成でいく。 ELBのSecurity Groupは自分家(自拠点)とGitHubのhookだけ許可する様に設定GitHubのIPはhttps://api.github.com/metaで調べて開けておく。 サクッと作りたいのでdockerを使う。 packageからinstallとかでもいいが、jenkinsのアップデートする時に面倒なのでdockerでold versionとnew versionの2つ立てて置いて切り替える時にポートだけ変更してアクセスするようにしたかった。(ALBのtarget groupとか使ってもいいけど面倒なので
CHANGELOG の書き方 - 角待ちは対空
VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。 ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。 CHANGELOG の原則 機械的に生成するのではなく人間の手で書く 各セクションへのリンクが容易にできる 1つのバージョンごとに1つのサブセクションを作る リリースは新しいものが上に来るようにする 日付のフォーマットは YYYY-MM-DD
個人開発環境にGithub Flowを適用する - chroju.dev
Github、joinしたのは2013年で作ったものは軒並みちゃんと突っ込んではいるんだけど、単に一区切りついたらadd => commit => pushしているだけでちゃんと使っていなかったので、個人開発ではあるがGithub Flowを取り入れてみた。 What is Github flow ? Githubを用いた開発作業を進めるにあたっての指針みたいなものです。基本的にはmasterブランチ上では作業せず、作業工程ごとにブランチ作って、終わったらプルリクしてmasterにマージしてもらうことでデプロイとしましょうね、というものだと理解している。至ってシンプルではあるけど、これを取り入れるだけで従来やっちゃってた「masterで作業してるのでデプロイしても動かないレポジトリがGithub上にある」みたいな状態が防げて良さそうだと思った。 ちなみにGit-flowというのもあるようだ
GitHub EnterpriseをAWSに構築した話
4009とは、株式会社フォークにおけるよろずごとメディアです。 「人」「未来」「技術」「仕事」「∞」のシーンから、日々の取り組みを裏表なく発信します。 4009とは、株式会社フォークにおけるよろずごとメディアです。 「人」「未来」「技術」「仕事」「∞」のシーンから、日々の取り組みを裏表なく発信します。 4009とは、株式会社フォークにおけるよろずごとメディアです。「人」「未来」「技術」「仕事」「∞」のシーンから、日々の取り組みを裏表なく発信します。 はじめに この記事はマニュアルのリンクが多数貼られておりますが参照時期によっては古い情報になります。 執筆時点では、GitHub EnterpriseのVersionは、2.7となっております。 最新のマニュアルをご参照頂ければと思います。 また、AWSの細かい設定（セキュリティグループなど）や、DNSの設定など本運用する為に必要であろう項目は
Linux Server管理者の管理を楽にする - Tomohisa Oda
昨年、libpam-mrubyを使って、Linux Serverにおける認証やその管理について思うところを書きました。今回はその続きです。 libpam-mrubyを使ってGithubのチームで認証をする OSSを使ってのLinuxユーザ管理といったら、一般的にOpenLDAPを用いると思いますが、LDAPって統合管理でやれること多いかわりにちゃんと使おうとしたら敷居が高い感じがするんです。LDAPを触る頻度が低いと、LDAPコマンドを毎回ググる事になり、地味に面倒というのは経験している人多いと思います。そして、自分たちがLDAPを通して解決したいことって単にsudo権限を持つ管理者かそうでないユーザの管理で意外とシンプルだったりします。それに気づかせてくれたのは、イケてる同僚の@pyama氏プロダクトのSTNSというやつで、STNSはユーザや鍵の管理をTOMLで行うというものでした。設定
今日からはじめるGitHub ～ 初心者がGitをインストールして、プルリクできるようになるまでを解説｜ハイクラス転職・求人情報サイト AMBI（アンビ）
今日からはじめるGitHub ～ 初心者がGitをインストールして、プルリクできるようになるまでを解説 エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ソースコードの管理はできていますか？ ファイルを修正するときに、修正前のソースコードをhoge.php.bakのようなバックアップファイルとして残し、開発環境をゴミだらけにしていませんか？ エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ここではGitの詳細な仕組みには触れません。GitやGitHubを利用したことのない人が、Gitを
GitHubでのプルリクエスト活用方法まとめ - ICS MEDIA
みなさんはGitHubのプルリクエストの機能を使ったことはありますか？ ウェブ制作の場でもGitHubが使われることが多くなったと思いますが、ソースの履歴管理機能のみを使用している方も多いのではないでしょうか？ 今回はGitHubのプルリクエストについて紹介します。普段からプルリクエストを使っている方でも役立つプラスアルファのTipsをまとめていますので、最後までお付き合いください。 プルリクエストとは？ プルリクエストとは、コードの変更をレビュワーに通知し、マージを依頼する機能です。コードのレビューを受けることで、1人で作ると気がつかないコードの指摘やバグや記述ミスの発見ができ、コードの品質を高めます。レビュワーにとっても、他人が書いたコードを読むことで新しい書き方を発見できるというメリットがあります。コードから発展してプロジェクトに関する有意義な議論の場になることもあるでしょう。 プル
GitHubが落ちてても慌てずに済む、SSHとGitだけでのPush/Pull - Qiita
Git Advent Calendarをご覧の皆様、初めまして。Piroといいます。普段はJavaScriptやRubyでのソフトウェア開発やFirefoxの法人向け技術サポートなどをしつつ、日経Linux誌でシス管系女子という連載マンガを描かせて頂いております。 今日の記事では、「SSHって何？」や「SSHは知ってるし時々使うけど、普段そんなに使う機会は無い」くらいのレベルの方を対象に、SSHとGitの組み合わせだけでこんな事もできるんですよ！という事をご紹介します。アドベントカレンダー的には最後の方の日なのに初心者向けの話で恐縮ですが、まあせっかくなのでおつきあい下さい。 GitHubが落ちて困った！ 日頃Twitterを見ていると、GitHubのサービスが停止する度に阿鼻叫喚の地獄絵図が繰り広げられている印象があります。 「デプロイしたいプロダクトの依存ライブラリがGitHubにある
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
Increments流GitHub稟議の手順と導入方法 - Qiita Blog
こんにちは、@tshunskです。 Incrementsではエンジニアでないスタッフも全員がGitHubアカウントを持っていて、社内の稟議もGitHub上で起票しています。 今日は稟議のシステム化をご検討されている方のためにIncrementsが行っているGithub稟議のやり方と導入する際の手順を簡単にご紹介したいと思います。 背景会社の規模がある程度以上になると社内の承認プロセスとして稟議という手続きが間違いなく必要になってきます。いくつかのワークフローシステムも試したのですがいまいちパッとしたものがなかったため、それではGitHub上でやってしまおうということになりました。 GitHubに決めた理由スタッフ全員がアカウントを持っていて、使い慣れているので導入・運用のコストがかからない。稟議の内容に対するコメントや修正履歴なども後から見ることができるし、誰がいつ承認したのかという記録も
GitHub EnterpriseをAWSで使おう – レプリケーションを利用したHA構成 | DevelopersIO
はじめに こんにちは、中山です。 GitHub Enterprise(以下GHE) on AWSシリーズの第4弾です。今回はレプリケーションを利用したHA構成をご紹介します。 GHEにおけるHA構成 GHEではプライマリ/セカンダリが1台ずつのシンプルなHA構成が構築可能です。プライマリとセカンダリはレプリケーションを通じて各種データストアをほぼリアルタイムで同期することができます。設定するための各種スクリプトはGHEに同梱されており、利用するだけであればかなり簡単に使うことができます。また、セットアップ用のドキュメントも充実しているので、上記ドキュメントを参照すれば難なく導入できると思います。今回はこのドキュメントをもとに、レプリケーションのセットアップ方法をご紹介します。 ただし、注意点としてHA構成はバックアップ目的で利用するものではないという点は認識しておく必要があります。レプリケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こっそり始めるGit／GitHub超入門
効果的にGitHubを使うために
git&github初心者のためのgit&githubの重要単語 - Qiita