あるレポジトリを別のレポジトリのサブディレクトリへ履歴付きで移動する - $shibayu36->blog;
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
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
ロジカルなコミットメッセージの書き方
チーム開発におけるコミットメッセージの書き方についてアウトプットします。 コミットメッセージに正解はありません。 組織によって最適な手法は異なるため、参考のひとつにしてください。 要点 フォーマット :Emoji: Title / Reason / Specification / Issue 項目 Emoji - 内容・種類をひと目で分かるように Title - タイトル（概要） Reason - このコミットをする理由 Specification - 言い訳ではなく、このコミット内容になった意図や仕様など Issue - 対応するIssue 作業内容はコードを見ればわかるので、「概要」「変更理由」「意図・仕様」を簡潔にまとめる。 例 コミットメッセージを書く理由 そもそも、コミットメッセージを書く理由は以下の通りです。 ひと目でどんなコミットなのか判断するため 簡潔にコミット内容を説明す
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
PRを小さく保つための、commit管理3TIPS - spice picks
Summary 何となくでも良いのでconventional commitの仕様にしたがってcommitを作る 変更はPR作る直前までcommitしない 3.レビュー以前の変更はfixupとforce pushで既存のcommitに入れる。追加のcommitは作成しない 解説 1. 「何となくでも良いのでconventional commitの仕様にしたがってcommitを作る」について conventional commitとは、「人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様」です。（公式から引用https://www.conventionalcommits.org/ja/v1.0.0/ ) この仕様(の特にコミットメッセージのタイトル部分)に従ってコミットを作るようにします。 タイトル部分の仕様はこんな感じです。 <type>[optional scope]:
git submodule と git subtree から見る外部リポジトリの取り扱い - tech.guitarrapc.cóm
先日、外部のgitリポジトリを参照しつつ開発を進めたい時に、改めて今ならどのようにやるといいのか調査と検証を行いました。 開発においてシンプルさは重要です。そのため、利用している言語やフレームワークで標準提供されたパッケージシステムを使うのは優先的に検討するべきです。 しかし会社などでprivate repoでコード参照をしたいときには、参照する外部リポジトリも適切にgit管理したいものです。 gitは、自分のリポジトリを扱うことに関してとても便利な機能がそろっています。 一方で、自分のリポジトリの外、外部リポジトリを連携させることについては、自リポジトリほど楽に取り扱えるわけではありません。 そこで今回は、gitが提供している外部リポジトリのハンドリングとして、submodule と subtree の2つを通して外部リポジトリをどのように扱うのか考えてみます。 これまでは外部リポジトリ
たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita
追記 先日外部向けに、この記事の内容に追加補足などを加えて発表しました。動画のアーカイブ、資料も公開しましたので、もし動画の方がわかりやすい方はこちらをオススメします。 注意: 動画の質疑の中で、 github のリリース機能が、アノテートタグを使っていると明言してしまいましたが、間違いです。gitのデータ上はただの軽量タグで、 release の内容は軽量タグに紐づく形で、 github のアプリケーション上で管理されているはずです。 はじめに 調べてもう1年放置していた内容なんですが、アドベントカレンダーで重い腰を上げました。 Gitの内部の仕組みを知りたい（動機） 毎日使うといってもいいGitですが、どうやって履歴を管理してるんだとか、よくわからないまま使っているのが急に怖くなりました。 Gitを触り始めで、よく以下のような疑問が沸くと思います。 どうやってGitは履歴を管理してるん
OpenAPIのYAML分割管理と構成案 - Qiita
はじめに READYFORのエンジニアリング部に所属している熊谷です。 この記事はREADYFOR Advent Calendar 2020の8日目の記事です。 概要 スキーマー駆動開発でOpenAPI（旧Swagger）を導入し始めたところなのですが、その中で、OpenAPIの運用管理について色々調査・検討していたので、記事として共有させていただきます。 対象読者 以下の方々を対象としています API開発でOpenAPI導入を検討している方。 既にOpenAPIの導入済みの方。 背景 ( 課題感 ) スキーマー駆動開発でOpenAPI（旧Swagger）を採用している企業は多いかと思いますが、OpenAPI導入において最初に感じた課題感として、陥りそうな状況の一つとして、最初に運用方針を決めないまま、多数のメンバーが一つのopenapi.yamlにスキーマー定義を追加・更新していった場合
綺麗なコミットログを作りたいときのgitテクニック - Qiita
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
GUI GitツールのRebase, Cherry pick | フューチャー技術ブログ
Gitを使っての開発で、指定のツールや好みのGitクライアントを使っていると思います。 ターミナルの黒画面でGitコマンドを使うのはちょっと不安、GUI画面から画面を確認しながらGitを操作したい方向けの記事です。 GitのBranch作成やCheckout, Commit, Pushまで使えた方向けに、次の段階としてRebase, Cherry Pickなどの実行方法を説明します。 紹介するツール Sourcetree Visual Studio Code with Git Graphプラグイン IntelliJ IDEA Git操作イメージ説明にあたりGitツリーが以下の状態であることを前提としています。 feature ブランチは個人の開発ブランチです。master ブランチは状況により develop ブランチなどに適宜読みかえください。 初期状態 masterブランチへRebas
[今日知ったこと]
ドキュメント文化https://note.com/takahiroanno/n/ne7e510a06cb9 ノンプログラマーだけど昨年の今頃の新型ウイルス騒ぎでGitやGitHub始めて以来、この手のネタが気になる今日この頃。すでにExcel方眼紙がのさばってしまっているのでダメか？○○内限定でこれを見習うことはできないのか？ ドキュメントされる者共 （全てのページはマークダウンで） ○○ルールとか 「ポートフォリオや実績表（HPに挙げてある者ども）」だから移植はイージー 「働き方 学び方」テキスト化するのか？一部の○○がpukiwikiとか使って実施していることか？ 「○○の設備関連情報（製図とかdxfファイルでバージョン管理するんか？）」 「ツールの使い方」 「各種フロー」これは一部Gitじゃないけど、内部HPで実施している。Gitに移植すればいい。 「各種コード管理」これはとてもGi
![[今日知ったこと]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b1638cdb5807a4788e4ba3c1109a984166e095fc/height=288;version=1;width=512/https%3A%2F%2Fanond.hatelabo.jp%2Fimages%2Fog-image-1500.gif)
パーシャルクローンとシャロークローンを活用しよう
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
自分が実際に企業で働くうえでよく使ったコマンドや役に立った設定をまとめてみました。 Git入門系に関しては飽和していると思いますが、ちょっとした応用編としてご覧いただければ幸いです。 自分の環境 ファイルの数や行数が膨大 複数の案件が同時進行することが多く、質問などに答えたりするためにブランチ移動をすることが多い プロジェクト内に複数文字コードが混在している（Shift-JISとUTF-8） コマンド編 基本のコマンド書きなぐり $ git clone <ブランチ名> <ディレクトリ名> # clone先のディレクトリ名まで指定してcloneする $ git pull # pullする。必要に応じて -u や、 remote名、ブランチ名を打ち込む $ git diff # 差分見る $ git diff master HEAD # 現在の状態とmasterを比較する $ git chec
自作Composerのパッケージの基本的な構成 - Qiita
●はじめに 以下の記事は当時の自分の検索スキルが足らず、該当する内容を見つけられず仕方なく自分で考察・実装した時のメモです。 コメントで教えて頂いたhttps://github.com/php-pds/skeletonの方がより洗練されて美しいので、こちらを参考にしてもらった方が良いと思います。 以上ご了承の上で敢えて読みたい方は以下から本編です。 ●概要 経緯として複数のWebアプリケーションで使用するモデルとビジネスロジックや、コマンドラインで使用するモジュールをコピペで再利用していた。 当然、追加機能の開発やらバグ対応やら運用がツライ → 爆死。 本当にありがとうございました。 これじゃーイカンなと、Composerパッケージとして開発・運用する必要があるなと痛感した次第であります。 「ではどうするか？」となった時に調査して考えた内容で、ある程度土台(テンプレートともいう)は共通化す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git Submodule 覚え書き - Qiita
Git でのバージョン コントロールの概要 - Training
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
Visual Studio Code で Git統合を使用する方法 | DigitalOcean