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? --
