I've been reading "Version Control using git" (already finish Pro Git). One 
thing the author said was that git really encourages developers to commit 
frequently. Mainly because they have an entire (at the time) copy of the 
repository. So there's not a lot of overhead of sending files across the 
Internet (or Intranet). This sounds good to me. Basically, what I like to 
do is: "until satisified do; edit; compile; test; commit; done " I do this 
for every program. Once a "change" is complete, i.e. all programs and files 
modified, and tested, I then do a "git push" to the repository.

But it occurs to me that this is a lot of commits for what is logically a 
single change. Would it be "better" to implement a single "change" as a 
single, well documented, commit? If so, then how to eliminate all those 
commits? What I've read says to do something like create a new branch; do 
all your development and commits in that branch; then do a "git checkout" 
back to "master" and do a single "git merge" of the new branch. The way 
that I read the doc, what happens is that your branch remains and the 
"master" branch commit has two parents. One from "master" the other from 
the "change" branch. What I was thinking would be better would be to 
completely remove all vestiges of the "change" branch. I think this can be 
done by abusing git as follows:

git tag starting
git branch changes
until satisfied; do edit; compile; test; commit; done #use the changes 
branch for all development
git merge --no-commit changes
git branch -d changes
git reset --soft starting
git tag -d starting
git commit #put in a single commit with very detailed documentation
git push #push the change up to the origin

Does this seem reasonable? Or am I entirely out of the ball park?


Reply via email to