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
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
この記事は はてなエンジニア Advent Calendar 2021 の16日目の記事です。昨日は id:masayosu の はてなにおけるCloudNative推進会の活動について でした。 サブ会という仕組みで専門領域における情報共有や深い議論ができるようになっていて、僕もスマート会*1に所属しています はてなではリリースブランチへのマージPRの管理にgit-pr-releaseをよく使っています。 git-pr-releaseは現在のリリースブランチのheadとの差分にあるPull Requestを一覧して、リリース前にチェックできます。このgit-pr-releaseはとても便利で、git-flowのようなブランチ戦略に非常にマッチしています。 一方、リリースブランチのないGitHub Flowのようなブランチ戦略を取った場合、リリースブランチが作られないため、マージ先のブラン
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある(Splitting a subfolder out into a new repository - GitHub Docs)。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
オープンソースのプログラミング言語であるPHPの開発者らが使用していたGitサーバーに何者かが侵入し、PHPのソースコードにバックドアをしかけていたことが判明しました。ハッカーは悪意のあるコミットをプッシュする際、PHPの開発者であるラスマス・ラードフ氏らになりすましていました。 php.internals: Changes to Git commit workflow https://news-web.php.net/php.internals/113838 PHP's Git server hacked to add backdoors to PHP source code https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 この記事は、NTT Communications Advent Calendar 2021 2日目の記事です。 今回は社内のソースコードを GitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。 背景 きっかけは「NeWork のソースコードが見たい」という私の思いつきでした。 これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。 GitHub (Team plan) Git
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営&翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう?って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
GitHubによるDockerコンテナレジストリ「GitHub Packages Container registry」が正式サービスに GitHubは、Dockerイメージの共有や公開ができるリポジトリサービス「GitHub Packages Container registry」が正式サービスとなったことを発表しました。 Container registry for GitHub Packages is now generally available! Check out how it can improve your development experience.https://t.co/qCe9DteR6d — GitHub (@github) June 21, 2021 GitHub Container Registryは、GitHubでソフトウェアパッケージを扱う機能である「G
あなたのパフォーマンスを倍にする Frontend Ops はいかがですか.md あなたのプロジェクトに Frontend Ops を。 現状 Full Plan: 1ヶ月 120万 秘密保持契約を行い、ソースコードを分析し、改善を行います 現在受付可能なのは、1月以降です 調査費用は50万~になります Lightweight Plan: 外部計測のみ 50万 秘密保持契約抜きで外部からの監視を行います 分析結果を結果を御社のエンジニアを含めて説明します 報告は社内勉強会形式にすることも可能です 分析を受け付けられるのは特殊な認証がないURLになります 認証やドメイン理解を伴うURLは要相談になります [経営者の方へ] ウェブサイトが遅くなっていませんか?機能追加が遅くなっていませんか? 私 @mizchi は Node.js とフロントエンドのエキスパートです。もし私を知らなければ、御社
GitHubは、GTP-4ベースのAIを用いた開発支援機能「GitHub Copilot Chat」を、GitHub Copilot for Businessユーザー向けに限定パブリックベータとして公開すると発表しました。 GitHub Copilot Chatは、今年3月に発表された同社のビジョン「GitHub Copilot X」で登場が予告されていた機能の1つです。 現在提供されているGitHub CopilotはGPT-3のAIをベースに、コードエディタ内でプログラマがコメントを記述するとそれに基づいてコードを自動生成する機能などを提供しています。 「GitHub Copilot X」では、強化されたAIであるGPT-4を用い、さらに高い精度でのコード生成やバグの指摘などを始めとする、以下のさまざまな新機能などを備えると説明されていました。 コードエディタ内でAIとテキストチャット
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか? それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール (「How to Write a Git Commit Message」の和訳記事) https://
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
GitHub Advent Calendar 2024の14日目の記事です。昨日はwa-chan222さんの未経験から始めたGitHub活用の基本と学びでした。 はじめにフューチャー社内の有志メンバーでGitブランチフローの規約を作成しました。 ひとまずは形になったので紹介します。 Gitブランチフロー規約 | Future Enterprise Coding Standards ※GitHub/GitLabを利用し、トランクベース開発を採用しないアプリケーション開発を想定しています。 内容へのフィードバックは、Issueかツイッター宛にメンションを入れてコメントを貰えると幸いです。 なぜ今更Git?Gitは2005年に公開され、2007年のGitHub登場以降、バージョン管理ツールとして爆発的に普及しました。現在では、業界のデファクトスタンダードと呼べるほどの地位を確立しています。 公開
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
これは何? GitHub ActionsからAWSのリソースへのアクセスする際にはなんらかの認証情報が必要です。 一昔前は,GitHub Actions Secretsに保存したAWSのアクセスキーとシークレットを埋め込む形が一般的でした。 しかし,最近この方法は非推奨になっています。 本記事では,Open ID Connectの技術を利用することによってよりセキュアにGitHub Actionsを使用する方法について紹介します。 OpenID Connectとは https://www.openid.or.jp/document/ より抜粋 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-Us
こんにちは、つくぼし(tsukuboshi0755)です! 現在 DevelopersIO 2023の一環として、YouTube でのビデオセッションが公開されています。 今回私の方では、「AWSとGitHubを用いたパターン別CI/CD構成解説」というタイトルで投稿しました。 概要 AWS基盤でCI/CD構成を作りたいが、どのようなサービスを組み合わせて作るべきだろうか? 特にCI/CDに関する有名なサービスとして、AWSのCodeシリーズとGitHubがあるが、両者の使い分けはどのようにすれば良いだろうか? そんなお悩みをすっきり解決するため、様々なパターンを想定したCI/CD構成をまとめて解説します。 動画 スライド 参考サイト ECS用のCDパイプラインに対する考察 CodeDeploy / GitHub Actions|Rails × CloudFormation ハンズオン A
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
merge_vs_rebase_vs_squash.md I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again. I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who sa
GitHub Skills Learn how to use GitHub with interactive courses designed for beginners and experts. Start with Introduction to GitHub
はじめに はじめまして、yasuda_naoto と申します。 未経験から WEB エンジニアとして活躍するために RUNTEQ というプログラミングスクールで学習しています。 概要 RUNTEQ ではミニアプリ作成会というものがあり、2023 年の 8 月に青春をテーマにたくさんのアプリが投稿されました。 その際に、愚かな私は「面倒だからgit add .してそれらを一気に commit して push すればええやろ」という、プログラマにあってはならないめんどくさがり精神で作ったアプリをリモートリポジトリに push してしまったのです。 その際に起きた悲劇を再現します。 更に、同じ轍を踏まないように、それを防ぐ方法と、もしあなたが同じしくじりをしてしまったら、そこから立て直す方法をご紹介します。 要点 細かく add & commit しなかったばかりに push が途中で進まなくな
オープンソースによるFirebase代替を名乗るBaaS(Backend as a Service)「Supabase」が正式サービス化を発表しました。 Supabaseはこれまで約4年間ベータ版としてサービスを提供してきました。現在は100万以上のデータベースをホストし、新規データベースも1日あたり2500以上増加しており、モバイルアプリケーションからエンタープライズ用途まで十分な機能と安定性、スケーラビリティが実証されたとしています。 Supabaseの主な機能はデータベースや認証、ファイルストレージなど SupabaseはBaaSとして主に以下のマネージドサービス群から構成されています。 PostgreSQLによるデータベースサービス 認証サービス ファイルストレージ エッジロケーションにおけるNode.jsDenoベースのサーバレス基盤 マルチプレイヤーゲームなどに対応するリアルタ
クレデンシャル含むソースコードをChatGPT等のクラウドLLMサービスにアップロードしないでください。 今回のプロンプトはオープンなリポジトリのみを対象としており、シェルスクリプトが実行される環境もChatGPT側のクラウド上のサンドボックス内のみを想定しています。 ローカル環境では以下のシェルスクリプトをそのまま実行せずに、ご自身が作成したシェルスクリプトを利用してください。 以下はソースコードのプロジェクトルートで実行することで、ソースコードのダンプを.txt形式でダンプするシェルスクリプトです。 \`\`\` #!/bin/bash # バイナリファイルかどうかを判定する関数 is_binary_file() { local file="$1" local file_output file_output=$(file "$file") if [[ "$file_output" ==
GitBookはMarkdownからドキュメントページや書籍を作成するツールですが、 以前OSSで公開されていたGitBook(legacy)はDeprecatedとなって開発は止まっています。 ⚠️ Deprecation warning: As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is no longer under active development. All content supported by the CLI are mostly supported by our GitBook.com / GitHub integration. Content hosted on the legacy.gitbook.com will continue worki
はじめに サイバーセキュリティ推進部の吉田です。普段は、CSIRTメンバーとしてAWS環境や各種端末のモニタリング、セキュリティインシデント対応、社内からのサイバーセキュリティに関する相談対応などの業務を行っています。 2023/05/10 追記 GitHubのアップデートによって、プライベートリポジトリのIssueやPull Requestsに新たにアップロードされたファイルは、権限を持たない外部からは参照できなくなったようです。詳細につきましては、以下のGitHubのブログをご確認ください。 https://github.blog/changelog/2023-05-09-more-secure-private-attachments/ 概要 GitHubのIssueやPull requestsに添付した画像はWebにアップロードされ、パブリックなURLが割り当てられます。このURLは
// 👀 https://docs.microsoft.com/ja-jp/windows/terminal/customize-settings/global-settings { "$schema": "https://aka.ms/terminal-profiles-schema", "defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "theme": "dark", "copyOnSelect": false, "copyFormatting": false, // ダブルクリックでパスを丸ごと選択したいため "wordDelimiters": " ", // 👀 https://docs.microsoft.com/ja-jp/windows/terminal/customize-settings/profi
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中に
いまさら聞けない「CI/CD」の意義――GitHubとGitHub ActionsでCI/CDを試してみよう:GMOペパボに学ぶ「CI/CD」活用術(1)(1/2 ページ) GMOペパボにおけるCI/CD活用事例を紹介する本連載。第1回は組織でCI/CDを導入する目的と意義を整理し、GitHub/GitHub Actionsを利用してCI/CDを実践する方法を紹介します。 ITがビジネスの中心となる中で「CI/CD」(継続的インテグレーション/継続的デリバリー)というキーワードは広く浸透してきています。しかし、CI/CDを導入、活用しているかは企業や現場で差があるのではないでしょうか。 CI/CDを実践した際のパフォーマンスは、組織全体のパフォーマンスにも相関があることが知られています。本連載では、筆者らが所属するGMOペパボでどのようにCI/CDを取り入れて開発プロセスの効率化や組織全体
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
こんにちは。 株式会社アカツキゲームスで ATLAS というチームに所属してゲーム内通貨管理基盤の開発及び運用を行っています、なかひこくん (@takanakahiko) です。 最近バイクを買いました。 私の担当するゲーム内通貨管理基盤の開発現場では、「マージ待ち」なるものが存在しました。 今回は、その課題を GitHub の新機能である merge queue で解決した方法を紹介します。 この記事は 2023-07-20 時点での merge queue 及び GitHub Actions の仕様に則ったものです。 今後のアップデートによりこの記事の内容が正しくないものとなる可能性があります。 「マージ待ち」とは 私の担当するゲーム内通貨管理基盤の GitHub リポジトリでは PR のマージ後に走る、同時に実施できない 15 分程度の E2E test が存在しました。 すなわち
GitとGitHubを分かりやすく! 組織開発で生かすツール選択とプロジェクト進行を解説 分散型バージョン管理システムのGitと、そのホスティングサービスとしてプルリクエストなどの機能をもつGitHubは、ソフトウェア開発環境として広く普及しています。本記事ではGitやGitHubの考え方や使い方の基本を解説するとともに、実際のプロジェクトにおける開発の進め方を簡単に紹介します。 この記事を読み始めているということは、GitやGitHubに興味をお持ちのことでしょう。Gitはバージョン管理システム、GitHubはGitのホスティングサービスで、いずれもソフトウェア開発を中心に利用されています。近年では、2018年にGitHubの運営会社がMicrosoft社によって買収されたことでも話題になりました。 この記事では、GitやGitHubの基本的な使い方や考え方を解説します。また、実際の開発
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く