Git:Care-free Committing
========================
:author: Aaron Ball
:email: nullspoon@iohq.net



In the past, I have found myself a bit afraid to fully use git, because git
history is something so painful to rewrite, especially when the repo is shared
by other users. Besides, it just seems bad practice (and it is) to rewrite
history.

With true code, my concerns are a bit alleviated because most of the time you
can test that locally. The situation I'm referring to is using git as a
deployment mechanism for servers. Let me walk you through my old thought
process.

I want to try a new change for particular server type. I have two options. I
can just log into the server and try out my change, hoping the one that I
commit as a "copy-paste" later into the git repo works identically, or I can
make the change inside the git repo, push it upstream, triggering the test
deployment, which I can (and should) test with. However, what if the change
doesn't work? I can fix it sure, but I'll muck up the history with unecessary
"Broke it...fixed it" commits, and removing those will require rewriting
history.


== Branching

Git is well known for its "cheap branching". Because it makes it so easy to
rebase and merge onto any given branch.


== Squashing Commits

Firstly, find the first commit of your branch. We'll assume that this branch
came off of master and that we are currently working inside this branch (if
not, run +git checkout <branchname>+)

----
git log master..HEAD
----

That command will give you a list of all commits that have happened on your
feature branch ahead of the master branch. Assuming someone hasn't rewritten
history (which has happened to me before...ugh), you should be looking at only
your branch's commits. Scroll to the bottom and copy the commit id for the very
first commit in the series.  

Now run...

----
git rebase -i <commit_id>^1
----

Don't forget the "carrot 1" (+^1+) at the end there, as it is very important.
We just told git to rebase the commit series on top of the most recent commit
from master (the "carrot 1" says "one commit before this commit", hence one
commit before your work started since you selected your first branch commit),
interractively. Iterractive mode gives us a chance to tell git how to handle
each commit, be it picking, squashing, editing, rewording, etc.

Running the interractive rebase should bring you into an editor with text that
looks something like...

----
pick e57d408 Implemented new ifcfg profile functionality
pick cd476e8 Fixed minor issue
pick 96a112b Fixed another stupid issue
pick 9741e2c Testing a small change
pick ec32a51 Revert "Testing a small change"
pick 5d61d26 Revert "Fixed another stupid issue"
...
----

Here we can change what we want to do with each commit as the rebase proceeds.
In this case, I want to reduce my commit set down to one commit, the most
recent (note in your set, the most recent is on the bottom).

----
pick e57d408 Implemented new ifcfg profile functionality
s cd476e8 Fixed minor issue
s 96a112b Fixed another stupid issue
s 9741e2c Testing a small change
s ec32a51 Revert "Testing a small change"
s 5d61d26 Revert "Fixed another stupid issue"
...
----

It doesnt matter what the commit messages are at this point. When the time
comes to merge the commits, you'll get a chance to rewrite the commit message. 

Category:Git
Category:Drafts

// vim: set syntax=asciidoc:
