Git commit
2012-02-27 16:39:06.836894+00 by
Dan Lyke
4 comments
Because @genehack made a post about this, I read his suggestions and still wasn't quite certain:
mkdir gittest; cd gittest; git init
Initialized empty Git repository in /home/dlyke/code/gittest/.git/
for a in First Second Third Fourth ; do echo $a >> abc.txt ; git add abc.txt ; git commit -m $a\ Commit ; done
[master (root-commit) 8c68792] First Commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 abc.txt
[master cbccf0c] Second Commit
1 files changed, 1 insertions(+), 0 deletions(-)
[master 426fd1a] Third Commit
1 files changed, 1 insertions(+), 0 deletions(-)
[master 94694d7] Fourth Commit
1 files changed, 1 insertions(+), 0 deletions(-)
If we now do a git rebase -i HEAD~3
, we can combine the second and third commit by changing the file to:
pick cbccf0c Second Commit
squash 426fd1a Third Commit
pick 94694d7 Fourth Commit
This will then pop up a second window which lets us amend the revised commit message, which I'll make "Second and Third Commit". git log
now shows three commits, and the middle one has 3 lines in it.
[ related topics:
Interactive Drama John S Jacobs-Anderson Music Television
]
comments in descending chronological order (reverse):
#Comment Re: made: 2012-02-28 03:30:14.583322+00 by:
John Anderson
Mars, the majority of my git rebase use is in reviewing the code of junior developers, who have a real bad
habit of fixing bugs, leaving their debug code in the change set with the fix, and then including one (or
sometimes more than one) subsequent change that removes the debugging. There's no need for that to
be two distinct changes; by squashing those commits into a single one during the review process, the
overall history of the project is improved -- there's less noise, it's easier to see the was
important in the change, and since I can point out to the junior dev what I did as part of the feedback they
get during the code review, it provides a teachable example too.
In other words, I think it's safe to say we disagree about rebase...
#Comment Re: made: 2012-02-27 22:29:29.246417+00 by:
Dan Lyke
There are personal projects where I use revision control in the makefile. All sorts of reasons why those intermediate steps never need to make any sort of public branch.
#Comment Re: made: 2012-02-27 19:56:49.009308+00 by:
Mars Saxman
git rebase horrifies me and I generally pretend it doesn't exist. It violates the entire purpose of keeping
history.
#Comment Re: made: 2012-02-27 17:36:55.927684+00 by:
John Anderson
Other fun stuff you can do:
- edit one of the commit messages
- edit one of the *commits*, directly
- drop one of the commits on the floor -- yank it out of the history and act like it was never there
- split one of the commits into two (or more) distinct two commits
- any combination of the above, all at once
'git rebase -i' is one of my favorite parts of git; I use it near-daily.