diff --git a/en/content/git-and-github/20200110_comic-stage-commit-push.md b/en/content/git-and-github/20200110_comic-stage-commit-push.md
new file mode 100644
index 0000000..645f589
--- /dev/null
+++ b/en/content/git-and-github/20200110_comic-stage-commit-push.md
@@ -0,0 +1,22 @@
+---
+title: Stage! Commit! Push! A Git story (for beginners) - comic
+published: true
+description: A comic about Git basics
+tags: git, beginners
+cover_image: https://res.cloudinary.com/practicaldev/image/fetch/s--canYLMBK--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/jr4fyx4uqh3v0oreou2a.png
+---
+
+_Originally published on [Dev.to](https://dev.to/erikaheidi/stage-commit-push-a-git-story-comic-a37)._
+
+When we're getting started with Git, it can be difficult to understand where our files live, how they change state, and when exactly they leave our local machine to reach the external repository.
+
+I have an analogy for that:
+
+![Stage! Commit! Push! A Git Story - comic about Git basics](https://cdn.erikaheidi.com/blog/stage-commit-push.jpeg)
+
+In practice:
+
+1. Work on your postcard (implement your changes).
+2. Put it on the "staged" pocket when you're ready to commit (git add).
+3. Stamp the postcard (git commit). 
+4. When you're ready, put the postcard in the mailbox (git push).
diff --git a/en/content/git-and-github/20200117_understanding-git-branches.md b/en/content/git-and-github/20200117_understanding-git-branches.md
new file mode 100644
index 0000000..ea42d2b
--- /dev/null
+++ b/en/content/git-and-github/20200117_understanding-git-branches.md
@@ -0,0 +1,34 @@
+---
+title: Understanding Git Branches (Illustrated)
+published: true
+description: When multiple developers need to work in the same Git repository, it is important to define a process that allows collaboration. That's when branches become essential. 
+tags: git, beginners, illustrated, comics
+series: Git Illustrated
+cover_image: https://thepracticaldev.s3.amazonaws.com/i/ban08i3ij12b7zv7ad1e.jpg
+---
+
+_Originally published on [Dev.to](https://dev.to/erikaheidi/understanding-git-branches-illustrated-ggh)._
+
+In a [previous post](https://dev.to/erikaheidi/stage-commit-push-a-git-story-comic-a37), we talked about the process of submitting changes to a remote Git repository. We've seen that this process is done in three steps: 1) stage. 2) commit. 3) push.
+
+In a small project with a solo contributor, it's not uncommon that these changes are pushed directly into `master`. But when multiple developers need to work in the same Git repository, it is important to define a process that leverages parallel collaboration. That's when **branches** become essential.
+
+![Git Tree Illustration](https://thepracticaldev.s3.amazonaws.com/i/7ph91rcm4nkmna10eqmb.jpg)
+
+>Not all trees are the same, but they all start small. In a typical Git repository, code grows as a tree. Features are implemented in development branches that are eventually **merged** into a **master** branch.
+
+Whenever working on a team, whether if it's in an open source project or a corporate setting, it's always a good practice to create a new branch (usually based on `master`) and start from there.
+
+Once you're finished with your changes, you can then push your branch to the remote repository and create a new **pull request**. A **pull request** is a formal request for merging your branch into `master`.
+
+![Pull Request Mando and Baby Yoda](https://thepracticaldev.s3.amazonaws.com/i/26ehw0t3trfmuc4jlmw8.jpg)
+
+> Although it is possible to push and merge a branch directly into "master", creating a pull request is usually the way to go when suggesting changes in a codebase.
+
+Opening a pull request creates an opportunity for code review and actionable feedback; that's why it became a standard procedure for collaborating in most open source projects.
+
+---
+
+For a more in-depth understanding of Git branches, please check [these docs](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) or have a look at this [quick reference guide](https://dev.to/digitalocean/how-to-use-git-a-reference-guide-6b6).
+
+Any Git topic you'd like to understand better? Leave your suggestion for my next comic in the comments :)
diff --git a/en/content/git-and-github/20200124_pick-squash-drop-rebase.md b/en/content/git-and-github/20200124_pick-squash-drop-rebase.md
new file mode 100644
index 0000000..8e05f57
--- /dev/null
+++ b/en/content/git-and-github/20200124_pick-squash-drop-rebase.md
@@ -0,0 +1,30 @@
+---
+title: Pick. Squash. Drop. Rebase! (Comic)
+published: true
+description: It is a common practice to use `git rebase` to squash commits before creating or merging a pull request; nobody needs to see that you fixed 10 typos in 5 separate commits, and keeping that history is of no use. So how does a rebase look like?
+series: Git Illustrated
+tags: git, beginners, illustrated, comics
+cover_image: https://thepracticaldev.s3.amazonaws.com/i/mipao0n3oqno93o22s7f.png
+---
+
+_Originally published on [Dev.to](https://dev.to/erikaheidi/pick-squash-drop-rebase-comic-607)._
+
+[Git Rebase](https://git-scm.com/docs/git-rebase) allows us to rewrite Git history. It is a common practice to use `git rebase` to squash commits before creating or merging a pull request; nobody needs to see that you fixed 10 typos in 5 separate commits, and keeping that history is of no use. So how does a rebase look like?
+
+![Git Rebase Comic](https://thepracticaldev.s3.amazonaws.com/i/fbah0r4533nv72y2wgiz.png)
+
+Let's imagine you have your deck of cards, they are ordered in a certain way that cannot be changed. Each card represents a commit in a project's branch.
+
+When running an interactive rebase with `rebase -i`, there are mainly three actions we may want to perform in a commit (card):
+
+- **p**ick: pick a commit.
+- **s**quash: squash this commit into the previous one.
+- **d**rop: drop this commit altogether.
+
+In this game, you want to **s**quash cards together into doubles and triples. Some cards make sense on their own, so you will **p**ick them. Sometimes, a card should not even be there, so you might want to **d**rop it.
+
+Although there are other ways of using `git rebase`, the interactive rebase used like this is a common practice observed in projects that rely on multiple contributors, both in open as well as in closed source. It enables you to commit earlier and with more frequency, because you are able to edit your history before submitting your pull request.
+
+If you'd like a deeper introduction to Git Rebase, please check this great dev article from [@maxwell_dev](https://dev.to/maxwell_dev):
+
+{% post https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had %} 
diff --git a/en/content/git-and-github/_index b/en/content/git-and-github/_index
new file mode 100644
index 0000000..5bfab03
--- /dev/null
+++ b/en/content/git-and-github/_index
@@ -0,0 +1,5 @@
+---
+title: Git and GitHub
+description: Resources for learning Git and GitHub
+index: 5
+---
diff --git a/en/content/php/_index b/en/content/php/_index
index 1bf0525..9ffacc0 100644
--- a/en/content/php/_index
+++ b/en/content/php/_index
@@ -1,5 +1,5 @@
 ---
 title: PHP
 description: Software development with PHP
-index: 1
+index: 2
 ---
diff --git a/en/content/php/20240311_setting-up-obsidian-for-content-planning-and-project-management.md b/en/content/productivity/20240311_setting-up-obsidian-for-content-planning-and-project-management.md
similarity index 100%
rename from en/content/php/20240311_setting-up-obsidian-for-content-planning-and-project-management.md
rename to en/content/productivity/20240311_setting-up-obsidian-for-content-planning-and-project-management.md
diff --git a/en/content/productivity/_index b/en/content/productivity/_index
new file mode 100644
index 0000000..0a90dc1
--- /dev/null
+++ b/en/content/productivity/_index
@@ -0,0 +1,5 @@
+---
+title: Productivity
+description: Tips for productivity
+index: 1
+---