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" <john.archie.mck...@gmail.com> 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?
> --


Reply via email to