Amending the checkin
After finishing a particular software feature, I like to check in my work. The problem is, I get into a dilemma. Do I check in now, or wait until I’m sure the feature works as advertised. If I check in now, then I might discover that forgot to add something else to the checkin. If I don’t check in now, I might start on another feature, and then it gets messed up.
git has a wonderful feature that fixes this. git commit –amend. Basically, you commit your changes. Later on, you realize there were some other files that should have been committed alongside the first commit. So you just amend the previous commit with your new files. Really nice feature, and should make the history logs much nicer to look at.
2 Comments »
RSS feed for comments on this post. TrackBack URI
When starting a new feature/project at my company we create a new branch and do all of our development there. We can then check things in/out as much as we desire without affecting the main branch. When our feature is complete we deliver a build from our feature branch to QA and they approve it. Once QA has approved the feature, we get permission to merge our changes back into the main branch.
Benefits:
1. You can check in your code so you don’t lose your changes!
2. You are isolated from changes other people make to the code
3. Your code can be approved/verified before it effects the main branch.
Downsides:
1. Merging can be a pain in the ass…but i can’t imagine its harder than 2 people working on the esame file in the same branch
Comment by Carson — Monday, November 10, 2008 @ 19:29
We use Rational Clearcase as our repository tool
Comment by Carson — Monday, November 10, 2008 @ 19:30