I think what you're looking for is a squash merge. If you develop the change in a dedicated feature branch like you describe, you can transfer all of the changes to the master branch with the `--squash` flag as follows:
git checkout master git merge --squash some-feature This concatenates all of your changes and adds it to the stage and doesn't create any kind of connection between `some-feature` and `master`. Then, you can run `git commit` to commit them to the master branch. The result will be a single commit that represents your entire feature. To delete all vestiges of the development work, just force delete the feature branch with `git branch -D some-feature`. Then push to the remote with a normal `git push`. Hope that helps. - Ryan On Dec 3, 2012 6:54 PM, "John McKown" <[email protected]> wrote: > > 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? > > -- > > --
