tigでmerge diffを表示する - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
綺麗なコミットログを作りたいときの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でのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog
ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
Git clone: データで見るクローンの仕組み
@derrickstolee は最近、いくつかの異なる git clone の方法について検討しましたが、それらの選択肢は実際に Git のパフォーマンスにどのような影響を与えるのでしょうか？あなたのクライアントではどの選択肢が一番速いのでしょうか？あなたのビルドマシンではどの選択肢が一番速いのでしょうか？これらの選択肢はサーバーのパフォーマンスにどのような影響を与えるのでしょうか？もしあなたが GitHub Enterprise Server の管理者であれば、複数の同時リクエストがあった場合にサーバーがこれらの選択肢にどのように反応するかを理解しておくことは重要です。 GitHub では、これらの疑問に答えるためにデータ駆動型のアプローチを採用しました。私たちは、これらの異なるクローンの選択肢を比較する実験を行い、クライアントとサーバーの挙動を測定しました。 git clone の時間
gitの空ブランチを作る - Qiita
空ブランチ？ そもそも空ブランチとは何かというと、すでにあるコミット (master) なんかのブランチとは関係なく、全く関連性も何もないブランチのこと。 『そんなものがあるのか？』と不思議に思ったのですが、GitHubのとあるリポジトリには、"gh-pages" というものが存在しているのに気がつきました。! ツリーを見ると、全く独立していて、ドキュメントやプロジェクトページのHTMLが入っていたりします。GitHub上では、このドキュメント用の空のブランチが作れますが、コマンドラインから作るのは知りませんでしたので、メモ。 作り方 "doc" というドキュメント用の空ブランチを作る場合。 git checkout --orphan doc orphanオプションを付ければ良いんですね。 ちなみに、既に履歴のあるリポジトリ上でorphanブランチを作ると、その時点での中身が入ったまま新し
Git のユーザー名を複数使い分ける時は global の設定を消す
2016/09/13 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります tech Git gitconfig 会社用のアカウントと個人用とで分けたいときなどに。 正攻法じゃないけど、間違えずに済むので一応メモ。 （以下いろいろ編集追記） これでしばらくやってみてほぼ困らなくなりましたのでオススメです。 ライブラリはオープンに個人用アカウントで作っておき、 それを会社用アカウントから利用するみたいなことも想定できるので、 user.name, user.email を複数使い分けられるようにしておいて損はないと思います。 global の .gitconfig の user.name をあえて空にする ホームディレクトリに置いてある .gitconfig 内の [user] name = foobar email = foobar@example.com み
GitHubで会社用とプライベートアカウントを分けよう(問題ないよ)
普段使うサービスで、会社用のアカウントとプライベートのアカウントを分けると便利でセキュアですよね？うっかり間違って仕事のデータを大公開してしまうリスクも小さくなります ただ、日本国内では、アカウント分離はNGで、個人ごとに1つのアカウントに集約しないと規約違反であるという言説が広まっているようです。 認識共有用に頑張って書いた図。指摘歓迎ですそこでGitHub Supportに事実を確認したところ(英語)、規約違反ということはないという話でした。会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば、各自のプライベートアカウントは無料でOKです。 ロジックとしては、オーガニゼーションに所属させているアカウントは有償コーポレートアカウント(名称仮)なので、個人アカウントに対する無料アカウントの複数所持禁止条項は無関係となります。 該当条項 One person or l
GitHubのプルリクエストの差分はどこと比較しているか？(git diffの".."と"..."の違い) - Qiita
ディップ Advent Calendar 2018 の1日目です。 はじめに チーム開発をしていて、GitHubのプルリクエストでファイル差分を見たときに、 「masterと同じはずなのに差分として表示されている...なぜ？」となった経験はありませんか？ 今回は、そのような事象にぶち当たったことがあるGit/GitHub初心者向けに、 GitHubのプルリクエストの差分の仕様についてまとめてみます。 また、その説明のためにGitのdiffコマンドのダブルドットとトリプルドットの違いについても確認します。 まずは、git diffについて git diffとは？ git diffは、コミット<->コミットやインデックス<->ワークツリーなどの差分を表示するコマンドです。 具体的な利用方法については、こちらの記事が分かりやすくてオススメです！ 忘れやすい人のための git diff チートシー
Get up to speed with partial clone and shallow clone
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
パーシャルクローンとシャロークローンを活用しよう
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
Gitの時刻を日本式に表示する設定 - Qiita
私は米国人の中に必要性が存在しませんと考えます。 あなたが git log コマンドを実行すると、以下のようなコミットログが表示されます。 $ git log commit 55bcdd4e7563e1041868703819006a9c86e9ae72 Author: Tnaka Taro <tanaka@example.com.com> Date: Thu Nov 22 12:04:50 2018 ほげほげ （以下略） ここで、あなたは言語学の能力を発揮しなければなりません。つまり、"Nov" は何月目かです。 "november"という単語は"novem"（ラテン語の "9"）語源とする単語。ラテン人のカレンダーの年の始まりは2月です。だから "11月"は現代のカレンダーの（2 + 9 =）11月です。 しかしながら、我々はプログラマーであり、言語学のエクササイズをして給料を受け取り
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git の merge.conflictStyle を merge から diff3 に変更したら, マージコンフリクトがより解決しやすくなった
複数のコミットを一括でcherry-pickする - Qiita
How can I reset or revert a file to a specific revision?
自分のいるブランチが他の人によってforce-pushされたとき，カレントブランチを削除せずに変更を取り込む - Qiita
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
