Thanks. I either didn't see that in the books, or was asleep. I'll read up
on it.
 On Dec 3, 2012 7:07 PM, "Ryan Hodson" <> wrote:

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