結局 Git のブランチ戦略ってどうすればいいの？ - Qiita
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
Git LFS からDVC(Data Version Control) に移行した話 - Qiita
主旨 従来、Git LFSを用いて機械学習のデータを管理してきた。最近、その代わりにDVCを使うようになったので、その過程で感じたことを示す。DVCをどう使っていいのか、使い方に迷っている人の参考になれば幸いです。 Git LFS の状況 機械学習のデータを指定のフォルダ以下をファイル単位の粒度で管理できるツールである。 変更があったファイル名を知ることができるし、テキストファイルの場合にはdiffを表示することもできる。 GithubなどでPRの差分をwebブラウザで表示させる場合には、画像ファイルの変更前と変更後とを表示させることもできる。 「Git LFSは、リポジトリに実際のファイルではなく、ファイルへの参照を保存することで大きなファイルを扱います」 通常のGitとの違いは、LFSで管理するファイルをファイルパターンで指定して、そのファイルについては、ファイルへの参照を保存するよう
Popular git config options
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
次世代バージョン管理システム jj を勉強するスレ
(2024-02-03: 追記) 本内容は、Book: 君のレポジトリを領域展開 - 次世代バージョン管理システム Jujutsu の世界 にまとめなおしました ちょっと前にマストドンかどこかで、存在を知った次世代バージョン管理システム jj (Jujutsu-呪術)について勉強している。 ホームページ：Jujutsu docs チュートリアル：Tutorial and Birds-Eye View - Jujutsu docs Git との比較：Git comparison - Jujutsu docs レポジトリ：martinvonz/jj: A Git-compatible VCS that is both simple and powerful 日本語の解説ページが見つからなかったため、英語のレポジトリのドキュメントをブラウザの翻訳アドオンを使って読まざるを得ない。 開発者の ma
Merge vs. Rebase vs. Squash
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
squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
SOPS: Secrets OPerationS！ | MoT Lab (GO Inc. Engineering Blog)
こんにちは、技術戦略部 SREグループのカンタンです！ データベースのパスワードやAPIサーバの認証情報など秘密情報をきちんと管理しないと漏洩が発生しセキュリティインシデントに繋がる可能性が高いでしょう。 数ヶ月前から、SREグループが扱っている秘密情報の管理方法をgit-cryptからsopsに切り替えました。運用が楽になり、セキュリティレベルが向上し、非常に満足しているためsops自体とSREグループの使い方を紹介させていただきたいと思います。 背景SREグループでは、Terraform用の設定やKubernetesで動いているサービスの環境変数など秘密情報を暗号化した上で一つのgitリポジトリで一元管理しています。秘密情報を利用する際、暗号化ファイルを復号してからgrepなどで検索したり、Terraformプロジェクトを適用したり、環境変数をKubernetesのSecretに反映し
初学者の私がGitを理解するために、この順番で読めばよかったと思った記事の順番 - Qiita
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む（コマンドなし） ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
git-secretsを使用してAWSアクセスキーのコミットを防ぐ方法の紹介 | DevelopersIO
CX事業本部Delivery部のアベシです。 この記事ではgit-secrets使用してAWSアクセスキーのコミットを防止する仕組みの導入方法について紹介します。 弊社の以下のブログにあるような実際の出来事では、アクセスキーが流出してから10分程度でマイニングに不正利用されてます。※ 弊社作業による流出ではありません。 【実録】アクセスキー流出、攻撃者のとった行動とその対策 このように、アクセスキーは流出するとすぐに利用されてしまうほど狙われやすい認証情報となっています。 このような被害を無くすために、AWSを使う方には是非今回のような対策をしていただけたらなと思います。 git-secretsについて git-secretsに登録したパターンに合致するシークレット情報が、コードに含まれていないかチェックできます。 GitHub - awslabs/git-secrets 実装方法の概要
git-sim: Visually simulate Git operations in your own repos
Coding Essentials Guidebook for Developers This book covers core coding concepts and tools. It contains chapters on computer architecture, the Internet, Command Line, HTML, CSS, JavaScript, Python, Java, SQL, Git, and more. Learn more! Decoding Git Guidebook for Developers This book dives into the initial commit of Git's C code in detail to help developers learn what makes Git tick. If you're curi
git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
.gitignoreでフォルダの構造のみを保持したい場合のより良い書き方 - Qiita
例えばWebサイトのバックエンドでアップロードされたファイルを/storage/フォルダ内に入れているとする。その場合、Gitではアップロードされた/storage/内の各ファイルは無視したいが、/storage/フォルダ自体は残しておきたいということがよくある。しかしGitで管理できるのはファイルだけなので、ファイルが一つも入っていないフォルダをGitで表現することはできない。そのために.gitkeepというダミーの空ファイルを作成してGitで管理することでフォルダを保持するということが頻繁に行われている。 ここではそのような場面でこれまでよく解説されている.gitignoreの書き方とは異なる、より柔軟で単純な書き方を発見したので解説する。 結論 保持したいフォルダ構造を作成。ここでは/storage/フォルダ以下のフォルダ構造をgitで保持したいとする。 各末端のフォルダに空のファイ
Terraform でAWS 環境にDockle + git-secrets を組み込んだCIを構築する - Qiita
はじめに コンテナセキュリティのガイドライン NIST SP800-190(アプリケーションコンテナセキュリティガイド) では、イメージのリスクの1つとして 「イメージの設定の不備」 について言及されています。 さらに、NIST SP800-190 では、このリスクへの対策として、 「セキュアな設定のベストプラクティスへの準拠を検証および実施するためのツールとプロセスを採用すること」 を推奨しています。 本記事では、この 「イメージの設定の不備」 へのリスク対策ツールとして、Dockle とgit-secrets を採用し、このツール群を組み込んだCI パイプライン(ビルドのプロセス)をTerraform でAWS 環境に構築する方法を記載しています。 コンテナイメージのセキュリティ対策の一例として参考になれば幸いです。 Terraform で構築する全体構成図 構成の概要 Dockerf
個人的によく使うGitエイリアス、zshキーバインド - 本日も乙
最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは（クラウドしかできない）ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ
Git Credential Manager: authentication for everyone
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - altsem/gitu: A TUI Git client inspired by Magit
gitでstashが面倒なあなたにautostash
コミットメッセージ規約 「Conventional Commits」を導入してみよう！ / Let's use Conventional Commits
