Yeah
-
It's 2.7 lol
Well it says 27
-
It caters more for a linear workflow, though. So modern large teams won't find joy with SVN
For what it's worth, I work at a FAANG company and we don't use branches at all. Instead, we use feature flags. Source control history is linear with no merges.
All code changes have to go though code review before they can be committed to the main repo. Pull requests are usually not too large (we aim for ~300 lines max), contain a single commit, aren't long-lived (often merged the same day they're submitted unless they're very controversial), can be stacked to handle dependencies between them ("stacked diffs"), and a whole stack can be landed together. When merged, everything is committed directly to the main branch, which all developers are working off of.
I know that both Google and Meta take this approach, and probably other companies too.
What's the difference between that and feature branches? Sounds like you still have PRs that get merged to main from somewhere - forked repos I guess?
-
Owned by Microsoft. Microsoft recently blocked e-mail access to a LibreOffice dev. Speculation is that they'll start blocking projects for competing products next.
(Alternative explanation: Gitlab should be part of IT divestment from US-based services.)
Gitlab itself is American these days, legally speaking.
Try Forgejo, self hosted or one of the European hosts (some allow private projects)
-
Well it says 27
I know
-
I'm not that accustomed with it myself, so my question: how can you bork your local repo so you can't roll back? Did you tinker in the .git folder? xD
There are many ways. Like the other user said, fucking up a merge/rebase then fucking up the merge abort.
Or (one of my personal favorites) accidentally typing
git reset --hard HEAD~11instead ofHEAD~1 -
Git is so easy to host yourself and everyone went and handed over all their code to evil corp to farm on anyway.
(Though I do understand that they were bought, but that was a while ago and it was only a matter of time before the evil seeped in.)
Their CI/CD minutes are very generous (unlimited!). Plus, if Microsoft wanted to scrape code, it doesn't have to be on Github. They can scrape it off codeberg too. And I can be sure Github won't shut down.
If Github does decide to screw users over, switching to self-hosted forgejo would be trivial.
-
Try Codefloe, it has a free tier and you can host both public and private projects.
It looks good. Thanks.
-
What's the difference between that and feature branches? Sounds like you still have PRs that get merged to main from somewhere - forked repos I guess?
wrote last edited by [email protected]Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be dozens of commits and weeks of work from several developers. The code isn't merged until the feature is complete. It's more common in the industry compared to trunk-based development.
My previous employer had:
- Feature branches for each new feature.
- A dev/trunk branch, where features branches were merged once they were done.
- A beta branch, branched from dev once per week.
- A live/prod branch, branched from beta four times per year.
This structure is very common in enterprise apps. Customers that need stability (don't want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.
Bug fixes were annoying since you'd have to first do them in the live branch then port them to the beta and dev branches (or vice versa).
On the other hand, feature flags mean that all the code goes directly into the trunk branch, but it's turned off until it's ready. A basic implementation of feature flags would be a static class with a bunch of booleans that get checked throughout the code, but they're usually dynamic so a misbehaving feature can be turned off without having to redeploy the code.
Some codebases use both feature branches and feature flags.
-
Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be dozens of commits and weeks of work from several developers. The code isn't merged until the feature is complete. It's more common in the industry compared to trunk-based development.
My previous employer had:
- Feature branches for each new feature.
- A dev/trunk branch, where features branches were merged once they were done.
- A beta branch, branched from dev once per week.
- A live/prod branch, branched from beta four times per year.
This structure is very common in enterprise apps. Customers that need stability (don't want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.
Bug fixes were annoying since you'd have to first do them in the live branch then port them to the beta and dev branches (or vice versa).
On the other hand, feature flags mean that all the code goes directly into the trunk branch, but it's turned off until it's ready. A basic implementation of feature flags would be a static class with a bunch of booleans that get checked throughout the code, but they're usually dynamic so a misbehaving feature can be turned off without having to redeploy the code.
Some codebases use both feature branches and feature flags.
Ah okay, places I've worked have tried to keep tasks as small as possible so you don't work on your feature branch more than a day. If it takes over a day, should've been an epic (and therefore multiple feature branches). Seen different approaches to the whole release thing too. Weekly deployments, 3x per year, or in my current company: deploy as soon as someone has tested it
-
This post did not contain any content.
This is how you lose your data if something goes wrong. Also, patch notes are extremely good to have.
