Add --squash option to feature finish about gitflow HOT 21 CLOSED

Hi Vincent,

We've been using the 'reinh method' successfuly for quite some time: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

It describes the use of local feature/bugfix branches that are squashed and merged (by rebasing) into the master branch after finishing. It does not contemplate the use of production/release branches etc. That's the main reason we want to switch to your workflow and the tool.

Citing the text on that website:
'Once work on the feature is complete, you will have a branch with a lot of small commits like “adding a model and a migration”, “adding a controller and some views”, “oh crap – adding tests” and so on. This is useful while developing but larger, incremental commits are more easier to maintain.'

It helps mantain a cleaner log and also code reviews are nicer as you mentioned. I know that squashing, as rebasing as well, does modify the history and thus should only be made if those feature branches have not been remote published. As long as you work on local branches you should be safe.

I imagine people working on bigger features might want to publish their branches and some other people might prefer to retain the whole history with the incremental commits. That's the reason I thought an option would be nice.

Let me know if I can give you anymore helpful feedback on this and of course, thanks a lot for this nice tool! :)

from gitflow.

What's the status on this?

We always squash commits when merging into master? Is there a way to it manually in the meantime using the git-flow tool or do we have to revert to using git rebase directly?

from gitflow.

I'd like to actually just have a "git flow feature squash" command that's separate from the finnish. Currently, our git-flow workflow usage also includes pushing topic branches to a gerrit code review server prior to merging into develop.

Ideally, I'd like to squash my commits before I send to gerrit. This would also work well for when having to resubmit patches for review, as I could do small commits, during rework, squash back to one commit, then resubmit the review.

This would work better than doing commit amends and not having an interim history.

from gitflow.

I don't actually see a use for the squashing here. What do you gain from that exactly? Is it so others can review your code more easily since they only have to consider one commit?

What do you mean by keeping the history by squashing instead of amending? As I see it, both methods rewrite history (discarding historical info) and thus lead to data loss. Am I missing a use case here?

from gitflow.

Vincent - the desire for the squash command comes mostly from our use of Gerrit as a code review tool.

With gerrit, a revised/updated commit with a special "Change-ID: SHA1xxxxx" reference of the original commit is pushed into the gerrit server. As this is a revised patch your changes or normally made as an ammended commit.

The work flow we're currently working with is:

1. git flow feature start XXXX
2. commit..commit...commit...commit...committ... ( its good having checkpoints when working )
3. squash down to one commit ( if you've done many commits )
4. git push to the gerrit server
5. if rejected, ammend commits, goto 4
6. if accepted, git flow feature finnish into develop

My reference to not having interim history comes from not having an easy squash setup and just doing commit ammends as I work - ammends give me a checkpoint to roll back to, but I'd rather have multiple checkpoints.

For now I just do an interaction rebase and manually set the commits to squash which is not a real big issue, but if one could automate that it'd be even nicer.

from gitflow.

I'd like to see a squash option as well, something that will crush my intermittent commits to a single pithy commit message... No one needs to see that I had a syntax error on my feature branch...

from gitflow.

For those 'syntax error' commits I use git commit --fixup... and git rebase -i --autosquash... to clean up my history before doing git flow feature finish.

from gitflow.

I would consider that a work around.

My basic work flow, before git flow, involved working on a branch, committing at random intervals, with nonsense messages, and then merge --no-commit --squash on master. This allowed me to do what you mentioned, in one seamless step, without those unseemly and largely useless merge commit messages.

Using git flow, my logs now have two commits per git flow action... I'd like to do away with the merge branch messages and squash, all in one go.

from gitflow.

+1 on squash

from gitflow.

+1 on squash for fork/pull request situations. It would make it easier to identify features and cherry pick.

from gitflow.

+1 on squash for code review

from gitflow.

+1 on squash

from gitflow.

+1 on squash

from gitflow.

+1 on squash as a non-default option. The pull request seems to handle this.

from gitflow.

+1 - This would be great and the suggested implementation seems to allow for the existing mechanism as well.

from gitflow.

OK, this has been pulled from #210. Thanks @mykehsd!

from gitflow.

+1 on squash

from gitflow.

+1 Squash finish option Please

from gitflow.

+1

from gitflow.

Feature needed! +1

from gitflow.

@stat1x I think it is merged.

OK, this has been pulled from #210. Thanks @mykehsd!

from gitflow.