DEV Community: Emanuele Bartolesi

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

Emanuele Bartolesi — Wed, 01 Apr 2026 12:21:58 +0000

Most GitHub Copilot setups are too polite to be useful.

By default, Copilot tries to agree, avoid criticism, and keep answers "safe".
That sounds good, but in practice it leads to weak suggestions, missed problems, and bad decisions slipping through.

If you want better output, you need to change its behavior.

The simplest way is a tone of voice file.

Create a voice-instructions.md in your repo and force Copilot to be critical:

---
applyTo: '**'
---

Give direct, critical feedback.
Identify mistakes, weak assumptions, unnecessary complexity, unclear naming, hidden risks, and poor trade-offs without softening the message.

Do not add generic praise or filler. Do not agree by default.

When something is wrong, say exactly what is wrong, why it is a problem, and what should be done instead.

Prioritize correctness, clarity, simplicity, maintainability, and practical delivery.

Challenge vague requirements and surface missing constraints, edge cases, and operational risks.

Be blunt but professional. Never be insulting. Always aim to be useful.

You get:

Clear problems called out
Weak assumptions challenged
Simpler and more maintainable alternatives

The result is better code and faster decisions.

There is a trade-off.

It feels harsher.
It is not ideal for beginners.
It removes the "friendly assistant" vibe.

But if you are building real systems, that is the wrong goal anyway.

If you want better output, demand better behavior.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Git Mirroring During Migrations: `--all` vs `--mirror`

Emanuele Bartolesi — Mon, 16 Mar 2026 07:00:00 +0000

During a Git migration, the new platform is rarely switched on overnight.

In many real scenarios, two systems must coexist for a while. For example:

repositories move from GitLab to GitHub
CI pipelines still run in GitLab
developers start working in GitHub

In this transition phase, the repositories must stay synchronized between both platforms.

One common solution is repository mirroring, where changes from one repository are pushed to another remote so both systems stay aligned.

Two approaches are often used for this:

git push gitlab --force --all
git push gitlab --force --tags

git push gitlab --force --mirror

At first glance, these commands may look equivalent. They are not.

The Common Approach: Pushing Branches and Tags

A common way to keep two repositories in sync is pushing all branches and tags to the second remote.

git push gitlab --force --all
git push gitlab --force --tags

These two commands are often used together during migrations.

`git push --all`

git push gitlab --force --all

This command pushes all local branches to the remote.

Important details:

It pushes every branch under refs/heads/*
It does not push tags
It does not push other reference types

So after this command runs, the remote repository will contain the same branches as the local repository.

`git push --tags`

git push gitlab --force --tags

This command pushes all tags under refs/tags/*.

Tags are often used for:

releases
versioning
deployment markers

Since --all does not include tags, they must be pushed separately.

What This Approach Synchronizes

Using these two commands ensures that:

all branches are synchronized
all tags are synchronized

For many teams, this is already enough to keep two repositories aligned during a migration.

However, this approach does not synchronize the entire repository state. Some Git references are still missing.

This is where --mirror behaves differently.

The Full Mirror Option

Git also provides a command designed specifically for repository mirroring:

git push gitlab --force --mirror

This command behaves differently from pushing branches and tags separately.

Instead of pushing selected references, --mirror pushes every reference under refs/* from the local repository to the remote.

This includes:

branches (refs/heads/*)
tags (refs/tags/*)
remote-tracking branches
notes
any other custom references

Another important behavior is that --mirror synchronizes deletions.

If a reference exists on the remote but no longer exists locally, --mirror will remove it from the remote as well. The goal is to make the remote repository an exact replica of the source repository.

In other words:

--all + --tags copies branches and tags
--mirror copies the entire reference namespace

This makes --mirror the closest thing to a true Git repository mirror.

Quick Recommendation

Both approaches can work during a migration, but they serve slightly different goals.

Use `--all` + `--tags` when

git push gitlab --force --all
git push gitlab --force --tags

This approach is usually enough if you only need to synchronize:

branches
tags

It is also safer in environments where the target repository may contain additional references created by tooling, CI systems, or platform features.

Since it does not delete references on the remote, it reduces the risk of accidentally removing something important.

Use `--mirror` when

git push gitlab --force --mirror

This option is appropriate when you want the destination repository to be a complete mirror of the source.

Typical cases include:

temporary mirrors during platform migrations
backup repositories
strict synchronization between two Git servers

However, --mirror is more aggressive. It will overwrite and delete references on the remote to match the source exactly.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub Copilot to Generate Conventional Commit Messages in VSCode and JetBrains Rider

Emanuele Bartolesi — Tue, 17 Feb 2026 08:03:45 +0000

Most commit messages are useless.

"fix stuff"
“update code"
"changes"

They work in the moment. They fail six (actually one) months later.

Commit messages are not for today or for something special. They are for:

your future self
your teammates
automation pipelines
changelog generators
semantic versioning

Writing structured commit messages takes discipline. Under pressure, discipline disappears. Even without the pressure sometimes, just because as developers, we are lazy by nature.

This is where GitHub Copilot becomes interesting.

Instead of using Copilot just for code, you can use it as a commit quality guardrail. With the right instructions, it generates strict Conventional Commit messages automatically, directly inside:

VS Code
JetBrains Rider

Why Conventional Commits Still Matter

Conventional Commits are not about style.
They are about structure.

The format is simple:

type(scope): description

Example:

feat(auth): add JWT token validation
fix(api): handle null response in user endpoint
refactor(ui): simplify navbar component

Readable Git History

Compare:

update stuff
fix bug
changes

With:

fix(auth): prevent null pointer on login
feat(api): add user filtering by role
ci(github-actions): add build cache

The second history is self-documenting.

Using GitHub Copilot for Commit Messages in VS Code

Copilot can generate commit messages directly from the Source Control panel.

By default, generation is generic.
Custom instructions make it strict.

Add this to your settings.json:

"github.copilot.chat.commitMessageGeneration.instructions": [
    { "text": "Follow Conventional Commits: type(scope): description." },
    { "text": "Use lowercase type and scope." },
    { "text": "Use imperative mood: 'add', 'fix', 'update', not past tense." },
    { "text": "Keep subject under 50 characters. No period." },
    { "text": "Describe the intent clearly. Avoid vague messages like 'update code'." },
    { "text": "Use only these types: feat, fix, docs, style, refactor, perf, test, chore, ci." },
    { "text": "Include a scope when the change targets a specific area." },
    { "text": "Ensure each commit represents one logical change." },
    { "text": "Add a body when needed, separated by a blank line." },
    { "text": "Use bullet points (*) in the body for multiple changes." },
    { "text": "Explain why the change was made, not only what changed." },
    { "text": "Add BREAKING CHANGE: in the footer when applicable." }
]

After staging changes, generate the commit message.

Instead of:

update login logic

You’ll get:

fix(auth): prevent null pointer on login

* add null check for user object
* improve error handling for invalid credentials

Copilot becomes consistent because the rules are explicit.

Using GitHub Copilot for Commit Messages in JetBrains Rider

In Rider, Copilot integrates in the Commit tool window.

With strict instructions, you can enforce full compliance.

Example instruction structure:

Follow the Conventional Commits specification strictly.

<type>(<scope>): <short description>

All sections except the first line are optional.
Use only these types: feat, fix, docs, style, refactor, perf, test, chore, ci.
Max 50 characters. Imperative mood. No period.
Each commit must represent one logical change.
Use BREAKING CHANGE: footer when applicable.

Example output:

feat(auth): add refresh token support

* implement refresh token endpoint
* update token validation logic
* improve session security

Breaking change example:

refactor(api): rename user endpoint

BREAKING CHANGE: /users endpoint is now /v2/users

Go to Settings *> **Tools *> **GitHub Copilot > Git Commit Instructions > Global.

Rider allows more verbose enforcement.
VS Code favors compact rule lists.

Both approaches work.

Making Copilot Strict (Not Creative)

Copilot predicts text.
Constraints reduce variance.

Key principles:

Write hard rules, not suggestions
Limit allowed types
Enforce atomic commits
Require proper breaking change footers
Review output before committing

Copilot is not replacing judgment.
It removes repetitive formatting work.

When configured correctly, writing a proper Conventional Commit becomes easier than writing a bad one.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

A Practical GitFlow Setup That Works on GitHub

Emanuele Bartolesi — Mon, 02 Feb 2026 12:06:43 +0000

I use GitFlow even for my side projects.

Not because it is elegant. Not because it is modern. I use it because it forces me to behave like the project matters, even when nobody else is watching.

When you work alone, shortcuts are tempting. You push directly to main. You skip reviews. You promise yourself you will clean it up later. Later never comes. GitFlow, with the right rules, removes that option. It makes discipline the default instead of a personal choice.

This is important to say upfront. GitFlow is not light. It adds structure, friction, and process. If you deploy to production ten times per day, GitFlow will slow you down. In that case, trunk-based development with feature flags is usually the better choice.

But when you ship versioned releases, when you have a real staging phase, or when you want a clean separation between “work in progress” and “ready to release”, GitFlow still works well. Even for a solo developer.

Everything in this article is what I actually run on GitHub today. On client projects (when they want to use GitFlow, of course). On open source. On side projects that may never make money.

If you are going to use GitFlow, use it properly. Otherwise, do not use it at all.

2. When GitFlow Makes Sense and When It Does Not

GitFlow is a release model, not a productivity hack.

I use it when the way I ship software matches the assumptions GitFlow makes. If those assumptions are wrong, the model fights you every day.

When GitFlow makes sense

GitFlow works well for me in these cases.

You ship versioned releases. You care about v1.2.3 meaning something. You want a clear moment where a release is cut, stabilized, tested, and then shipped.

You have a real staging phase. Not “production with a flag”, but an environment where release candidates live, get tested, and sometimes get rejected.

You need parallel workstreams. New features continue on develop while a release is being stabilized, or while a hotfix is being prepared.

You want a hard separation between work in progress and releasable code. main always deployable. develop allowed to move faster and break occasionally.

In these scenarios, GitFlow reduces stress instead of adding it. The branches reflect reality.

When GitFlow is the wrong choice

I avoid GitFlow in these situations.

You deploy to production continuously. Multiple times per day. No staging. No release windows. In that world, GitFlow adds branches without adding safety.

Your team already struggles to keep develop stable. GitFlow assumes you can treat develop as an integration gate. If you cannot, you are better off with trunk-based development and feature flags.

You do not have environments to support it. No staging. No separation between integration and production. In that case, GitFlow becomes naming theater.

The most common mistake

The worst setup I see is this.

Teams adopt GitFlow “by the book”, but keep their old habits. Direct pushes sneak in. Hotfixes do not get merged back. Releases happen straight from develop because it is “almost ready”.

3. The GitFlow Branch Model I Actually Use on GitHub

I keep the branch model boring and strict. No variations. No “almost GitFlow”. If I start bending the rules, the model stops working.

These are the only branches I use.

`main`

main is always releasable. Always.

I never push directly to it. Not even for a typo. If main is broken, the whole model failed upstream.

What this gives me is simple. At any point in time, I can tag main and ship. No excuses. No cleanup phase.

If you cannot guarantee this, GitFlow gives you nothing.

`develop`

develop is my integration branch.

This is where features meet. This is where conflicts show up early. This is where I accept temporary instability, but only temporarily.

I treat develop as protected, even when I work alone. No direct pushes. Always via pull request. That PR is my forced pause to think: is this actually ready to be integrated?

If develop stays broken for days, GitFlow collapses. Integration must be frequent and boring.

`feature/*`

All work starts here.

Feature branches are short-lived by design. If a feature takes more than three to five days, I split it. Long-lived feature branches are the biggest source of merge pain and hidden risk.

I do not optimize for “perfect feature branches”. I optimize for deleting them quickly.

Examples:

feature/auth-token-refresh
feature/api-rate-limits
feature/ui-settings-page

Once merged into develop, the branch is gone. No reuse. No resurrection.

`release/*`

I only create a release/* branch when I actually need stabilization.

If there is no staging phase, I skip release branches entirely. Creating them without a purpose is pure ceremony.

A release branch exists to say one thing: no new features. Only fixes, hardening, documentation, and versioning.

Typical names:

release/1.4.0
release/2026.02

When the release is ready, it gets merged into main, tagged, and then merged back into develop. Always both. This is where many teams drift.

`hotfix/*`

Hotfixes are rare. That is intentional.

A hotfix starts from main, never from develop. It fixes production. Nothing else.

After the fix, I merge it into main and immediately back into develop. Skipping the back-merge is the fastest way to reintroduce the same bug later.

Names stay explicit:

hotfix/login-nullref
hotfix/payment-timeout

Hotfixes are treated with more care, not less.

4. The Rules That Make GitFlow Work (And Why I Enforce Them on Myself)

GitFlow without rules is just branch naming.

I enforce the same rules on my side projects that I enforce on client projects. The reason is simple. If the setup only works when I am “careful”, it will fail under pressure.

Protected branches are non-negotiable

I protect main and develop. Always.

No direct pushes.
No force pushes.
No branch deletion.
Pull requests only.

Even when I am the only contributor.

This removes temptation. I cannot “just push a quick fix”. Every change goes through the same path. That consistency is the real value.

Pull requests are mandatory checkpoints

A pull request is not about collaboration. It is about forcing a decision point.

Before merging, I answer a few basic questions:

Why does this change exist?
What exactly changed?
How did I verify it works?
What is the risk?

If I cannot answer those clearly in a PR description, the change is not ready.

This sounds heavy. In practice, it saves time. It avoids “I’ll fix it later” commits.

Approvals still matter, even solo

I require at least one approval.

Yes, I approve my own PRs. That is not the point.

The point is the pause. The forced context switch. Opening the PR, reading the diff in GitHub, and approving it is different from pushing code from an editor.

That pause catches mistakes more often than people expect.

Conversation resolution is underrated

I require all conversations to be resolved before merging.

This prevents half-finished reviews and “we will come back to this” comments that never get addressed.

If a comment exists, it deserves a decision. Fix it. Reject it. Explain it. Then resolve it.

Linear history vs merge commits

This is where teams hurt themselves.

If your team is comfortable with rebasing and understands it well, require a linear history. It keeps develop clean.

If not, allow merge commits. But standardize it. Do not mix strategies per PR.

I personally use:

Squash merge for feature/* into develop
Merge commits for release/* and hotfix/* into main

The key is not which option you pick. The key is that it is enforced, not debated every time.

5. Pull Requests as the Core Unit of Work

In my setup, branches exist to create pull requests. Pull requests are the real workflow.

If you get PRs right, GitFlow becomes manageable. If PRs are large, vague, or inconsistent, GitFlow falls apart.

A boring PR template on purpose

I use the same PR template everywhere. It is intentionally simple.

Why: the problem or reason for the change
What: what changed at a high level
How tested: tests run, manual checks, environments
Risk: what could break
Rollback: how to undo it if needed

This is not documentation. It is a forcing function. If I cannot fill this in quickly, the PR is probably doing too much.

Small PRs beat clever branch strategies

If a reviewer needs more than 30–45 minutes, the PR is too big.

Large PRs hide bugs. They also create social pressure to approve without fully understanding the change. That is how regressions slip in.

I optimize for PRs that can be reviewed quickly and confidently. That usually means slicing features into vertical, mergeable steps.

GitFlow does not fix big PRs. It amplifies the pain if you allow them.

CODEOWNERS even for tiny repos

I use CODEOWNERS even when I am the only owner.

It makes review routing explicit. It also prepares the repo for future contributors without rethinking the rules.

More importantly, GitHub treats CODEOWNERS reviews differently. That gives you another enforcement layer, not another convention.

6. Naming, Traceability, and Future Me

Most conventions exist for one reason. You will forget.

Future me is the main consumer of my Git history. Not GitHub. Not tools. Me, six months later, trying to understand why something exists.

Branch names should explain intent

I use explicit branch names. Not clever ones.

feature/login tells me nothing.
feature/oauth-token-refresh tells me exactly what problem was being solved.

If I use an issue tracker, I include the ID:

feature/ABC-123-oauth-token-refresh

This costs seconds. It saves minutes every time I search history.

PR titles are part of the changelog

I treat PR titles as public API.

Release notes, changelogs, and audit trails are generated from them. If the title is vague, everything downstream becomes vague.

I avoid “fix stuff” or “cleanup”. I prefer:

“Fix token refresh race condition”
“Add rate limiting to public API”

If I cannot summarize the change in one sentence, the PR is probably too large.

Link everything, even when it feels redundant

I always link PRs to issues. Always.

Even on side projects. Even when the issue only exists to track the PR.

GitHub already gives you the syntax. Use it.
Closes #123 is enough.

This creates a navigable graph. Branch to PR. PR to issue. Issue to release. Without links, GitFlow loses one of its biggest advantages.

Traceability must be enforced, not suggested

If traceability is optional, it will be skipped.

I enforce naming and linking through:

Branch naming patterns
PR templates
Required checks

The goal is not bureaucracy. The goal is predictability.

Why this matters more with GitFlow

GitFlow creates more branches than trunk-based development. That increases cognitive load.

Naming and traceability reduce that load. They make the model survivable over time.

In the next section, I will map this structure to CI/CD pipelines, and explain what I run where, and why.

6. Naming, Traceability, and Future Me

Most conventions exist for one reason. You will forget.

Future me is the main consumer of my Git history. Not GitHub. Not tools. Me, six months later, trying to understand why something exists.

Branch names should explain intent

I use explicit branch names. Not clever ones.

feature/login tells me nothing.
feature/oauth-token-refresh tells me exactly what problem was being solved.

If I use an issue tracker, I include the ID:

feature/ABC-123-oauth-token-refresh

This costs seconds. It saves minutes every time I search history.

PR titles are part of the changelog

I treat PR titles as public API.

Release notes, changelogs, and audit trails are generated from them. If the title is vague, everything downstream becomes vague.

I avoid “fix stuff” or “cleanup”. I prefer:

“Fix token refresh race condition”
“Add rate limiting to public API”

If I cannot summarize the change in one sentence, the PR is probably too large.

Link everything, even when it feels redundant

I always link PRs to issues. Always.

Even on side projects. Even when the issue only exists to track the PR.

GitHub already gives you the syntax. Use it.
Closes #123 is enough.

This creates a navigable graph. Branch to PR. PR to issue. Issue to release. Without links, GitFlow loses one of its biggest advantages.

Traceability must be enforced, not suggested

If traceability is optional, it will be skipped.

I enforce naming and linking through:

Branch naming patterns
PR templates
Required checks

The goal is not bureaucracy. The goal is predictability.

8. Releases, Tags, and Changelogs I Can Trust

Releases are not a side effect. They are a deliberate action.

GitFlow only pays off if releases are predictable and traceable. That starts with being strict about where and how you tag.

Tags exist only on `main`

I tag releases only on main. No exceptions.

If a tag exists anywhere else, it lies. A tag should mean “this is what went to production” or “this is the shipped artifact”.

Tagging on develop or release/* breaks that guarantee and creates confusion later when you try to answer a simple question: what is actually running?

Release branches are not releases

A release/* branch is a candidate. Not a promise.

It can be delayed. It can be fixed. It can even be abandoned. That is fine.

The release only exists when:

The release branch is merged into main
A tag is created on main

Anything else is pre-release noise.

Versioning decisions are made early

I decide versioning strategy at the start of a project, not during the first release.

Semantic versioning when public contracts matter
Date-based versioning for internal tools or fast-moving products

Changing versioning mid-stream creates churn and inconsistent expectations. Pick one and live with it.

Changelogs are generated, not remembered

I do not write changelogs by hand.

They are generated from:

PR titles
Labels
Commit history on main

This is why PR titles matter. Sloppy titles produce useless release notes.
(Actually GitHub Copilot helps me a lot to create these ones and commit messages)

9. Environments or GitFlow Is Just Ritual

GitFlow assumes environments. Without them, you are just renaming branches.

I see many setups where GitFlow exists on paper, but everything deploys to the same place. In that case, the extra branches add zero value.

The minimum environment setup I use

I keep it simple. Three environments.

Dev / Integration
Automatically deployed from develop. This is where features meet and conflicts surface early.
Staging
Deployed from release/*. This environment exists to say “no”. If something fails here, the release is not ready.
Production
Deployed from main. Always. No exceptions.

If you cannot support at least this, GitFlow will not protect you.

Why each environment matters

develop needs a shared place where the system actually runs. Unit tests are not enough. Integration bugs appear only when components talk to each other.

release/* needs a stable environment. The whole point of a release branch is to freeze scope and validate reality.

main maps one-to-one with production. If you blur this line, you lose confidence in every tag and every rollback.

GitFlow without environments is overhead

Branches alone do not reduce risk. Feedback loops do.

If all feedback arrives only after merging to main, GitFlow becomes slower trunk-based development, nothing more.

In the next section, I will explain how I handle hotfixes, and why this is where most teams break the model.

10. Handling Hotfixes Without Breaking the Model

Hotfixes are where GitFlow discipline is tested.

They arrive under pressure. Something is broken. Time matters. This is exactly when shortcuts feel justified. That is also when long-term damage happens.

Hotfixes start from `main`

A hotfix always branches from main. Never from develop.

main represents what is running in production. If you start a hotfix anywhere else, you are guessing what you are fixing.

The goal of a hotfix is simple. Fix production. Nothing more.

Scope is deliberately small

A hotfix branch contains the minimal change required to restore service.

No refactoring. No cleanup. No “since we are here” improvements. Those belong on develop or in a future release.

Every extra change increases risk at the worst possible moment.

CI and reviews still apply

I do not disable checks for hotfixes.

Pipelines might be slightly faster. Reviews might be faster. But rules still apply.

Hotfixes are urgent, not special.

Why teams drift here

Under pressure, people optimize for now. GitFlow optimizes for later.

Skipping the back-merge or bypassing rules feels harmless in the moment. It creates invisible debt that surfaces weeks later.

If your GitFlow setup cannot survive hotfix pressure, it is not real.

11. Merge Conflicts and How I Keep Them Boring

Merge conflicts are not a Git problem. They are a workflow problem.

Every painful conflict I have dealt with had the same root cause. Branches lived too long.

Short-lived branches solve most conflicts

I keep feature branches short. Days, not weeks.

If a feature cannot be merged within three to five days, I split it. Vertical slices. Mergeable steps. Incremental progress.

This single habit reduces conflicts more than any Git command ever will.

12. GitHub Actions Patterns I Reuse Everywhere

Automation is what makes GitFlow survivable long term.

If the workflow depends on people remembering rules, it will degrade. GitHub Actions are there to make the right path the default path.

Required checks are gates, not guidelines

Every protected branch has required checks.

If a check is required, the PR cannot merge. No override. No “just this once”.

This removes social pressure. The system says no, not a person.

I treat required checks as part of the branch contract. If they are flaky or slow, I fix the checks. I do not remove the requirement.

Reusable workflows or nothing

I do not copy-paste workflows across repositories.

I use reusable workflows so:

The same rules apply everywhere
Changes are made once
Drift is impossible

Environment protection is part of GitFlow

For production deployments, I use GitHub environments with protection rules.

Required reviewers
Scoped secrets
Explicit approval step

This adds a final safety net without bypassing GitFlow.

If main deploys to production, production must be protected.

Secrets and permissions are minimal

Workflows get only the permissions they need. No wildcard tokens. No long-lived secrets when OIDC is available.

This matters more as automation grows. GitFlow increases automation surface. Least privilege keeps that surface manageable.

13. Security and Governance I Enable by Default

Security and governance are not enterprise-only concerns. I enable them even on side projects. Especially on side projects.

If the repo matters enough to use GitFlow, it matters enough to protect it.

Dependabot is always on

I enable Dependabot alerts and PRs by default.

Alerts tell me when I am exposed.
PRs force the fix through the same PR rules as any other change.

I never update dependencies directly on protected branches. Updates go through PRs, checks, and reviews like everything else.

Code scanning is part of the pipeline

At minimum, I run code scanning on:

develop
main

This catches obvious issues early and prevents shipping known problems.

I do not chase perfect security scores. I want signal, not noise. But no scanning at all is not an option.

14. In a nutshell, what I do (copy this section)

This is the setup I apply by default. On client projects. On open source. On side projects.

Branches

main
Always releasable. Production only.
develop
Integration branch. Can move fast, but must stay usable.
feature/*
Short-lived. One purpose. Merged into develop.
release/*
Created only when a real stabilization phase exists.
hotfix/*
Urgent fixes from main. Always merged back.

Protection rules

Protected branches:

main
develop
release/*
hotfix/*

Rules applied:

Pull requests required
At least one approval
Required status checks
Conversation resolution required
No direct pushes
No force pushes
No branch deletion

Pull request rules

Mandatory PR template: Why, What, How tested, Risk, Rollback
Small PRs by design
CODEOWNERS enabled
One merge strategy enforced

Merge strategy

Squash merge for feature/* into develop
Merge commits for release/* and hotfix/*
No rebasing of shared branches

CI/CD

feature/*: build, unit tests, lint
develop: full test suite, security checks
release/*: full suite, packaging, deploy to staging
main: production deploy, tag, changelog

Releases

Tags on main only
Semantic or date-based versioning decided early
Changelogs generated from PR metadata

Environments

develop → dev/integration
release/* → staging
main → production

Hotfix discipline

Branch from main
Minimal scope
Merge to main
Merge back to develop
No skipped steps

This policy is intentionally boring. Boring scales.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

How I created a Cozy Workspace in VS Code

Emanuele Bartolesi — Thu, 11 Dec 2025 15:54:26 +0000

I love VS Code. It is fast, flexible, and works for almost any stack. But the default layout is not great if you want a clean space to think. The editor area is smaller than it should be, and the UI is packed with elements that pull attention away from the code. With the new Copilot Chat panel taking even more space, the problem becomes obvious. Too much noise, not enough room to work.

In the picture above, the default layout, with Copilot opened on the right, the space for code is really limited.

I have been searching for a layout that removes distractions without sacrificing functionality. Something simple, comfortable, and optimized for long sessions. This article explains the setup I finally arrived at. It is a Productivity profile built around a few key layout changes: moving the sidebar to the right, putting the Activity Bar at the top, centering Quick Input, hiding the Command Center, switching themes automatically based on daylight, improving cursor visibility, and adding one small bonus to make the day more pleasant.

These changes are minimal but have a clear impact. They turn VS Code into a focused, cozy environment that gives space back to the code instead of the UI.

Creating a Dedicated “Productivity” Profile

VS Code profiles let you build isolated setups for different workflows. This solves a common problem. When you install extensions or change layout settings for one project, everything else gets affected. A dedicated Productivity profile keeps your focused environment clean and consistent.

I use this profile only for work sessions. For the training session I usually have, of course I still use the Default profile, otherwise the people are confused and lost.

Creating the new profile takes a minute:

Open the Command Palette.
Run Profiles: Create Profile.
Choose Empty.
Name it Productivity.
Customize settings only for this profile.

You can also click on the Gear icon on the bottom left and select "Profiles" from the menu.

Moving the Primary Sidebar to the Right

By default, VS Code puts the sidebar on the left. This works, but it also competes with your natural reading flow. Having the file tree on the left constantly pulls the eye away from the editor.
Also, when you close the sidebar, the code moves a little bit on the left, because the sidebar is not present anymore.

Moving the sidebar to the right reduces this tension. It keeps the editor centered and makes the coding area the first thing your eyes land on.

"workbench.sideBar.location": "right"

You can also click with the right button on the sidebar and select "Move Primary Sidebar Right".

This simple switch makes the layout feel more balanced and less cluttered.

Activity Bar at the Top

The Activity Bar is highly visible. Keeping it on the left (or right, if the primary sidebar is on the right) creates unnecessary vertical columns. Moving it to the top uses horizontal space instead of eating into the editor.

"workbench.activityBar.location": "top"

It's possible to change the same settings, even by clicking on the top of the sidebar and choose Top from the Activity Bar Position menu.

This change pairs well with the right-aligned sidebar and creates a cleaner overall layout.

Centering Quick Input for Better Focus

The Command Palette and file switcher usually appear at the top. This forces a constant eye shift upward. Centering Quick Input keeps everything in your immediate focus area.

"workbench.quickInput.location": "center"

This is especially useful if you use the keyboard heavily.

Hiding the Command Center

If you already use keyboard shortcuts and the centered Quick Input, the Command Center becomes redundant. It adds noise without adding value.

"window.commandCenter": false

Hiding it cleans up the top UI and keeps attention on the code.

Move the Menu bar

How often do you use the Menu? I think not so much, so, you can use that space for something else by changing the position of the menu, on the top of the Activity Bar.

"window.menuBarVisibility": "compact"

If you want to use the UI to change this settings, click on the Customize Layout on the top right corner of VS Code window and change the Visibility of the Menu Bar.

One more row is saved but first of all you are not distracted by the menu items on the top.

Automatic Light/Dark Theme Switching With PowerToys LightSwitch

PowerToys LightSwitch changes your Windows theme based on sunrise and sunset. VS Code can detect this automatically and switch between your preferred light and dark themes.

"workbench.preferredDarkColorTheme": "JetBrains Rider Dark Theme",
"workbench.preferredLightColorTheme": "Default Light+",
"window.autoDetectColorScheme": true

I use the JetBrains Rider Dark theme because I also use it on Rider, and it helps me stay focused when switching between IDEs.

This keeps the editor comfortable throughout the day with zero manual work.

Improving Cursor Visibility With “Expand” Blinking

The default cursor blink is subtle. In a busy file, it is easy to lose track of it. The “expand” style is more visible without being distracting.

"editor.cursorBlinking": "expand"

A small tweak, but surprisingly helpful.

Bonus: A Bit of Fun With VS Code Pets

A cozy environment should be enjoyable, not just efficient. The VS Code Pets extension adds a small animated pet to your workspace. It keeps you company during long sessions and adds a bit of charm without affecting focus.

It is optional, but it makes the environment feel more human.

Final Result

A cozy development environment is not about adding more tools. It is about removing friction. By focusing only on VS Code's layout settings, you can reclaim space, reduce noise, and make the editor feel purpose-built for deep work.

In the screenshot below, you can see the final result after all these easy changes.

If you want to spend time changing all the settings manually, you can find all my settings in the following repo:

kasuken / Windows11-Setup

My settings for Windows 11 and other tools I use everyday.

Windows 11 Setup & Automation

Automate, configure, and optimize your Windows 11 environment with ease.

🚀 Overview

This repository provides a comprehensive, automated, and customizable setup for Windows 11. It includes PowerShell scripts, terminal and VS Code configurations, and best practices to help you:

Set up a new Windows 11 machine in minutes
Apply productivity-boosting tweaks
Install essential tools and extensions
Maintain a consistent, portable dev environment

📦 Features

PowerShell Automation: Scripts for system tweaks, package installs, and profile management
Terminal Customization: Pre-configured settings for Windows Terminal
VS Code Setup: Recommended extensions and settings for a modern dev workflow
Modular Structure: Use only what you need—easy to extend and adapt
Documentation: Clear instructions for every step

🗂️ Repository Structure

Windows11-Setup/
├── PowerShell/         # PowerShell scripts and user profile
│   └── profile.ps1
├── Terminal/           # Windows Terminal settings
│   └── settings.json
├── VSCode/             # VS Code

…

View on GitHub

This layout turned VS Code into a cleaner and more intentional workspace for me. If you try it or customize it, share your version. Every developer ends up with their own definition of cozy.

📘 Get the Book with 50% Off!

I turned my beginner programming mistakes into a guide so you don’t have to repeat them.

Grab The Mistakes I Made as a Beginner Programmer today with a special discount.

👉 Get it on Gumroad

💸 Use code MISTAKESDEVTO50 at checkout for 50% off.

Why I Built TaskDeck and How It Improves Your VS Code Workflow

Emanuele Bartolesi — Thu, 20 Nov 2025 12:50:24 +0000

VS Code tasks are powerful, but most developers barely use them. The problem is not the feature itself. It is the workflow. Tasks are hidden behind menus, the command palette, or a tasks.json file that nobody enjoys editing. Running the same commands over and over becomes a small but constant tax on your focus.

I built TaskDeck to remove that tax. I wanted a simple way to see all tasks in one place, launch them with one click, and stop jumping between JSON files, menus, and shortcuts. No magic, no reinvention. Just a faster way to work inside VS Code.

The Problem: VS Code Tasks Are Underrated but Hard to Use

VS Code tasks are one of the most useful features in the editor. They let you run scripts, build steps, linters, tests, and any command you need with a single entry. They should save time. Instead, most developers ignore them.

The reason is simple. The workflow is not smooth.

You have to open the command palette, remember the task name, or dig into the Run Task menu. If you want to change something, you open tasks.json, navigate its structure, and hope you wrote the syntax correctly. Even when tasks are configured well, finding the one you want still requires multiple steps.

This friction adds up. Developers avoid tasks, fall back to terminal commands, and lose the benefits of a shared, consistent workflow. Teams suffer too because tasks are not discoverable. New team members rarely browse tasks.json, so useful automation stays hidden.

Tasks are not the problem. The UI is.

What I Wanted as a Developer

I needed something simple. A place where I could see all my tasks without touching JSON or opening menus. A way to run tasks without breaking my focus or switching contexts. Something that made tasks feel like a natural part of my workflow, not an extra step.

I also wanted a solution that worked the same across projects. Some repositories have many tasks. Others have only a few.

Most importantly, I wanted to avoid the constant “open palette, type, run, repeat” cycle. It is fast for one action, but slow if you repeat it all day. A dedicated side panel felt like the obvious answer, yet VS Code did not offer one for tasks. So I built it.

TaskDeck started as a selfish idea: reduce my friction.

Introducing TaskDeck

TaskDeck is a VS Code extension that gives tasks the visibility they deserve. It adds a dedicated side panel that lists every task from your workspace, ready to run with a single click.

When you open a folder, TaskDeck reads your existing tasks.json and displays the tasks in a clean, structured tree. If your project contains multiple task groups or compound tasks, TaskDeck shows them clearly so you always know what is available.

The extension does not try to change how VS Code tasks work. It simply makes them easier to use. Developers get a permanent view of their automation without jumping between menus. New team members immediately see what tasks exist. And you get a smoother workflow that stays out of your way.

How TaskDeck Improves Your Workflow

TaskDeck changes how you interact with VS Code tasks by removing unnecessary steps. Everything is in one place. You focus on your work instead of navigating the editor.

No more context switching.
You do not need to open the command palette or remember task names. The side panel is always visible, so you click and run. The fewer steps you take, the less mental load you carry.

Clear visibility for every task.
A list on the side makes tasks discoverable. You see what exists, how they are grouped, and which ones matter. This is especially helpful in large repositories or monorepos where tasks tend to multiply.

Faster onboarding for teams.
New developers immediately understand the available actions in a project. They no longer rely on README notes or tribal knowledge to find build, lint, or test tasks.

One-click execution.
The core improvement is speed. Launching a task becomes as easy as launching a file. There is no friction in trying, running, or combining tasks throughout your day.

Key Features with Examples

TaskDeck is built around a simple idea. Make tasks easier to find, easier to run, and easier to understand. Here are the core features that make that happen, with practical examples of how developers use them.

Side Panel Overview

The extension adds a new TaskDeck view in the VS Code sidebar.
It lists all detected tasks in a clean tree, grouped by their group property when present.

Example workspace task definition:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "command": "npm run build",
      "group": "build"
    },
    {
      "label": "test",
      "command": "npm test",
      "group": "test"
    }
  ]
}

How TaskDeck shows it:

You see everything immediately. No guessing and no hunting through JSON.

One-Click Run

Every task has a play button.
You click it and VS Code runs the task right away.

This is especially useful for actions you repeat daily:

build the solution
run the backend
run the frontend
run tests
run code generation
run a watcher

No palette. No typing. No remembering.

Automatic Detection of Workspace Tasks

TaskDeck loads tasks from:

.vscode/tasks.json
the root of the workspace
multi-root workspaces

If tasks are defined, they show up automatically.
If you add a new task, the panel updates without reloading the extension.

Optional Icons (If Enabled)

If you assigned icons or emojis to your task labels, TaskDeck shows them.
Not required, but useful for visual scanning.

Behind the Scenes: How I Built It

TaskDeck is simple on the surface, but building it required dealing with how VS Code exposes tasks internally. The goal was to keep the architecture small, predictable, and easy to maintain. Nothing fancy. Just a clean extension that does one thing well.

Activation and Task Loading

The extension activates when a workspace loads.
VS Code exposes an API that returns all tasks defined in the workspace. The extension reads them and organizes them into a structure that can be rendered in the side panel.

Key points I focused on:

load tasks once on activation
listen for changes in workspace files
refresh the tree when tasks.json is updated
stay lightweight so activation time stays near-zero

No custom parsing. No extra config. Just using the official tasks provider.

The Tree View

The entire UI is built on VS Code’s TreeDataProvider.
Every task becomes a tree item. Groups become parent nodes.
For multi-root workspaces, each folder becomes a root node with its own groups.

Structure example:

Workspace Folder
  Build
    - build
    - full-build
  Test
    - test

Tree nodes expose:

a label
an optional icon
a tooltip
a command to run the task

This keeps the implementation small and makes the UI responsive.

Running Tasks

Running a task is a direct call into VS Code’s task API:

vscode.tasks.executeTask(task);

This means TaskDeck doesn’t reinvent any behavior.
It delegates execution completely to VS Code, which ensures logs, terminals, and task output behave exactly as expected.

Handling Multi-Root Workspaces

One of the trickiest parts was supporting multi-root folders.
Some projects have one tasks.json. Others have several.
TaskDeck detects them all and scopes tasks correctly under each folder.

This avoids the common problem where tasks from different services get mixed together.

Lessons Learned

A few things became clear while building TaskDeck:

Tasks are powerful but under-exposed in the UI.
Most developers never open tasks.json unless they have to.
A simple UI change can unlock the value of an existing feature.
VS Code’s APIs make this kind of extension surprisingly easy once you understand tree views.
Good defaults matter more than new features.

TaskDeck was built with a “minimum friction” mindset.
Do less, but do it well.

What’s Next for TaskDeck

TaskDeck is intentionally minimal. It focuses on visibility and speed, but there is room to grow without turning it into a complex automation tool. These are the improvements I am considering next.

Task Filtering and Search

Large workspaces can contain many tasks.
A small search bar or quick filter inside the panel would help you jump to the right one instantly.

Inline Task Editing

Not a full editor.
Just a lightweight way to jump directly to the task definition or toggle simple fields without digging through JSON.

Better Multi-Root Experience

Multi-root workspaces work well today, but a few enhancements could improve clarity:

collapsible sections
root-level summaries
optional grouping modes

Telemetry-Free Insights

If I add metrics or insights (for example, most-used tasks), they will be completely local.
Developers do not want telemetry in their tools, and TaskDeck will stay strict about that.

Community Feedback

The next features will depend on what developers find useful.
TaskDeck is small by design, so additions must keep the workflow simple and fast.

If you have ideas or requests, open an issue on GitHub or leave feedback on the Marketplace page.

Try it, use it in your projects, and share your feedback.

Links

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

👨‍💻 GitHub Technical Lead | Microsoft MVP (12x) | GitHub Star (4x)

🛠️ I build things with .NET, Azure, AI, and GitHub

🌈 Turning code into 🦖 and 🦄 — one commit at a time

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

Why I Use JetBrains Rider for .NET Development

Emanuele Bartolesi — Thu, 13 Nov 2025 09:55:00 +0000

Finding the ideal IDE for .NET work is rarely a straightforward journey. As .NET developers, I invest huge amounts of time in tooling, and every annoyance—slow loading, awkward workflows, missing features, can disrupt my focus and flow. Visual Studio has long dominated my daily tool statistics, but in recent years JetBrains Rider has earned a place on my machine, and for good reason.

Rider is not just another editor. It’s a modern, cross-platform IDE built from the ground up by the same people behind ReSharper. If you’ve ever dreamed of a fast, resource-efficient, and deeply integrated development environment for .NET, Rider is likely already on your radar. What I’ve found is that, once you get past the initial adjustment, Rider quietly improves the everyday experience of .NET development—sometimes in ways you don’t notice until you go back to something else.

As you can see on the screenshot above, I don't have Visual Studio on my machine anymore.

Why I Chose Rider Over Visual Studio

My journey with Rider began out of curiosity but quickly turned into appreciation for the sheer number of pain points it eliminates. The first thing that struck me was how effortlessly Rider runs on all my machines, regardless of operating system. I routinely work across Windows and Mac, and the ability to carry my IDE and settings with me is invaluable. No need for workarounds, no feature gaps, no “missing” editor windows.

I also used VS Code in the past as my main .NET environment, but I missed a lot of features. I love VS Code (I have also a tattoo with the logo), but for .NET it is not the right tool.

Performance is another area where Rider delivers. It opens massive solutions fast and rarely stumbles even when refactoring or running code analysis on large codebases. The UI feels modern and uncluttered, but it’s also highly customizable. Shortcuts and navigation are easy to adjust, and you quickly fall into a rhythm where you can fly through files, definitions, and references without reaching for the mouse.

What really sold me, though, was the depth of built-in tooling. Rider ships with ReSharper-level code inspections, refactorings, and quick-fixes by default. There’s no need to add extra plugins or endure the lag that sometimes comes with layering on more extensions in Visual Studio. Integrated Git support (even if I use more often a mix between GitKraken, GitHub Desktop and the console), a robust database explorer, and even a built-in HTTP client are all available out of the box.
For this reason, I still have Postman on my machine, but when I can, I use the http client inside Rider. I can save the http files directly in the solution and everyone in the project can use it, because they are part of the source code.

Living With Rider Day to Day

Switching IDEs is a real commitment, and I was skeptical about leaving behind years of muscle memory from Visual Studio.
At the beginning, I had VS and Rider, side by side, but I always finished to using VS because I was too lazy to learn new things.
Then, when I got a new laptop, I installed only VS Code and Rider, so I forced myself to use it. No excuse.
But after the first week, Rider’s workflow began to feel natural. Solution management is painless. I can open .NET Core, ASP.NET, and Windows Forms in the same window. Multi-targeted projects work without friction. Git operations and branching are tightly integrated. The built-in terminal means fewer context switches, and the task runner lets me automate everything from builds to test runs with a couple of keystrokes.

Debugging is quick and reliable—setting breakpoints, inspecting variables, attaching to processes, and even editing code while debugging all feel snappy. Navigating large codebases is more fluid, thanks to instant "Go to Definition" and symbol search features. Code inspections and suggestions are always present, but never intrusive.

Rider feels purpose-built for people who want to code more and configure less. Dark mode, custom themes, and adaptable keymaps let you shape the environment to your preferences with little effort.

As a theme, now I am using the default Dark theme of Rider. For having the same feeling when I use VS Code, I found the porting of the theme even for VS Code.

5 Hidden Gems in Rider

Beyond the headline features, Rider hides a number of tools that can fundamentally change how you work, often going unnoticed until you stumble across them.

First, Rider’s dynamic code analysis runs continuously in the background, flagging potential bugs, code smells, and even subtle style violations. The real value is in the instant quick-fixes: a single keyboard shortcut (Alt+Enter) and Rider can reformat, refactor, or even rewrite problematic code, all without interrupting your train of thought.
Sometimes I disable this option when I am on my laptop on the train or in general not at my desk to preserve a little bit the battery. It's quite easy to turn it on and off because there is an option directly on the File menu.

Navigation is another quiet superpower. The "Search Everywhere" window, triggered with Shift+Shift, brings up files, classes, symbols, settings, and even menu commands in one place. Combined with highly customizable keymaps and actions, it’s easy to move around a project without ever reaching for the mouse.

If you care about code consistency, Rider’s integration with .editorconfig files stands out. The IDE enforces formatting and style rules across your project and visually indicates where your code diverges from team standards. The built-in visual editor makes tweaking rules straightforward, and you can catch issues before they hit code review.
I use the .editorconfig of a friend of mine, Marco Minerva. I move that file from project to project all the time.

For those who frequently interact with web APIs, Rider’s HTTP client is a small but powerful addition. It lets you create .http files directly in your solution, send requests, inspect responses, and even generate C# HTTP client code—all without leaving the IDE or reaching for external tools like Postman.

Finally, the database explorer in Rider means you don’t need a separate SQL tool for most data work. You can connect to major databases, run queries, and even preview LINQ queries mapped to your schema—all from within your solution. As a not really an expert in Database and Entity Framework, I love this integration.

GitHub Copilot Integration

One of the most exciting developments for Rider is its tight integration with GitHub Copilot. As you type, Copilot surfaces context-aware suggestions—sometimes completing whole methods or filling out boilerplate code from just a comment or a function signature.

What’s especially useful is how well Copilot integrates with Rider’s own completion system. Suggestions appear inline, can be accepted or cycled with familiar shortcuts, and work across all supported languages—including C#, JavaScript, TypeScript, and Razor files. This means you get AI assistance not just for backend code but also for front-end, tests, and even scripting tasks.

For me, Copilot in Rider isn’t just a novelty; it’s a genuine productivity boost. It helps me prototype faster, learn new APIs in context, and avoid repetitive coding.
I will write another blog post for this specific topic.

Drawbacks and Considerations

No tool is perfect, and Rider is no exception. The most obvious barrier for many is cost: Rider requires a commercial license. For hobbyists or open-source developers, there is a free version with all the features enabled!

Extension support is another point to consider. While Rider’s plugin ecosystem is robust and growing, there are still some Visual Studio extensions and integrations that haven’t made the leap. If you rely on a very specific workflow or niche tooling, you’ll want to check compatibility before switching.

The UI does take some getting used to if you’re coming from Visual Studio. Some menus are arranged differently, and not all wizards or designers are present. If you’re tied to Windows-specific features, especially for legacy .NET workloads or advanced Azure integrations, you may find Rider lacking in those areas.

Finally, in larger organizations, the choice of IDE may not be yours alone. Some teams or companies standardize on Visual Studio, so using Rider could be discouraged or unsupported in those environments.

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

👨‍💻 Senior Cloud Engineer | Microsoft MVP (12x) | GitHub Star (4x)

🛠️ I build things with .NET, Azure, AI, and GitHub

🌈 Turning code into 🦖 and 🦄 — one commit at a time

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

⚡ Turn On or Off Fast Startup in Windows 11

Emanuele Bartolesi — Fri, 10 Oct 2025 15:19:25 +0000

Since few months my primary laptop is a Microsoft Laptop 6 (you can see my entire setup on my website https://www.emanuelebartolesi.com/uses).
In the last few weeks I had a lot of performace issues with the laptop.
I thought it was something related the tools I am using for working (LM Studio and other dev tools), but actually I was wrong.
I did a lot of research around and finally I discovered that my issue is the Fast Startup on Windows 11.

Fast Startup helps your PC boot up faster after shutdown by combining the cold boot and hibernation processes. While it’s convenient, it can sometimes cause issues with dual-boot setups or device drivers (primarily Intel).

🧠 Understanding Fast Startup

There are three types of startup modes in Windows:

Cold Boot – Traditional full startup (everything initializes from scratch).
Wake-from-Hibernation – Restores your previous session from disk.
Fast Startup – A hybrid approach combining both.

When you shut down your PC with Fast Startup enabled, Windows logs off all user sessions but saves the system state (drivers, kernel session) to a file called:

C:\hiberfil.sys

At the next boot, Windows reads this file instead of reinitializing everything — resulting in a noticeably faster startup.

💡 Note: Fast Startup depends on Hibernate. If hibernation is disabled, Fast Startup won’t work.

🧩 Step 1 — Check if Fast Startup is On or Off (PowerShell)

Open Windows Terminal as Administrator (right-click Start → Windows Terminal (Admin)).
Run the following command:

   (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power").HiberbootEnabled

Check the result:

1 → Fast Startup is Enabled
0 → Fast Startup is Disabled

⚙️ Step 2 — Turn Fast Startup On or Off (Control Panel)

Open the Control Panel (press Win + R, type control, and hit Enter).
Go to:
Hardware and Sound → Power Options → Choose what the power buttons do
Click Change settings that are currently unavailable.
Under Shutdown settings, you’ll see:

✅ Turn on fast startup (recommended)

To enable Fast Startup → check the box.
To disable it → uncheck the box.
Click Save changes.

🧰 Step 3 — (Optional) Enable Hibernate if Needed

If you don’t see the “Turn on fast startup” option, Hibernate might be disabled. Enable it using PowerShell:

powercfg /hibernate on

If you only want to use Fast Startup and not full hibernation, you can reduce the hiberfile size:

powercfg /h /type reduced

This keeps Fast Startup working but saves disk space.

🧹 Step 4 — Disable Hibernate (Also Disables Fast Startup)

If you want to completely disable both Hibernate and Fast Startup:

powercfg /hibernate off

This removes the C:\hiberfil.sys file and disables related features.

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

Building My New Website with Astro, GitHub Copilot, and AWS Amplify

Emanuele Bartolesi — Tue, 07 Oct 2025 12:41:50 +0000

For me, in general, the best way to learn something new is to start from zero and hit “publish.”

That’s exactly what I did when I decided to rebuild my personal website — emanuelebartolesi.com — from scratch.
No templates. No frameworks I already knew. Just curiosity, a blank repo, and a lot of help from GitHub Copilot.

I had never touched Astro before, but I wanted to explore it because it felt and I read about it as the perfect mix between simplicity, speed, and flexibility.
Instead of following tutorials, I decided to apply my own “Copilot personas” approach — the same method I use in my daily projects to guide AI tools like GitHub Copilot through different roles: architect, implementer, reviewer, and so on. It felt like pair programming with an assistant that never gets tired.

Emanuele Bartolesi for Playful Programming

Aug 26 '25

🚀 GitHub Copilot: A Persona-Based Approach to Real-World Development

#githubcopilot #github #ai #vscode

Comments 10

9 min read

To make the challenge even more interesting, I built the entire project inside GitHub Codespaces, streamed the first steps live on Twitch, and deployed it for the first time ever using AWS Amplify with an Astro adapter.
And because I can’t resist automating things, I also set up an AWS Lambda function to re-publish the website every two hours — becase I have a lot of data on the website streamed from our external services.

Starting from Zero: Learning Astro with GitHub Copilot

When I started this project, my Astro knowledge level was exactly zero.
I knew it existed, I had seen a few demos, but that was about it. I wanted to understand how it actually worked — component structure, routing, layouts, everything.

Instead of spending hours reading documentation or tutorials, I decided to try something different:
I would learn by building, with GitHub Copilot as my coding partner.

But not just Copilot as a “code completion” tool — I used it through my personas approach, a method I’ve been refining for months. The idea is simple:
treat Copilot like a team of specialists instead of a single assistant.

So, for example:

I’d ask “Architect Copilot” to explain how Astro handles layouts and partials.
Then I’d switch to “Implementer Copilot” to help me generate the first components.
And finally, “Reviewer Copilot” to check consistency and readability.

In just a few hours, I had a working homepage, a blog section, and some reusable components.

What surprised me the most (but not so much because Copilot is very good with React) was how Astro and Copilot worked so well together.
Copilot was able to suggest entire component structures, meta tag configurations, and even some optimizations for Lighthouse performance.

Here’s a small example — I just typed a comment:

with the same style of the other pages, I would like to add a page dedicated to books I written or I am writing.
like this one: https://www.packtpub.com/en-us/product/mastering-minimal-apis-in-aspnet-core-9781803237824

and Copilot generated:

---
import BaseHead from '../components/BaseHead.astro';
import Footer from '../components/Footer.astro';
import Header from '../components/Header.astro';
import { 
  getFeaturedBooks, 
  getPublishedBooks,
  getUpcomingBooks,
  bookCategories, 
  getBookStats
} from '../data/books';

const featuredBooks = getFeaturedBooks();
const publishedBooks = getPublishedBooks();
const upcomingBooks = getUpcomingBooks();
const stats = getBookStats();
---

and the entire HTML and Astro code for the page and the TypeScript class for the data.

Live Coding on Twitch

When I started working on the project, I thought: “Why not share the process live?”
So I opened Twitch, hit “Start Streaming,” and decided to build the first parts of the website in front of everyone.

Live coding is always a mix of excitement and vulnerability.
You make mistakes, talk through your reasoning, and sometimes get stuck — all in real time. But that’s exactly what makes it authentic.
And since I was diving into Astro for the first time, it became a great way to learn in public.

During those sessions, I wasn’t trying to “teach” Astro. I was learning it live, asking ChatGPT and Copilot questions, and letting people in the chat contribute with suggestions.
Sometimes, Copilot would generate code I didn’t fully understand, and viewers helped me reason through it. Other times, it just worked — and we all learned something new together.

What I loved about this format is how it kept me accountable.
When you know people are watching, you can’t just stop halfway because you got stuck on a CSS grid layout. You find a way through — and that’s powerful motivation.

After a few sessions, I already had the basic structure of my site, a working navigation, and a clear plan for the next steps.
Streaming wasn’t just about building a website — it was about sharing curiosity and the joy of learning.

You can find me on Twitch here: http://twitch.tv/kasuken

Developing in GitHub Codespaces

One of the decisions I made early on was:

“I don’t want to install anything locally.”

I wanted this project to be 100% cloud-based, from the first line of code to deployment.
So I opened GitHub, clicked on the “Open in Codespaces” button, and within seconds, I was coding directly in the browser — with my full VS Code setup.

It was surprisingly smooth.
Astro ran perfectly, previews loaded fast, and I had GitHub Copilot right inside Codespaces to help me iterate.
No Node.js version mismatches, no missing dependencies, no setup headaches.
It just worked.

This setup also had another big benefit: portability.
I could jump between my MacBook, my Windows laptop that I use for work or my private one (you can find the list of all my hardware on my website, in the Uses page) and continue working exactly where I left off.
Everything — the editor, the extensions, and the environment — was consistent and ready.

That’s it.
No cloning. No manual setup.

I didn't change the default Codespaces image but I use the default one.
Usually I customize the container, but in this case works like a charm, so, no reasons to change it and also the default image is faster to rebuild o start.

For me, Codespaces became the perfect environment for experimenting and learning with Copilot (and not only).

When I finally switched to deploying on AWS, everything was already structured neatly in the repo.
No “works on my machine” moments, ever again.

First Steps with AWS Amplify

Once the site was running smoothly in Astro, it was time to bring it online.
I had two main goals for hosting:

Keep it fully automated from GitHub.
Use a platform I hadn’t used before — because this was, after all, a learning project.

So I chose AWS Amplify.
It was my first time using it, and honestly, I was curious to see how it compared to platforms like Vercel or Microsoft Azure.

The onboarding experience was smoother than I expected.
Amplify detected my GitHub repository, connected automatically, and offered to build and deploy my Astro app in just a few clicks.
No YAML setup, no manual build commands — it just picked up npm run build and dist/ as defaults.

I like the simplicity of the UI (even if I needed 2 days to be productive on the AWS console), especially compared to the Azure Portal.
I used to use Azure since ages now, but actually the AWS console is not so bad.

But I soon realized Astro isn’t natively supported in Amplify…
and that’s when I discovered the AWS Amplify Adapter for Astro.

After adding it, everything started to click.

Here’s the short version of what I did:

npm install astro-aws-amplify

Then in my astro.config.mjs:

import mdx from "@astrojs/mdx";
import sitemap from "@astrojs/sitemap";
import { defineConfig } from "astro/config";
import awsAmplify from "astro-aws-amplify";

// Conditionally use AWS Amplify adapter for deployments
const isAWSDeployment = process.env.NODE_ENV === 'production' || process.env.AWS_AMPLIFY === 'true';

// https://astro.build/config
export default defineConfig({
  site: "https://example.com",
  integrations: [mdx(), sitemap()],
...(isAWSDeployment && { adapter: awsAmplify() }),
  output: isAWSDeployment ? "server" : "static",
});

Once I pushed these changes to GitHub, Amplify automatically rebuilt and deployed the site.
No manual steps, no servers to configure — pure CI/CD magic.

The only thing that I changed from the official documentation is the check of the environment, otherwise I was not able to run the website from my local machine anymore.

I have also contributed to the official repo for AWS Amplify to add the node version as parameter: https://github.com/alexnguyennz/astro-aws-amplify/pull/37

Astro + AWS Amplify Adapter

Once I added the Amplify adapter to my Astro project, everything started to feel like a real production pipeline.

The adapter acts as the bridge between Astro’s static-site output and AWS’ serverless infrastructure.
In practice, it takes your built site and wraps it in an AWS Lambda function that Amplify can deploy and serve.
That means no servers, no containers — just instant scalability with minimal configuration.

But what really impressed me was how Amplify handled different branches from GitHub.
Each branch can become its own environment — automatically.

So, for example:

main branch → production (emanuelebartolesi.com)
dev branch → staging (dev.emanuelebartolesi.com)

Every time I pushed a commit to either branch, Amplify rebuilt and deployed it without me touching a thing.

That setup was powerful because it gave me the same comfort I have on larger SaaS projects — real CI/CD with environment isolation — but for my personal site.

Here’s what the process looked like visually:

GitHub Repo
 ├── main → Amplify Production → emanuelebartolesi.com
 └── dev  → Amplify Dev Env → dev.emanuelebartolesi.com

In just a few hours, I had a multi-environment setup that I used to experiment with new pages, styles, and layout changes before merging them into main.
That kind of workflow used to take hours to configure manually — now it was a few clicks and one adapter import.

Automation with Lambda

In my website I have different components that need to load a lot of data from APIs.
For instance, I have a component to render my commmits on GitHub, all the info about my GitHub account and below I have the statistics about my productivity during the day with RescueTime.

So, I created a couple of loader on Astro to load all this data, but I need to rebuild the website everytime I want to update the pages.

If there’s one thing I can’t resist, it’s automation.
Once the site was up and running, I thought:

So I built a simple Lambda function that triggers the Amplify build every two hours.
It’s a small piece of automation, but it makes the whole workflow feel alive — and it was surprisingly easy to set up.

Here’s the basic lambda I have created :

import json
import urllib.request

def lambda_handler(event, context):
    r = urllib.request.Request(
        'https://webhooks URL',
        data=json.dumps({}).encode('utf8'),
        headers={
            'Content-Type': 'application/json'
        },
        method='POST'
    )
    urllib.request.urlopen(r)
    return

Then I just scheduled it using Amazon EventBridge (formerly CloudWatch Events) with a cron rule like:

cron(0 7-17/2 ? * * *)

So every two hours, from 7 in the morning to 5 in the afternoon, Lambda wakes up, triggers Amplify, and goes back to sleep — costing practically nothing.

It’s a small piece of the puzzle, but it reflects my favorite principle:

automate everything that can be automated — even personal projects.

Route 53 and Custom Domains

Once everything was running perfectly on Amplify, it was time for the final touch:
connecting my own domains.

I wanted two environments with clean, memorable URLs:

emanuelebartolesi.com for production
dev.emanuelebartolesi.com for my staging environment

I decided to manage everything directly in AWS Route 53, mostly out of curiosity — but also because I’d heard good things about how seamlessly it integrates with Amplify.

And honestly, it was a pleasant surprise.

Route 53 automatically recognized my Amplify app and helped me configure both records with just a few clicks.
No manual DNS entries, no propagation headaches, no SSL nightmares.

The SSL certificates are provided directly from Route 53.

Here’s roughly what the configuration looked like:

emanuelebartolesi.com        → Amplify Production (main branch)
dev.emanuelebartolesi.com    → Amplify Dev Environment (dev branch)

It was one of those moments where everything just works —
and it made me appreciate how much AWS has improved in terms of developer experience.

The best part?
If I ever decide to add more environments (like preview or experimental builds), I can just connect new branches and Route 53 will take care of the rest.

Lessons Learned & What’s Next

Even though the final result looks clean and simple, getting there wasn’t always smooth.
Astro is a great framework — but when you start going beyond static pages, things get a little more complex.

⚠️ Working with dynamic data isn’t as straightforward as it seems

Astro shines for static sites, but integrating dynamic data from APIs can be tricky.
I wanted to pull data at runtime, not just during build, and that required experimenting with different patterns — from server endpoints to hybrid rendering.

There were moments where I felt like I was “fighting” the framework a bit.
The documentation is good, but when it comes to incremental updates or live API data, you often need to combine several Astro concepts together to make it work smoothly.
It’s definitely doable, but not as plug-and-play as other frameworks like Next.js.

🧩 The AWS Amplify adapter still has room to grow

Another challenging part was understanding how the AWS Amplify adapter actually works under the hood.
It abstracts away a lot (which is great), but when something goes wrong or you want to customize the deployment flow, it’s not always clear where to look.

That curiosity led me to dig into the adapter source code — and eventually, to contribute directly to the open-source project:
🔗 github.com/alexnguyennz/astro-aws-amplify

It was a small contribution, but it helped me understand the logic behind it — and reminded me how valuable it is when developers give back to the tools they use.

🚀 What’s Next

I am preparing a new special page for my website for my next secret project. 🚀🧑🏻‍🚀🦄
Stay tuned!

I forgot to write that my website is open source (because why not) and you can use it as your starting point for your personal website:

kasuken / website

The code for my website based on Astro.

🚀 Emanuele Bartolesi's Website

A blazing-fast, modern, and SEO-optimized portfolio website showcasing expertise in software development, technical writing, speaking, and education. Built with cutting-edge web technologies and optimized for performance and accessibility.

✨ Key Features

🎯 Performance & SEO

100/100 Lighthouse Performance - Optimized for speed and user experience
SEO Optimized - Canonical URLs, OpenGraph, structured data, sitemap, and RSS feed
Web Accessibility - WCAG compliant with semantic HTML and proper ARIA labels
Progressive Enhancement - Works without JavaScript, enhanced with it

🎨 Modern Design & UX

Responsive Design - Mobile-first approach, looks great on all devices
Dark/Light Theme Toggle - Automatic system preference detection with manual override
Smooth Animations - Subtle micro-interactions and hover effects
Typography Excellence - Carefully chosen fonts and spacing for optimal readability

📚 Content Management

Dynamic Blog Integration - Automatic synchronization with Dev.to articles
Books Showcase - Dedicated section for published and upcoming books
Portfolio…

View on GitHub

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

🌱 Introducing Green Software Indicator: a Browser Extension for a greener web

Emanuele Bartolesi — Tue, 30 Sep 2025 20:05:25 +0000

As developers, we obsess over performance, accessibility, and design — but how often do we think about the environmental impact of the websites we build?

That’s why I built Green Software Indicator — a simple yet powerful Chrome and Edge extension that evaluates websites for sustainable development practices in real time.

What It Does

Every time you visit a website, the extension automatically analyzes it for common green software best practices, including:

✅ Image Optimization (modern formats like WebP, lazy loading)
✅ Minified Resources (compressed JS/CSS)
✅ Server-side Compression (gzip, Brotli, etc.)
✅ Reduced HTTP Requests (bundled assets, CDNs)
✅ Energy-Efficient Design (dark mode support, async scripts)

It then gives a color-coded badge (✓ Green, ~ Yellow, ✗ Red, ? Gray) and a detailed breakdown when you click the icon in your browser toolbar.

Why This Matters

According to the Green Software Foundation, software contributes significantly to global carbon emissions — from data transfer and rendering to power usage on user devices.

Small optimizations in your frontend code — like compressing images or enabling dark mode — can actually reduce electricity consumption at scale.

Green Software Indicator is a gentle reminder of how our decisions as developers have real-world consequences.

🛠️ Try It Now

You can install the extension from either store:

🌍 Chrome Web Store
🧭 Microsoft Edge Add-ons

No login. Just browse and click.

💚 Looking for Contributors!

This is a community-first project. The repo is open source:
👉 https://github.com/kasuken/green-software-indicator

Here’s how you can help:

Improve or add new evaluation criteria (e.g., WebAssembly, power hints)
Enhance performance analysis
UX/UI feedback for the popup interface
Translate the UI to other languages
Spread the word — share with friends & colleagues

Even small contributions matter. Let’s build a more sustainable web.

🔖 Stay ahead of the dev curve
I created a Curated RSS Feed Bundle for Web Developers — a hand-picked OPML file of the best dev blogs and websites on the internet.
💡 Just download, import into your favorite RSS reader (like Feedly or NetNewsWire), and enjoy fresh insights every day.

👉 Grab it on Gumroad — stay sharp without the noise.

Weekly 0087

Emanuele Bartolesi — Mon, 08 Sep 2025 19:20:08 +0000

From Migrations to Marketplace 🚀

This week was a mix of heavy-duty migration testing, customer work on CI/CD, and a personal milestone: publishing my new VS Code extension! Some days were long (hello, 14-hour Tuesday 😅), but wrapping up with DropComments going live on the Marketplace made it worth it.

Monday

I spent the entire day testing my custom tool for migrating from Perforce to Git. It’s one of those tasks that requires full focus and endless trial runs, but slowly things are taking shape.

Mood: Focused but drained 🛠️😓

Tuesday

Another full day of testing the migration tool — and when I say full, I mean 14 hours straight. It’s time-consuming, repetitive, and occasionally frustrating, but I know this groundwork is essential to making the process smooth for future migrations.

Mood: Exhausted but determined 💪😴

Wednesday

Shifted gears a bit to work on a CI/CD implementation analysis for a customer, preparing some slides to explain the approach. Later, I joined our monthly team meeting where everyone shared project updates and ongoing initiatives — always nice to get a pulse on what others are doing.

Mood: Balanced and collaborative 🤝🙂

Thursday

Big day! I officially published my DropComments extension on the VS Code Marketplace 🎉
👉 DropComments - Visual Studio Marketplace
👉 Source repo: kasuken/DropComments

In between the excitement, I continued my work on the CI/CD analysis and built more slides for the customer.

Mood: Proud and motivated 🚀😎

Friday

Closed the week by fixing some slides for today’s customer presentation and sneaking in a bit of extra work on DropComments. A nice way to tie together customer needs with personal projects.

Mood: Productive and satisfied ✅😊

That’s it for this week — a rollercoaster of testing marathons, customer work, and a shiny new extension launch. See you next week for more updates!

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

👨‍💻 Senior Cloud Engineer | Microsoft MVP | GitHub Star

🛠️ I build things with .NET, Azure, AI, and GitHub

🌈 Turning code into 🦖 and 🦄 — one commit at a time

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

✨ Advanced Tips and Tricks for GitHub Gists (Part 1: Unlocking the Power of Gists)

Emanuele Bartolesi — Fri, 05 Sep 2025 06:05:12 +0000

If you’ve been coding for a while, chances are you’ve stumbled across a GitHub Gist. Maybe you copied a handy Bash script, or saved a quick snippet for later. Most developers think of Gists as “just pastebins with syntax highlighting” — but they’re way more powerful than that.

In this series, we’ll dive into advanced tips and tricks that transform Gists into mini-repositories, collaboration hubs, and personal knowledge bases. Whether you use them to share snippets, automate workflows, or even host JSON data, you’ll discover that Gists are one of GitHub’s most underrated features.

I use them for everything!

In Part 1:

Why Gists are more powerful than you think
How to organize them like a pro
The hidden superpower: forking and cloning Gists

🔑 Why Gists Are More Powerful Than You Think

At their core, Gists are just Git repositories. That means all the goodness of version control — commits, history, forks, and clones — is baked in. But since most people only interact with them via the web UI, they miss out on this power.

Here are a few things many developers don’t realize:

Public vs Secret Gists
- Public Gists are searchable and indexable — great for sharing snippets with the world.
- Secret Gists are “unlisted,” not truly private. Anyone with the link can access them, so treat them like a hidden blog post, not a secure vault.
When to use Gists instead of repos
- Use Gists for: quick snippets, single scripts, throwaway demos, dotfile sharing.
- Use repos for: projects that need issues, CI/CD, or multiple contributors.
They’re versioned
- Every time you edit a Gist, GitHub keeps a full version history. You can roll back to earlier states, just like with a normal repo.

Think of Gists as lightweight repos: perfect for experiments, one-off utilities, or sharing knowledge without the overhead of a full project.

🗂 Organize Gists Like a Pro

One of the biggest misconceptions about Gists is that they’re only good for single-file snippets. In reality, Gists can hold multiple files, complete with meaningful names and descriptions — making them feel almost like mini-repositories.

Here are some ways to keep your Gists tidy and useful:

1. Use Multi-File Gists

Did you know you can add more than one file to a Gist? This is great for:

Keeping related scripts together (e.g., a Dockerfile + docker-compose.yml)
Sharing a working demo with config + code in one place
Writing a “mini tutorial” where each file represents a step

👉 Example: A Python script with a separate requirements.txt file inside the same Gist.

2. Naming Conventions Matter

Don’t settle for script.js or test.ps1. The others will thank you if you use descriptive file names, like:

azure-cleanup.ps1 instead of script.ps1
jwt-validator.cs instead of Program.cs

This makes your Gists more searchable and recognizable when embedded elsewhere.

3. Treat the Description Like a README

The description is often overlooked, but it’s the first thing people see. Use it to:

Explain what the snippet does
Add quick usage instructions
Drop in keywords (so your Gist shows up in GitHub search)

Example:

“PowerShell script to clean up unused Azure resource groups. Run with ./azure-cleanup.ps1.”

4. Pseudo-Tags in Descriptions

Gists don’t have official tagging, but you can fake it. By adding hashtags in your description (#python #azure #automation), you make them easier to search later — both for you and anyone browsing.

🔀 Forking and Cloning Gists (The Hidden Superpower)

Here’s a secret most developers don’t know: every Gist is a Git repository under the hood. That means you can fork, clone, commit, and push just like you would with any other repo.

1. Fork a Gist to Build on It

If you find a useful snippet but want to tweak it without affecting the original, hit “Fork”.

This creates your own copy, linked back to the original.
It’s perfect for bug fixes, feature improvements, or adapting scripts to your own setup.
Bonus: others can discover your fork and use it, too.

2. Clone a Gist Locally

Just like any repo, you can clone a Gist:

git clone https://gist.github.com/<gist-id>.git

Now you have the Gist on your machine. From here you can:

Edit with your favorite IDE
Create branches for experiments
Commit and push changes back

Example workflow:

git clone https://gist.github.com/123abc456def.git
cd 123abc456def
git checkout -b add-logging
# make edits
git commit -am "Added logging for better debugging"
git push origin add-logging

3. Treat Gists Like Mini Repos

Once cloned, Gists behave almost identically to standard repositories. You can:

Use git log to inspect history
Branch for different variations of a snippet
Collaborate by sharing forks and diffs

This makes Gists a hidden gem for lightweight collaboration — no need to spin up a full repo for a tiny script.

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken.

👨‍💻 Senior Cloud Engineer | Microsoft MVP | GitHub Star

🛠️ I build things with .NET, Azure, AI, and GitHub

🌈 Turning code into 🦖 and 🦄 — one commit at a time

🚀 If you're into .NET, GitHub, DevOps, or just cool side projects,

feel free to connect with me on LinkedIn

P.S. I break things so you don’t have to. 😉

DEV Community: Emanuele Bartolesi

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

👀 GitHub Copilot quota visibility in VS Code

Git Mirroring During Migrations: `--all` vs `--mirror`

The Common Approach: Pushing Branches and Tags

git push --all

git push --tags

What This Approach Synchronizes

The Full Mirror Option

Quick Recommendation

Use --all + --tags when

Use --mirror when

👀 GitHub Copilot quota visibility in VS Code

GitHub Copilot to Generate Conventional Commit Messages in VSCode and JetBrains Rider

Why Conventional Commits Still Matter

Readable Git History

Using GitHub Copilot for Commit Messages in VS Code

Using GitHub Copilot for Commit Messages in JetBrains Rider

Making Copilot Strict (Not Creative)

👀 GitHub Copilot quota visibility in VS Code

A Practical GitFlow Setup That Works on GitHub

2. When GitFlow Makes Sense and When It Does Not

When GitFlow makes sense

When GitFlow is the wrong choice

The most common mistake

3. The GitFlow Branch Model I Actually Use on GitHub

main

develop

feature/*

release/*

hotfix/*

4. The Rules That Make GitFlow Work (And Why I Enforce Them on Myself)

Protected branches are non-negotiable

Pull requests are mandatory checkpoints

Approvals still matter, even solo

Conversation resolution is underrated

Linear history vs merge commits

5. Pull Requests as the Core Unit of Work

A boring PR template on purpose

Small PRs beat clever branch strategies

CODEOWNERS even for tiny repos

6. Naming, Traceability, and Future Me

Branch names should explain intent

PR titles are part of the changelog

Link everything, even when it feels redundant

Traceability must be enforced, not suggested

Why this matters more with GitFlow

6. Naming, Traceability, and Future Me

Branch names should explain intent

PR titles are part of the changelog

Link everything, even when it feels redundant

Traceability must be enforced, not suggested

8. Releases, Tags, and Changelogs I Can Trust

Tags exist only on main

Release branches are not releases

Versioning decisions are made early

Changelogs are generated, not remembered

9. Environments or GitFlow Is Just Ritual

The minimum environment setup I use

Why each environment matters

GitFlow without environments is overhead

10. Handling Hotfixes Without Breaking the Model

Hotfixes start from main

Scope is deliberately small

CI and reviews still apply

Why teams drift here

11. Merge Conflicts and How I Keep Them Boring

Short-lived branches solve most conflicts

12. GitHub Actions Patterns I Reuse Everywhere

Required checks are gates, not guidelines

Reusable workflows or nothing

Environment protection is part of GitFlow

Secrets and permissions are minimal

13. Security and Governance I Enable by Default

Dependabot is always on

Code scanning is part of the pipeline

14. In a nutshell, what I do (copy this section)

Branches

Protection rules

Pull request rules

`git push --all`

`git push --tags`

Use `--all` + `--tags` when

Use `--mirror` when

`main`

`develop`

`feature/*`

`release/*`

`hotfix/*`

Tags exist only on `main`

Hotfixes start from `main`