DEV Community: Javi Palacios

Push and fetch in Git: syncing with the remote

Javi Palacios — Thu, 25 Jun 2026 08:48:11 +0000

You already know that remotes are aliases for URLs, and that origin has nothing special about it. But having the remote configured isn't enough — the whole point is to synchronize your work with it. When do you use git push? When do you use git fetch? And what exactly is the difference between git fetch and git pull? There are people who've been using Git for years without having this fully clear (no judgment — me included when I started).

Let's fix that today, and along the way we'll see why git push --force is one of the most efficient ways to make your teammates hate you.

Sending changes to the remote: git push

git push sends your local commits to a remote repository. The basic form:

git push origin master

This sends the local master branch to the origin remote. If the remote doesn't have that branch yet, it creates it. If it already exists and your commits are a direct continuation of its history (no divergence), the push works without issue.

Setting the upstream with -u

The first time you push a new branch, add -u to set up tracking:

git push -u origin new-feature

After that, from that branch you can just type:

git push

And Git already knows where to go. Without -u, Git will ask you to specify the remote and branch every time, with an error message that a lot of people copy into Google without reading it in full.

What happens when a push is rejected?

If someone else pushed changes to the same branch while you were working, you'll see something like:

 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:youruser/my-project.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

Git refuses to overwrite someone else's work. The fix: bring in the remote changes first, integrate them, then push. We'll cover this in detail in the next section.

Receiving changes: fetch vs pull

This is where confusion is most common. There are two ways to bring changes from the remote:

git fetch: downloads the changes but doesn't apply them
git pull: downloads the changes and applies them (it's fetch + merge in one shot)

git fetch

git fetch origin

This updates your local remote references (origin/master, origin/develop, etc.) with what's on the server, but doesn't touch your working branch. It's like checking your mail without opening it.

After a fetch, you can see what changed:

git log master..origin/master --oneline

a7f3c21 Fix authentication bug
b2e9d14 Add user profile endpoint

That shows you the commits that are in origin/master but not yet in your local master. You can inspect them at your own pace before deciding to integrate them.

When you're ready to integrate:

git merge origin/master

git pull

git pull origin master

This is equivalent to running git fetch origin followed by git merge origin/master. Faster to type, but it removes the intermediate inspection step.

On personal projects or when you trust what's on the remote, git pull is perfectly fine. On team projects with high activity, fetching first gives you more control over what you're integrating and when.

fetch + manual merge      git pull
────────────────────      ─────────
git fetch origin     ←→   git pull origin master
git log master..origin/master
git merge origin/master

Neither option is universally better. It comes down to how much you want to see before integrating.

The danger of --force

When a push is rejected because the remote has changes you don't have, the temptation is to use --force:

# ⚠️ Dangerous on shared branches
git push --force origin master

--force overwrites the remote's history with yours, ignoring any commits that are there. If you're working alone on a feature branch that only you touch, it can be valid. On a shared branch, it's like deleting your teammates' work without asking.

--force-with-lease: the sensible alternative

git push --force-with-lease origin master

--force-with-lease does the same operation as --force, but with a prior check: it fails if the remote has commits you don't have in your local copy. In other words, it protects you from overwriting someone else's work that you haven't seen.

The practical difference:

--force            # "Overwrite no matter what"
--force-with-lease # "Overwrite only if the remote hasn't changed since my last fetch"

When do you use force (with lease)? The most common case is after a git rebase: by rewriting history, your commits get new hashes and Git sees them as diverging from the remote, even though the content is essentially the same. If the branch is yours alone, --force-with-lease is safe.

On shared branches like master or main: never, except in very specific situations with explicit team coordination.

Practical case: the full workflow

A typical flow in a project where more than one person is working on the same branch:

# 1. Bring in the latest changes before starting
git fetch origin
git log master..origin/master --oneline  # what's new?

# 2. Integrate if there are changes
git merge origin/master

# 3. Do your work and commit locally
git add .
git commit -m "feat: add search functionality"

# 4. Before pushing, check if someone else pushed while you worked
git fetch origin
git log master..origin/master --oneline

# 5. If there are new changes, integrate them first
git merge origin/master  # or git rebase origin/master, depending on the project

# 6. Now push
git push origin master

This looks like a lot of steps, but with practice it becomes automatic. And it prevents 90% of remote conflicts.

With this you have the full cycle: you know how to send changes to the remote, how to receive them with control, and why --force-with-lease exists (and bare --force should give you pause).

In the next tutorial, lesson 18, we'll look at how to undo commits: from minor fixes with --amend to reverting already-pushed changes without breaking shared history.

💡 Challenge: In one of your repositories, run git fetch origin and then git log HEAD..origin/master --oneline. Are there commits on the remote that you don't have locally? If not, create a commit directly on GitHub and repeat the exercise. Then integrate with git merge.

Never stop coding!

Obtaining and cloning new commits from a Git repository

Javi Palacios — Tue, 23 Jun 2026 09:42:46 +0000

Yay! We have our fancy fresh baked repo on GitHub, now let's face our main purpose of working with a remote server: Allowing as many people as you need to work on your project indepently from their locations. For simulating this scenario, instead of working from two different machines, we're going to create two folders. In our last article, we uploaded our project to the folder test and as we are really original we are going to create another folder with the name test2, which is going to act as our second machine.

When we see a repository on GitHub that we want to copy to our computer, with a simple click on Clone or Download AND double checking that we ticked the option to clone thru SSH (which is the recommended option and in a near future we will explain why) will copy the called project to our computer.

We need to copy the Git address we see in the text field and paste it onto our terminal with this command: git clone git@github.com:fjpalacios/test.git test2
As you can tell, test2 is the folder which we choose to download the repo (by default, if we don't specify any folder, it would use test, same as the name of our project).

Cloning into 'test2'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

Let's say another team member, or ourselves, from the other computer (test folder), we do some changes, then, the other repository we just cloned is not up to date anymore!

$ echo "This is a test file" > test.txt
$ git add .
$ git commit -m "Adding a test file"

[master d40c331] Adding a test file
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

$ git push origin master

Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 957 bytes | 957.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:fjpalacios/test.git
   9da799a..d40c331  master -> master

Even if we think the file should be there, it isn't! Let's see the files in the current folder with ls and as we said before, the file isn't there! There's only one file: README.md which was the only file when we cloned the repo. Solving this won't take long, don't you worry:

$ git pull origin master

remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:fjpalacios/test
 * branch            master     -> FETCH_HEAD
   9da799a..d40c331  master     -> origin/master
Updating 9da799a..d40c331
Fast-forward
 test.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

Let's re-check again with ls and you are going to see the new file (or files, depending on how many files were in the other repo). When we are working on our own is not that complicated to know if we have changes in any of our machines, but when we are working as part of a team, that's tricky! That's why it's good to ask Git if he has any changes for us.

As an extra: If you're working on different branches and you want to pull all the changes from every branch, instead of specifying a specific branch, we would use --all as a parameter: git pull origin --all.

And this is it, Another part of the course! As always, never stop programming! Which, if you're with us since the start of this course, you can code with the peace of mind that your project is safe thanks to Git.

Working with Git Remotes

Javi Palacios — Mon, 22 Jun 2026 12:15:51 +0000

You've been typing git push origin master for a while now. It works, the code lands on GitHub, everyone's happy. But if someone asked you right now what exactly origin is, could you answer without hesitating? Or do you use it "on faith" — the kind of faith where you pray the command works and don't ask too many questions?

Don't worry. Most people use Git for years without fully understanding what's behind that origin. Let's fix that today.

What does Git know about your remotes?

A remote in Git is simply an alias for a URL. That's it. origin is not a mystical entity or a special server: it's a name pointing to an address, just like a contact in your phone has a name pointing to a number.

To see which remotes you have configured:

git remote -v

origin  git@github.com:youruser/my-project.git (fetch)
origin  git@github.com:youruser/my-project.git (push)

Each remote appears twice: once for fetch (receiving) and once for push (sending). In almost every case they point to the same URL, but Git treats them independently. This lets you, in theory, fetch from one place and push to another — useful in weird setups you'll probably never need, but good to know exist.

origin is the default name Git assigns when you run git clone. There's nothing special about it. You could call it github, main-remote, or potato and it would work exactly the same.

If you only want the names without the URLs:

git remote

origin

Adding and removing remotes

Adding a remote

git remote add <name> <url>

For example, to add a second remote called backup:

git remote add backup git@github.com:youruser/my-project-backup.git

Now you have two:

git remote -v

backup  git@github.com:youruser/my-project-backup.git (fetch)
backup  git@github.com:youruser/my-project-backup.git (push)
origin  git@github.com:youruser/my-project.git (fetch)
origin  git@github.com:youruser/my-project.git (push)

Removing a remote

git remote remove backup

Or its equivalent alias (because in Git there's always two ways to do the same thing):

git remote rm backup

This removes only the local configuration — the remote repository on the server keeps existing, don't worry.

Renaming a remote

git remote rename origin github

From that point you'd use git push github master instead. Useful when you have multiple remotes and want more descriptive names than origin, origin2, and origin-that-one-I-dont-know-what-it-does.

Changing a remote's URL

If you originally cloned with HTTPS and now want to switch to SSH (so you stop typing your password every five minutes), you don't need to delete and re-add the remote:

git remote set-url origin git@github.com:youruser/my-project.git

Verify the change was applied:

git remote -v

origin  git@github.com:youruser/my-project.git (fetch)
origin  git@github.com:youruser/my-project.git (push)

Inspecting a remote in detail

git remote -v gives you the URLs, but if you want a full picture of what's happening with a remote:

git remote show origin

* remote origin
  Fetch URL: git@github.com:youruser/my-project.git
  Push  URL: git@github.com:youruser/my-project.git
  HEAD branch: master
  Remote branches:
    develop tracked
    master  tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    master pushes to master (up to date)
    develop pushes to develop (local out of date)

That last part — local out of date — is the important bit: before you start working on develop, you already know someone pushed changes you don't have. Without this command, you'd find out after trying to push and getting a cryptic error.

Multiple remotes: origin and upstream

The most common reason to have more than one remote is when you work with forks. Say you want to contribute to an open source project — the Git project itself, or any library you use daily:

You fork the repository on GitHub (now you have your own copy at youruser/project)
You clone your fork: git clone git@github.com:youruser/project.git
Git configures origin pointing to your fork

The problem: the original project keeps moving forward without you, and you need to bring those changes in periodically. For that you add the original repository as a second remote. The universal convention (that everyone follows so nobody goes crazy) is to call it upstream:

git remote add upstream git@github.com:original-author/project.git

Result:

git remote -v

origin    git@github.com:youruser/project.git (fetch)
origin    git@github.com:youruser/project.git (push)
upstream  git@github.com:original-author/project.git (fetch)
upstream  git@github.com:original-author/project.git (push)

The typical workflow:

# Bring in the latest changes from the original project
git fetch upstream

# Integrate them into your main branch
git merge upstream/master

Your origin stays as your fork. upstream is read-only in practice — you won't have push permissions there, and even if you did, you shouldn't push directly to the original repository (that's what pull requests are for).

Tracking branches: the link between local and remote

When you clone a repository or run git push -u origin master, Git creates something called a tracking branch: a reference that connects your local branch to its counterpart on the remote. This is what lets Git know where to send changes when you run git push with no extra arguments.

To see which tracking branches you have configured:

git branch -vv

* master  a3f8c21 [origin/master] Add form validation
  develop e1b9d44 [origin/develop: ahead 2] Integrate payments module

In brackets you see the remote branch being tracked. ahead 2 means you have 2 local commits that aren't on the remote yet. Very useful before a git push to know exactly what you're about to send.

When you create a new branch and push it for the first time, you set up the tracking with -u (short for --set-upstream):

git push -u origin new-feature

From that point on, git push and git pull from that branch work without extra arguments. If you forget the -u, Git will politely remind you it doesn't know where to push — with an error message that a lot of developers copy into Google without reading it.

Practical cases

Cleaning up references to deleted remote branches

Over time, teammates delete branches on the remote after a merge, but those references keep showing up in your local as ghosts of branches past. To clean them up:

git fetch --prune

Or configure it globally so it happens automatically on every fetch:

git config --global fetch.prune true

I recommend enabling this. Having references to branches that no longer exist only creates confusion, especially in high-activity projects.

Now you understand what's behind that origin you'd been using without questioning. Remotes are aliases, not magic. You can add as many as you need, inspect them, change their URLs, and know exactly which tracking branches connect them to your local work.

In the next tutorial we'll look at how to synchronize your repository with those remotes: git clone to start from scratch with an existing repository, and git pull to keep your local copy up to date.

💡 Challenge: Add a second remote to an existing repository (it can point to the same URL as origin, just with a different name). Run git remote show on both and compare the output. Then remove it. Bonus: enable fetch.prune globally if you haven't already.

Never stop coding!

Operators and expressions in Python

Javi Palacios — Sun, 21 Jun 2026 00:11:53 +0000

You already know what variables are and how to store data in them. But having data stored without doing anything with it is like having ingredients in the fridge without cooking: it doesn't matter how great your tomatoes are if you don't know how to fry them.

This is where operators come in: the symbols that tell Python what to do with the data it has. Adding numbers, comparing values, combining conditions... with operators is when the code starts doing genuinely interesting things.

Arithmetic operators: Python's calculator

Let's start with the most intuitive part. Python understands basic math exactly as you'd expect:

x = 10
y = 3

print(x + y)   # 13 — addition
print(x - y)   # 7  — subtraction
print(x * y)   # 30 — multiplication
print(x / y)   # 3.3333... — division

So far so normal. But Python has two operators you won't find on a regular calculator, and they're tremendously useful:

Integer division (//): returns the quotient without decimals, discarding the remainder:

print(10 // 3)   # 3
print(7 // 2)    # 3

Modulo (%): returns the remainder of the division. What's that good for? More than you'd think. For example, to check if a number is even (if the remainder of dividing by 2 is 0, it's even):

print(10 % 3)   # 1  (10 = 3×3 + 1)
print(8 % 2)    # 0  (8 is even, no remainder)
print(7 % 2)    # 1  (7 is odd)

And finally, exponentiation (**), the coolest operator of them all:

print(2 ** 10)   # 1024  (2 to the power of 10)
print(3 ** 3)    # 27    (3 cubed)
print(9 ** 0.5)  # 3.0   (square root of 9)

Notice that last one: 9 ** 0.5 is the square root, because the square root is the same as raising to the power of 0.5. Python handles this perfectly.

Order matters: operator precedence

What do you think Python does with this?

print(2 + 3 * 4)

If you answered 20, the logic is impeccable but the answer is wrong. Python, just like in math class, follows the order of operations: multiplications and divisions first, then additions and subtractions. So the result is 14 (3×4=12, then 2+12=14).

What if you really want to add first? Parentheses work exactly the same as in school:

print((2 + 3) * 4)   # 20
print(2 + 3 * 4)     # 14
print(10 / 2 + 3)    # 8.0
print(10 / (2 + 3))  # 2.0

The golden rule: when in doubt about order, use parentheses. They cost nothing and make the code much easier to read.

Comparison operators: is this greater than that?

Here comes one of the points where beginners stumble most. Python has two symbols that look similar but do completely different things:

= is assignment: stores a value in a variable
== is comparison: checks if two values are equal

Don't mix them up. If you write x = 5 you're storing 5 in x. If you write x == 5 you're asking "is x equal to 5?", and Python answers True or False.

x = 10

print(x == 10)   # True  — is x equal to 10?
print(x == 5)    # False — is x equal to 5?
print(x != 5)    # True  — is x different from 5?
print(x > 5)     # True  — is x greater than 5?
print(x < 5)     # False — is x less than 5?
print(x >= 10)   # True  — is x greater than or equal to 10?
print(x <= 10)   # True  — is x less than or equal to 10?

The result of a comparison is always a boolean: True or False. This is fundamental because later, when you get to conditionals (if/else), you'll be using these comparisons constantly to make decisions in your code.

Logical operators: combining conditions

What if a single comparison isn't enough? Imagine you want to know if someone can enter a website: they need to be over 18 and have accepted the terms. Or maybe you want to know if a number is between 1 and 10.

That's what logical operators are for: and, or, and not.

and: both conditions must be met

age = 20
accepted_terms = True

print(age >= 18 and accepted_terms)          # True — meets both
print(age >= 18 and not accepted_terms)      # False — terms not accepted

x = 7
print(x > 1 and x < 10)   # True — x is between 1 and 10

or: just one condition needs to be met

is_admin = False
is_moderator = True

print(is_admin or is_moderator)   # True — one is enough

day = "Saturday"
print(day == "Saturday" or day == "Sunday")   # True — it's the weekend

not: inverts the result

has_account = False

print(not has_account)   # True — if they DON'T have an account...
print(not True)          # False
print(not False)         # True

not is like putting a "no" in front: it turns True into False and vice versa.

A very common combination in real code:

user_active = True
account_locked = False

can_access = user_active and not account_locked
print(can_access)   # True

Read it out loud: "the user can access if they're active and their account is not locked". That's how natural well-written code reads.

Assignment operators: updating variables without repeating yourself

Imagine you have a counter and you want to add 1 to it. The obvious way would be:

counter = 0
counter = counter + 1
print(counter)   # 1

It works, but Python has a more compact form. The += operator adds and assigns in a single step:

counter = 0
counter += 1   # equivalent to: counter = counter + 1
print(counter)   # 1

counter += 5   # equivalent to: counter = counter + 5
print(counter)   # 6

The same exists for all other operations:

x = 10

x += 3    # x = 10 + 3 = 13
x -= 2    # x = 13 - 2 = 11
x *= 4    # x = 11 * 4 = 44
x /= 2    # x = 44 / 2 = 22.0
x //= 3   # x = 22.0 // 3 = 7.0
x **= 2   # x = 7.0 ** 2 = 49.0
x %= 10   # x = 49.0 % 10 = 9.0

print(x)  # 9.0

You'll see these operators constantly in loops (for, while) when you need to accumulate values or count iterations.

Putting it all together: a simple calculator

Let's write something that uses everything we've seen. A small calculator that analyzes two numbers and tells us various things about them:

a = 15
b = 4

# Arithmetic operations
print(f"{a} + {b} = {a + b}")
print(f"{a} - {b} = {a - b}")
print(f"{a} * {b} = {a * b}")
print(f"{a} / {b} = {a / b:.2f}")
print(f"{a} // {b} = {a // b}")
print(f"{a} % {b} = {a % b}")
print(f"{a} ** {b} = {a ** b}")

# Comparisons
print(f"Is {a} > {b}? {a > b}")
print(f"Is {a} == {b}? {a == b}")

# Is 'a' even?
print(f"Is {a} even? {a % 2 == 0}")

# Are both between 1 and 100?
print(f"Both between 1 and 100? {1 <= a <= 100 and 1 <= b <= 100}")

The output would be:

15 + 4 = 19
15 - 4 = 11
15 * 4 = 60
15 / 4 = 3.75
15 // 4 = 3
15 % 4 = 3
15 ** 4 = 50625
Is 15 > 4? True
Is 15 == 4? False
Is 15 even? False
Both between 1 and 100? True

Notice that 1 <= a <= 100: Python allows chaining comparisons this natural way, something that in many other languages you can't do directly.

The most classic mistake: = instead of ==

Before you close this tutorial, burn this into your memory:

# This ASSIGNS the value 5 to x (does not compare)
x = 5

# This COMPARES whether x is equal to 5
print(x == 5)   # True

If you try to use = where == should go in a comparison, Python will throw an error (or worse, do something unexpected without warning). It's the most common mistake among Python beginners, so watch out for it.

Summary

With operators you can now make your code take decisions and perform real calculations. What we've covered:

Arithmetic (+, -, *, /, //, %, **): for doing calculations with numbers
Comparison (==, !=, >, <, >=, <=): for comparing values and getting True or False
Logical (and, or, not): for combining multiple conditions
Compound assignment (+=, -=, *=, etc.): for updating variables concisely
Precedence: parentheses win, then **, then * / // %, and finally + -

In the next tutorial we'll dive into strings: how to create them, manipulate them, and get the most out of Python's string methods.

Never stop coding!

Creating our first repository on GitHub

Javi Palacios — Sat, 20 Jun 2026 10:11:48 +0000

We have already worked a lot with Git locally, we have seen how to create repositories, how to create commits, how to work with branches, how to recover files...

But, how can I work with other people?, how do I share that great project that I just finished and I want more people to see it?, or the solution to that problem that half the world is encountering?

For that, we have GitHub!

What is GitHub?

Well, basically GitHub is a website where you can have your Git repositories, but not just any website, but the website par excellence with more than 20 million users according to data from April 2017, and with more than 57 million repositories.

Not bad, right?

So let's see how to create our first repository on GitHub. The first thing we must do if we haven't already is to create a GitHub account.

Creating our repository

Once we have logged into our GitHub account, we will see the Dashboard, which is the main page of GitHub, like that of any other social network, where we can see the activity of the people we follow or the repositories we have subscribed to.

But well, let's get to what interests us, creating our first repository. To do this, in the upper right corner we will see our avatar, and next to it a + symbol, click on it and then New repository.

After that it will take us to the following page:

As we can see, we have several fields to fill in, below I will explain what each of them is for:

Repository name: the name of our repository, it is something that we must fill in yes or yes, without that field it will not allow us to create the repository.
Description: a description of what our project consists of, it is not mandatory to fill it in.
Public/Private: do we want our repository to be public for everyone or private only for us (or people we invite)? It is paid to be able to have private repositories.
Initialize this repository with a README: do we want a README file to be automatically created when the repository is created (which is the one we will use to describe what the project is about)?
Add .gitignore: do we want to add a .gitignore file? We can choose what language we are going to use in the project to add a standard .gitignore file of the language/framework we want (we can modify it later).
Add a license: do we want to add a license to our project? We can choose from the most popular ones.

We fill in the Repository name field, choose whether we want the repository to be public or private, check the Initialize this repository with a README checkbox and click on Create repository.

After a few seconds it will take us to our repository page:

This is where we can see everything related to our project.

At first we will see several things, such as the README.md file that we have created (which is the one we see below the files), and the .gitignore if we have created it too.

Also, if we click on 1 commit, we can see the only commit we have so far, which is the initialization of the two files:

As you can see, GitHub repositories also have branches, in the previous screenshot we can see that the master branch is shown, which is the one we have by default.

Conclusion

We have already seen how easy it is to create a repository on GitHub. In future tutorials we will see how to interact with it, how to download it to work locally, and a thousand more things.

Never stop programming!

Getting started with Git remotes

Javi Palacios — Fri, 19 Jun 2026 10:08:19 +0000

Like we already explained in our first article for this course What is Git?: Git is a decentralized service, you won't find the typical client-server kind of structure but with remotes we can emulate this method to which all of us are so used to.

Remotes… What the heck are they?

As soon as we hear Remote, our mind flies to GitHub or GitLab, which are perfect to emulate the mentioned structure and not only that, they are a great showroom for Open Source projects.

A remote basically is another node where we can send data or where we can receive data from, another pc on our network, a colleague's pc or our company's main server.

Remote servers are in other terms a place where we can save a Backup (and many other things :P) exact same the way we have the data on our computers, but probably the most brighter side is when we are sending code to a service like GitHub or GitLab, takes out work from our side, as automatizes some tedious tasks, which cause serious time loss and nerves (above the sky!) and are (sometimes) the most hated tasks by devops like us. Executing our test battery for the new-ly sent code to GitHub is a perfect idea to make sure not even a single bracket is missing the closure or a function has stopped working since the implemented a new greeting method and the best of all, doing this is free! So why not give it a chance?

This this this is everything friends??

Nope, we are bringing more stuff about Git and the use of remotes in our following articles for this course.

And a quick reminder, all the code we are sharing with you is available in our GitHub Repo where you can access it and have an idea how Git works from a remote node perspective.

Meanwhile, as we always say… Never stop programming!

Installing Neovim and LazyVim

Javi Palacios — Thu, 18 Jun 2026 13:20:04 +0000

You're convinced: you want to try Vim. You understand the philosophy of modal editing, you know it can make you more productive, and you're ready to take the leap. But there's one small problem: how the hell do I install this thing?

If you're like me when I started, you've probably heard of Vim, Neovim, NeoVim nightly, Vim 9.0, LazyVim, LunarVim, NvChad... What is each thing? Where do I start? Is my computer going to explode?

Relax. We're going to install Neovim (the modern version of Vim) with LazyVim (a preconfigured setup that gives you a modern IDE from minute zero). And we're going to do it step by step, without assuming you have a PhD in Unix systems.

Neovim or Vim? The eternal question

Before installing anything, let's clear up the confusion: Vim is the classic editor, created by Bram Moolenaar in 1991. Neovim is a modern fork of Vim (since 2014) that:

Has better support for modern plugins (written in Lua)
Supports LSP (Language Server Protocol) natively, which means autocomplete, diagnostics, and refactoring like in VSCode
Has a cleaner, more extensible architecture
Updates faster with modern features

Does this mean Vim is dead? No. But for someone starting in 2026, Neovim is the recommended choice. You can do the same with Vim, but with more manual work.

So here we're going to install Neovim.

Installing Neovim according to your operating system

On Linux (Ubuntu/Debian and derivatives)

If you use Ubuntu, Debian, Linux Mint, Pop!_OS, or any Debian-based distribution:

sudo apt update
sudo apt install neovim

Easy, right? The problem is that official repositories sometimes have old versions. To make sure you have a recent version (we need at least 0.9.0), check:

nvim --version

You should see something like:

NVIM v0.10.0
Build type: Release
LuaJIT 2.1.0-beta3

If your version is less than 0.9.0, I recommend installing from the official PPA or using the AppImage:

# Option 1: PPA (more up-to-date)
sudo add-apt-repository ppa:neovim-ppa/unstable
sudo apt update
sudo apt install neovim

# Option 2: AppImage (portable, always updated)
curl -LO https://github.com/neovim/neovim/releases/latest/download/nvim.appimage
chmod +x nvim.appimage
sudo mv nvim.appimage /usr/local/bin/nvim

On Arch Linux and derivatives

If you use Arch, Manjaro, EndeavourOS, etc., you're in luck. Neovim is always up-to-date in the official repos:

sudo pacman -S neovim

And done. Arch users don't need more explanation, you already know how this works.

On macOS

If you use Mac, the easiest way is with Homebrew (if you don't have it installed, go to brew.sh):

brew install neovim

Homebrew takes care of giving you the latest stable version. Check that it works:

nvim --version

On Windows

Here things get a bit complicated (because Windows, you know), but you have several options:

Option 1: Scoop (recommended)

Scoop is like Homebrew for Windows. If you don't have it:

# In PowerShell as administrator
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
irm get.scoop.sh | iex

# Install Neovim
scoop install neovim

Option 2: Chocolatey

If you prefer Chocolatey:

choco install neovim

Option 3: Manual download

Go to github.com/neovim/neovim/releases, download the .msi installer, and run it.

Once installed, open PowerShell or CMD and check:

nvim --version

The first launch (and initial panic)

Now that you have Neovim installed, open it:

nvim

You'll find yourself with... an empty screen with the Neovim logo and some instructions. This is normal. Neovim without configuration is minimalist to the extreme.

Try typing something. You can't. Press i (insert mode), type "Hello", press Esc, type :q! and press Enter to exit.

Feeling confused? Perfect. That means you're in the right place. Now we're going to give Neovim superpowers.

What is LazyVim and why do you need it?

Configuring Neovim from scratch is like building a PC piece by piece. You can do it, and you'll learn a lot, but it takes weeks to get something usable.

LazyVim is a preconfigured Neovim distribution that gives you:

🎨 A beautiful, modern theme (by default, TokyoNight)
🔍 Telescope (fuzzy file finder, like Ctrl+P in VSCode)
🌳 Neo-tree (sidebar file explorer)
💡 Configured LSP (autocomplete, diagnostics, go to definition)
🚀 Treesitter (advanced syntax highlighting)
⚡ Lazy.nvim (ultra-fast plugin manager)
🔧 Which-key (shows keyboard shortcuts as you use them)

All of this, working from minute zero, without you having to configure anything.

Think of it as the difference between buying a PC with components (pure Neovim) vs a Mac (LazyVim): the second works when you turn it on, the first requires assembly.

Installing LazyVim dependencies

LazyVim needs some tools installed on your system to work at 100%. Don't worry, they're quick to install.

On Linux

# Ubuntu/Debian
sudo apt install ripgrep fd-find

# Arch
sudo pacman -S ripgrep fd

# Optional but highly recommended: lazygit (for Git from Neovim)
# Ubuntu/Debian (add the PPA)
sudo add-apt-repository ppa:lazygit-team/release
sudo apt update
sudo apt install lazygit

# Arch
sudo pacman -S lazygit

On macOS

brew install ripgrep fd lazygit

On Windows (with Scoop)

scoop install ripgrep fd lazygit

What do these tools do?

ripgrep (rg): Ultra-fast text search in files (like grep but faster)
fd: File search (like find but more friendly)
lazygit: TUI interface for Git (optional, but incredibly useful)

Installing a Nerd Font (critical for icons)

LazyVim uses icons in the file explorer, status bar, etc. For them to display properly, you need a Nerd Font (a font with integrated icons).

On Linux

# Download Fira Code Nerd Font
mkdir -p ~/.local/share/fonts
cd ~/.local/share/fonts
curl -fLo "Fira Code Nerd Font Complete.ttf" \
  https://github.com/ryanoasis/nerd-fonts/raw/master/patched-fonts/FiraCode/Regular/FiraCodeNerdFont-Regular.ttf

# Update font cache
fc-cache -fv

On macOS

brew tap homebrew/cask-fonts
brew install --cask font-fira-code-nerd-font

On Windows

Download the font from nerdfonts.com, extract, right-click on the .ttf, and "Install".

Important: Now you have to configure your terminal to use this font. Go to your terminal settings (Windows Terminal, Alacritty, Kitty, iTerm2, etc.) and change the font to "FiraCode Nerd Font" or "FiraCode NF".

If you don't do this, you'll see weird squares where icons should be.

Installing LazyVim (the moment of truth)

Now yes. We're going to install LazyVim. But first, important: if you already had a Neovim configuration, make a backup:

# Backup your current configuration (if it exists)
mv ~/.config/nvim ~/.config/nvim.backup
mv ~/.local/share/nvim ~/.local/share/nvim.backup
mv ~/.local/state/nvim ~/.local/state/nvim.backup
mv ~/.cache/nvim ~/.cache/nvim.backup

On Windows, the path is ~/AppData/Local/nvim instead of ~/.config/nvim.

Now, clone the LazyVim starter configuration:

# Linux/macOS
git clone https://github.com/LazyVim/starter ~/.config/nvim

# Windows (PowerShell)
git clone https://github.com/LazyVim/starter $env:LOCALAPPDATA\nvim

This creates the LazyVim configuration structure in your Neovim config folder.

Now, remove the .git directory so you can customize your configuration without conflicts:

# Linux/macOS
rm -rf ~/.config/nvim/.git

# Windows
Remove-Item -Recurse -Force $env:LOCALAPPDATA\nvim\.git

The first LazyVim launch

Take a deep breath. Open Neovim:

nvim

You'll see... lots of things happening. LazyVim is:

Installing the plugin manager (lazy.nvim)
Downloading all configured plugins
Compiling Treesitter parsers
Installing LSP servers

This can take 1-3 minutes depending on your connection. You'll see a window with progress bars. Don't close Neovim. Let it finish.

When it's done, you'll see the LazyVim dashboard, something like:

╭──────────────────────────────────────────╮
│                                          │
│           ⚡ LazyVim ⚡                   │
│                                          │
│   󰈞  Find File                           │
│   󰈢  Recent Files                        │
│   󰈬  Find Text                           │
│     Config                              │
│     Restore Session                     │
│   󰗼  Lazy                                │
│                                          │
╰──────────────────────────────────────────╯

If you see this, congratulations! LazyVim is working.

What do I do now?

Press ? to see keyboard shortcuts. Press <Space> (spacebar) and wait a second: you'll see the Which-key menu with all available commands.

For now, don't stress about learning all the shortcuts. In the next tutorial we're going to see the basic survival commands to open files, edit them, save them, and exit without panic.

But first, let's do a quick check that everything works.

Check: does LSP work?

Let's create a test file to make sure autocomplete works.

From Neovim, press : (colon) and type:

:e test.js

This creates (or opens) a file called test.js. Now press i (insert mode) and type:

const greeting = "Hello"
console.log(gree

When you type gree, an autocomplete menu should appear suggesting greeting. If you see that, LSP works. If not, don't worry, you may need to install the language server for JavaScript. LazyVim will ask you automatically the first time you open a .js file.

Press Esc, then type :q! and Enter to exit without saving.

Summary: what we've achieved

If you've made it this far, you now have:

✅ Neovim installed and working (version 0.9.0+)
✅ LazyVim configured with modern plugins
✅ Nerd Font installed for icons
✅ CLI tools (ripgrep, fd, lazygit) for full functionality
✅ LSP working (autocomplete, diagnostics)

What you DON'T have yet is any idea how to use this. And that's normal. In the next tutorial we're going to learn the survival commands: how to open files, move through text, edit, save, and (most importantly) how to exit Vim without Googling it.

Final tips before continuing

Don't try to learn everything at once. Vim literally has hundreds of commands. Start with the basics, use them until they become automatic, and then add more.

Don't get frustrated if you're slow at first. It's like learning to play piano: the first few days you're clumsy, but in a few weeks you'll be flying through code.

Don't give up in the first few hours. Vim's learning curve is steep at the beginning, but the reward is worth it.

Now, breathe, close this tutorial, open Neovim, and get ready for the next step.

Never stop coding!

Stashing Changes with git stash

Javi Palacios — Wed, 17 Jun 2026 08:36:30 +0000

Imagine this situation: you're working on a new feature, you've modified several files, but suddenly you get an urgent alert. There's a critical bug in production and you need to fix it right now. The problem is that your current changes aren't ready for commit, they're half-done… What do you do?

You could make a commit with a message like "WIP" (Work In Progress) and then undo it, but that pollutes your history. You could copy files to another folder, but that's manual and error-prone. Or… you could use git stash, the perfect tool for this scenario.

What is git stash?

git stash is like a temporary box where you can save your current changes (both those in the staging area and modified files) without needing to make a commit. Your working directory will be clean, as if you hadn't made any changes, and you'll be able to switch branches, do other tasks, and then recover those changes exactly where you left them.

Think of it as saving your game before turning off the console. You don't lose your progress, you just pause it to resume later.

Saving changes with git stash

Let's see it with a practical example. Suppose you're working on your project and you've modified index.html:

<h1>Welcome to my awesome site</h1>
<p>This is a work in progress feature...</p>

If you run git status you'll see:

On branch feature/new-homepage
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

Now the urgency arrives. You need to switch to master to fix that bug. If you try to switch branches like this:

git switch master

Git will prevent you:

error: Your local changes to the following files would be overwritten by checkout:
        index.html
Please commit your changes or stash them before you switch branches.
Aborting

Git is protecting you! It doesn't want you to lose your changes. This is where git stash comes in:

git stash

Or if you want to be more explicit and add a descriptive message (highly recommended when you have multiple stashes):

git stash push -m "WIP: New homepage"

You'll see something like:

Saved working directory and index state On feature/new-homepage: WIP: New homepage

And now? Check with git status:

On branch feature/new-homepage
nothing to commit, working tree clean

Magic! Your directory is clean. Now you can safely switch to master, fix the bug, commit, and return to your working branch.

Listing your stashes

What happens if you save several changes at different times? Git maintains a list of all your stashes. To see it:

git stash list

You'll get something like:

stash@{0}: On feature/new-homepage: WIP: New homepage
stash@{1}: On feature/api-integration: Partial API changes
stash@{2}: On master: CSS experiment

Each stash has an identifier: stash@{0}, stash@{1}, etc. The most recent is always {0}.

Viewing stash contents

Before recovering a stash, you might want to remember what changes you saved. For that you use:

git stash show

This shows you a summary of the most recent stash:

 index.html | 1 +
 1 file changed, 1 insertion(+)

If you want to see the full content (like a diff):

git stash show -p

diff --git a/index.html b/index.html
index 1234567..abcdefg 100644
--- a/index.html
+++ b/index.html
@@ -1 +1,2 @@
 <h1>Welcome to my awesome site</h1>
+<p>This is a work in progress feature...</p>

To see a specific stash (not the most recent):

git stash show stash@{1} -p

Recovering your changes: apply vs pop

Now that you've fixed the urgent bug and returned to your feature/new-homepage branch, you want to recover your changes. You have two options:

git stash pop

This command recovers the most recent stash and removes it from the list:

git stash pop

You'll see:

On branch feature/new-homepage
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html

Dropped refs/stash@{0} (abc1234...)

Your changes are back and the stash has been deleted. It's like taking something out of the box and throwing the box away.

git stash apply

This command recovers the stash but does NOT remove it from the list:

git stash apply

This is useful if you want to apply the same changes to several different branches, or if you're not sure you want to delete the stash yet.

To apply a specific stash:

git stash apply stash@{1}

And if after applying it you want to manually delete it:

git stash drop stash@{1}

Advanced situation: conflicts with stash

What happens if while your changes were saved in the stash, you modified the same files with other commits? When trying to do git stash pop or apply, Git may encounter conflicts.

For example, if you saved changes to index.html, then made a commit modifying that same file, and now try to recover the stash:

git stash pop

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
The stash entry is kept in case you need it again.

Git warns you of the conflict, and keeps the stash for safety (even though you used pop). You'll have to resolve the conflict manually as you would with any merge, editing the file, doing git add, and then deleting the stash with git stash drop if you no longer need it.

Creating a branch from a stash

Sometimes you recover a stash and it turns out the conflicts are too complex. Git offers an elegant solution: create a new branch directly from the stash:

git stash branch new-temp-branch

This:

Creates a new branch called new-temp-branch
Checks out that branch
Applies the stash to it
Removes the stash from the list

It's perfect for isolating problematic changes and working on them without affecting other branches.

Cleaning old stashes

Over time you may accumulate stashes you no longer need. To delete a specific stash:

git stash drop stash@{2}

To delete all stashes (be careful with this!):

git stash clear

Practical use cases

1. Urgent context switching

We already saw this: you're working, an urgency arrives, you do git stash, switch branches, fix it, return, and git stash pop.

2. Testing something quickly

You have local changes but want to test how the code works without them:

git stash
# Testing...
git stash pop

3. Clean working directory to pull

Sometimes you want to do git pull but have local changes that conflict:

git stash
git pull
git stash pop

4. Save experimental changes

You're experimenting with something you're not sure you want to commit. Stash it, work on something else, and decide later if you want to recover that experiment.

Useful git stash options

git stash -u or git stash --include-untracked: Includes untracked files in the stash. By default, git stash only saves files that Git is already tracking.
git stash -a or git stash --all: Includes all files, even those in .gitignore.
git stash push <file>: Saves only specific files:

  git stash push index.html styles.css

git stash push -p: Interactive mode, asks you hunk by hunk what you want to save in the stash.

Summary

git stash is an essential tool for daily Git workflow. It allows you to:

Temporarily save changes without committing
Switch context quickly between tasks
Experiment without fear of losing your work
Resolve conflicts in an organized way with git stash branch

The key commands are:

git stash or git stash push -m "message": Save changes
git stash list: View saved stashes
git stash show -p: View stash contents
git stash pop: Recover and delete the last stash
git stash apply: Recover without deleting
git stash drop: Delete a specific stash
git stash clear: Delete all stashes

Mastering git stash will make you much more agile and confident in your daily work. It's one of those tools that, once you know it, you wonder how you lived without it.

Never stop coding!

Why Vim? The Modal Editing Philosophy

Javi Palacios — Tue, 16 Jun 2026 08:40:44 +0000

If you're reading this, you're probably curious about Vim. Maybe you've seen a coworker editing code at lightning speed without touching the mouse. Maybe you've heard the meme about "how to exit Vim". Or maybe you simply want to understand why so many people still use a text editor from the 90s in 2026.

Welcome. This is the beginning of a journey that will forever change the way you edit text.

What is Vim? And Neovim?

Vim is a modal, highly configurable, and extremely efficient text editor. It was created by Bram Moolenaar in 1991 as an improvement to vi (1976), the standard Unix editor.

Neovim is a modern fork of Vim (2014) that preserves all the original philosophy but adds:

Native support for LSP (Language Server Protocol) - autocompletion, diagnostics, refactoring
Modern architecture with asynchronous APIs
Configuration in Lua (in addition to Vimscript)
Better performance and code maintainability
Active community and modern plugins

In this course we'll use Neovim because it's the future of Vim. Everything you learn works in classic Vim, but Neovim gives you additional superpowers.

A bit of history: vi → Vim → Neovim

1976: vi (Bill Joy)

The original Unix editor. Designed for slow terminals connected via phone lines. Modal editing wasn't a whim: it was technical necessity. You couldn't send every keystroke to the server in real-time.

1991: Vim (Bram Moolenaar)

"Vi IMproved". Added windows, syntax highlighting, plugins, and a thousand improvements while maintaining the modal essence.

2014: Neovim (Community)

Fork of Vim to modernize it. Asynchronous architecture, native LSP, Lua, better extensibility. Vim and Neovim coexist: many use Neovim but both are valid.

2026: LazyVim and modern distributions

Pre-packaged configurations that turn Neovim into a complete IDE in minutes. This is what we'll use in this course.

The modal editing paradigm

This is the idea that will change your life as a programmer: instead of having a single mode where you type and navigate mixed together (like VS Code or Sublime), Vim radically separates these two concepts.

The four modes of Vim

Normal Mode

The default mode. You don't type text, you navigate and execute commands. You'll spend 80% of your time here. You can move word by word, delete lines, copy blocks, search, replace... without touching the mouse.

Insert Mode

This is where you DO type text, like in any normal editor. But the key is: you enter, make ONE edit, and exit. Vim trains you to make atomic, precise changes.

Visual Mode

To visually select text (like dragging with the mouse, but with the keyboard). You can select characters, complete lines, or rectangular blocks (yes, vertical blocks of code).

Command Mode

Execute Vim commands by typing :something. Here you save files (:w), exit (:q), search and replace (:s/old/new/g), open files, etc.

Why is this so powerful?

In traditional editors, to delete a word you:

Double-click to select the word (mouse)
Or Ctrl+Shift+→ (three keys at once)
Backspace or Delete

In Vim:

dw (two keys in normal mode)

Delete to the end of the line?

VS Code: Shift+End → Backspace (3 keys + move hand to mouse if you mess up)
Vim: D (one key)

Delete everything inside quotes?

VS Code: Double-click, adjust selection, Delete (several movements)
Vim: di" (three keys: delete inside quotes)

The magic isn't in individual shortcuts. The magic is in the composable language.

The Vim language: composable grammar

Vim doesn't have "keyboard shortcuts". Vim has a language. And once you learn the grammar, you can combine concepts infinitely.

The basic structure is:

[count] operator motion

Operators:

d - delete
c - change (delete and enter insert mode)
y - yank (copy)
v - visual select

Motions:

w - word
$ - end of line
i" - inside quotes
ap - a paragraph
t. - till .

Combined examples:

dw - delete word
d$ - delete to end of line
di" - delete inside quotes
cap - change a paragraph
y3w - yank 3 words
dt. - delete till .

See the pattern? You don't memorize shortcuts, you learn vocabulary. Once you know that:

i( means "inside parentheses"
a{ means "around braces"
c means "change"

Then ci( (change inside parentheses) is obvious. And da{ (delete around braces) too.

This scales. Regular keyboard shortcuts don't.

Common myths about Vim

Before continuing, let's debunk some misconceptions:

❌ "Vim is too hard"

Reality: Vim has a steep learning curve at the beginning (2-3 uncomfortable days), but then it becomes exponentially easier. Most editors have a flat curve: you're always equally "slow".

Vim is like learning to play guitar: the first chords are tough, but once you master them, you can play thousands of songs. Traditional shortcuts are like memorizing each song note by note.

❌ "Vim is only for terminals / 'old-school' people"

Reality: Neovim in 2026 with LazyVim has:

LSP (autocompletion, go-to-definition, refactoring)
Tree-sitter (advanced syntax highlighting)
Telescope (fuzzy finder like VS Code's Cmd+P)
Neo-tree (visual file explorer)
Git integration (like GitLens)
Integrated debugger (DAP)
Support for any language (TypeScript, Rust, Python, Go...)

It's a complete IDE, not a plain text editor.

❌ "I don't need Vim, VS Code is enough"

Reality: This is the most common trap. VS Code is excellent, but:

Speed: Editing with Vim is 2-3x faster once you master it. No exaggeration.
Ergonomics: You don't need a mouse. Your hands never leave the home row. Goodbye wrist pain.
Portability: Vim is on any remote server. SSH to a server and you can edit with the same skills.
Resources: Neovim uses 50MB of RAM. VS Code uses 500MB+ (and that's just on startup).

Plus, there's a VSCode Neovim extension if you want the best of both worlds.

❌ "Vim is for purists who hate modern technology"

Reality: GitHub, Google, Meta, Netflix have thousands of engineers using Vim/Neovim in 2026. ThePrimeagen (Netflix engineer) has millions of YouTube views teaching Neovim. This isn't nostalgia, it's pragmatism.

Why learn Vim in 2026?

Let me give you pragmatic reasons, not nostalgic ones:

1. Editing speed (productivity multiplier)

Once you master Vim, editing code is like thinking at the speed of your fingers. There's no friction between "I want to change this" and "I've changed it".

Real example: refactoring 20 function calls in a file.

VS Code: Search, Cmd+D for each match, edit (2 minutes, carefully)
Vim: :%s/oldFunc/newFunc/gc (10 seconds, with visual confirmation)

2. Ergonomics and health

As a programmer, you'll spend 30,000+ hours of your life editing code. Do you want to spend them moving your hand to the mouse 500 times a day?

Vim keeps you on the home row (asdfghjkl). Less movement = less fatigue = less risk of repetitive strain injuries.

3. Works in ANY environment

SSH to a production server without a graphical interface. Does your VS Code work there? No.

Vim is everywhere: Linux servers, Docker containers, Raspberry Pi, your Mac, your Windows PC... Learn once, use everywhere.

4. Composability with the terminal

Vim isn't just an editor. It's part of the Unix philosophy:

# View only lines with "error" from a file
vim +'g/error/p' file.log

# Sort lines alphabetically from Vim
:%!sort

# Format JSON
:%!jq .

Vim integrates with grep, sed, awk, git, tmux... It's part of an ecosystem.

5. Once you learn it, it's for life

VS Code shortcuts change with each version. Plugins break. Configuration becomes obsolete.

Vim is 30 years old and the commands are still the same. What you learn now will work in 2030, 2040, 2050... Learn Vim once, use it forever.

Real-world use cases

Web development (React, Vue, Svelte)

LSP for TypeScript, autocompletion, linting with ESLint, formatting with Prettier, Git integration, Node.js debugger. All from Neovim.

Backend (Python, Go, Rust)

LSP for each language, testing with pytest/go test, DAP for debugging, integration with Docker/Kubernetes.

Data Science

Jupyter notebooks inside Neovim (Jupytext), Pandas, NumPy with autocompletion, graph visualization.

DevOps / SRE

Edit files on remote servers, Bash scripts, YAML/JSON configurations, IaC with Terraform.

Technical writing

Markdown with preview, spell checking, grammar, Pandoc integration to generate PDFs.

Vim vs modern editors (2026)

Feature	Vim/Neovim	VS Code	IntelliJ
Editing speed	⚡⚡⚡⚡⚡	⚡⚡⚡	⚡⚡⚡
RAM consumption	50MB	500MB+	1GB+
LSP / Autocompletion	✅ Native	✅ Native	✅ Native
Customization	⚡⚡⚡⚡⚡	⚡⚡⚡⚡	⚡⚡
Learning curve	Steep	Gentle	Gentle
Remote environments (SSH)	⚡⚡⚡⚡⚡	⚡ (limited)	❌
Ergonomics (no mouse)	⚡⚡⚡⚡⚡	⚡ (with extensions)	⚡
Plugin ecosystem	⚡⚡⚡⚡⚡	⚡⚡⚡⚡⚡	⚡⚡⚡⚡
Free and open source	✅	✅	❌ (Community yes)
Config stability	⚡⚡⚡⚡⚡	⚡⚡⚡	⚡⚡⚡⚡

Verdict: Vim isn't "better" at everything, but for pure text and code editing, it has no rival. For giant projects with many integrated tools, IntelliJ shines. VS Code is the accessible middle ground.

Many professionals use Neovim for quick editing + IntelliJ/VS Code for complex debugging. Or simply Neovim + extensions for everything.

Is Vim for you?

Vim is for you if:

✅ You spend 4+ hours a day editing code
✅ You want to be more efficient long-term (even if it hurts at first)
✅ You like optimizing your tools
✅ You work with remote servers or Docker
✅ You want a tool that lasts decades

Vim is NOT for you if:

❌ You only code occasionally (1-2 hours a week)
❌ You don't have patience for 1-2 weeks of initial discomfort
❌ You only work on visual projects (UI/UX design, not code)
❌ You need immediate results without time investment

Next steps

In the next lesson we'll install Neovim + LazyVim on your system. LazyVim is a pre-made configuration that gives you a modern IDE in 5 minutes, without needing to configure anything manually.

Then we'll learn to survive in Vim: how to open files, move around, edit, save, and exit (yes, the famous :q that became a meme).

In just 3-4 lessons you'll already be editing real code. And in 2 weeks, you'll be faster than with your current editor. I promise.

Key concepts from this lesson

Vim is a modal editor (1991), Neovim is its modern fork (2014)
Modal editing separates navigation (Normal) from typing (Insert) from selection (Visual)
Vim has a composable language: operators + motions = infinite combinations
They're not shortcuts, it's grammar: di" (delete inside quotes) is obvious if you know the syntax
Vim is NOT "old-school": with LazyVim you have LSP, fuzzy finder, debugger, Git integration... a complete IDE
The learning curve is real, but the investment is worth it if you spend hours editing code
Vim is portable (works on servers), efficient (50MB RAM), ergonomic (no mouse needed)

Ready to install Neovim and enter the Matrix? See you in the next lesson.

Never stop coding!

Advanced branching in Git

Javi Palacios — Mon, 15 Jun 2026 10:32:47 +0000

You've already seen in previous tutorials how to create branches, switch between them, and do basic merges. Now it's time to go deeper: we'll look at the different merge strategies Git has, how to manage branches efficiently, and some special situations you'll encounter sooner or later.

Fast-forward vs non-fast-forward merges

When you merge one branch into another, Git has to decide how to do it. The simplest way is the fast-forward merge.

Fast-forward merge

Imagine you create a feature branch from master, make some commits on feature, but master hasn't moved since then. When you go back to master and merge feature, Git simply moves the master pointer to the last commit of feature:

git checkout master
git merge feature

Updating f7c5eba..e02c63c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

The Fast-forward message tells you that no merge commit was created: the pointer was just moved. The history remains linear, as if you'd never used branches.

Non-fast-forward merge (merge commit)

But if master has moved forward while you worked on feature, Git can't do a fast-forward. It has to create a merge commit that joins both lines of development:

git merge feature

Merge made by the 'recursive' strategy.
 about.html | 10 ++++++++++
 1 file changed, 10 insertions(+)

This merge commit has two parents: the last commit of master and the last of feature. The history is no longer linear.

Force a merge commit (--no-ff)

Sometimes you want to create a merge commit even though Git could do a fast-forward. This is useful for keeping an explicit record that there was a branch:

git merge --no-ff feature

This makes it clear in the history that feature was a separate branch, even if master hadn't moved forward. It's common in workflows where you want to document each feature.

Force fast-forward (--ff-only)

Conversely, you can make Git only merge if a fast-forward is possible. If it's not, the command fails:

git merge --ff-only feature

If master has moved forward, you'll see an error. This forces you to rebase before merging, keeping the history linear.

Merge strategies

Git has several strategies for merging branches. Most of the time you don't have to worry about this (Git chooses the best one), but it's good to know they exist.

recursive (default)

This is the strategy Git uses in most cases. It can handle complex scenarios where there are many changes in both branches.

ours and theirs

When there are conflicts, you can tell Git to always prefer one version:

# Always prefer changes from the current branch
git merge -X ours feature

# Always prefer changes from the branch you're merging
git merge -X theirs feature

This is useful when you know beforehand which version you want to keep in case of conflict.

Branch management with git branch

The git branch command isn't just for creating branches. It has many options for managing them.

List branches

Without arguments, it lists all local branches:

git branch

  feature
* master
  bugfix

The asterisk (*) indicates which branch you're currently on.

To also see remote branches:

git branch -a

  feature
* master
  bugfix
  remotes/origin/master
  remotes/origin/develop

Rename a branch

If you make a mistake with a branch name (or decide to change it), use -m:

git branch -m old-name new-name

If you're on the branch you want to rename, just use:

git branch -m new-name

Delete a branch

Once you've merged a branch, you probably don't need it anymore. To delete it:

git branch -d feature

Git will warn you if the branch hasn't been merged yet. If you're sure you want to delete it anyway:

git branch -D feature

The capital -D forces deletion even if there's unmerged work.

See merged branches

To know which branches have already been merged into the current branch:

git branch --merged

And to see those that haven't been merged yet:

git branch --no-merged

This is useful for cleaning up old branches.

git switch: the modern alternative to checkout

Since Git 2.23 (2019) there's git switch, a command designed specifically for switching branches. Previously git checkout was used for everything, but that was confusing because checkout does too many different things.

Switch branches

git switch master
git switch feature

It's clearer than git checkout because switch is only for changing branches, nothing else.

Create and switch to a new branch

git switch -c new-branch

Equivalent to the old git checkout -b new-branch.

Go back to the previous branch

git switch -

The dash (-) takes you to the branch you were on before. Very useful for going back and forth between two branches.

Should I use switch or checkout?

If your Git version is 2.23 or higher (which it should be), use git switch to change branches. Reserve git checkout for recovering files (or even better, use git restore for that).

It's more semantic and avoids confusion. Old tutorials will continue using checkout, but switch is the way forward.

Detached HEAD: what it is and how to get out

Every now and then Git will tell you you're in a detached HEAD state. It sounds alarming, but don't worry: it's a perfectly valid situation (though a bit special).

What is detached HEAD?

Normally, HEAD points to a branch (for example, master), and that branch points to a commit. When you make a new commit, the branch automatically advances.

But if you checkout a specific commit instead of a branch, HEAD points directly to the commit, not to any branch. That's detached HEAD.

git checkout e02c63c

Note: switching to 'e02c63c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

When does it happen?

When you checkout a specific commit (not a branch)
When you checkout a tag
When you rebase interactively and Git temporarily places you on old commits

Is it dangerous?

No, but be careful: if you make commits in this state and then switch branches without saving those commits to a branch, they'll be orphaned and eventually Git will delete them (though with reflog you can recover them).

How to get out

Option 1: Simply go back to a branch

git switch master

Any commits you made in detached HEAD will be lost (unless you save them with reflog).

Option 2: Create a branch from there

If you made changes you want to keep:

git switch -c new-experiment-branch

Now those commits are on new-experiment-branch and you can merge it wherever you want.

Practical cases

Maintaining a linear history

If you prefer a history without merge commits:

Before merging feature into master, rebase:

   git checkout feature
   git rebase master

Then merge with fast-forward:

   git checkout master
   git merge --ff-only feature

This keeps the history completely linear.

Cleaning up old branches

To delete all branches that have already been merged:

git branch --merged | grep -v "\*" | xargs git branch -d

This lists merged branches, excludes the current one (grep -v "\*"), and deletes them all.

Recovering an accidentally deleted branch

If you deleted a branch and then regretted it, you can recover it with reflog:

git reflog

Find the commit where the branch was before deletion, and create a new branch there:

git branch recovered-branch <commit-hash>

With what you've learned in this tutorial you now have advanced mastery of branches in Git. You know how to merge in different ways, manage branches efficiently with git branch and git switch, and even how to get out of a detached HEAD without losing work.

In the next tutorial we'll look at git stash, an essential tool for when you need to quickly change context without committing half-finished changes.

Never stop coding!

Variables and data types in Python

Javi Palacios — Sun, 14 Jun 2026 18:07:26 +0000

In the previous lessons you already know what Python is, you have your environment set up, and you've written your first program with print(). Now it's time to take the next step: learn to store and manipulate information.

Imagine you're writing a video game. You need to save the player's score, their name, whether they have lives remaining... That's what variables are for: containers where you store information that can change while your program runs.

What is a variable?

A variable is a name you give to a piece of data so you can use it later. Think of it as a labeled box where you store something.

name = "Ana"
age = 25
score = 1500

You just created three variables:

name contains the text "Ana"
age contains the number 25
score contains the number 1500

Creating a variable

In Python, creating a variable is as simple as writing a name, the = sign, and the value you want to store:

message = "Hello, world"

You don't need to declare the data type (like in other languages). Python is smart enough to know that "Hello, world" is text.

Using a variable

Once created, you can use the variable by writing its name:

name = "Carlos"
print(name)  # Prints: Carlos

age = 30
print(age)   # Prints: 30

You can also use variables inside operations:

price = 50
discount = 10
total = price - discount
print(total)  # Prints: 40

Variables can change

That's where the name comes from: they're variable. You can change their value at any time:

counter = 0
print(counter)  # Prints: 0

counter = 1
print(counter)  # Prints: 1

counter = 100
print(counter)  # Prints: 100

Rules for naming variables

Python has some strict rules (and others that are good practices):

Mandatory rules

Only letters, numbers, and underscores: You can't use spaces or special symbols

   full_name = "Ana Garcia"  # ✅ Correct
   full-name = "Ana Garcia"  # ❌ Error
   full name = "Ana Garcia"  # ❌ Error

Can't start with a number

   age1 = 25      # ✅ Correct
   1age = 25      # ❌ Error

You can't use Python reserved words (if, for, while, def, etc.)

   for = 5         # ❌ Error (for is a reserved word)
   my_for = 5      # ✅ Correct

Good practices (conventions)

Use snake_case: lowercase words separated by underscores

   user_name = "Ana"      # ✅ Preferred in Python
   userName = "Ana"       # ❌ Works but not pythonic
   UserName = "Ana"       # ❌ This is reserved for classes

Descriptive names: make it clear what the variable contains

   user_age = 25           # ✅ Clear
   a = 25                  # ❌ What is "a"?

   discounted_price = 45   # ✅ Descriptive
   dp = 45                 # ❌ Too short

In English (recommended): facilitates international collaboration

   user_age = 25           # ✅ Recommended

Basic data types

When you create a variable, Python automatically assigns it a data type depending on the value you give it. The three most important types to start with are:

1. Integers (int)

Numbers without decimals. Used for counting, indexes, ages, scores...

age = 25
players = 4
year = 2026
temperature = -5

You can do mathematical operations with them:

sum = 10 + 5        # 15
subtraction = 10 - 5       # 5
multiplication = 10 * 5    # 50
division = 10 / 5    # 2.0 (note: result is float)
floor_division = 10 // 3  # 3 (integer division, discards decimals)
remainder = 10 % 3       # 1 (remainder of division)
power = 2 ** 3    # 8 (2 to the power of 3)

2. Floating point numbers (float)

Numbers with decimals. Used for measurements, prices, percentages...

price = 19.99
temperature = 36.5
percentage = 0.15

Important: In Python you use the dot (.) as decimal separator, not the comma:

price = 19.99   # ✅ Correct
price = 19,99   # ❌ This creates a tuple, not a number

Operations with floats:

total = 10.5 + 2.3   # 12.8
half = 10.0 / 2      # 5.0

When you mix int and float, the result is always float:

result = 10 + 2.5    # 12.5 (float)

3. Text strings (str)

Any text goes between quotes. You can use single quotes '...' or double quotes "...", it doesn't matter:

name = "Ana"
surname = 'Garcia'
message = "Hello, world"

Tip: Use double quotes by default. Only use single quotes when you need double quotes inside the text:

phrase = 'She said: "Hello"'

Concatenating strings

You can join texts with the + operator:

name = "Ana"
surname = "Garcia"
full_name = name + " " + surname
print(full_name)  # Ana Garcia

f-strings: the modern way to format text

Since Python 3.6 there's a much more comfortable way to include variables inside text: f-strings (formatted strings). Put an f before the quotes and write the variables inside {}:

name = "Carlos"
age = 30

# Old way (works but ugly)
message = "Hello, my name is " + name + " and I am " + str(age) + " years old"

# Modern way with f-strings (much better!)
message = f"Hello, my name is {name} and I am {age} years old"
print(message)  # Hello, my name is Carlos and I am 30 years old

You can do operations inside the curly braces:

price = 100
discount = 20
print(f"Final price: {price - discount} euros")  # Final price: 80 euros

4. Booleans (bool)

Can only have two values: True (true) or False (false). Used for conditions, decisions, states...

is_adult = True
has_won = False
has_discount = True

Important: True and False start with a capital letter. It's mandatory:

active = True    # ✅ Correct
active = true    # ❌ Error (NameError)

Booleans usually come from comparisons:

age = 25
is_adult = age >= 18    # True

temperature = 15
is_cold = temperature < 20    # True

points = 100
has_won = points >= 150       # False

Checking the type of a variable

If you're not sure of a variable's data type, use type():

name = "Ana"
print(type(name))    # <class 'str'>

age = 25
print(type(age))      # <class 'int'>

price = 19.99
print(type(price))    # <class 'float'>

active = True
print(type(active))    # <class 'bool'>

This is especially useful when debugging code and you want to understand what's happening.

Converting between types

Sometimes you need to convert one data type to another. Python has functions for that:

str() — Convert to text

age = 25
age_text = str(age)
print("I am " + age_text + " years old")  # I am 25 years old

Or better with f-strings (which does the conversion automatically):

age = 25
print(f"I am {age} years old")  # I am 25 years old

int() — Convert to integer

price_text = "100"
price = int(price_text)
print(price + 50)  # 150

⚠️ Careful: If you try to convert something that isn't a number, Python will throw an error:

number = int("abc")  # ValueError: invalid literal for int()

float() — Convert to decimal

price_text = "19.99"
price = float(price_text)
print(price)  # 19.99

bool() — Convert to boolean

number = 5
is_true = bool(number)
print(is_true)  # True

Important rule: In Python, 0, "" (empty string), None, empty lists [] and empty dictionaries {} are considered False. Everything else is True:

bool(0)      # False
bool(1)      # True
bool(-5)     # True
bool("")     # False
bool("Hi")   # True

Practical exercise

Open your REPL (type python in the terminal) and try this step by step:

# 1. Create variables with personal information
>>> name = "Your Name"
>>> age = 25
>>> height = 1.75  # in meters
>>> student = True

# 2. Display the information
>>> print(f"Name: {name}")
>>> print(f"Age: {age} years")
>>> print(f"Height: {height} meters")
>>> print(f"Is a student? {student}")

# 3. Do calculations
>>> birth_year = 2026 - age
>>> print(f"Approximate birth year: {birth_year}")

# 4. Check types
>>> print(type(name))
>>> print(type(age))
>>> print(type(height))
>>> print(type(student))

# 5. Convert data
>>> age_text = str(age)
>>> print("I am " + age_text + " years old")

# 6. Experiment with operations
>>> discount = 20
>>> original_price = 100
>>> final_price = original_price - (original_price * discount / 100)
>>> print(f"Original price: {original_price}€")
>>> print(f"Discount: {discount}%")
>>> print(f"Final price: {final_price}€")

Key concepts from this lesson

Variables are named containers for storing data
Use snake_case and descriptive names for your variables
Basic data types are: int, float, str, bool
f-strings (f"Text {variable}") are the modern way to format text
Use type() to check a variable's type
You can convert types with int(), float(), str(), bool()

Next steps

In the next lesson we'll learn about operators and expressions: how to do more complex calculations, compare values, and combine conditions. It's the foundation for making decisions in your code.

💡 Challenge: Create a program in a file calculator.py that:

Stores two numbers in variables
Calculates sum, subtraction, multiplication, and division
Displays the results with f-strings in a clear way

Example output:

Number 1: 10
Number 2: 3
Sum: 13
Subtraction: 7
Multiplication: 30
Division: 3.33

Never stop coding!

Getting started with Git branches (II)

Javi Palacios — Fri, 12 Jun 2026 06:17:59 +0000

In the last article of this series we were explaining about Git branches, how useful they are and a theorical case of Git Branches, but now it's time to play with them in a real case scenario.

Now our index.html is less stormy (Crazy, yeah!) and it has grown in structure.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Our wonderful Git tutorial</title>
    <link rel="stylesheet" href="css.css" />
  </head>
  <body>
    <header class="header">
      <h1>My Website</h1>
    </header>
    <section class="main">
      <h2>Getting started with Git</h2>
      <p>Would you like to get ninja level in Git? Stay tuned to our course!</p>
      <p>
        But if you aren't interested in this course, we recommend you to stay tuned to updates too because we'll be
        adding posts about other different topics with no relation to this type of courses.
      </p>
    </section>
  </body>
</html>

And we have an CSS (StyleSheet) as well!

html,
body,
h1 {
  margin: 0;
  padding: 0;
}

.header {
  padding: 10px;
  font-size: 1.5em;
  text-align: center;
  background-color: #000;
  color: #fff;
}

.main {
  width: 90%;
  margin: auto;
}

Coding this is time consuming and we spent 7 hours polishing our code and creating a new design (CSS), now, for our surprise, our customer call us to complain about the size of the font on the current site, as he thinks is too small for his taste. And what's the problem? Well, maybe you don't want to show your new design just yet, but still want to make him happy and not loosing your current progress.

We should learned by now that we have to use two branches for these changes, as easy as git checkout -b header-feature master

A quick explanation for what we just did, the command we used is to clone the current master branch and create a new one named header-feature or if you like doing it one by one there you go.

$ git branch header-feature master
$ git checkout header-feature

With master in the command we are telling Git that we want to clone the repository to make a new one from it, if we use the same command but using different values, let's say git checkout -b whatever header-feature, whatever would be copied from header-feature and not from master.

The output for our last command would be:

M       index.html
Switched to a new branch 'header-feature'

And now if we try our beloved git status

On branch header-feature
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        css.css

no changes added to commit (use "git add" and/or "git commit -a")

Git let's us now index.html was modified and a new file named css.css was created as well.
Easy to fix with git add . && git commit -m "Fancy new header with 10000 man hours work"

[header-feature c7a9e08] Fancy new header with 10000 man hours work
 2 files changed, 28 insertions(+), 5 deletions(-)
 create mode 100644 css.css

And now if we do a git checkout master we have our site as before we modified anything. Let's do the changes our client requested. Now we know what to do: git checkout -b changing-font-size master

And this is what our index.html looks like now:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Our wonderful Git tutorial</title>
    <link rel="stylesheet" href="css.css" />
  </head>
  <body>
    <section class="main">
      <h1>Getting started with Git</h1>
      <p>Would you like to get ninja level in Git? Stay tuned to our course!</p>
      <p>
        But if you aren't interested in this course, we recommend you to stay tuned to updates too because we'll be
        adding posts about other different topics with no relation to this type of courses
      </p>
    </section>
  </body>
</html>

And our css.css

.main {
  font-size: 1.2em;
}

With something this easy, we make our client happy. Now let's save it with git add . && git commit -m "Changing the font-size of our website"

[changing-font-size 71e3aef] Changing the font-size of our website
 2 files changed, 11 insertions(+), 5 deletions(-)
 create mode 100644 css.css

Everything we changed is on changing-font-size, if we move to master we will have our initial website and now that our customer told us he was happy as a rainbow with the font size, we merge those changes from changing-font-size to master.

$ git checkout master
$ git merge changing-font-size

Updating 497f0c9..71e3aef
Fast-forward
 css.css    |  3 +++
 index.html | 13 ++++++++-----
 2 files changed, 11 insertions(+), 5 deletions(-)
 create mode 100644 css.css

With merge we combine the changes from both repositories, in Fast-forward mode, the most common merging branches method, Git detects the changes doesn't make any conflict and combine them perfectly. We have the changes from changing-font-size in master but still we have to merge those changes to header-feature. Sometimes it can happen (It really does...) we forget what branches we have… don't worry! simply type: git branch

  changing-font-size
  header-feature
* master

As you can see (or read… anyway…), Git gives us a list of all the branches we currently have and on top of that marks with an asterisk which branch is active. Let's do this!

$ git checkout header-feature
$ git merge changing-font-size

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Auto-merging css.css
CONFLICT (add/add): Merge conflict in css.css
Automatic merge failed; fix conflicts and then commit the result.

Jesus Christ… We broke it… What happened? Git detects the files from one branch to the other conflicts between them but Git is a professional tool and knows how guide us on fixing it. Our index.html looks like:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <meta http-equiv="X-UA-Compatible" content="ie=edge">
        <title>Our wonderful Git tutorial</title>
        <link rel="stylesheet" href="css.css" />
    </head>
    <body>
<<<<<<< HEAD
        <header class="header">
            <h1>My Website</h1>
        </header>
        <section class="main">
            <h2>Getting started with Git</h2>
            <p>Would you like to get ninja level in Git? Stay tuned to our course!</p>
            <p>But if you aren't interested in this course, we recommend you to
            stay tuned to updates too because we'll be adding posts about other
            different topics with no relation to this type of courses.</p>
=======
        <section class="main">
            <h1>Getting started with Git</h1>
            <p>Would you like to get ninja level in Git? Stay tuned to our course!</p>
            <p>But if you aren't interested in this course, we recommend you to
            stay tuned to updates too because we'll be adding posts about other
            different topics with no relation to this type of courses</p>
>>>>>>> changing-font-size
        </section>
    </body>
</html>

As you can see, Git indicates us where the conflict between the files is coming from. With small work, we fix our file and give it this look:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Our wonderful Git tutorial</title>
    <link rel="stylesheet" href="css.css" />
  </head>
  <body>
    <header class="header">
      <h1>My Website</h1>
    </header>
    <section class="main">
      <h2>Getting started with Git</h2>
      <p>Would you like to get ninja level in Git? Stay tuned to our course!</p>
      <p>
        But if you aren't interested in this course, we recommend you to stay tuned to updates too because we'll be
        adding posts about other different topics with no relation to this type of courses.
      </p>
    </section>
  </body>
</html>

And our CSS file:

<<<<<<< HEAD
html, body, h1 {
    margin: 0;
    padding: 0;
}

.header {
    padding: 10px;
    font-size: 1.5em;
    text-align: center;
    background-color: #000;
    color: #fff;
}

.main {
    width: 90%;
    margin: auto;
=======
.main {
    font-size: 1.2em;
>>>>>>> changing-font-size
}

With some small work:

html,
body,
h1 {
  margin: 0;
  padding: 0;
}

.header {
  padding: 10px;
  font-size: 1.5em;
  text-align: center;
  background-color: #000;
  color: #fff;
}

.main {
  width: 90%;
  margin: auto;
  font-size: 1.2em;
}

We just need to save the changes with git add . and this time, as we are merging two branches, if we don't write any commit message, Git adds automatically Merge branch 'changing-font-size' into header-feature with a simple git commit

[header-feature 44e74a6] Merge branch 'changing-font-size' into header-feature

As the already know to apply our fancy header to the branch master just:

$ git checkout master
$ git merge header-feature

Updating 71e3aef..44e74a6
Fast-forward
 css.css    | 15 +++++++++++++++
 index.html | 11 +++++++----
 2 files changed, 22 insertions(+), 4 deletions(-)

This time, spotless, no problem at all, common merge in Fast-forward mode. And now, we don't need to look like a cheapskater and keep useless things with us! Let's delete useless branches from our project.

$ git branch -d changing-font-size
$ git branch -d header-feature

Deleted branch changing-font-size (was 71e3aef).
Deleted branch header-feature (was 44e74a6).

I hope your need for knowledge of Git branches is fulfilled!

Never stop programming!