Vibe Coding: GitHub and Git¶

Before you build and deploy your first app, you need two things in place: somewhere to store your project, and a way to track your changes. That is what Git and GitHub give you.

Have you ever done this?¶

Look at this folder:

report.docx
report_final.docx
report_final_v2.docx
report_final_FINAL.docx
report_final_FINAL_reviewed.docx

If that looks familiar - you have already been doing version control. Just manually, and without much safety net.

Git solves this. Instead of saving copies with new names, you:

• Keep one file (or one project folder)
• Let Git automatically track every change you make
• Give each saved state a short description ("Added login page", "Fixed the export bug")
• Compare any two versions, or roll back to any point in history - instantly

Then there is collaboration¶

Now imagine you and a colleague are both editing the same PowerPoint presentation in M365. You can both make changes at the same time, and OneDrive syncs everything automatically - no committing, no pushing, no thinking about it. It just works. That is great for a single file.

But notice: it only helps with that one file. If your project is a folder full of related files - a presentation, a data file, a script that generates the charts - M365 does not know they belong together. You are back to the report_final_FINAL.docx problem, just spread across multiple files instead of one.

Git is designed for exactly this. It treats an entire project folder as a single unit, tracks changes across every file together, and lets you commit them as a group with a single description of what changed and why. You also decide when to save a snapshot - which means your history reflects meaningful moments ("Updated the chart data and regenerated the slides") rather than every individual keystroke. The trade-off is that it requires a little more deliberate action: you commit, you push. But you get full control over your project history, across every file, with none of the naming chaos.

Git vs GitHub¶

People use the names interchangeably, but they are different things:

Git works entirely on your own machine. GitHub is where you push your work so others can access it - and where the vibe coding deploy pipeline picks it up.

Key concepts¶

You do not need to memorise all of these before you start. The vibe coding trail will walk you through each one in context.

AFRY's GitHub setup¶

AFRY uses GitHub Enterprise Managed Users (EMU). This means your GitHub account is created and managed by AFRY through Entra ID - it is not a personal account you own. You log in with your AFRY credentials, and the account is scoped entirely to the AFRY enterprise.

Personal repositories¶

You can create repositories under your own user account, but they are always private. This is an EMU restriction - no public content is allowed. Personal repos are fine for experimenting, but they come with a key limitation for vibe coding: you cannot set up GitHub Actions for automated deployment from a personal repo. For anything you want to publish or deploy with CI/CD, you need an organisation repo.

Organisations¶

AFRY has a set of GitHub organisations - one for each division, plus a shared one for cross-company tools:

You will only see the organisations you have been added to. Access is managed by each organisation's owners.

Visibility inside an organisation¶

When you create a repository in an organisation, you choose between two visibility levels:

Use Internal for anything that should be open to all of AFRY (like Inner-Source content). Use Private when you want to control exactly who has access - you can still invite specific collaborators to a private repo. Either way, no one outside AFRY can see it.

For your own vibe coding projects, you will typically create a private repository in the organisation that matches your division. This gives you GitHub Actions support for deployment, while keeping the code visible only to your team.

The six Git commands you actually need¶

You do not need to memorise more than these to get through the vibe coding trail:

Use Copilot as your Git tutor¶

Git has a reputation for being confusing - and honestly, that reputation is not entirely unfair. Branches, merge conflicts, rebasing, detached HEAD states... there is a lot to get wrong, and the error messages are not always helpful.

Here is the good news: GitHub Copilot is excellent at Git. It understands the concepts deeply, can explain them in plain language, and can walk you through any situation you get stuck in. That makes it an ideal tutor - not just a command generator, but something you can actually have a conversation with.

Ask it to explain things:

"Explain how Git branches work, as if I have never used version control before."

"What does 'HEAD' mean? ELI5 please."

"What is "merge"? What is the difference between "merge" and "rebase", in simple terms?"

Ask it to help you do things:

"I want to create a new branch, make some changes, and then merge it back into main. Walk me through the steps."

"I ran git pull and now I have a merge conflict. What do I do?"

"I committed to the wrong branch. How do I move that commit to the right one?"

Ask it to review what happened:

"Show me how to see the history of this file and who changed what."

"I think I messed something up. How do I see what changed since my last commit?"

Let it run the commands for you - but ask it to explain:

One of the best things AI has brought to programming is automatic commit message generation. Instead of writing "fixed stuff" for the hundredth time, Copilot looks at exactly what changed and writes a meaningful, descriptive commit message for you. This alone is worth using it for.

You can go further and ask Copilot to handle the whole workflow - staging, committing, pushing - and have it explain each step as it goes. This is one of the fastest ways to build real understanding:

"Stage all my changes, write a commit message based on what I changed, commit, and push. Explain each command before you run it."

You get the work done and learn Git at the same time. After a few sessions of watching Copilot narrate its way through a push, the commands start to feel natural.

The more you ask, the more you learn - and the faster you build up intuition for how Git actually thinks. Treat it as a conversation, not a search engine.

VS Code also has a built-in Source Control panel (Ctrl+Shift+G) if you prefer a visual interface for staging, committing, and syncing - and the Git Graph extension gives you a visual diagram of your branch history. But even if you use those tools day to day, Copilot is the fastest way to understand what is happening under the hood.

Git vs GitHub CLI - two different tools¶

This trips people up. There are two command-line tools with similar names:

Both are covered in the installation instructions. You need git from the start. You can install gh later when you reach the deploy step - the deploy skill will prompt you to run gh auth login the first time.

Creating your first repository¶

1. Go to github.com and sign in with your AFRY account
2. Click the + button in the top right and select New repository
3. Give it a name, set visibility (Private or Internal), and click Create repository
4. Copy the repository URL
5. In VS Code, press Ctrl+Shift+P, type Git: Clone, and paste the URL

Learning more¶

This chapter gives you enough to follow the vibe coding trail. If you want to go deeper:

• GitHub Git Handbook - a concise official introduction
• VS Code Source Control docs - everything the built-in Git UI can do

You can also just ask Copilot. Any Git concept or command is fair game:

"Explain what a merge conflict is and how to resolve one."

"What is the difference between git fetch and git pull?"

Copilot will explain it in plain English, or walk you through fixing a specific problem in your repository.