え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
GitHub_Revertでマージする前の状態に戻す_Revert後に再度マージする #255日目｜モリユウキ|YM202110
Gitでバージョン管理している中で、一度マージした内容を取り消したいケースが出てくると思います。そんな時に使える機能が「revert」です。 pull requestを出してブランチをマージした後でも、revertを使うことでマージ前の状態に戻すことができます。 一見すると、マージを取り消してマージ前の状態に戻っているように見えます。しかし実体は少し違っていて、「履歴に残っているマージ前の状態のブランチを、マージ後のブランチに再度マージする」という処理になっています。 そのため上記の「Revert」を押下すると、「revert-プルリク番号-元のブランチ名」という名前の、Revert用のブランチが作成されていることが分かります。 後は通常通りMerge pull requestすればOKです。 次はこのRevart自体を取り消して、このブランチを再度Mergeしてみたいと思います。 ところ
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
git commit --fixup が便利 - Qiita
始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
コードより先にコミットメッセージを書く
これは、フィヨルドブートキャンプ Advent Calendar 2021（Part 1） 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR（プルリクエスト）を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方まず、タスクを分解して TODO リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ
【Git】２つ以上前のコミットを修正する。 - Qiita
はじめに commitを修正するときに直前のコミットを修正するには 「git commit --amend」を使用することで容易に修正することができます。 しかし、2つ以上前のコミットを修正するのは初心者にとっては少しハードルが高いです。 今回は２つ以上前のコミットを修正する方法を記載していきます。 事前準備 今回は、以下のような手順を踏んだ状態からコミットを修正していきます。 ①index.htmlの作成 index.htmlが下記の状態でコミットメッセージ：「最初のコミットです。」でコミットしていきます。 ②style.cssの作成 style.cssを作成し、コミットメッセージ：「２番目のコミットです。」でコミットしていきます。 ②home.htmlの作成 コミットメッセージ：「3番目のコミットです。」でコミットしていきます。 コミットの修正 今回は2番目のコミットを修正していきたい
コンフリクトの解決を記録して再適用する git rerere - Qiita
はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
Gitの操作を間違ってしまった時に簡単に元に戻せる「git undo」を使う方法
プログラミングを行う上でバージョン管理システムとしてよく利用される「Git」において、ほとんどの操作をやり直せるコマンド「git undo」をTwitterで働くエンジニアのarxanasさんが開発・公開しています。 git undo: We can do better https://blog.waleedkhan.name/git-undo/ Gitはユーザーのさまざまなうっかりミスに対してデータが失われにくい構造に設計されているものの、実際に操作ミスをしてしまった際にもとの状態に戻すにはそれぞれの状況に応じて別のコマンドを使わなくてはならず、「初心者がさらに間違いを重ねて複雑怪奇な状態にしてしまう」というケースがありがち。 こうした状況を解決するためにarxanasさんが開発したのが「git undo」です。git undoはその名の通り、間違って行ってしまった操作をやり直せるコマン
綺麗なコミットログを作りたいときのgitテクニック - Qiita
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
~/.gitignore_global を指定するのをやめ、デフォルトの置き場に置こう
Gitで全てのリポジトリのignore指定を ~/.gitignore_global に置いている例はよく見られます。実際、この名前はGitが公式で公開している本 (Pro Git 2) (→日本語版) でも言及されています。 このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、 (...) ところがこれはややミスリーディングです。この部分は core.excludesfile 自体の説明にほかならないのでわざわざ設定を書き換えていますが、実はデフォルト値があります。これは gitignoreのマニュアル で説明されています。 Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is eith
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 のユーザー名を複数使い分ける時は global の設定を消す
2016/09/13 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります techGitgitconfig 会社用のアカウントと個人用とで分けたいときなどに。 正攻法じゃないけど、間違えずに済むので一応メモ。 （以下いろいろ編集追記） これでしばらくやってみてほぼ困らなくなりましたのでオススメです。 ライブラリはオープンに個人用アカウントで作っておき、 それを会社用アカウントから利用するみたいなことも想定できるので、 user.name, user.email を複数使い分けられるようにしておいて損はないと思います。 global の .gitconfig の user.name をあえて空にするホームディレクトリに置いてある .gitconfig 内の [user] name = foobar email = foobar@example.com みたいな
プロダクトのリリースとGitブランチ運用を考えてみた | DevelopersIO
詳細は下記をご覧ください。 Gitブランチ運用 Git FlowとGitHub Flow Gitのブランチ運用としては、Git FlowやGitHub Flowがよく用いられます。Git Flowはプロダクトやチームの規模に対して過剰かつ複雑と判断し、GitHub Flowを少しだけアレンジしたGit運用を行います。 求めるポイント GitHub Flowに対して追加で求めるポイントは、ステージング環境と本番環境へのリリースタイミングを自分たちでコントロールしたいです。理由は下記です。 プロダクトオーナーのOKが出たモノだけをステージング環境と本番環境にリリースしたい 「masterブランチにマージされたらすぐに本番環境にデプロイ」は都合が悪い リリース頻度は1週間に1回ぐらいなので、masterブランチへのマージを手動Stopするのは都合が悪い これらについてアレンジしています。 考えた
大規模リポジトリで高速に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を実行するのは最初のセットアップ時だけなのであまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
gitでプロジェクト毎に設定を変更したい場合 - Qiita
「Visual Studio Code」2020年8月更新、「Git」でのトラブルを防止する新オプションを追加／デバッグコンソールにフィルタリング機能も
