結局 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 ブランチ バグ修正など緊急時に対応するためのブ
コミットメッセージを書く時にgitmojiを使うのをやめた話 - Pepabo Tech Portal
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
Rubyメソッドの実装を参照するためのいくつかの方法 - BOOK☆WALKER inside
こんにちは、メディアサービス開発部Webアプリケーション開発課のシゲタです。普段はRuby on Railsによるバックエンドの開発に携わっています。 先日とあるRubyメソッドの仕様が気になりコードリーディングに挑戦したのですが、当該メソッドがどこに何という名前で定義されているのかわからず、定義にたどり着くのに時間を要してしまいました。 同じようなポイントでつまづいた方、これからコードリーディングを始めようと思っている方のために、本記事ではRubyメソッドの実装を参照する方法をいくつかご紹介したいと思います。 pry-docで参照する リファレンスから参照する Rubyリポジトリをgit cloneしてローカルから参照する githubで検索して参照する まとめ 最後に pry-docで参照する pryにpry-docをインストールして$コマンドを使うことで、C言語で実装されたRubyメ
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
Homebrew のリポジトリを GC してサイズを削減する - ymyzk’s blog
Homebrew のリポジトリで GC を実行して, リポジトリのサイズを削減できるサブコマンド brew git-gc を作成しました. Homebrew と Git Homebrew 自体や Formula, Tap はすべて Git で管理されています. これらは多くのファイルを含み頻繁にアップデートされるため, リポジトリのサイズが肥大化する傾向にあります. Git リポジトリは GC を実行することで, 一つのパックファイルに圧縮してリポジトリのサイズを削減することが出来ます. GC はリポジトリ内で git gc とすれば実行できるほか, 一定の条件に達すると自動で実行されます. 詳細はこちらが参考になります. Homebrew は複数の Git リポジトリで構成されているため, それぞれのリポジトリで git gc を実行するのは面倒です. brew git-gc は Ho
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
Git - メンテナンスとデータリカバリ
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
Gitlab-flowの説明 - Qiita
Gitlab-flowのグラフ Gitlab-flowのブランチ説明 feature/hotfixは機能開発、不具合対応ブランチです masterはメインのブランチ pre-production(オプションブランチ)はリリース前のテスト用(git-flowで言うreleaseブランチ) productionはリリース済みのコード置き場 Gitlab-flowの流れ 機能開発 機能開発するとき、masterブランチからfeature/NAMEブランチを切って開発進む 開発が終わったらfeatureブランチからmasterにMerge Requestを作成します。 masterをステージング環境へデプロイして、確認する プリプロダクションへデプロイしたい場合、masterブランチからpre-productionブランチへのMerge Requestを作成します。マージ済みになるとデプロイする
git-flow 図解 - Qiita
git-flow is Vincent Driessen さんがブログで公開した A successful Git branching model のこと 元記事：A successful Git branching model 日本語訳： A successful Git branching model を翻訳しました または、A successful Git branching modelを補助するためのツールの名称 git-flow cheatsheet ブランチの運用ルール、命名規則を設けることで、 複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる もっとシンプルなルールにしたものに、GitHubFlowがある 元記事：GitHub Flow 日本語訳：github-flow.ja.md 小さなサイクルでデプロイするケース向き この記事では、A success
巨大Subversionリポジトリを一人こっそりGitで扱いたい - Qiita
会社のプロジェクトのバージョン管理はSubversion。しかも、10G弱でコミット数も相当数あるリポジトリ。だけど、Gitを使いたい！と思って方法を模索したのでそのメモです。Gitをよく知らないのもあり、もっと良い方法があれば教えていただけると幸いです。 背景 会社のプロジェクトではSubversionが使われています。しかし、世の中ではGitの方が主流（？）ということもあり、自分もGitを使って開発をしたい、と思いました。 新人のペーペーの力でSubversionからGitへ移行することもできないので、なんとか自分だけでもGitを使えないものかと考え、調査・環境構築を行いました。 使用環境 Windows 7 + MSYS2 git-svn の利用 「SubversionリポジトリをGitで扱う」ことに関しては、ネットに情報が結構あったので、比較的すんなりできました。 使用するのは g
スタートアップが初めてGitHubを使う際の手順 - 素数好きの最高技術責任者のブログ
先日、スタートアップの方からGitHubの使い方について質問を受けたのでまとめてみます。この記事を読んで役に立つ可能性があるのは これからGitHubを使ってみようとしている ソースコードを管理したいが公開はしたくない エンジニア歴が短かったり非エンジニアだったりする という方々に対してなので、これらに当てはまらない方はそっとブラウザを閉じていただければと思います。 まず最初に、「Organizationを作る or 作らない」によって手順が若干異なるので、決めてしまいましょう。Organizationというのはいわゆる「会社用のアカウント」みたいなもので、権限の管理（◯◯さんはソースコードを見るだけ、△△さんはソースコードを改変することもできる、等）が楽になるというメリットがあり、毎月の利用料金がかさむというデメリットがあるもの、と考えていただければ概ね間違っていないかと思います。 リポ
Linuxで暗号鍵を管理する
SSH 用の暗号鍵を格納しておいたり、パスワードを覚えておくことは大変です。しかし、悪意のハッカーや侵害行為が蔓延している世界では基本的なセキュリティの備えが大事です。一般ユーザーの大半にとって、つまるところパスワードを記憶することであり、パスワードを覚えてくれるプログラムを探すことになります。IT 分野で仕事をしている我々は、より高いレベルが必要です。パスワードだけではなく、SSH 用キーも扱う必要があります。 次のような状況を考えてみましょう。クラウド上に git リポジトリを扱うサーバーを持っています。作業するためのコンピューターを数台持っています。各コンピューターから、サーバーにプルしたりプッシュしたりします。git は SSH を使うように設定しています。git が SSH を使う場合、SSH コマンドでサーバーのコマンド ラインを実行する時と同じ方法を用います。すべてを設定する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubみたいなサービスを今一から作るならどの言語・フレームワークを使うか
これならしんどくないGit運用の考え方
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25
GitHubでプロジェクトを共有してみよう (1)
git init | Atlassian Git Tutorial