When I'm on a git project, I have a workflow that goes something like this:
- Start a new feature (open a new branch)
- Write some code, commit some code, repeat
- Push the code to a remote, possibly with my initials in the branch name, and 'WIP' commits, indicating that it's unfinished
- Once things start taking shape, squash commits together, change their messages, delete them, rearrange them, etc.
- Keep working
- Decide things are ready for review, submit a pull/merge request (possibly after force-pushing to destroy my old, work-in-progress, branch)
- Get some review, put more changes that came from that review on top
- Get approval to merge the branch
- Merge the branch. Bask in the beautiful history of the feature it is that I just merged, but never rewrite history on the master/default branch (unless I'm the only one on the project)
Is this workflow supported in mercurial? How about without plugins? I'm fairly new to mercurial, but I know enough (and lean on this cheatsheet enough) to get what I want to get done. However I'm not able to use this workflow. There is much care in crafting the perfect commit, and just piling stuff on top of it because otherwise I seem to get error messages. This seems to be by design, but I'd really rather use my workflow for my branches.. and then conform to the type of history management (e.g. merges/rebases/no rewriting) for branches that many people work on.
rebase --interactive
,push --force
,pull
,fetch
,merge --ff-only
,reset --hard
, possibly others?commit --amend --all --reuse-message=HEAD
rebase --this-option --that-option --yet-another-option
nonsense withhg
. Just let it do it's thing. The git penchant for hacking history targets one specific project that involves thousands of developers spread across the globe. Unless you are contributing to that singular project, the standard git workflow <expletives deleted>. In my opinion, of course. Actually, not just my opinion. The developers at github eschew that git workflow for a workflow that makes gitflow look complex.