Homebrewは定期的にupdateしないとupdateできなくなるんじゃないか説 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
組織横断で中央管理するGitHub Actions Workflowを整備する
この記事で紹介しているRequired workflowはRepository Rulesに移行し、2023年10月18に廃止されます。(気に入ってたけど) https://github.blog/changelog/2023-08-02-github-actions-required-workflows-will-move-to-repository-rules/ 先日、GitHubのアップデートによりRequired workflowが使えるようになりました。 これにより、 Organization内のリポジトリに対して共通のWorkflowを設定できるようになりました。 スマートショッピングでは、さっそく組織横断でWorkflowを中央管理するリポジトリを作成し、運用を始めたので共有します。 Required workflowsを管理するリポジトリの設定 組織のプライベートリポジトリ
GitHub 上のプロジェクトに Codecov を導入してカバレッジの変化量を可視化する | DevelopersIO
Codedov を使うと出された PR がどれくらいのカバレッジの変化量があるのかを簡単に可視化することができます。こうしたものが数値となって見えるようになると、積極的にテストを書くきっかけにもなるはずです。OSS であれば無料で利用でき、導入もとても簡単でおすすめです。 以前 rehype の プラグインを作成したのですが、そのプロジェクトでカバレッジの変化量を可視化したくなったため、Codecov を導入してみました。 対応内容の PR は次になります。 github actions で Codecov を使用する #13 Codecov の料金については公式サイトの Pricing に記載されおり、OSS であれば無料で利用できます。 事前準備 Codecov にサインアップして利用するリポジトリを setup する必要があります。 この手順については、公式ドキュメントの Quick
GitHub Actions - Support for organization-wide required workflows public beta - GitHub Changelog
GitHub Actions – Support for organization-wide required workflows public beta Today, we are announcing public beta of required workflows in GitHub Actions 🎉 Required workflows allow DevOps teams to define and enforce standard CI/CD practices across many source code repositories within an organization without needing to configure each repository individually. Organization admins can configure requ
インフラのGitOpsを可能にする「Pulumi Deployments」登場。コードをGit Pushするだけでインフラの構成変更を実行
インフラのGitOpsを可能にする「Pulumi Deployments」登場。コードをGit Pushするだけでインフラの構成変更を実行 コードを用いてクラウドをはじめとするITインフラの構成を定義できる、いわゆるInfrastructure as Codeを実現するオープンソースの「Pulumi」を開発するPulumi社は、インフラの構成を定義したコードをGit Pushすると自動的に定義に従って実行してくれる新サービス「Pulumi Deployments」を発表しました。 Introducing #Pulumi Deployments for remote execution of your Pulumi programs! Deploy by pushing to a @github branch Click to deploy from the Pulumi Service c
SSH commit verification now supported - GitHub Changelog
GitHub now supports SSH commit verification, so you can sign commits and tags locally using a self-generated SSH public key, which will give others confidence about the origin of a change you have made. If a commit or tag has an SSH signature that is cryptographically verifiable, GitHub makes the commit or tag "Verified" or "Partially Verified." If you already use an SSH key to authenticate with G
すぐに始められる！GitHubコミュニケーションでチームの情報共有コストを下げよう - Money Forward Developers Blog
こんにちは。あるいはこんばんは ＜VTRyo＞です。 2022年6月に一人Product SREだった僕もようやくメンバーが増え、チームとしてコミュニケーションを成立させねばという気持ちになってきました。 タスク管理ツールといったチームに閉じているものは基本的にチーム単位で選定できるのがマネーフォワードの良いところです。 我々マネーフォワードクラウドHRソリューションのSREグループ（以降SREグループと表記）では、GitHubを使って以下のことをしています。 チームの概要情報（ミッション、責任範囲、スキルスタックなど） タスク管理 メンバー間の情報共有 所有するコードの管理（issue template、GitHub Actionsなど） 今回は、社員の方からこんな声を頂いたことをきっかけに執筆しています！ なぜ、チームコミュニケーションをGitHubに寄せたのか 最も強いモチベーション
GitのWorking TreeとIndexが分かる記事 - Qiita
こんにちは。 この記事は、GitのWorking TreeやIndexについて分かるようになる記事です。 なぜコミットの前にgit addするのか分からない git restoreで何が復元されるのかが分からない git reset で何がリセットされるのか分からない このような疑問を持つ人向けに、Working Tree (Working Directory)とIndex (Staging Area)について解説していきたいと思います。またよく使うGitコマンドがこれらにどう作用するかについても見ていきたいと思います。 用語の定義はこちらのGit公式リファレンスから引用しています。 今回使うリポジトリの準備 あまりGitリポジトリを初期化したことのない方が読む可能性を考え、このセクションに今回使うリポジトリの準備方法を書いておきます。折りたたんでおきますので、見たい方のみご覧ください。
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき
git add の対話モード
すると、対話モードが開始されます。対話モードでは、git statusと似た「どのファイルがステージに追加されているか・されていないか」といった情報と、この対話モードで実行できるコマンドの一覧が表示されています。 ❯ git add -i staged unstaged path 1: unchanged +4/-0 Cargo.lock 2: +1/-0 nothing Cargo.toml *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> status は git status とほぼ同等の目的を達成できますが、ステージした変更が左側、ステージしていない変更が右側に表示されます。直感的ですね。 update は、実行後ファイ
僕が使ってる git コマンドのエイリアスを紹介 - Qiita
はじめに @ohakutsu が alias の記事を書いていたので私も利用している alias を書いてみました 設定してる Git aliase .gitconfig や .zshrc は dotfiles レポジトリに保存しています その中で Git に関連するもの ( かつ よく使うもの ) だけ記載します Zsh [alias] ad = add ci = commit co = checkout cop = !"git branch --all | tr -d '* ' | grep -v -e '->' | peco | sed -e 's+remotes/[^/]*/++g' | xargs git checkout" d1 = diff HEAD~ d2 = diff HEAD~~ d3 = diff HEAD~~~ d4 = diff HEAD~~~~ d5 = dif
Write Better Commits, Build Better Projects
EngineeringWrite Better Commits, Build Better ProjectsHigh-quality Git commits are the key to a maintainable and collaborative open- or closed-source project. Learn strategies to improve and use commits to streamline your development process. How often have you found yourself thinking: What’s the point of this code? Isn’t this option deprecated? Is this comment out-of-date? I don’t think it descri
.gitignoreでフォルダの構造のみを保持したい場合のより良い書き方 - Qiita
例えばWebサイトのバックエンドでアップロードされたファイルを/storage/フォルダ内に入れているとする。その場合、Gitではアップロードされた/storage/内の各ファイルは無視したいが、/storage/フォルダ自体は残しておきたいということがよくある。しかしGitで管理できるのはファイルだけなので、ファイルが一つも入っていないフォルダをGitで表現することはできない。そのために.gitkeepというダミーの空ファイルを作成してGitで管理することでフォルダを保持するということが頻繁に行われている。 ここではそのような場面でこれまでよく解説されている.gitignoreの書き方とは異なる、より柔軟で単純な書き方を発見したので解説する。 結論 保持したいフォルダ構造を作成。ここでは/storage/フォルダ以下のフォルダ構造をgitで保持したいとする。 各末端のフォルダに空のファイ
GitHubの使い方を学ぶ「GitHub Skills」が無料公開。GitHubを実際に操作してMarkdown、Pages、Pull Requests、マージのコンフリクト解消などを体験
GitHubの使い方を学ぶ「GitHub Skills」が無料公開。GitHubを実際に操作してMarkdown、Pages、Pull Requests、マージのコンフリクト解消などを体験 GitHubは、実際にGitHubを操作しながらGitHubの使い方を学べる無料の教材「GitHub Skills」を公開しました。 Expand all you know about the GitHub platform. We're introducing GitHub Skills, a new learning experience integrated into the GitHub UI, backed by GitHub Actions. Try it out today! https://t.co/XnqCYdVqBL — GitHub (@github) June 6, 2022 G
全社的に会社用GitHubアカウントを廃止した件 - ZOZO TECH BLOG
はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
cherry-pick 運用の地獄から這い上がった話をしよう - Qiita
はじめに はじめに断っておくが、こんな生易しいものじゃない。本当に地獄の沙汰である。 状況と問題点 筆者が参加しているプロジェクトでは、ブランチの運用が cherry-pick で行われていた。Git Flow でも GitHub Flow でもない。言うなれば、Cherry-pick Flow である。 Git Flow について Git Flow なら、本番リリースする際にまず develop ブランチからリリースブランチを切る。 それを master にマージする。 そして、master へのマージ後のマージコミット (M1) を develop に逆輸入すれば、基本的に develop ブランチが Fast-forward な状態となる。 ホットフィックスの場合も同様である。 コミットの取りこぼしなど起きるわけがないし、リリース作業自体もやることが明確でわかりやすい。 Cherry
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【git】特定のブランチを除外して、ローカルブランチを一括で削除するコマンドの解説 - Qiita
https://twitter.com/JI/status/1546948817462800384?t=IGUvoKWyjc2BUfwitHZOKg&s=09