Gitの内部表現から理解するSquash
コミットはスナップショットであり差分ではないとすると、Squashは何をしているのでしょうか。 コミット（スナップショット）を「まとめる」とは具体的にどのような操作を指すのか、詳しく見ていきます。 おさらい：Gitの内部表現 Gitの内部表現についてざっくり思い出します。Gitオブジェクトは以下の4種類です。 コミット：ある時点におけるリポジトリ内のコンテンツのスナップショット ツリー：ディレクトリ ブロブ：ファイル タグ：今回は関係なし まず、以下のコマンドでサンプルリポジトリを作成します。 mkdir sample-repo cd sample-repo git init echo "sample 1" > sample.txt git add . git commit -m "sample commit 1" sleep 1 echo "sample 2" >> sample.txt
Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - ESM アジャイル事業部 開発者ブログ
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Gitでよく使用するコマンドをGIFアニメで解説
Gitでよく使用するコマンドが何を行っているかをGIFアニメで解説した記事を紹介します。 Gitのマージ、リベース、リセット、チェリーピック、フェッチ、プル、リフログなど、コマンドを実行した時にブランチはどのように相互作用し、履歴にどのような影響を与えるのか視覚的に学べます。 🌳🚀 CS Visualized: Useful Git Commands by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Gitのマージ（fast-forward, no-fast-forward） Gitのリベース（rebase） Gitのリセット（reset, revert） Gitのチェリーピック（cherry-pick） Gitのフェッチ（fetch） Gitのプル（pull） Gitのリフログ（re
死んで覚える本当のGitの使い方 - mizchi log
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
gitでまだマージしたくない変更を間違ってmasterにマージしてしまった時の対処 - @satomikko94.b
久々にgitですごい躓いたので。 説明すると、branch02の内容を謝ってmasterにマージしてしまった後、それに気づかずbranch01の内容もmasterにマージしてしまった。 あとから気づいたので、branch02の内容だけmasterから取り除いて、もろもろレビューが終わってからbranch02の内容はmasterにマージしたい。 言葉で説明すると意味不明なので図*1がこちら commitを取り消すコマンドはgit resetが有名だけど、git resetはあるcommit時点まで戻り、それ以降のcommitをなかったことにするというものなので、branch01のcommit内容も消されてしまう。(まあ戻そうと思えば戻せる) そこでまず使うのがgit revert git revert {commit No} Git チュートリアル: 変更を元に戻す | アトラシアン これで
モノレポ入門 – Gutenberg が採用するリポジトリ戦略 – Capital P – WordPressメディア
WordPress 5 から導入されたブロックエディタの Gutenberg は JavaScript で記述されたフロントエンドのプロジェクトで、 Node.js のパッケージマネージャーの npm で管理されています。Gutenberg は単一のパッケージではなく、多数のパッケージから構成されている巨大プロジェクトです。GitHub のリポジトリを見てみると、./packages というフォルダの中に大量のパッケージが同梱されているのが分かります。 たくさんの npm パッケージが 1 つのリポジトリに同梱されている このように 1 つのリポジトリの中に複数のパッケージを同梱するリポジトリの運用方法は monorepo (モノレポ・モノリポ)と呼ばれています。この記事では、モノレポのメリットやモノレポを実現するためのツールである Lerna を紹介します。 モノレポのメリット・デメリッ
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
意外と知らない？ Gitコマンド 100本ノック - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 みなさん、Git使ってますか？ もしくは、使いこなしていますか？ 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git 100本ノック Gitに馴染む 1. メールアドレスをGitのグロー
git statusでcopiedとなる操作は？
https://git-scm.com/docs/git-status 上記公式ドキュメントのヘルプに記載されている、git status -sで表示されるc(copied)というステータスはどんな操作をした時に発生するものでしょうか？ ファイルを複製すると発生するのかと思い、 以下操作をしてみましたが発生しませんでした。 1.file1を作成(中身は適当) 2.git add file1 3.git commit file1 -m 'test' 4.file1をコピーしてfile2を作成 5.git add file2 6.git status -s file2はfaile1のコピーなのでC(copied)となるかと思いましたがA(added)という判定になりました。
ルーターのコンフィグを git にぶち込んで世代管理してみたはなし - miyalog
この記事を三行で みんな好き勝手な名前でコンフィグファイルをアップロードしてサーバーがパンク＆どれが最新版かわからない状況に 命名規則を作り、サーバーに置いておくコンフィグを最新世代１つのみとした さらにファイルを社内 GitLab に自動アップロードし履歴確認ができるようにした ※ GitLab を入れ物として使うだけで、git を使ったワークフローを導入したとかのカッコイイ話じゃありません あらまし とある通信会社の委託でIPネットワークの監視作業員をやっています（非エンジニア）。うちの会社ではルーター・スイッチ類のコンフィグをTFTPサーバーへアップロードしてバックアップとしていますが、先日そのサーバーで反応が5分くらい返ってこなかったり、ファイルのアップロードに失敗したりと動作が不安定に･･･。HDDでも壊れたかな？と思いながら調べてみると... $ df -h Filesyste
Git subtreeによるライブラリ管理について
前回は Git subtree merge について説明しましたが、今回はそれに深い関係がある Git subtree コマンドについての説明です。 まず基本的なこととして、 Git subtree は Git subtree merge と同じものではありません。 subtree merge はマージ戦略として subtree を指定したマージにすぎませんが、 Git subtree は明確に外部ライブラリの取り込みと submodule の代替を目的として設計された機能です。 Git 1.7.11 以降であれば、 Git subtree を使用するのが望ましいでしょう。 なぜなら、 Git subtree には、 Git subtree merge にはない、下記のような機能があるからです。 取り込んだライブラリ側の歴史を"潰し"(squash)てコンパクトな歴史にできる。 自分のプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git pull で conflict した場合の対処方法 | YONEHUB
git fetch する度に"Auto packing the repository in background for optimum performance." が出る - Qiita
Why does git keep telling me it's "Auto packing the repository in background for optimum performance"?
GitExplorer
GitHub - dondoko-susumu/git-learning
git status / git diff -C not detecting file copy in index