0

Trying to learn best practices for git when working in a team.

When is good to use rebase and when to use squash and when is NOT good to use them? (scenarios description/examples would be great to illustrate)

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
Joe
  • 11,983
  • 31
  • 109
  • 183
  • I might be wrong, but this does not seem specifically enough about programming to be on-topic for SO, and I think it's too broad/vague to be of much use to any of the related sites either. – underscore_d May 01 '18 at 15:55
  • 2
    Best practices are almost always opinion based, which is off topic. This isn't to mention you should be able to find plenty of examples online. – jhpratt May 01 '18 at 15:56
  • Can I get some opinions? – Joe May 01 '18 at 18:59
  • Related: https://stackoverflow.com/questions/5250817/git-rebase-loses-history-then-why-rebase?lq=1 – k0pernikus May 03 '18 at 11:08
  • I have written a recomendation for a git workflow in here: https://stackoverflow.com/a/49922422/457268 – k0pernikus May 03 '18 at 11:21

1 Answers1

0

When not to use them: If you are afraid of changing the git history, and potentially, losing changes.

When to use: In order to keep a consistent flat history with on-point messages.

  • Squash
    • Assume you are working on a branch and do a bunch of commits in the form of wip templates, wip logic, wip -- you then can combine all those intermedient commits into one big commit through squash and create a decent message for them.

I don't squash manually anymore as most decent web clients (e.g. bitbucket, github) allow for squash merging strategy for Pull Requests.

  • Rebase
    • Avoids merge commits (tango history)
    • git undoes all your commits, uses a different state of another branch as the new base, and re-applies your commits. Each of your commits will get a new hash in the process.
    • Use it to keep a feature branch up to date with the main branch

Both rebase and squashing change the history and should therfore only be used on feature branches owned by one developer. Your main branch should and any public branch should stay as they are.

(You may allow always for pull --rebase instead of pull as that only changes the history of your local repository.)

k0pernikus
  • 60,309
  • 67
  • 216
  • 347