In case of fire:

1. git commit
2. git push
3. leave building

git push --force

You don't want to have to deal with the conflicts

Git commit
Git pull
Conflict
Git rebase?
Resolve using theirs?????
Just burn in the building?!?!?!?!?

Depending of the dev that might just spread the fire into production... true story

@CorruptComputer why would each dev have their own forks on an internal project? Forks for open source yes, but for a small dev team that just makes things more convoluted

- Git commit
- Git push...
Network problem because of the fire
- Die

@CorruptComputer but that's not the purpose of forks.

From github: Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.

Forks are either used to make changes to someone else's project or as a starting point in a new direction, but in a dev team it's a collaborative project, not any single developers so there's no need for forks.

Having worked on projects where devs have had their own forks and where they haven't, I can definitely say from my own experience that individual forks only make things worse. We had one instance where our commits started colliding between devs because the individual forks had no way of keeping track of the hash's across the different forks. And that was with only 20 devs!!!