【Git】ブランチ切り替えはcheckoutではなくswitchを使おう！
今までブランチ切り替えはgit checkout <ブランチ名> が使われることが多かったと思います。 しかし、このcheckoutコマンドでできることはブランチ切り替えだけでなく、変更の取り消しや過去ファイルの復元など様々な用途で使われてきました。 同じコマンドなのにできることが違うというのは何とも直感的ではないですよね。 そのため、現在ではブランチ切り替えなどのブランチ操作専用のswitchというコマンドが用意されています。 本記事では、このswitchの使い方をcheckoutと比較しながら解説していきます。 使い方はcheckoutとそれほど変わらずとても簡単なので、ブランチ切り替えにcheckoutを使っていた方は是非参考にしてみてください！ switchコマンドとはcheckoutコマンドからブランチ操作に関わる機能を切り出したものがswitchコマンドです。 元々ブランチ切り
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
Gitのコミットメッセージを後から変更する方法をわかりやすく書いてみた
こんにちは、ひさっしーです！ 今回は、久しぶりにGitネタです。 Gitを使っている方のあるあるかと思いますが、急いで作業している時にコミットメッセージを書き間違えたままcommitしてしまった！なんてことありますよね。 また、グランフェアズではBitbucketで課題を発行してタスクをこなすことがあるので、コミットメッセージに「refs #25」などをつけてコミットを該当の課題と関連付けたりするのですが…これを書き忘れたり、間違えて違う番号にして関連付けをミスったり…ということもあったりします。 コミットメッセージを書き間違えた！ 課題との関連付けをし忘れた！ そういった迷えるうっかりさんを救う、「コミットメッセージを後から変更する方法」を今回はご紹介します！ 【初級編】直前にコミットしたメッセージを変更する 例えばこんな風に、今書いたコミットメッセージを書き直したい！という時があります
第5章 情報価値の高いコミットをしよう―コードだけではわからない意図を伝える技術 | gihyo.jp
そういう意味じゃないって。一緒のチームで開発するうえで大事なのは、それぞれのメンバーがどういう仕事をしているのか、この部分は誰がどうやって作ったのか、これは何のためにあるのか、そういった開発に関するさまざまな情報を適切に共有することだよ Redmine[1]とメールじゃだめなんですか？ ああ。VCSの使い方の最小単位といえば「コミット」だけど、そこにどんな情報を込めるかによって、意図の伝わりやすさは大きく変わるんだ。VCSは、使いかたによって宝の山にもゴミの山にもなるんだよ 情報価値の高いコミットメッセージを書こう コミットメッセージは、開発を継続していくうえでとても貴重な情報源になります。しかし、初級者、あるいはそのプロジェクトに明るくない人は、情報価値の低いコミットメッセージを書いてしまいがちです。たとえば、図1はあるコミットの詳細をgitshowで表示したもので、コミットメッセージに
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
やらかしたとき - 戯術memo
$ git config --global user.name "Your Name" $ git config --global user.email you@example.com $ git commit --amend --reset-author ※ これは最初の1回のみ(--amendによる直前のコミットのみ修正) 複数のcommitがある場合は一括変更も可能。 ※ 条件設定しない場合、(forkなどしてきた)他ユーザーのコミットも書き換えるので注意 GitのCommitユーザを修正する方法 - Qiita ブランチに移動する前に編集してしまった(未コミット状態) stash saveで変更を退避 -> ブランチに移動 -> stash popで退避した変更点を取り出す
GitのCommitの取り消し方法 | ギークの逆襲 🐟
Commit の 『取り消し』に要注意 この記事では、異なる状況でのコミット取り消し方法について、初心者向けにわかりやすく説明します。 一言に『取り消し』と言っても様々な意味になります。 とくにGitにおいてはどの状態に戻すのかが重要となります。 下記は目的別のCommitの取り消し方法となります。 1. 最新のコミットを取り消し、その変更を次のコミットのために保持したい 使用コマンド: git reset --soft HEAD~1 シナリオ: コミットをし忘れたファイルがある場合や、コミットメッセージを変更したい場合に便利です。 2. 最新のコミットを取り消し、変更内容をワーキングディレクトリに保持したい 使用コマンド: git reset --mixed HEAD~1（デフォルト） シナリオ: コミットしたが、更に変更を加えたい場合に適しています。ステージングされていない状態に戻りま
golangのgit ライブラリ「go-git」を使ってインメモリでgit操作をする | DevelopersIO
こんにちは。齋藤です。 今日はgolangを使ってgitの操作をやります。 はじめに golangには pure go implementation な git のライブラリがあります。 go-git 今回の記事では、このライブラリを使って git の操作を行います。 今回動かしたいシナリオは以下のようなものです。 あるリポジトリAを リリースする リポジトリAのイベントをhook起点に別のリポジトリBに コミットして PRを送る 今回はリポジトリBに commit して PRを送るに着目して この記事では リポジトリBを clone した後にファイルを変更・commit して push までをやってみます。 なお後々、Webhook などで動かしたいので AWS Lambda の上で動かしてみます。 gitの操作は全てインメモリで行います。 準備 今回はAWS Lambdaで実行すること
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣ - Qiita
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記： OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(
Git の一般的な落とし穴を回避します: ベスト プラクティスと回復手順。 | DevelopersIO
Gitは、バージョン管理に強力なツールで、開発者がコード変更を追跡し、プロジェクトで協力し、作業履歴を維持することを可能にします。Gitは複雑なプロジェクトを管理するための堅牢なフレームワークを提供しますが、同時にプラットフォームの初心者にとっては習得の曲線があり、一般的なミスにつながる可能性があります。これらのエラーは、些細な面倒から、プロジェクトのワークフローに重大な混乱をもたらすまでさまざまです。 これらの落とし穴を理解し、回避することは、プロジェクトの整合性と安定性を維持するだけでなく、チームメンバー間の効果的な協力関係を育むためにも不可欠です。このブログでは、Gitを使用する際にユーザーが直面する最も一般的な課題について掘り下げます。メインブランチへの直接コミット、ブランチの非効率的な使用、不適切なコミットの処理、マージコンフリクトの解決など、さまざまな問題を探ります。 一般的な
中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
あるレポジトリを別のレポジトリのサブディレクトリへ履歴付きで移動する - $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 にあるように、サブツリーマージという方法も取れる。しか
git の merge, rebase, revert で衝突した際の ours, theirs はどんな状態になるか
git の merge, rebase, revert で衝突した際の ours, theirs はどんな状態になるかGit はじめに 他のブランチを merge しようとしてコンフリクトした時、他のブランチを rebase しようとしてコンフリクトした時、他のブランチの merge を revert しようとしてコンフリクトした時、それぞれ git checkout --ours と git checkout --theirs した際にファイルがどのブランチの状態になるかを確認した。 先に結論 他のブランチを merge しようとしてコンフリクトした時 ours: 現在のブランチの状態になる theirs: merge しようとしているブランチの状態になる 他のブランチを rebase しようとしてコンフリクトした時 ours: rebase しようとしているブランチの状態になる the
コマンドを使わずに理解するGit - Qiita
この記事はNuco Advent Calendar 2022の7日目の記事です はじめに 株式会社Nucoでエンジニアをしている@noshishiです。 今回は、ついついその場限りのコマンド実行で乗り越えがちなGitを、コマンドを使わず理解するための記事を書こうと思います。 Gitとは バージョンを管理し、作業を分散する Gitは、分散型バージョン管理システムと呼ばれるソースコードの管理システムの1種です。 Gitは、ファイルの変更履歴（バージョン）を記録・追跡することで、過去と現在のファイルを比較し、変更点を明らかにすることで、円滑に開発作業を進めるためのツールです。 また、一度に複数の開発者がファイルを編集できるシステムなので、作業を分散して行うことができます。 Gitを使うということ まず、みんなで共有できる保存場所（以下、リモートリポジトリ）にあるファイルなどを、手元のパソコン（以
【備忘録】Azure DevOpsからgit cloneする方法(認証エラー対策) | Inno-Tech-Life
こんにちは、現役エンジニアの inno_tech です。 Microsoft の Azure DevOpsからhttpsプロトコルでgit cloneをする際に認証系でエラーが発生しました。 どうやらhttps経由ではパスワード認証が廃止されたようです。 備忘録として、Personal Access Token(PAT)を用いてCloneする手順をまとめました。 本記事は ubuntu20.04LTSの環境で検証しています。 Azure DevOpsって? Microsoft社のサービスの一種で、Azure ReposというサービスでGitHubのようなリポジトリサービスを提供しています。 MicrosoftによるGitHubの買収によって、今現在はGitHub無料プランでPrivateリポジトリを使用できますが、以前は有料でした。 一方、Azure DevOpsでは無料でPrivateリ
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git tagで既存のタグの名前(タグ名)を変更・修正する方法｜タグ名を他のタグに付け替える（移動）する方法
gitでstashが面倒なあなたにautostash
すぐ使いこなせるようになりたい人のためのGit入門一覧
