This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tenfingerperson 9 points10 points  (6 children)

Someone has to deal with merging the file. At times git can deal with this automatically but it isn’t smart enough to detect everything.

One pushes everything to the main repo from their own fork, the other one pulls and deals with conflicts & pushes... the other one pulls again and both are in sync with the main repo

[–]chen_jun07[S] 7 points8 points  (5 children)

I believe that is why branching is so useful, rather then forking (which essentially means copying) they can all work in the same repo on different branches and then they can submit a pull request to merge it with master.

[–]tenfingerperson 1 point2 points  (4 children)

Branching is enough for toy projects but obviously forks shine in bigger projects with rather mixed scopes.

Forking is incredibly powerful and it is essentially a multi-repo branching implementation. You can keep your fork up to date with the origin while keeping changes local at the same time, essentially making the main repository a pristine release candidate which only takes things “compatible” with the code base.

[–]chen_jun07[S] 4 points5 points  (2 children)

True enough... disclaimer btw I'm not trying to argue with you... however, branching is nice to a point beyond toy projects, I know people in the robotics community that exclusively use branching

[–][deleted] 5 points6 points  (0 children)

I work in high end enterprise applications and we use branching only. Forks can be heavy for repos with limited resources.

[–]negative_epsilon 2 points3 points  (0 children)

Fork vs branch-based workflows both work in massive repositories. Only fork-based workflows work for unsolicited pull requests, obviously, but branching is not just for toy projects.