なぜファイルの末尾に改行を入れたほうが良いのか - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
複数のgithubアカウントをノンストレスで運用する方法（脱ssh鍵設定）（git credential helperの活用） - Qiita
はじめに githubは公式でも言っているように、基本的に1人1アカウントで運用することが推奨されています。 しかし、様々な事情で複数のGithub Accountを利用している人も多いのではないでしょうか。 そんな時に困るのが、git commandを使用する時の認証だと思います。 実際にググってみると、以下のような回避方法がありました。 ssh keyを登録して、ssh configを設定して切り分ける方法（一番王道） 1つのリポジトリだけであれば、 https://username:password@github.com/xxx/xxx でcloneする方法（リポジトリ一つならこれが圧倒的に楽） .netrc を切り替えて使う方法 (sshの設定しなくていいけど、手動切り替え) しかし、sshの鍵登録するのもいやだし、すべてのremote設定を git:// にするのも面倒。 go
Ship.jsでリリースフローを改善する - Qiita
PLAID で i18n おじさんエンジニアしてる kazupon です。 この記事は plaid advent calendar 2019 の 17日目の記事です。 はじめに 筆者は、PLAID のプロダクト開発以外にも、オープンソースソフトウェア (以下 OSS )開発者として vue-i18n といったオープンソースプロジェクトを持っており、Node.js においては npm または yarn といったパッケージマネージャーと呼ばれるもので、Node.js そして必要に応じてブラウザ向けに動作するコードをパッケージにして OSS として配布しています。 npm / yarn で配布する OSS は、一般的には semver のようなセマンティックバージョンニングの仕様に沿った形で、バージョンをリリース毎に発行して管理して、npm publish や yarn publish によって
中の人に聞いたGitHub flowの本当の使い方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
間違えてGitHubなどにSECRET_KEYをpushしてしまった時の対処法（個人のみ） - Qiita
備忘録です 2019/03/09 15:00 - @tetsukay さん @shibukk さんのコメントを反映しました やらかした！！ GitHubなどで、TwitterのpasswordやAWSなどのSECRET_KEYが含まれたプロジェクトを管理する際、.gitignoreをちゃんと指定してやらないとgitのcommit履歴などにそのSECRET_KEYなどの値が残ってしまいます。 こういったミスでSECRET_KEYなどが流出するとセキュリティインシデントに繋がりますね。 この記事では一番最悪な「SECRET_KEYなどがcommitされた履歴がpushされてしまった」という事態の対策として、「git上での履歴の削除方法」と「リモートリポジトリ上の履歴の削除方法」を解説します。 パスワードの変更 まずはパスワード/SECRET_KEYを今すぐ変更しましょう。 対応が遅れてしまうと
【GitFeatureFlow】GitFlowをやめて本番リリースが楽になった話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた
GitHub.com・BitBucket.org・GitLab.comの月額料金比較 + α - Qiita
チームで利用する場合は、GitHub.comは3名、BitBucket.orgは5名までなら無料で利用できます。また、GitLab.comなら人数に制限なく無料で利用することが出来ます。 なお、BitBucket.orgは来春に値上げが予定されていますが、それでもGitHub.comと比べるとかなり安く料金が設定されています。それと、BitBucket.orgにあるコラボレーターの無制限プランは来春には廃止される予定のため、コラボレーターが100名以上の大規模ユーザーの場合はかなりの値上げとなる可能性があります。 CIサービスの月額料金比較 次に、CIサービスのTravis CI・Circle CI、及びGitLab CIの月額料金を比較します。 なお、単純に月額料金を比較することが難しいためビルドの同時実行数によって、月額料金がどのくらい違うのかを比較します。ビルドの同時実行数とは、CI
HoundCIでリポジトリに番犬を飼おう
プルリクエストのレビュー時に 「規約では１行あたり最大８０文字なので、１文字削ってください」 などと一々指摘していると人間関係が破綻する可能性があります。 こういう定量的なものに関してはロボットに任せるのが一番です。 そこでHoundCIを使いましょう。 これはRubocopにリポジトリを監視させるというコンセプトのサービスです。 HoundCIを使うメリット コーディング規約違反のコードがmasterに入る前に必ず検知できる チームメンバー全員でRubycopを使う必要がない ダルいコーディング規約に関する議論が可視化できる 人間関係が壊れない（重要） 気軽にみんなでRubocopを使える Rubocopをsyntasticを使ってVimから自動実行する Rubocopを使ってコーディングルールへの準拠チェックを自動化 Qiitaの上のような記事を読んでから、暇があったら導入しようと思っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actionsの実行・結果確認をターミナルで完結させるalias - Qiita
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
入門書には載ってない Git & GitHub Tips
英語コミットコメントに使えるオシャレフレーズ集