なぜファイルの末尾に改行を入れたほうが良いのか - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき
gitで特定のcommitバージョン/リビジョンを指すコレをなんと呼ぶか問題 - Qiita
これ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ commit 3a8461e04c04ed94a64df5d2cd7adbe764a2b8d8 Author: bigwheel <hogehoge@gmail.com> Date: Tue May 2 02:50:19 2017 +0900 Fix Process output method 同僚に「ちょっとそのコミットのこれ、slack DMで送ってー」なんて言うとき、あると思います。 これをなんと呼ぶか。 自分はコミットハッシュないしコミットIDと呼んできましたがどうやら正しい呼称ではなさそう。 先に結論 Git manual的には コミットのSHA-1 ないし コミット(オブジェクト)?の(オブジェクト名|SHA-1)が正しい。 もしくはPro Git - Bookには以下の表現もある。 コミッ
複数の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
git-secretsとhuskyを同時に使用する
はじめに 機密情報をコミットしないようにgit-secretsの設定をしようとしたところ、既にprecommit用のNode.jsライブラリhuskyがインストールされていたため、コンフリクトしてgit-secretsの設定ができませんでした。 どっちとも使いたかったので、それぞれ動くように工夫してみました。 2019/07/10 追記 会社の @aki77 さんが、もっと良い方法を見つけてくれたので、 そっちを「方法1」として追記しました！ 方法1: husky内でgit-secretsを呼び出す gitのhooks内では、デフォルトのままhuskyだけが呼ばれるようにしておき、 huskyでのチェック項目の1つとして、git-secretsを呼び出します。 lint-stagedも併用します。 git-secretsをグローバルにインストール
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作成 ⇩ 修正 ⇩
git switchとrestoreの役割と機能について - Qiita
先日8/16にGitバージョン2.23.0がリリースされました。 今回の目玉機能と言えば、新しいコマンド git switch と git restore ですね！ 本稿ではこちらの2つに絞ってどういう役割・位置づけの機能なのか英語ソースの引用も含めてご説明します。 TL;DR ブランチの変更は git switch ファイルの変更は git restore 今まで通り git checkout は使える 新機能は「実験的機能」なので今後変更の可能性あり 新機能が追加された背景 Highlights from Git 2.23によると、 git checkout に出来ることがあまりに多いため（ブランチ操作のほか、indexされたファイルの復旧、履歴上のファイルの取得など）、役割を明確に分けるためのコマンドが追加されたとのことです。 It turns out git checkout ca
明日から出来る重い Gitレポジトリへの対抗策 - Qiita
はじめに これは Git Advent Calendar 2016 の4日目の記事です。 今回の記事が対象とする大規模なレポジトリは、何年間も開発が続けられ、ファイル数、履歴、ブランチ、タグなど、全般的に肥大化してしまったようなレポジトリです。肥大化したレポジトリを何も気にせず扱った場合、以下のような不幸な自体に見舞われます。 終わらない git clone 止まらない disk full 帰ってこない git status これらは貴重な時間や資源だけでなく、エンジニアや周りの人の精神エネルギーまで持っていきます。 この記事においては、これらの原因を解決するための実践テクニックのうち、明日から利用できるものをまとめます。歴史を改ざんする系のもの、レポジトリ構成を変えるもの、アプリケーション層に入り込んだ改修などは今回の記事の範囲から割愛させていただきます。 また、巨大なレポジトリを扱うた
Flutterで1年間開発して利用した使えるライブラリ - Qiita
dependencies: sample_plugin0: ^1.0.0 sample_plugin1: path: ../sample_plugin1/ sample_plugin2: git: url: git://github.com/flutter/sample_plugin2.git ref: sample_branch sample_package1: git: url: git://github.com/flutter/packages.git path: packages/sample_package1 DeviceInfoPlugin deviceInfo = DeviceInfoPlugin(); if (Theme.of(context).platform == TargetPlatform.android) { deviceInfo.androidInfo.then
間違えて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を今すぐ変更しましょう。 対応が遅れてしまうと
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
【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
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actionsの実行・結果確認をターミナルで完結させるalias - Qiita
npmにライブラリをアップロードするときに.npmignoreで生成物を公開/制限するパターン - Qiita
あなたのプロジェクトに秩序をもたらす！git commit 支援ツールを作りました。 - Qiita
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
