Like, I'm the git guru on my team, and we're about to start a new project larger than what we've done before. My teammates are old school and don't get git

Is frequent rebasing something I should push for? A clean history is nice, but I've just won them over on feature branches... Is this something quick and easy that would improve our quality of life?

[–] zalgotext@sh.itjust.works 4 points 1 day ago* (last edited 1 day ago)

Is frequent rebasing something I should push for? A clean history is nice, but I've just won them over on feature branches... Is this something quick and easy that would improve our quality of life?

Realistically, in the short term, no. If neither you nor any of your team members are familiar with rebasing or rebase-based workflows, you will encounter problems that no one will know how to solve without researching. That'll lead to frustration, and before you know it those old school teammates that don't get git will fall back into using svn, or zip files with names like final_project_v1.2_final_final (copy)

I recommend getting familiar with rebase- and merge-based workflows on your own first, like on your own projects/private repos, and reading through the git documentation. Once you become more of an expert, you might be able to teach your teammates how to be proficient at using git, or at bare minimum, you'll be able to help them unfuck themselves when they inevitably fuck their repos up.

[–] kewjo@lemmy.world 3 points 1 day ago

it's great if your commits are smaller and more focused. main issue is it can be harder to solve some diff issues as it requires solving merges at each commit being rebased. so if you have a large feature branch that can be challenging when it starts to diverge a lot (ex: bug fixes on main). though the argument then is more for keeping branches smaller and focused which is a better process imo.

just beware it can be confusing for newer git users and when using shared branches can cause no ff commits.

[–] Traister101@lemmy.today 1 points 1 day ago

It can. It depends on what changed. If both of you touch the same file in a conflicting way you'll have to merge the commit with the conflict. If you don't then it just auto magically works.

For example if you have commits A - B - C with a branch A - D with D adding a brand new file you can trivially rebase (IE no need to merge) D onto C for a history of A - B - C - D

The best part about rebasing imo is that you get to merge commit by commit. Using the previous example if there's a conflict in commit B but nothing in C all you have to do is fix commit D to handle the changes B made, nothing else