There's also the option of cleaning up your commits using interactive 
rebase (git rebase -i, google for some examples, it's very neat).

Then there is the question of whether you actually want to have a 
merge-commit as a "sign-off" for the completed feature, and keep the 
smaller work-commits (although they should still be tidy and neat for 
future code archeology's sake). Some projects/teams avoid merge-commits at 
all costs, and other teams don't mind them at all.

Personally, I tend to commit directly on master when doing smaller fixes 
(combining with git pull --rebase to avoid those ugly pull-merges). I 
create a feature branch when I set out to create a larger feature (that is, 
takes more than half a day or so). When I'm done, I tidy up the commits 
I've made in the branch, and then merge them (without squashing) back to 
master. In the merge commit message, I describe the feature in full.

That way, when people study the history, they'll have a way of seeing both 
the larger-scope goal of the branch (the merge commit), while they still 
have the opportunity to drill further down in the branch commits to see why 
I did this and that (the commits on the branch).

On Tuesday, December 4, 2012 2:26:49 AM UTC+1, John McKown wrote:
> 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" < <javascript:>> 
> 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" <<javascript:>> 
>> 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