Gitブランチフロー規約 | Future Enterprise Coding Standards
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに 本規約はGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意すること。 GitHub ／ GitLab の利用トランクベース開発（フィーチャーフラグ）を 採用しないライブラリではなく、アプリケーション（CLIツール、Webアプリケーションなどの）開発で利用する免責事項 有志で作成したドキュメントである フューチャーアーキテクトには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された設計開発の方針が存在する。本規約はフューチャーアー
【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
git commit --fixupを使いましょう - Don't Repeat Yourself
発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
日々勉強した事を振り返る為に er_repository という Git リポジトリを作って毎日草を生やす話 - Qiita
■ はじめに 説明 普段は、Notion というツールでデータベースを作って毎日の振り返りを行ってます。 又、月初と月末には目標と結果もまとめて来月に活かしてます。 ざっと構成としては以下のような感じです。 2024/01 ページ — 目標 — 実績 — 01/01 — 01/02 — 01/03 — etc… これは誰かに見せるとかではなく、完全に自分用の日報？みたいなものです。 今月は、こういった事が頑張れたな、積読してる書籍を◯本消化出来たな、などです。 このまま Notion で管理しても良いのですが、せっかくなので Git リポジトリ作ってそこに毎日 push すれば、毎日草生やせるじゃんと閃いたので試験的にやってみようと思いました。 毎日の振り返り、everyday_retrospectiveを略して er_repository とします。 とりあえず事前準備としてやる事として
初心者向けgitのあれこれ - Qiita
はじめに こんにちは！ 今年の DMM WEBCAMP Advent Calendar 202312/4の担当します。 今回のQiitaの執筆が初めてになります。 そこそこの頻度で、Gitで躓く人を見かけるので今回書いてみました！ 目次 そもそもGitってなに？？ git add /git commit が行っていること よくわからない時に使えるコマンド 今まで説明したコマンドの優位性 エラーを紐解く 1. そもそもGitってなに？？ 簡単に説明すれば、バージョンを管理するもの もっと詳しく言えば、差分を管理するもの 差分とは、二つのデータ集合を比較して、両者の間で異なっている部分のことです 多分、これだけだとイメージが付かないと思うので例 この時の差分は、bbbになります(gitだとスペース1個単位で認識されます。) git diffコマンドを使用すると差分のあるファイルを表示してくれま
【Rails初心者向け】ブランチを切り替える前に気を付けたいDBマイグレーションの注意事項 - Qiita
はじめに Railsはとても便利なwebアプリケーションフレームワークです。 gitも非常に便利なソースコード管理ツールです。 この2つのツールがあれば、初心者でも効率良くwebアプリケーションを開発できます。 ただし、学習用の小さなアプリケーションを一人で開発しているときはブランチはひとつかふたつで十分ですが、業務などで大きなアプリケーションを複数人で開発する場合は、複数のブランチで並行して開発が進める必要が出てきます。 こういうケースではデータベースマイグレーションを正しく理解し、正しく扱わないと、開発環境やソースコードが混沌としてきます。 Rails初心者の多くはこうした知識を持たないまま、チーム開発に参加しがちです。 この記事では「学習用の小さなRailsアプリケーション」を卒業し、「チームで開発する大きなRailsアプリケーション」に足を踏み入れる前に知っておくべき、データベース
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
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
Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
Git for Data「Dolt」というDBの話
ここ最近、何やらデータベースの相談をされることが何やら多くなってきたmasamikiです。 今、とあるプロダクトの開発をしようと、要件まとめたり設計したりたりしてるのですが、この仕組みをやるためには…version管理いるなぁ…gitが欲しいなぁ……となってます。 そして、調べてみたところ、2年も前のものですがこんな記事を見つけました。 「DoltとDoltHubが我々の結論だ」とおっしゃってます。 Doltとは Doltは、Gitリポジトリと同じように、フォーク、クローン作成、ブランチ、マージ、プッシュ、プルできる最初で唯一のSQLデータベースです。（← by Google翻訳） おぉ、まさしく、そのままんま、これだ。 他にも、GitRows とかも使えそうかな…と思ってみていたものの、どうやら今の要件にあうのあはDoltっぽそう。 上記事だと、他にもdata.world（Microso
ghを導入したらDXが爆上がりした話 - Qiita
GitHubの公式CUI ghコマンドを使うようになってから、開発してく中でのストレスが減ったなーと気づきがあり、これ結構DX（開発体験）上がったんじゃね？と思ったので記事にしてみます。 想定読者 GitHubのPull Request（以下、PR）をよく使う方 GitHubのCUIなのでGithub使ってない方には興味なさげな話です その中でもPRにフォーカスした話をしようと思ってます ghコマンドを使ったことがない方、使い始めの方 ghコマンドの基本的な話をするので、バリバリ使いこなしてる方にはそんなの知ってるわって話かもしれません zsh使ってる方に特にオススメします 詳細は後述ですがzshとの相性が抜群です zsh使ってない方はラッパー用意するとか一手間加えることになるかもです エンジニアの方 違う方のDX(Digital Transformation)の話は一切出てきません🙇
Write yourself a Git!
This article is an attempt at explaining the Git version control system from the bottom up, that is, starting at the most fundamental level moving up from there. This does not sound too easy, and has been attempted multiple times with questionable success. But there’s an easy way: all it takes to understand Git internals is to reimplement Git from scratch. No, don’t run. It’s not a joke, and it’s
個人開発者のためのコマンドラインGit使いこなし術
英語で先に書いてから翻訳しています どうも個人アプリ作家のTAKUYAと申します。 Gitはコードベースや変更履歴の管理に必要不可欠なツールです。たとえ個人でアプリを開発していたとしても。 僕はデスクトップとモバイルの両方で動作する、InkdropというMarkdownのノートアプリを独りで開発しています。 当アプリはデスクトップ版はElectron、モバイル版はReact Nativeで作られています。 僕は開発作業は基本的にtmuxとvimでターミナル上で行っています。vimによるJavaScriptコーディングのためのセットアップについては前回シェアしたとおりです。 本稿では、僕のGitのワークフローについてご紹介したいと思います。 内容はすでにGitの基本をご存知の方向けとなります。 Gitの操作も基本的にはターミナル上で行っています。 色んなGUIベースのGitクライアントアプリ
git submodule はトモダチ！怖くないよ！ （チートシート付き） - エムスリーテックブログ
この画像は本文とは関係ありません。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 みなさん、git submodule コマンドは好きですか？git submodule は特定の状況下では便利なコマンドです。 社内アンケートでも25%が怖いという結果に しかし、なぜか世間にはgit submodule が怖いという人が相当数いるようです。推測ですが、git submodule は動作モデルや使用手順が誤解されがちなところがあり、それで「怖い」と思われているのないでしょうか。git 本体でも昔そんなことがありましたよね。 この記事では git submodule の誤解を解き、適切な使い方を解説します。また、記事の最後にチートシートをつけます。 git submoduleはトモダチ！怖くないよ！ git submodule って何？ 誤解1 「プロジェクトが大きくなっ
VSCodeでgit add -p を快適に行う - Qiita
git add -p 便利ですよね。ファイルの変更箇所の一部だけをコミットしたいときによく使います。 ですが、自分はコマンドラインで git add -p する操作がどうにも慣れず、億劫に感じていました。 そこで Visual Studio Code の機能を使えばもっと直感的で快適に git add -p ができることを知りましたので紹介したいと思います。 動作イメージ こんな感じで快適にできるよっていうイメージを伝えるためにgifを作ってみました。 このサンプルは3行の変更があるときに、git add -p を利用して「1行目をコミット」してから「2,3行目をコミット」する例です。 git add -p する手順としては下記になります。 addしたい箇所を選択する。 addする変更箇所が1行の場合はその行にカーソルがあればOK（↑の例でいう「1行目を変更」のコミットのやり方） 複数行の
gitのdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
git checkoutするブランチ名をpecoで選択する git エイリアス - Qiita
ブランチ選択面倒ですよね git branch して、あるいは git branch --remote してブランチ一覧を確認 ブランチ名をコピーして、remoteブランチだったら remotes/origin/ などのプレフィックスを外して git checkout そんなゴニョゴニョは peco に任せましょう。 前提条件 peco コマンドがインストールされていること tr, grep , sed, xargs などのunixでは標準的なコマンドが使える環境であること alias に設定するコマンド コマンドの詳細 git branch --all remoteブランチも含めすべてのブランチを出力（ただし、 git fetch していないなどでremoteブランチの情報が同期されていないと表示されません） tr -d '* ' * と (半角スペース)を削除します grep -v -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - evilmartians/lefthook: Fast and powerful Git hooks manager for any type of projects.
【git revert】複数コミットをまとめてrevertする【使い方】
GitHub - RomuloOliveira/commit-messages-guide: A guide to understand the importance of commit messages and how to write them well
