Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Points 2 and 4 are contradictory. You either group changes in a commit or make atomic commits. Both at the same time are not possible.
About the rebase thingy you should take care with that, let me explain:
You should avoid doing Rebase on a branch that is shared. i.e. if you are not alone working on that branch and the branch exists remotely as well as locally, rebasing is not a good choice as it can cause bubble commits. Also you should not do Rebase on pushed commits, i.e. If you are working on a branch and you already pushed some commits to this branch on remote/origin.
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Points 2 and 4 are contradictory. You either group changes in a commit or make atomic commits. Both at the same time are not possible.
About the rebase thingy you should take care with that, let me explain:
You should avoid doing Rebase on a branch that is shared. i.e. if you are not alone working on that branch and the branch exists remotely as well as locally, rebasing is not a good choice as it can cause bubble commits. Also you should not do Rebase on pushed commits, i.e. If you are working on a branch and you already pushed some commits to this branch on remote/origin.
You can find a good explanation in the ProGit Book, section titled "The Perils of Rebasing":
Squashing commits at the end of a PR >>> git rebase dark magic