DEV Community: Florian

What Really Belongs in a Git Repository? (Asking for a Friend)

Florian — Fri, 13 Jun 2025 15:49:59 +0000

You’d think by now we’d all agree on what goes into a Git repository. But alas — I still get pull requests containing .env, .p12, and even node_modules. So let’s settle this like adults (with a healthy dose of sarcasm and too much coffee).

🔐 Self-Signed Certificates

Ah yes, the good old cert.pem. Nothing screams "I'm new here" like committing private keys to a public repo.

Rule of thumb:

If it can be used to impersonate your server, decrypt traffic, or ruin your weekend — don’t commit it.

Exception:

If you’re building a fully fake local environment and your cert.pem is literally useless outside of localhost:3000, fine. But at least .gitignore the real ones.

📦 `.env` Files

Your .env file is like your toothbrush. Vital, personal, and not something you share with the internet.

Yes, I know:

“But it’s just the development config!”

Cool. Then use .env.example, strip out the secrets, and let your teammates fill in the blanks like grown-ups.

Exception:

Some people commit .env files with public/default values (e.g., PORT=3000). That's okay-ish — if you enjoy living on the edge. Just don’t cry when your database password ends up on GitHub’s trending page.

📁 `node_modules`, `vendor`, and other sins

This isn’t 2005. We have package managers now.

Don’t commit your dependencies.

Exception:

If you’re on a remote island with no internet and you're building a Docker image that needs offline builds. Even then, maybe ask yourself: Should I even be coding right now?

🛠️ Build Artifacts

Dist folders. Compiled binaries. Webpack outputs. You name it.

Don’t. Do. It.

Unless you're managing a release branch explicitly for deployment or versioning static artifacts.

Even then:

Tag your releases.
Upload the assets elsewhere.
Sleep better at night.

✅ What Should Be in Git?

Your source code (yep).
Configuration templates.
Docs. Real ones. Not just README.md with TODO in it.
Infrastructure as Code (Terraform, Dockerfiles, etc.)
Tests. (You do write tests, right?)

🧹 Also, don’t forget these...

Some files aren’t as obvious — but still don’t belong in your Git history unless you enjoy shame-based learning:

System/IDE configs: .DS_Store, Thumbs.db, .vscode/, .idea/, .swp
Local-only settings: .env.local, .eslintcache, .npmrc, .bash_history
Log & debug output: debug.log, *.log, npm-debug.log
Database dumps: dump.sql, *.sqlite, backup.db

They may seem harmless — until they become evidence.

TL;DR

If it's secret, generated, or weighs more than your project — don't commit it.

Your Git repo isn’t a trash bin or a backup drive. It's a versioned source of truth, not a confession booth for every debug print and API key you've ever written.

Treat it with respect, and it'll return the favor.

(Unless you rebase force-push on main, in which case: good luck.)

P.S.: If you're working with Vue 3 and want your forms to behave better than your coworkers’ Git hygiene, check out Vorm — a form engine that actually makes sense.

Why I built Vorm – a schema-based form engine for Vue 3 that doesn’t get in your way

Florian — Tue, 10 Jun 2025 08:17:53 +0000

Forms.

They’re everywhere.

Even when typing a URL, technically, you’re already interacting with one.

But let’s not get dramatic. 😄

Still, on nearly every site, every web app, we deal with forms in one way or another.

Login screens. Registration. Profile settings. Blog editors. Ordering a pizza.

Forms are not the enemy.

But something changed for me when I had to work on a massive form with over 120 fields, many of which were conditionally shown or enabled depending on other values:

"If select A has value X, then select B must be Y, and input Z disappears."

It was thousands of lines of code.

Not elegant. Not maintainable.

Just glue code to bind state, validation, conditional rendering, wrappers, etc.

At that point I asked myself:

Why do we keep doing this over and over again?

Why do I have to handcraft even the simplest login form or settings page from scratch —

or adopt a huge validation framework just to validate a checkbox?

Most forms are not special.

They follow simple patterns.

I realized: 90% of forms could be auto-generated, if we just had a tool that stays out of your way.

So I decided to build one.

I like schemas. I like types. I like simplicity.

And that’s what Vorm is built on.

At its heart is a reusable schema that defines everything:

fields
layout
validation
conditional logic
even styling

You define the schema once.

Then drop in a component like <AutoVorm />, maybe pass in a few props – and you're done.

No input spamming. No boilerplate. No magic.

Just clean, explicit structure.

But that wasn’t enough.

Vorm had to be flexible too. Because when the 90% doesn’t cut it —

you still need 100% control.

And so that’s how Vorm works:

Use AutoVorm for fast results.
Use useVorm() when you need full programmatic control.
Use wrappers, slots and your own components to style anything.

What Vorm became

A single schema — used everywhere.

Want to hide a field? showIf.

Want to change the wrapper component? Use the wrapper slot.

Want to inject your own field renderer? Go ahead.

And most importantly:
You always have full access to the reactive form data and validation state.

Here is a short example:

Define your scheme in script

const schema: VormSchema = [
  {
    name: 'username',
    label: 'Username',
    type: 'text',
    validation: [{ rule: 'required' }],
  },
  {
    name: 'email',
    label: 'Email address',
    type: 'email',
    validation: [{ rule: 'required' }, { rule: 'email' }],
  },
  {
    name: 'password',
    label: 'Password',
    type: 'password',
    validation: [{ rule: 'required' }],
  },
  {
    name: 'notes',
    label: 'Notes',
    type: 'textarea',
  },
  {
    name: 'role',
    label: 'Role',
    type: 'select',
    validation: [{ rule: 'required' }],
  },
  {
    name: 'adminCode',
    label: 'Admin code',
    type: 'text',
    showIf: { role: 'Admin' },
  },
  {
    name: 'tos',
    label: 'Accept terms',
    type: 'checkbox',
    validation: [{ rule: 'required' }],
  },
];

And then all you have to do is this:

<VormSection title="Basic Example" titleClasses="text-xl font-bold">
  <AutoVorm layout="grid" :columns="2" />
</VormSection>

To get this:

What happened to the 120-field beast?

I rebuilt that monstrous form in a separate project using Vorm.

It took some time — and honestly, it broke Vorm a few times. 😅

But that’s when Vorm started becoming real.

I moved all the logic into the schema. The template shrunk down to maybe 30–40 lines.

And the performance?

All 120 fields, fully validated, in under 20ms on cold start.

No debounce hacks. No suspense loading. Just solid reactive performance.

So… just another form library?

No. Or, yes — but one that does it differently.

Yes, Vorm is "another" form engine.

But it’s one that:

doesn’t force you into rigid components,
doesn’t ship with opinionated styling,
doesn’t rely on global mixins or massive plugins.
has only 51kB package size and uses "no" other dependencies

It’s not perfect.

The schema is strongly typed, but can be better.
File inputs aren’t natively supported yet (though you can easily render them via slots or wrappers).
It’s still very young — but very alive.

That’s why Vorm is currently in Alpha.

Not ready for your enterprise CRM.

But absolutely ready for small projects, experiments, side apps — and community feedback.

I want your thoughts

If you’ve ever written a form and thought

“Why am I still manually doing this?”

Then Vorm might be worth a look.

Try it.

Break it.

Tell me what doesn’t work.

Let’s shape this thing together, before it hits v1.0.

🧪 GitHub: https://github.com/Flo0806/vorm

📘 Docs: https://vorm.fh-softdev.de

🎮 Playground: Basic Example Real-World Example

Thanks for reading — and if this resonated with you, feel free to ⭐️ it or leave a comment.

Let’s make forms fun again. 🚀