From ebfe5dae13f3593a969664d2e7999929868ff6fa Mon Sep 17 00:00:00 2001 From: Matthias Baumgarten Date: Tue, 20 Nov 2018 18:00:56 +0100 Subject: [PATCH 1/3] Add section on how to modify an arbitrary commit Explain how to solve situations where you want to modify a commit which is not your last by using interactive rebase. --- README.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/README.md b/README.md index 57b767e..e13386d 100644 --- a/README.md +++ b/README.md @@ -38,6 +38,7 @@ All commands should work for at least git version 2.13.0. See the [git website]( - [I accidentally did a hard reset, and I want my changes back](#i-accidentally-did-a-hard-reset-and-i-want-my-changes-back) - [I accidentally committed and pushed a merge](#i-accidentally-committed-and-pushed-a-merge) - [I accidentally committed and pushed files containing sensitive data](#i-accidentally-committed-and-pushed-files-containing-sensitive-data) + - [I need to change the content of a commit which is not my last](#i-need-to-change-the-content-of-a-commit-which-is-not-my-last) - [Staging](#staging) - [I need to add staged changes to the previous commit](#i-need-to-add-staged-changes-to-the-previous-commit) - [I want to stage part of a new file, but not the whole file](#i-want-to-stage-part-of-a-new-file-but-not-the-whole-file) @@ -344,6 +345,38 @@ If you want to completely remove an entire file (and not keep it locally), then If you have made other commits in the meantime (i.e. the sensitive data is in a commit before the previous commit), you will have to rebase. + +### I need to change the content of a commit which is not my last + +Consider you created some (e.g. three) commits and later realise you missed doing something that belongs contextually into the first of those commits. This bothers you because if you'd create a new commit containing those changes, you'd have a clean code base, but your commits weren't atomic (and this matters much to you, because you're a good developer). In such a situation you may want to change the commit where these changes belong to contain them and have the rest of your following commits unaltered (because they are atomic and that is because - you might guess it- you are a very good developer). In such a case, `git rebase` might safe you. + +Consider a situation where you want to change the third last commit you made. +```sh +(your-branch)$ git rebase -i HEAD~4 +``` +gets you into interactive rebase mode, which allows you to edit any of your last three commits. A text editor pops up, showing you something like +```sh +pick 9e1d264 The third last commit +pick 4b6e19a The second to last commit +pick f4037ec The last commit +``` +which you elegantly change into +```sh +edit 9e1d264 The third last commit +pick 4b6e19a The second to last commit +pick f4037ec The last commit +``` +This tells rebase that you want to edit your third last commit and keep the other two unaltered. Then you'll save (and close) the editor. `git` will then start to rebase. It stops on the commit you want to alter. This is your chance to alter that commit. Now you have to fix the files you missed to alter when you initially commited that commit. You do so by editing and staging them. Afterwars you'll run +```sh +(your-branch)$ git commit --amend --no-edit +``` +which tells `git` to recreate the commit, but to no edit the commit message. Having done that, the hard part is solved +```sh +(your-branch)$ git rebase --continue +``` +will do the rest of the work for you. + + ## Staging From 42b55198917bc1a5842a92e8affd5dc1d241e4e2 Mon Sep 17 00:00:00 2001 From: Matthias Baumgarten Date: Thu, 29 Nov 2018 20:00:27 +0100 Subject: [PATCH 2/3] Wording improvements due to review comments Like discussed in the PR this commit improves the quested section regarding lesser spelling mistakes and improved wording. The discussion about --no-edit lead to no changes required, so it is not altered. See https://github.com/k88hudson/git-flight-rules/pull/256 --- README.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index e13386d..359fd1d 100644 --- a/README.md +++ b/README.md @@ -348,7 +348,7 @@ If you have made other commits in the meantime (i.e. the sensitive data is in a ### I need to change the content of a commit which is not my last -Consider you created some (e.g. three) commits and later realise you missed doing something that belongs contextually into the first of those commits. This bothers you because if you'd create a new commit containing those changes, you'd have a clean code base, but your commits weren't atomic (and this matters much to you, because you're a good developer). In such a situation you may want to change the commit where these changes belong to contain them and have the rest of your following commits unaltered (because they are atomic and that is because - you might guess it- you are a very good developer). In such a case, `git rebase` might safe you. +Consider you created some (e.g. three) commits and later realise you missed doing something that belongs contextually into the first of those commits. This bothers you, because if you'd create a new commit containing those changes, you'd have a clean code base, but your commits weren't atomic (i.e. changes that belonged to each other weren't in the same commit). In such a situation you may want to change the commit where these changes belong to, include them and have the following commits unaltered. In such a case, git rebase might save you. Consider a situation where you want to change the third last commit you made. ```sh @@ -360,15 +360,14 @@ pick 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit ``` -which you elegantly change into +which you change into ```sh edit 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit ``` -This tells rebase that you want to edit your third last commit and keep the other two unaltered. Then you'll save (and close) the editor. `git` will then start to rebase. It stops on the commit you want to alter. This is your chance to alter that commit. Now you have to fix the files you missed to alter when you initially commited that commit. You do so by editing and staging them. Afterwars you'll run -```sh -(your-branch)$ git commit --amend --no-edit +This tells rebase that you want to edit your third last commit and keep the other two unaltered. Then you'll save (and close) the editor. git will then start to rebase. It stops on the commit you want to alter giving you the chance to edit that commit. Now you can apply the changes you missed applying when you initially commited that commit. You do so by editing and staging them. Afterwards you'll run```sh +(your-branch)$ git commit --amend ``` which tells `git` to recreate the commit, but to no edit the commit message. Having done that, the hard part is solved ```sh From 1877d108b027046ee36ab7c91f6adb3fe0da798e Mon Sep 17 00:00:00 2001 From: Richard Littauer Date: Thu, 29 Nov 2018 14:12:07 -0500 Subject: [PATCH 3/3] Small wording changes --- README.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 359fd1d..b2519a2 100644 --- a/README.md +++ b/README.md @@ -348,31 +348,42 @@ If you have made other commits in the meantime (i.e. the sensitive data is in a ### I need to change the content of a commit which is not my last -Consider you created some (e.g. three) commits and later realise you missed doing something that belongs contextually into the first of those commits. This bothers you, because if you'd create a new commit containing those changes, you'd have a clean code base, but your commits weren't atomic (i.e. changes that belonged to each other weren't in the same commit). In such a situation you may want to change the commit where these changes belong to, include them and have the following commits unaltered. In such a case, git rebase might save you. +Consider you created some (e.g. three) commits and later realize you missed doing something that belongs contextually into the first of those commits. This bothers you, because if you'd create a new commit containing those changes, you'd have a clean code base, but your commits weren't atomic (i.e. changes that belonged to each other weren't in the same commit). In such a situation you may want to change the commit where these changes belong to, include them and have the following commits unaltered. In such a case, `git rebase` might save you. Consider a situation where you want to change the third last commit you made. + ```sh (your-branch)$ git rebase -i HEAD~4 ``` + gets you into interactive rebase mode, which allows you to edit any of your last three commits. A text editor pops up, showing you something like + ```sh pick 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit ``` + which you change into + ```sh edit 9e1d264 The third last commit pick 4b6e19a The second to last commit pick f4037ec The last commit ``` -This tells rebase that you want to edit your third last commit and keep the other two unaltered. Then you'll save (and close) the editor. git will then start to rebase. It stops on the commit you want to alter giving you the chance to edit that commit. Now you can apply the changes you missed applying when you initially commited that commit. You do so by editing and staging them. Afterwards you'll run```sh + +This tells rebase that you want to edit your third last commit and keep the other two unaltered. Then you'll save (and close) the editor. Git will then start to rebase. It stops on the commit you want to alter, giving you the chance to edit that commit. Now you can apply the changes which you missed applying when you initially commited that commit. You do so by editing and staging them. Afterwards you'll run + +```sh (your-branch)$ git commit --amend ``` -which tells `git` to recreate the commit, but to no edit the commit message. Having done that, the hard part is solved + +which tells Git to recreate the commit, but to leave the commit message unedited. Having done that, the hard part is solved. + ```sh (your-branch)$ git rebase --continue ``` + will do the rest of the work for you.