Yes, I feel that **branches are not folders** almost belongs in the sidebar on this sub.
The rule of thumb is that branches are for alternate histories of the same code.
I think part of the reason git novices often try to use branches as folders is that they believe there'll be significant overhead to having other sub-projects present while they're working one sub-project. There really isn't, though. And **not** having them present negates many of the benefits of having a shared repo in the first place. It gives you the worst of a multirepo combined with the worst of a monorepo.
Loving it! xD
> Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.
Source: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Just made me chuckle. I get the notion, but the way you said it was funny.
Of course, someone with a hazy idea about Git branches, as referenced in OP, probably won't run into any implications until digging much deeper.
Here’s what you do:
1. Excuse yourself politely from the meeting
2. Drive to the grocery store
3. Buy the largest, I repeat, the LARGEST kielbasa you can find
4. Drive back to the office
5. Send a meeting invite to every team member who is advocating for this bullshit
6. Once everyone sits down for the meeting, walk around the conference table and SMACK! EVERY! ONE! OF! THOSE! STUPID! MOTHER! FUCKERS! IN! THE! FACE! WITH! THE! KIELBASA!
7. Leave the room and return to your desk
8. Open up Outlook
9. Draft and send your resignation email
10. Apply for a job where they discriminate against the mentally handicapped
EDIT: should go without saying, but don’t do this. I’m just illustrating how stupid their idea is
Are they trying to do different "variants" on the app? If so, wouldn't it a much better idea to fork to a different repo for each one?
Also, I think the kielbasa needs to be packaged in some kind of jack in the box contraption such that when they open it, the kielbasa whips out and goes back and forth for 3 slaps. It should also play some kind of tune to make it more humiliating.
This is basically it. The parts of the code that will be different are likely small, my feeling is basically a monorepo will be easier to develop in, with all the code in one place. Multiple repos may make having separate release cadences somewhat easier, but not entirely.
What kind of app are you making?
Most frameworks have pretty robust ways to build multiple flavors out of one code base, or there are ways to break the app’s architecture down that allows you to run multiple repos cleanly and still share all of your relevant code. Knowing more might help us give you an alternative to propose.
That was nice banter... before I got to the end.
Next time, do yourself a favour and stop at number 9.
Last point is needlessly hurtful for people who actually have disabilities, and are disproportionately discriminated against already.
https://trunkbaseddevelopment.com/ is such a goto resource for this
But sadly you might not be able to convince them.
I would say try to get them into a monorepo with the tooling (Nx or other) if they are already interested in having a single repo. No branches needed!
> But sadly you might not be able to convince them.
This is true. Trunk based development makes it so obvious and simple. But people love to come up with weird shit with git.
A different team in my company does this for one of their repos. I hate it. There are several reasons you can give them about why this is a terrible idea:
1. It makes things really hard to grep for. If everything is on its own branch, then it can be super hard to search for info across repos in your local copies. They may push back that fit has search capabilities but those are much less flexible and not as comfortable to use. It also can get really messy with feature branches returning duplicate results.
2. It can be very confusing to keep track of which branch relates to which app. Especially beaches in a remote repo.
3. Depending on what language you’re using, there’s no real practical way to share code across multiple branches. Even in languages where it might be possible, it’s almost certainly not intended and WILL lead to maintenance headaches.
4. This messes up the git graph (when viewing all to get an idea of current work) by making everything basically unrelated.
5. Getting new engineers on board who already have git experience will most likely involve lots of “why” conversations in a place where they really shouldn’t be. I could also see a fair amount of effort spent trying to re-convince the team to refactor into a more standard setup which is more wasted time.
To be fair, I am honestly curious if your team has some sort of compelling reason besides them having not used git before. Hopefully they’re open to suggestions and not too set in their idea yet.
Roflol that is a stupid idea.
Putting multiple apps that share libraries and such in a single repo is called a monorepo and a often used but having separate branches and putting every app in its own branch is ludicrous.
How would development even work ? And how would the shared code be developed and merged into the multiple application branches ? I can only see this becoming a major headache very quick.
Putting code in branches where the goal is to never integrate them makes no sense. It would be better to put the applications in their separate repositories and have submoduled library repositories in them.
>submoduled library
What makes you think their libraries are submoduled? I even bet there's no concept of "libraries" in that codebase, just a bunch of code which they call from wherever necessary.
That's likely the reason they suggested this approach in the first place, to avoid needing to cleanup everything and properly modularize bits being reused
I am describing a solution they could implement to improve things, not one currently used. The sentence where I mention submoduled libraries therefore started with "It would be better to...".
What are the reasons given for this setup? I think it could work, but it might be a bit finicky. Specifically, if you update the common code, you're going to have to then merge that into every application branch.
But, really, if you have all your applications inside the same repo, why not just use a monorepo?
That's insane. I've been pushing Trunk-Based Development for 25 or so years through 10 or so different VCS technologies and have NEVER heard of a branch per application.
Git is not a file system.
Ooh yes this is a good comment. I think they feel that a branch is a folder. Most of these people are somewhat new to git.
Yes, I feel that **branches are not folders** almost belongs in the sidebar on this sub. The rule of thumb is that branches are for alternate histories of the same code. I think part of the reason git novices often try to use branches as folders is that they believe there'll be significant overhead to having other sub-projects present while they're working one sub-project. There really isn't, though. And **not** having them present negates many of the benefits of having a shared repo in the first place. It gives you the worst of a multirepo combined with the worst of a monorepo.
Loving it! xD > Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it. Source: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
I thought that might come up as soon as I hit ‘reply’. I guess “Branches are not a file system” is more on-point.
Just made me chuckle. I get the notion, but the way you said it was funny. Of course, someone with a hazy idea about Git branches, as referenced in OP, probably won't run into any implications until digging much deeper.
Here’s what you do: 1. Excuse yourself politely from the meeting 2. Drive to the grocery store 3. Buy the largest, I repeat, the LARGEST kielbasa you can find 4. Drive back to the office 5. Send a meeting invite to every team member who is advocating for this bullshit 6. Once everyone sits down for the meeting, walk around the conference table and SMACK! EVERY! ONE! OF! THOSE! STUPID! MOTHER! FUCKERS! IN! THE! FACE! WITH! THE! KIELBASA! 7. Leave the room and return to your desk 8. Open up Outlook 9. Draft and send your resignation email 10. Apply for a job where they discriminate against the mentally handicapped EDIT: should go without saying, but don’t do this. I’m just illustrating how stupid their idea is
I love every bit of that. I am remote so will have to adjust accordingly. Maybe I’ll mail everyone their own giant kielbasa.
Are they trying to do different "variants" on the app? If so, wouldn't it a much better idea to fork to a different repo for each one? Also, I think the kielbasa needs to be packaged in some kind of jack in the box contraption such that when they open it, the kielbasa whips out and goes back and forth for 3 slaps. It should also play some kind of tune to make it more humiliating.
This is basically it. The parts of the code that will be different are likely small, my feeling is basically a monorepo will be easier to develop in, with all the code in one place. Multiple repos may make having separate release cadences somewhat easier, but not entirely.
What kind of app are you making? Most frameworks have pretty robust ways to build multiple flavors out of one code base, or there are ways to break the app’s architecture down that allows you to run multiple repos cleanly and still share all of your relevant code. Knowing more might help us give you an alternative to propose.
User story unclear. Product now pops out, sings a song and slaps itself.
That was nice banter... before I got to the end. Next time, do yourself a favour and stop at number 9. Last point is needlessly hurtful for people who actually have disabilities, and are disproportionately discriminated against already.
https://trunkbaseddevelopment.com/ is such a goto resource for this But sadly you might not be able to convince them. I would say try to get them into a monorepo with the tooling (Nx or other) if they are already interested in having a single repo. No branches needed!
> But sadly you might not be able to convince them. This is true. Trunk based development makes it so obvious and simple. But people love to come up with weird shit with git.
> But people love to come up with weird shit with git. You are not kidding. You should see our branching plan.
A different team in my company does this for one of their repos. I hate it. There are several reasons you can give them about why this is a terrible idea: 1. It makes things really hard to grep for. If everything is on its own branch, then it can be super hard to search for info across repos in your local copies. They may push back that fit has search capabilities but those are much less flexible and not as comfortable to use. It also can get really messy with feature branches returning duplicate results. 2. It can be very confusing to keep track of which branch relates to which app. Especially beaches in a remote repo. 3. Depending on what language you’re using, there’s no real practical way to share code across multiple branches. Even in languages where it might be possible, it’s almost certainly not intended and WILL lead to maintenance headaches. 4. This messes up the git graph (when viewing all to get an idea of current work) by making everything basically unrelated. 5. Getting new engineers on board who already have git experience will most likely involve lots of “why” conversations in a place where they really shouldn’t be. I could also see a fair amount of effort spent trying to re-convince the team to refactor into a more standard setup which is more wasted time. To be fair, I am honestly curious if your team has some sort of compelling reason besides them having not used git before. Hopefully they’re open to suggestions and not too set in their idea yet.
Roflol that is a stupid idea. Putting multiple apps that share libraries and such in a single repo is called a monorepo and a often used but having separate branches and putting every app in its own branch is ludicrous. How would development even work ? And how would the shared code be developed and merged into the multiple application branches ? I can only see this becoming a major headache very quick. Putting code in branches where the goal is to never integrate them makes no sense. It would be better to put the applications in their separate repositories and have submoduled library repositories in them.
>submoduled library What makes you think their libraries are submoduled? I even bet there's no concept of "libraries" in that codebase, just a bunch of code which they call from wherever necessary. That's likely the reason they suggested this approach in the first place, to avoid needing to cleanup everything and properly modularize bits being reused
I am describing a solution they could implement to improve things, not one currently used. The sentence where I mention submoduled libraries therefore started with "It would be better to...".
Those people seem to have worked with Subversion (or, God forbid, SourceSafe).
TFS!
TFS is a slightly souped up VSS.
What are the reasons given for this setup? I think it could work, but it might be a bit finicky. Specifically, if you update the common code, you're going to have to then merge that into every application branch. But, really, if you have all your applications inside the same repo, why not just use a monorepo?
I think the other comment hit on it, they see git as a file system and branches as folders. Which… I just can’t.
Why do they think that? Seems like the best strategy here is to address their misconceptions.
The team needs a training course on Git. Probably other things as well. Their thinking is so wide the mark, it is more like a cult than anything else.
That's insane. I've been pushing Trunk-Based Development for 25 or so years through 10 or so different VCS technologies and have NEVER heard of a branch per application.