Bro every time this guy wants to create a PR, rather than branching off another branch and raising a PR to get it merged back in, this dude creates a fork and then makes a PR to merge the fork back in.

Holy. Fuck. Please don’t do this. It makes checking out your “branch” a massive pain in the ass. Plus, it’s totally unnecessary, and I can’t even check it out to begin with because your forked repo is fucking private you stooge. If we were in completely different orgs or doing open source I’d understand a fork. Not if you’re sitting right fucking next to me!!!!!111

Yeah, much better to have the main repo littered with hundreds of junk branches

@Kernel does not change the fact that all the WIP and abandoned branches are still there

Is it an open source project or a private dev team project?

@Kernel cannot agree on that. If it's some very small project, then maybe it is viable, but for a medium to large one it will be a nightmare of branches. The main repo shall be the representation of the final product, so only the relevant branches should be present there.

There is nothing wrong with either trunk or git flow development if used properly. I have worked in both situations and they both have their pros and cons.

Dude, creating forks is the standard practice, that helps to avoid creating(and forgetting to delete) and keeping tons of ghosts branches.

@arcioneo Wrong. So wrong.

There is absolutely no need to fork a repository when you’re working in a small team who all are familiar with the code base.

“Ghost branches” are easily avoidable with some basic discipline. Also, most source control management systems allow you to delete branches once they’ve been merged.

Forking makes it incredibly annoying to checkout someone else’s work to validate they have implemented something correctly. This means for every person that forks the repo, you need to clone their forked repo to checkout their work. THIS IS STUPID.

Forking can lead to certain security issues as well.

The argument regarding branches is pretty dumb in my opinion.

One works locally in git - you need not to have every remote branch checked out.

Git was *made* for branches. They're the primary concept of git.
Saying no to a lot of branches is saying no to GITs core concept.

If you have a problem in your IDE which tries to download 800 remote branches at once just to give you a search bar for choosing a branch.... Then the problem is the IDE.

Git even offers to search for a remote branch case insensitive with patterns via CLI, as - already said, yes - branches are the primary concept in git.

It all comes down wether one wants to take offense in having a lot of branches or not... I don't see a problem in it.

The last branch cleanup script I wrote was a 2 hour bash quickie.

@whiskey0 you don't need to clone the whole repo. Just add another source tohtge existing one and checkout

@whiskey0 I am not sure how you rebase or merge latest changes on a fork to merge on the target repo/branch afterwards. I mean, sure, you can sync a fork but it's not designed to be merged back afterwards lol.

It would only make sense to sync in a ghetto manner on an open source repo if you want to hide some development work maybe, but there is surely a smarter way.

It's pretty much standard way of working for any bigger open source project

I really don’t think it’s that big of a deal either way - the main thing IMO is to not fuck up your history. I often see fucked up histories in trunk strategies.

Cherry-picking maybe useful? 🤔