DEV Community

loading...

Discussion on: I'm a Git Master, Ask Me Anything

Collapse
bakgaard profile image
Rasmus Bækgaard

Scenario: you work with 4 other developers on a project, where you use the Git Flow methods (though no pull-requests).
When will you use `git rebaseand when will you usegit merge --no-ff`?

Collapse
gonedark profile image
Jason McCreary Ask Me Anything

git rebase is likely reserved for feature branches to prepare them for merge. Under Git Flow, you'd likely never want to run git rebase on the long lived branches.

The git merge --no-ff ensures the merge does not fast forward your commits onto the target branch. Essentially, this guarantees a merge commit.

Collapse
stecman profile image
Stephen Holdaway • Edited

I'd add to Jason's answer that git rebase is far more than an alternative workflow to merge. I use it heavily during local development for example, before and during merge/pull requests:

  • Updating your in-progress branch to include changes someone else has merged that you need (this is the classic example)

  • Moving your work to be based on a different branch (eg. you originally branched from master as a hotfix, but part-way through you've found it makes more sense to fix with the changes already on develop to avoid additional changes when merging).

  • Separating commits from a branch into multiple branches that make more sense for review. I often do this if I find a bug while writing a tests for existing code - commit a fix on the tests branch, then move the fix commit(s) to a separate branch once everything is done to submit them separately to the test changes. You can also do this with other people's commits and the authorship is not modified.

  • Changing the order of commits, dropping, squashing and combining commits (ie. fixup)

  • Amending a commit on my local branch that's not the last commit (rewording, adding/removing changes, etc).