The three concepts that stand out to me as the most fundamental for being able to effectively work with Git at a basic level are:

1. The working directory

2. The staging area

3. The commit history

In this article, we’ll take a new approach to representing these three concepts: by visualizing them in an immersive, 3D game world!

I’ll provide a tangible, visual representation of these key Git concepts which are almost always described in an abstract and confusing way. I hope that this will make them much more intuitive for you to grasp.

Table of Contents

1. Visualize your Working Directory

2. Demystify your Staging Area

3. Literally Walk through your Commit History

4. Summary

5. Try it Yourself

Visualize your Working Directory

What does your brain picture when you think of the “working directory”? I assume it’s something like a folder structure starting at the project root, containing the code files and subfolders that make up the project.

While that is a fair description of the working directory, it is a bit hard to imagine and misses the segmentation that Git applies to your project. Although the current state of your entire project, folder structure, and code files do reside in the working directory, Git doesn’t really need to do much about that unless certain changes are detected in those files.

Git detects and reports changes to the working directory with the Git status command, which shows output like this:

Jack@RAPTOR ~/my-project (main)> git status
On branch main
Your branch is up to date with 'origin/main'.

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:   main.py
        modified:   settings.py

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

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

The two relevant sections here are:

1. Changes not staged for commit: Lists existing files tracked by Git which currently contain code changes. In the example above, we see two “modified files”: main.py and settings.py.

2. Untracked files: Lists new files in your project that Git doesn’t know about yet. In the example above, we see three new, untracked files: one.py, two.py, and three.py.

When it comes to understanding Git, thinking of the working directory as the changes Git sees in these two sections – Untracked files and Modified files – is quite helpful.

But the git status command reports these details in the terminal in a purely text-based way, which doesn’t do newer Git users any favors when it comes to wrapping their heads around Git.

Some Git GUI’s do a better job with this (they do provide a safer point-and-click interface, after all), but in my experience, none of them make things obvious at a glance.

Instead, imagine that as a new Git user, you saw this:

A nice big wall with clearly delineated sections for Untracked files and Modified files. Files corresponding to each section are represented as blocks on the wall within that section, clearly labelled with their filename.

More specifically, the blocks representing files one.py, two.py, and three.py are all sitting neatly in the Untracked files section, and the blocks representing the files main.py and settings.py are in the Modified files section.

This makes it abundantly clear to even a total novice that Git is interpreting these files differently and categorizing them in a logical way. It takes the abstract Git concept of the “working directory” and transforms it into a form that almost anyone can wrap their heads around at a glance.

But something is missing here. Let’s say you run the command git add one.py. This stages the untracked file one.py to be included in the next commit. What happens to the block labelled one.py on the wall?

Demystify your Staging Area

To answer that, let’s move on to the mysterious Git “staging area”. But first, where exactly IS the staging area?

Well, technically any staged file changes are still just sitting in the working directory, which makes things a bit confusing.

Here is how Git reports this in the terminal:

Jack@RAPTOR ~/D/git-worlds (main)> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   one.py

As you can see from Git’s output, it now includes the section Changes to be committed, which includes the file one.py that was staged with the git add command.

But this is still a bit unclear. Are the staged file changes in one.py still a part of the working directory? Or does Git store them elsewhere?

Well, the answer is… BOTH:

Here you can see that we zoomed out a bit from the previous image, to reveal a third section of the wall labeled Staged files.

Since we ran the command git add one.py, you can see that the corresponding block representing the one.py file moved from the Untracked files column to the Staged files column.

This conveys quite clearly that a file sitting in the staging area is still a part of the working directory (because it is a part of the overall wall), while also being segmented into its own designated space.

From a technical perspective, Git’s staging area is just a file named index which lives in the .git/ folder. Git builds up the code changes specified by the git add command in this file, which is used as the source for those changes the next time the git commit command is run.

But from a workflow perspective, representing the staging area as a section on the “working directory wall” as in the image above makes things more intuitive to understand.

Next, let’s explore how we might visualize things once the staged changes are turned into a new Git commit and become a part of the active branch.

Literally Walk through your Commit History

What does your mind’s eye see when you think of Git’s “commit history”?

Well, the prettiest way Git does it in the terminal is by using the Git log command, such as git log --graph --all, which provides output like:

* commit 88085cff3e2d7657f26eb6479b308526df7d2bba (HEAD -> dev, origin/dev)
| Author: Jacob Stopak <jacob@initialcommit.io>
| Date:   Tue Apr 23 20:31:24 2024 -0700
|
|     Fix command as title clip, ellipses and arrow length in rebase subcommand
|
|     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
*   commit e264605ea26a808c34d4dc2fbc6dad65a8e28c5f
|\  Merge: cb3fa5f b8c071c
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Wed Mar 20 19:51:06 2024 -0700
| |
| |     Merge branch 'main' into dev
| |
* | commit cb3fa5f3bdbdcff3d9a8c844cda99d46bf64e337
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Sat Mar 9 22:00:49 2024 -0800
| |
| |     Add --staged flag to git restore subcommand
| |
| |     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
| |
| * commit b8c071cb9a1653748525aa01c2b6bafe06ed9100
|/  Author: Jacob Stopak <jacob@initialcommit.io>
|   Date:   Wed Mar 20 19:50:53 2024 -0700
|
|       Correct license specified in pyproject.toml from MIT to GNU GPLv2
|
|       Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
* commit 32a3a3fca583f6c68225b974716e74b557a1a094
| Author: Jacob Stopak <49353917+initialcommit-io@users.noreply.github.com>
| Date:   Tue Aug 22 11:31:38 2023 -0700
|
|     Update README.md

Unfortunately, this is not so pretty at all. This long, garbled list of commit IDs, names, dates, and commit messages is definitely not something most folks would consider user-friendly.

The --graph option supplied above does show the commit relationships by drawing little lines connecting each commit in the terminal, but the purely text-based nature of this is just not intuitive to most people at a glance.

Now consider the following gamified representation of Git’s commit history:

Now we’re talkin’! In this image, each Git commit is represented by a white block with a shortened 6-character commit ID.

Each white commit block points back to its parent commit with an arrow, forming very clear chains of commits that make up Git branches.

You might have noticed that some of the white commit blocks have colored blocks sitting on top of them. The green blocks are branch names, the yellow blocks are Git tags, the blue block is Git’s HEAD pointer, and the red blocks are remote-tracking branches. These are collectively referred to as Git refs.

Besides being able to easily distinguish between them, representing ref types as different colored blocks clarifies another often-confusing Git concept. In Git, branches (along with other refs types) are just “pointers” to a specific commit. It is tempting to think of a branch as a series of connected commits that share a history – and conceptually this is correct – but in Git, a branch is really just a glorified label pointing to a specific commit.

In this gamified world, you can literally walk through your commit history to see, interact with, and examine the code changes in any commit.

Summary

In this article, we explored how Git’s fundamental concepts - the working directory, staging area, and commit history - can be difficult to grasp due to their abstract nature.

To make these concepts more accessible, we introduced a gamified, visual approach that transforms them into something tangible: an immersive game world where files and commits are represented as interactive blocks.

By presenting Git this way, beginner coders, students, and developers of all experience levels can intuitively learn Git concepts and commands, and confidently apply them in professional projects.

Try it Yourself

The images in this post were captured in Devlands, the first and only gamified Git interface and tutorial, which I’m building in Python.

In Devlands, not only can you walk through your codebase… You can also learn Git concepts and commands with a character-guided tutorial, simulate and run Git commands directly in the game, see their results applied in the game world in real time, and use AI to explain code you don’t understand.

If you or someone you know is a visual learner, beginner coder, or newer Git user, consider checking it out!

Not only that, but Git commands often have nuances that lead to varying results on the state of your local repository. In addition, even once you learn a specific Git command, you might not use that command for a significant amount of time before needing it again.

This leads devs to repeatedly search Google or Stackoverflow for specific situational Git commands over and over again, praying that parallel results will occur when executing the command locally.

This commonly occurs with notoriously confusing Git commands such as git reset, git merge, and git rebase.

In this article, we'll provide an overview of these 3 commands using a command-line tool called Git-Sim to visually simulate Git operations in your local repo. This tool will enable us to easily create handy diagrams and animations illustrating how each Git command will affect the state of your own Git repo.

git reset – How to Reset Git HEAD while Managing Changes

The git reset command is one that I constantly find myself Googling before I need to use it.

This is partly because there are several commands that you can use to undo changes in Git, and I want to make sure I'm choosing the right one.

Also, any command that could accidentally lead to "losing work", like git reset --hard is worth taking a few seconds beforehand to make sure you're confident in what you're about to do.

What does git reset do?

In a nutshell, git reset simply moves the tip of the current branch back to a previous commit. In that sense it can be used to "undo" the changes applied by commits between the current commit and the commit you want to reset back to.

Technically speaking, a Git branch is just a name (or label) that points to the newest commit in a chain of commits. This gets moved forward each time you make a new commit on a branch, and therefore always identifies what is known as the branch head commit.

The git reset command moves this branch label back to a previous commit, which becomes the new branch head – effectively undoing all the changes in between.

Let's consider a simple example. Assume we have a repository which only tracks 1 file called cheese.txt. The repo has 5 commits, each changing the text content within the file to a different cheese name.

We can illustrate this visually using Git-Sim by running the $ git-sim log command to visually simulate the output of the $ git log command:

Note: we actually simulated this git log output using the git-sim command $ git-sim log, which draws 5 commits in the output image by default.

As you can see, we have a main branch pointing to the commit with ID 14c121... with commit message Cheddar.

Now let's say we want to undo the commits changing the content of cheese.txt to "cheddar" and "Swiss". We can do this using the git reset command to reset the main branch back 2 commits, to "Gouda":

$ git reset HEAD~2

But if we are ever unsure about the impact this command will have, we can simulate it first using Git-Sim:

$ git-sim reset HEAD~2

Or if you prefer, the simulation can be rendered as a dynamic video animation using Git-Sim's --animate flag as follows:

$ git-sim --animate reset HEAD~2

As you can see, the Git-Sim simulated output above shows that the main branch and HEAD pointer are reset backward 2 commits to the "Gouda" commit.

In addition, we can see that Git-Sim created a table with 3 columns:

• Changes deleted from

• Working directory modifications

• Staging area

By default, the git reset command applies the --mixed flag behavior, which moves any changes in reset commits into the working directory.

Git-Sim reflects this in the simulated output above by adding the file cheese.txt into the Working directory modifications column.

Now that you've simulated the git reset command using Git-Sim and can clearly see the expected result in the image output above, you can run the actual Git command $ git reset HEAD~2 with confidence.

In addition to --mixed, Git-Sim understands --soft and --hard resets. The command $ git-sim reset --soft HEAD~2 would keep the undone changes in the Staging area column, while the command $ git-sim reset --hard HEAD~2 would place the undone changes in the Changes deleted from column since a hard reset discards changes to committed files.

Note that git reset doesn't ever delete any commits (even when using the --hard option), which means you don't lose any work at the time of executing it. But keep in mind that commits can become orphaned, meaning that certain commits become unreachable by any branch head. Git will eventually remove these via garbage collection, but they are retrievable for a while if you need them!

git merge – How to Merge Changes from Multiple Branches

The git merge command is another tricky one for beginner and intermediate Git users to wrap their heads around. There are several different types of merges that Git performs depending on the circumstances.

To provide a foundation, this sequence of two commands highlights how the merge syntax works:

$ git checkout <merge-into>
$ git merge <merge-from>

The first command shows that the <merge-into> branch is the active branch that you currently have checked out in your working directory. Then when you execute the merge, you specify <merge-from> as the branch that you want to merge changes from, into the active branch.

So for example, the following commands would merge changes from the dev branch into main:

$ git checkout main
$ git merge dev

Git three-way merge

The most common merge case occurs when the history of two branches has diverged and the developer wishes to recombine the changes. In this scenario, Git performs something known as a three-way merge.

It is called a three-way merge because Git uses three commits to determine how to combine changes in your diverged branches:

• The commit at the tip of branch A

• The commit at the tip of branch B

• The merge-base of the two branches

We can use Git-Sim to simulate a three-way merge which merges the changes in two new commits on the dev branch into main:

$ git checkout main
$ git-sim merge dev

Three-way merge output in Git-Sim

In the example above, the tip of the main branch before the merge is commit 14c121 ("Cheddar"), and the tip of the dev branch is f42fee ("Asiago"). The third commit used in Git's three-way merge algorithm is commit 640bb5 which is the merge base of the two branches. You can identify this by tracing back both branches until you find the first common ancestor.

Using the content in these 3 commits, Git creates a new merge commit (labelled abcdef in the Git-Sim diagram above) which combines the changes from both branches.

Unlike regular commits, a merge commit has two parents instead of one, corresponding to the tips of the two branches that were merged together. These two parent relationships are denoted by the two dotted lines in the image above.

Git fast-forward merge

A fast-forward merge in Git occurs when the branch you are merging from is just further along the same line of development as the active branch. Consider the example below:

$ git-sim log

In this case, the dev and main branches have not actually diverged – they both lie along the same line of development. As a result, if you check out the dev branch and try to merge in main, Git doesn't even need to actually need to merge the content from the two branches.

Instead, Git can simply repoint the dev branch ref to the same commit as main points to, which is 14c121. (Remember a branch in Git is just a label pointing to a particular commit).

Git-Sim knows how to simulate this type of merge as well:

$ git checkout dev
$ git-sim merge main

Fast-foward merge

Note that after checking out the dev branch and merging main into it, the dev branch label was simply fast-forwarded to the same commit as main, and no new merge commit was created.

However, in some cases you may want to force Git to create a merge commit even when doing a fast-forward merge.

This might be useful if you want to preserve the history of all merges so that your team knows when a merge was performed. You can do this using the --no-ff flag, which is also supported by Git-Sim:

$ git checkout dev
$ git-sim merge --no-ff main

Forced merge commit

In the simulated output image above, Git created a new merge commit abcdef which the dev branch label now points to, even though it was possible to simply fast-forward to the commit pointed to by main.

Keep in mind that even when forcing a merge commit in this way, no divergence of branch history has taken place. Both branches still fall along a single line of development.

git rebase – How to Move the Current Commit onto a New Base Commit

Lastly, we'll briefly cover one specific scenario of the standard git rebase command. Instead of merging the contents of two branches, git rebase <new-base> reapplies the commits reachable by the current branch onto a new base commit, specified by <new-base>.

By default, git rebase runs in standard mode, which is what we'll be discussing here. The -i flag allows rebase to run in interactive mode, but that is out of the scope of this article.

Using our previous example repo, let's note the 2 new commits added to the dev branch ead5cc ("Fontina") and f42fee ("Asiago"):

Then we want to move these 2 new commits to the tip of the main branch using the git rebase command. This can be simulated using the commands:

$ git checkout dev
$ git-sim rebase main

In the simulated output above, the dotted lines show how the 2 new commits on the dev branch are rebased onto the tip of main.

In a standard rebase, Git identifies the number of commits to rebase by walking back from the tip of the active branch until a common ancestor commit is found between the two branches.

Of course, this common ancestor already exists on the destination branch, so the rebase does not need to include it, and can end at that point.

In this case, the two commits on the dev branch that don't yet exist on main are ead5cc ("Fontina") and f42fee ("Asiago"). These get rebased onto main as shown by the dotted lines above. Since commit 640bb5 ("Gouda") already exists on main, it is not included in the rebase.

Note that rebasing in Git actually rewrites commit history, since each commit ID depends on that commit's content and the history that comes before it.

Even if the content in the two rebased commits in the example above applies cleanly to the main branch, new commit ID's must be calculated since their history now differs from when they were applied to the dev branch.

For this reason, a good rule of thumb is to only rebase commits locally that haven't yet been pushed to a remote repository. This will ensure that you and your team maintain a consistent repository state for your project over time.

Summary

In this article, we use the Git-Sim tool to provide an overview of 3 notoriously confusing Git commands – git reset, git merge, and git rebase.

We illustrated how to reset Git's HEAD pointer to a previous commit while managing committed files, staged files, and working directory files as desired using the --soft, --mixed, or --hard flags.

Then we outlined the basic merge types in Git, including the 3-way merge and the fast-forward-merge.

Finally, we discussed rebasing branches, which means moving a set of commits onto a new base commit.

For each of these commands, we showed how the Git-Sim command-line tool can be leveraged to create unique, customized simulations of your Git command's effects before running the actual Git command itself.

Next Steps

If you're a visual learner and Git user, I encourage you to try out Git-Sim to simulate Git commands in your own local repos before running the actual commands.

This will give you the confidence to execute the actual Git commands, and even provide you with visual content to aid in documentation, content-sharing, and teaching others to use Git.

Git-Sim is a free and open-source tool written in Python, so if you're interested in contributing or if you find any bugs, feel free to check out the Git-Sim project on GitHub and/or contact me at jacob@initialcommit.io!

One way to approach this in Git is to draw a graph like the one you see above.

You've probably encountered images like this when learning how to use Git.

This graph depicts a sample commit history in a Git repository.

In Git, commit history is represented as a DAG, or Directed Acyclic Graph, which is a type of network graph. Each commit is displayed as a circle and commits are chained together using arrows. Each arrow points from a child commit to its immediate parent.

For the most part, if you want one of these graphs you need to draw it yourself (manually or digitally) – which takes time and effort. Also, these graphs are static and it would be more engaging in certain cases to animate the commit progression in a video format.

For those reasons, I created Git Story, which lets you easily generate mp4 videos presenting the layout and progression of your Git commit history, all using one single command: git-story.

How to Visualize Git's Revision History

In Git, a commit is also known as a revision and represents a set of content changes made at a specific point in time by a specific person.

There are several additional components that help us visually understand our Git history.

Commit Properties

When committing in Git, human readability is important. Therefore, it's best practice to leave a clear commit message describing your change. This helps other devs viewing the commit history understand the purpose of each revision.

The commit ID is a unique identifier for each commit, generated specifically from the content of each commit. As a Git user, you've probably seen that many Git commands accept a full or partial commit ID as an argument. For that reason, having commit ID's available in Git visualizations can be very useful.

Refs: Branches, HEAD, and Tags

When visualizing Git history, it is also useful to know where you are. Git refs (short for references) help you understand how commits are organized in your Git repository.

Refs are labels that Git attaches to specific commits. Branch names, Git HEAD, and tags are all examples of refs in Git. You can think of a ref as a human-readable name that points to a specific commit.

Git Story Video Output

Git Story parses all of this information for you – commits, relationships, and refs – and animates it as a .mp4 video. The best part is that all you need to do is browse to your project in the terminal and run the command git-story.

Below is an example of a video animation generated by Git Story:

Why I Wrote Git Story in Python

I chose to write Git Story in Python since there are two very useful libraries that power this project.

GitPython

The first is called GitPython. GitPython is a Python package that provides access to data from Git repositories via a convenient set of methods. This is how Git Story accesses data from the local Git repo in order to animate it:

import git

repo = git.Repo(search_parent_directories=True)

This creates a repository object within the Python program's memory that allows access to the underlying Git objects and their properties. A list of commits can be accessed as follows:

commits = list(repo.iter_commits(REF))

# This pulls a list of commits working backwards from REF
# REF can be a branch name, tag, HEAD, or commit ID

Iterating through the list of commits allows access to the properties of each commit, which are used in the next step for generating the animation.

Manim

The second dependency is called Manim which is used to generate animated math videos using a Python API. Manim makes it easy to create Python objects that represent lines, shapes, text, and equations, and place those objects in an animated scene.

Git Story uses Manim to draw the circles, arrows, text, Git branch names, and refs that represent the portion of your Git history obtained using GitPython.

Here's how the Python code uses Manim to create a red circle for each commit:

circle = Circle(stroke_color=commitFill, fill_color=commitFill, fill_opacity=0.25)

And here's how Manim is used to create the arrows between commits:

arrow = Arrow(start=RIGHT, end=LEFT, color=self.fontColor).next_to(circle, LEFT, buff=0)

Lastly, here's how these objects are added to an animated scene:

self.play(Create(circle), Create(arrow))

How to Install Git Story

1. Install manim and manim dependencies for your OS

2. Install GitPython: $ pip3 install gitpython

3. Install git-story: $ pip3 install git-story

How to Use Git Story

1. Open a command-line terminal

2. Navigate to the root folder of your Git project using cd

3. Execute the command: git-story

Running this command will generate an mp4 video animation from the most recent 8 commits in your Git repo. The video file will be placed within the current directory at the path ./git-story_media/videos.

How to Customize Git Story's Output

Git Story includes various ways to modify the way your Git repo is represented in the output video. You do this through command-line options and flags.

To specify the number of commits to animate, use the option --commits=X, where X is the number of commits you want to show.

You may want to start animating from a specific commit besides HEAD. You can use the --commit-id=ref option to select the commit to start working backwards from. Instead of ref, you can substitute in a full or partial commit ID, branch name, or Git tag.

You can use the --reverse flag to animate the commits from newest to oldest, that is reverse-chronological order to more closely match the Git log output.

Try out the --low-quality flag to speed up the animation generation time while testing. Once you're satisfied with the way your animation looks, remove the flag and run the command again to get a final best quality version.

If you prefer a light color scheme instead of the default dark one, you can specify the --light-mode flag.

For presentation purposes, you may want to add an intro title, logo, and outro to your animation. You can do this with the following options:

$ git-story --show-intro --title "My Git Repo" --show-outro --outro-top-text "My Git Repo" --outro-bottom-text "Thanks for watching!" --logo path/to/logo.png

Use the --media-dir=path/to/output option to set the output path of the video. This is useful if you don't want extra files to be created within your project.

Finally, you may want to test out the --invert-branches flag if your Git commit history has multiple branches. This flag will flip the order in which branches are parsed, which changes the branch orientation in the output video. Some animations will look better with this flag set and some won't.

Here is a final example showing what the generated video looks like when multiple branches exist in the input commit range:

Summary

Git Story is a command-line tool that I wrote in Python to make it easy to create video animations of your Git commit history. Dependencies include Manim and GitPython.

The output video displays the desired set of commits and their relationships, along with branch names, the HEAD commit, and tags.

Git Story has a variety of command-line flags and options that allow you to customize the animation. Run the command git-story -h for the full set of available options.

Feel free to send me an email at jacob@initialcommit.io with any comments, questions, or suggestions.

Pull requests are very welcome on the Git Story GitHub page.

Thanks for reading and happy coding!

In this article, I've shared 7 questions I had when I first started learning to code about 20 years ago (man, now I feel old). And I've answered them as thoroughly as possible to help you start your coding journey.

What programming language should I learn first?

In my opinion, it doesn't really matter! There are certainly languages that are easier for beginners to pick up, such as Python, Ruby, or JavaScript. But most programming languages have a plethora of things in common, and the core concepts are usually fairly similar.

In most cases, the syntax (the keywords, structure, and semantics) of languages differ much more than the underlying concepts.

Once you know the basics of any programming language, it becomes a lot easier to pick up another one. It is also likely that the language you learn first won't be the central one you end up using at your job or side hustle.

For example, I started with Python back in the day, dabbled with JavaScript and PhP, but now use Java for my job and side hustle.

Of course, you probably don't want to start by learning some obscure and difficult language that isn't commonly used. But you really can't go wrong by starting with a popular modern language like Python, Java, Ruby, or JavaScript.

The most important part isn't what language you learn first, but that you actually start and incrementally improve your skills over time. In a nutshell, focus on mastering essential coding concepts as opposed to the syntax of a specific language.

How do we categorize programming languages?

Although most programming languages have a lot in common, there are many ways to organize languages into various categories.

These categories are used to group together languages with a particular feature or trait, although two languages with an overlapping trait might very well differ with respect to others.

Here are 5 of the most useful programming language categories for new devs to know about:

• Compiled programming languages

• Interpreted programming languages

• Statically-typed programming languages

• Dynamically-typed programming languages

• Object-oriented programming languages

Below, is a short description of each of these categories, along with a short list of languages in each one.

Compiled programming languages

A compiled language is one that uses a compiler to convert source code (the code you write yourself) into a form the computer knows how to understand (often called machine code).

Usually, the output from the compiler is saved in one or more files called executables. Executables can be packaged for sale and distribution in standard formats that make it easy for users to download, install, and run the program.

An important characteristic of the compiling process is that the source code is compiled before the program is executed by the end user. In other words, code compilation typically takes place separately from program execution.

Popular compiled languages:

• C

• C++

• Java

• Rust

• Go

Interpreted programming languages

An interpreted language is one that uses an interpreter to convert source code (the code you write yourself) into a form the computer knows how to understand.

An interpreter is a program that takes a set of source code written in a specific programming language, converts it into a form the computer can understand, and immediately executes it in real-time.

A primary difference between compiling and interpreting is that the interpreting process has no gap between code conversion and execution – both of these steps happen at program run time or on-the-fly. Whereas with compiling, the code conversion takes place in advance (sometimes far in advance) of program execution.

Popular interpreted languages:

• Python

• JavaScript

• Ruby

Statically-typed programming languages

Static-typing means that the data types of the variables in a programming language are known and established at the time the program is compiled. Furthermore, the datatype of a variable is not allowed to change during program compilation or execution.

For example, each time you create a variable in a statically-typed language, you must explicitly specify the datatype of that variable. This datatype could be an integer, string, boolean, and so on. This is called variable declaration. Once you declare a variable’s data type, it can only hold that type of data throughout the execution of the program.

Popular statically-typed languages:

• C

• C++

• Java

Dynamically-typed programming languages

Dynamic-typing means variable data types are established during program execution, also known as runtime.

Variable data types are not explicitly stated in the source code and variables can be easily reassigned to store values of any datatype on the fly.

Popular dynamically-typed languages:

• Python

• JavaScript

• Ruby

Object-oriented programming languages

Object-oriented programming (OOP) is a coding paradigm that allows programmers to create and work with "objects". An object is a representation or model of something the programmer needs to describe via code.

This probably sounds super vague, because it is. Pretty much anything can be modeled as an "object" in code. Objects often represent real things, such as the products for sale in a store or the customers buying those products.

But objects can also represent digital things such as web forms, and even more abstract stuff like URL endpoints, network sockets, and so on.

Object-oriented programming is usually implemented in a language using Classes. You can think of a class as a template (or model) for the type of object that is being created.

A class contains a set of attributes (properties or characteristics) that define each object of the class. Classes also contain a set of methods (functions) that allow operations to be performed on specific objects of the class.

For example, a "Product" class might have the following attributes:

• Product SKU (unique identifier for each product)

• Product name (descriptive name for each product)

• Product type

• Product price

• Product discount

As mentioned, a class is really just a template for creating objects. Creating an object using a class as a template is known as instantiation. You can create as many objects as you want from the same class, and each object created is known as an instance of that class. The instance is usually stored as a variable in code that you can use as you need it by interacting with its attributes and methods.

Continuing with our example, you can use our "Product" class above to create multiple objects of type "Product". Each product would have its own set of attribute values, such as SKU, name, type, price, and discount.

Representing structured sets of data in this object-oriented fashion can be a very intuitive way for programmers to write and organize their code. This is likely because humans tend to be naturally good at thinking in terms of identifiable entities that exist in the real world.

What's the difference between front-end, back-end, and full-stack development?

As a newer dev, you've likely browsed job opportunities in tech and noticed frequent mention of the terms "front-end", "back-end" and "full-stack".

These terms generally refer to the part of the application you'll be working on. Moreover, they also imply that you'll be working on a software application, usually a web application or mobile app.

The front end refers to the parts of the application that users (also known as "clients") interact with directly. For a web application, the front end is the collection of webpages (and functionality) that are presented in the user's browser. For a mobile app, the front end is the set of screens that the user interacts with on their mobile device.

Development tasks related to the front end include user experience design, user interface creation, client-side networking, integration and use of client-side libraries, and collecting/validating/submitting user input.

As a front-end dev, you'll implement these tasks primarily using HTML to define the structure of web pages, CSS to add styling, and JavaScript to add interactivity.

The back end refers to the parts of the application that run behind the scenes and aren't presented directly to the user/client.

The back end typically includes a web server which handles HTTP connections received from the front-end client (usually a web browser). The web server handles these connections and directs them to the back-end code which performs the logic necessary to respond to the client. This part of the back end is called routing or the API (application programming interface).

The back-end code itself is traditionally a standalone monolith codebase that is deployed as a single unit. But depending on the application's architecture, the back-end code can operate as a set of serverless functions running on a cloud service as opposed to a standalone codebase.

The back-end code validates user input, applies business logic, interacts with data storage such as a database, and crafts a response that gets sent back to the front-end client.

Now that we've covered the front end and back end, full-stack development is easy! :) Full stack simply includes both the front end AND back end! The term "full stack" comes from the term "stack" which is a shortened form of "software stack". The software stack is the collection of tools, frameworks, programming languages, and operating systems that are used to support an application.

What are some popular software stacks?

Now that we know what a software stack is, we'll briefly discuss some popular options for you to choose from.

LAMP Stack (Linux, Apache, MySQL, PHP)

The LAMP stack is a time-tested and industry standard back-end stack that uses the Linux operating system as its foundation. On top of that, you use an Apache webserver to handle web requests and direct them to a PHP codebase. Data is stored in a MySQL database, which is a free and open-source (FOSS) relational database platform.

This stack is great for fairly standardized content-serving websites like blogs.

You might notice that I didn't explicitly mention any front-end tools as being a part of this stack – so this means that LAMP is a back-end stack.

MEAN Stack (MongoDB, Express.js, Angular.js, Node.js)

The MEAN stack is a more modern stack that uses the MongoDB unstructured database platform for storing data. You use Express.js as the back-end web framework and Angular.js for the front end. Finally, you use Node.js to run JavaScript on the back end.

A major benefit of the MEAN stack is that all components are designed to natively operate using the JavaScript programming language, via JSON (JavaScript Object Notation).

Note that this stack's components are geared toward both the front end (Angular.js) and back end (MongoDB, Express.js, Node.js), so MEAN can be considered full stack.

MERN Stack (MongoDB, Express.js, React.js, Node.js)

As you can probably see, the MERN stack is very similar to the MEAN stack except it uses React.js library as the front end instead of Angular.js.

This stack is well suited to devs who like React for its flexible and intuitive style of creating user interfaces.

Notable frameworks

I wanted to take a brief moment to point out two other popular backend frameworks (not stacks) that you can incorporate or swap out for specific components of the stacks mentioned above.

Spring Boot is a Java framework (technically a special case of the broader Spring Framework) that is excellent for developing back-end Java code for web applications and mobile apps. If you are new to Java coding, I highly recommend you check it out.

Django is a Python framework that is specifically crafted for use with the Python programming language. If you prefer building web apps in Python, it is definitely worth looking into.

How do devs collaborate on code without being in the same room?

When I started coding, I opened up a Python text editor on my local machine and created a single file which grew to contain all the code for my project. I quickly found that this became unruly, so I split my code up into several Python .py files (or modules as they are known).

When I coded with a friend, they would usually be sitting there behind me while I typed, or I would be sitting there behind them. If we needed to exchange code snippets or files, we would just send them back and forth via email.

It was years before I learned how devs successfully collaborate while coding, and that it is often done remotely.

The key to successful code collaboration is learning to use a Version Control System (VCS). A VCS is a tool that tracks changes that multiple developers make to code files over time, and enables developers to efficiently work together on the same set files.

Version control systems create a repository that stores the data necessary to recreate any version of the code files as they existed at specific points in time. This is called version control.

Version control systems are very versatile tools, since they serve multiple useful functions for development teams:

• Tracks changes made to code files

• Allows devs to easily share their changes with others and access changes made by others

• Offers simple ways for merging code changes made by multiple devs or teams

• Provides a full-history backup of a project's code as it evolves over time, and a way to efficiently restore any previous version of the code

• Allows developers to easily manage code conflicts made on the same lines of the same files

• Provides various other tools to improve team collaboration and efficiency

There are many version control systems out there, but you've almost certainly heard of one: GitHub.

Actually, GitHub itself is not a version control system. GitHub is a company that provides online hosting for projects using version control. GitHub gets its name from the specific version control system that it uses: Git.

The first version of Git was created in 2005, and it has evolved into by far the most well-known and most popular version control system on the planet. Git is used by the vast majority of development teams today, and it is an essential tool to learn if you plan on coding professionally.

Does it matter what operating system I use?

When it comes to learning to code for the first time, I would answer this question similarly to the first in this list. I think what matters much more than which operating system you have, is that you get started learning as soon as possible with what you have.

That being said, I feel my answer would be a cop-out if I leave it at that. Let's assume you're trying to make an active decision about what OS to choose for coding work.

Taking into account the fact that there are many subjective reasons people prefer their operating system, in my opinion an operating system that provides access to a quality command-line terminal can be very useful to wrap your head around.

For that reason, my preference is using Unix-like operating systems such as a Linux flavor or MacOS if possible for development work. Full disclosure – I develop mostly on MacOS.

My reasoning for this is that learning to work on the command-line (much like learning to use Git) is an essential coding skill to learn. A fully featured and intuitive command line is a core part of software development. In my opinion, Linux and MacOS better incorporate modern command lines than Windows.

What text editor or IDE should I use?

Text editors and IDE's (Integrated Development Environments) have evolved massively over the years, and developers pick favorites for many reasons.

One reason could be that a particular editor or IDE was created specifically for a particular programming language or framework. Another could be that your company uses a specific editor, so that is the one you learned and stuck with. I found this reason to be especially true in my experience.

If you are primarily working with interpreted, dynamically-typed languages such as Python, JavaScript, Ruby, or PHP, I recommend that you start with a GUI-based editor such as Sublime Text or Visual Studio Code. These are two of the most popular text editors out there and provide a plethora of features and customizations to make your life easier as a developer.

If you work with Java, I recommend either Eclipse or IntelliJ IDEA which offer a multitude of features specifically crafted for working in the Java ecosystem.

Finally, regardless of which editor you choose for your main dev work, I recommend that you learn a bit of Vim. Vim is a text editor that is meant to be used directly within your command-line terminal. It definitely takes more time to get used to since you have to learn to use Vim's keyboard commands to interact with your files instead of point-and-click with your mouse.

But in my experience is well worth it. Even if you only learn the basic commands, these will help you immensely if you find yourself browsing through a non-GUI terminal at work, and need to inspect or modify some files.

I highly recommend the built-in Vimtutor program that is downloaded automatically when you install Vim. It walks through the basic directly in your command-line terminal.

Summary

In this article, I discussed 7 questions commonly asked by new coders. We cast a fairly wide net, covering questions about programmings language selection, software dev stacks, operating systems, and text editors.

If there are any questions you have that I didn't cover, feel free to message me at jacob@initialcommit.io.

Next steps

If you got value out of this article, I wrote a book called Coding Essentials Guidebook for Developers which has 14 chapters, each covering a core coding concept, language, or tool.

Topics include computer architecture, the Internet, Command Line, HTML, CSS, JavaScript, Python, Java, SQL, Git, and more.

These topics were meticulously selected to help put together a bigger picture of the development puzzle, instead of focusing on one topic in depth. This might be a good resource for you to check out if you got value out of this article.

One way many people start learning to code is by picking a popular programming language and jumping in head first with no direction. This could take the form of an online coding course, a tutorial project, or a random book purchase on a specific topic.

Rarely do prospective developers start with a roadmap – a bird's eye view of the coding world that outlines a set of relevant programming concepts, languages, and tools that almost 100% of developers use every day.

In this article, I propose one such roadmap. I do this by outlining 14 steps – each one discussing an essential concept, language, or tool – that professional developers use to write code, collaborate, and create professional projects.

I meticulously chose these 14 steps based on my own personal journey learning to code, which spans almost 20 years.

Part of the reason it took me so long to feel comfortable as a developer is that I would learn about specific topics without a broader context of the coding world.

Each of the steps in this article discusses a "coding essential" – something that I believe is critical to at least know that it exists at the start of your coding journey.

One final note before listing the steps in the roadmap: of course reading this article will not make you an expert programmer. It isn't meant to. The purpose of this article is to make you aware that each one of these topics exists, and hopefully give you a basic idea of how each one works so you can build on it intelligently going forward.

14 Step Roadmap for Beginner Developers

1. Familiarize Yourself with Computer Architecture and Data Basics

2. Learn How Programming Languages Work

3. Understand How the Internet Works

4. Practice Some Command-Line Basics

5. Build Up Your Text Editor Skills with Vim

6. Take-up Some HTML

7. Tackle Some CSS

8. Start Programming with JavaScript

9. Continue Programming with Python

10. Further Your Knowledge with Java

11. Track Your Code using Git

12. Store Data Using Databases and SQL

13. Read About Web Frameworks and MVC

14. Play with Package Managers

Without further ado, let's start at the top!

1) Familiarize Yourself with Computer Architecture and Data Basics

One of the wonderful things about modern programming languages is that they enable us to create fancy applications without worrying about the nitty-gritty details of the hardware behind the scenes (for the most part).

This is called abstraction – the ability to work with higher-level tools (in this case programming languages) that simplify and narrow down the required scope of our understanding and skills.

However, that doesn't mean it's useless to know the basics of the metal that your code is executing on. At the very least, being aware of a few tidbits will help you navigate workplace conversations about high CPU and memory usage.

So, here is a bare minimum of computer architecture basics to get you started:

Your computer's most important parts live on microchips (also known as integrated circuits).

Microchips rely on an electrical component called a transistor to function. Transistors are tiny electrical switches that are either off (0) or on (1) at any given time. A single microchip can contain millions or billions of tiny transistors embedded on it.

Most modern computers have a microchip called the Central Processing Unit (CPU). You can think of it as the computer’s brain. It handles most of the number crunching and logical tasks that the computer performs.

Each CPU has something called an instruction set, which is a collection of binary (zeros and ones) commands that the CPU understands. Luckily, we don't really need to worry about these as software devs! That is the power of abstraction.

If the CPU is the logical center of the brain, it is useful to have memory as well to store information temporarily or for the long term.

Computers have Random Access Memory (RAM) as "working memory" (or short-term memory) to store information that is actively being used by running programs.

RAM is made up of a collection of memory addresses, which can be used to store bits of data. In older languages like C, programmers do have access to working directly with memory addresses using a feature called pointers, but this is rare in more modern languages.

Finally, we'll touch on a component you're surely familiar with – the hard drive. In our analogy of the brain, this represents long-term memory. A hard drive is an internal or external device that stores data that should persist even after the computer is turned off.

Before moving on to more details about programming languages, let's spend a second talking about data. But what exactly do we mean by the word data?

At a high level, we think of things like text documents, images, videos, emails, files, and folders. These are all high-level data structures that we create and save on our computers every day.

But underneath the hood, a computer chip (like a CPU or RAM chip) has no idea what an "image" or a "video" is.

From a chip’s perspective, all of these structures are stored as long sequences of ones and zeros. These ones and zeros are called bits.

Bits are commonly stored in a set of eight at a time, known as a byte. A byte is simply a sequence of eight bits, such as 00000001, 01100110, or 00001111. Representing information in this way is called a binary representation.

2) Learn How Programming Languages Work

In the previous section, we mentioned that most computers rely on a CPU, and a CPU can understand a specific set of instructions in the form of ones and zeros.

Therefore, we could theoretically write code that tells the CPU what to do by stringing together long sequences of ones and zeros in a form the CPU understands. Instructions written in binary form like this are called machine code.

Sounds horrible to work with, doesn't it? Well it probably is, but I wouldn't know since I mostly use higher-level programming languages like JavaScript, Python, and Java.

A higher-level programming language provides a set of human-readable keywords, statements, and syntax rules that are much simpler for people to learn, debug, and work with.

Programming languages provide a means of bridging the gap between the way our human brains understand the world and the way computer brains (CPUs) understand the world.

Ultimately, the code that we write needs to be translated into the binary instructions (machine code) that the CPU understands.

Depending on the language you choose, we say that your code is either compiled or interpreted into machine code capable of being executed by your CPU. Most programming languages include a program called a compiler or an interpreter which performs this translation step.

Just to give a few examples – JavaScript and Python are interpreted languages while Java is a compiled language. Whether a language is compiled or interpreted (or some combination of the two) has implications for developer convenience, error handling, performance, and other areas, but we won't get into those details here.

3) Understand How the Internet Works

Whatever type of programming you aspire to do, you'll run into situations where it helps to know how computers interact with each other. This typically occurs over the Internet.

The Internet is nothing more than a global collection of connected computers. In other words, it is a global network. Each computer in the network agrees on a set of rules that enable them to talk to each other. To a computer, "talking" means transferring data.

As we discussed in the previous section, all types of data – web pages, images, videos, emails, and so on – can all be represented as ones and zeros.

Therefore, you can think of the Internet as a very large set of computers that can transfer ones and zeros amongst themselves, in a way that preserves the meaning of that data. The Internet is nothing more than a digital conversation medium.

If the Internet is just a big conversation arena, let’s define the conversation participants.

First, an analogy: most human conversations require at least two participants. In most cases, one person initiates the conversation and the other person responds, assuming they are both present and available.

In Internet speak, the computer initiating the conversation is called the client. The computer responding or answering is called the server.

For example, let’s say you open a web browser and go to "www.google.com". In this scenario, your web browser is the client. By extension, you can also think of the computer you are working on as the client.

In a more abstract sense, YOU are the client because you are the one initiating the conversation. By typing "www.google.com" into the search bar and clicking , your browser is requesting to start a conversation with one of Google’s computers.

Google’s computer is called the server. It responds by sending the data required to display Google’s web page in your browser. And voilà! Google’s web page appears in front of your eyes. All Internet data transfers utilize this sort of client/server relationship.

4) Practice Some Command-Line Basics

The Command Line can be intimidating at first glance. It is often featured in movies as a cryptic black screen with incomprehensible text, numbers, and symbols scrolling by. It is usually associated with an evil hacker or genius techie sidekick.

The truth is that it doesn’t take a genius to use or understand the command line. In fact, it allows us to perform many of the same tasks that we are comfortable doing via a point-and-click mouse.

The main difference is that it primarily accepts input via the keyboard, which can speed up inputs significantly once you get the hang of it.

You can use the Command Line to browse through folders, list a folder’s contents, create new folders, copy and move files, delete files, execute programs, and much more. The window in which you can type commands on the Command Line is called a terminal.

Let's walk through a short tutorial of basic navigation commands that will give you a feel for working on the command line.

Once you open your terminal, a typical first question is "Where am I"? We can use the pwd command (which stands for "Print Working Directory") to figure that out. It outputs our current location in the file system which tells us which folder we are currently in.

Try it yourself:

How to Use the Command Line

If you’re on a Mac, open the Terminal app, which is essentially a Unix Command Line terminal.

If you’re running an operating system without a GUI (Graphical User Interface), like Linux or Unix, you should be at the Command Line by default when you start the computer. If your flavor of Linux or Unix does have a GUI, you’ll need to open the terminal manually.

At the prompt, type pwd and press <ENTER>. The Command Line will print out the path to the folder that you’re currently in.

By default, the active folder when opening the Command Line is the logged-in user’s home directory. This is customizable in case you want the convenience of starting in a different location.

For convenience, the home directory can be referenced using the tilde ~ character. We will use this in a few examples going forward.

Now that we know what folder we’re in, we can use the ls command to list the contents of the current directory. The ls command stands for "List".

Type ls and press <ENTER>. The contents (files and subfolders) that reside in the current directory are printed to the screen.

Rerun the previous command like this ls -al and press <ENTER>. Now we will get more details about the directory contents, including file sizes, modification dates, and file permissions.

The hyphen in the previous command allows us to set certain flags that modify the behavior of the command. In this case we added the -a flag which will list all directory contents (including hidden files) as well as the -l flag which displays the extra file details.

Next, we can create a new folder using the mkdir command, which stands for "Make Directory". Below we create a new folder called "testdir".

Type mkdir testdir and press <ENTER>. Then type ls and press <ENTER>. You should see your new directory in the list.

To create multiple nested directories at once, use the -p flag to create a whole chain of directories like this: mkdir -p directory1/directory2/directory3

The Command Line isn’t that useful if we can only stay in one location, so let’s learn how to browse through different directories in the file system. We can do this via the cd command, which stands for "Change Directory".

First, type cd testdir and press <ENTER>. Then type pwd and press <ENTER>. Note the output now shows that we are inside the "testdir" directory specified in the cd command. We browsed into it!

Type cd .. and press <ENTER>. The .. tells the Command Line to browse backwards to the parent directory.

Then type pwd and press <ENTER>. Note the output now shows that you are back in the original directory. We browsed backwards!

Next we’ll learn how to create a new empty file in the current directory.

Type touch newfile1.txt and press <ENTER>. You can use the ls command to see that the new file was created in the current directory.

Now we’ll copy that file from one folder to another using the cp command.

Type cp newfile1.txt testdir and press <ENTER>. Now use the ls and ls testdir commands to see that the new file still exists in the current directory and was copied to the "testdir" directory.

We can also move files instead of copying using the mv command.

Type touch newfile2.txt and press <ENTER> to create a new file. Next, type mv newfile2.txt testdir and press <ENTER> to move the file into the "testdir" folder.

Use the ls and ls testdir commands to confirm that the file has been moved into the "testdir" folder (it should no longer appear in the original location you created it, since it was moved not copied).

The mv command can also be used to rename files.

To do that, type touch newfile3.txt and press <ENTER> to create a new file. Then type mv newfile3.txt cheese.txt and press <ENTER> to update the file’s name. Use ls to confirm that the filed was renamed.

Finally, we can delete files and folders using the rm command.

Type rm cheese.txt and press <ENTER> to remove the file. Use ls to confirm the file was removed.

Type rm -rf testdir and press <ENTER> to remove the "testdir" directory and its contents. Use ls to confirm the directory was removed.

Note that we need to use the -rf flags when removing directories. This forces the removal of the folder and all of its contents.

5) Build Up Your Text Editor Skills with Vim

At this point, we’ve covered the basics of the Command Line and seen a few examples of how we can work with files without a mouse.

Although we now know how to create, copy, move, rename, and delete files from the Command Line, we haven’t seen how we edit the content of text files in the terminal.

Working with text files in the terminal is important because computer code is nothing more than text saved in an organized set of files.

Sure we could use a fancy text editor like Microsoft Word (or more likely specialized code editors like Sublime or Atom) to write and edit our code, but this is not required. The terminal is often the most convenient place to write and edit code since we usually already have it open to run commands!

There are several excellent text editors created specifically for this purpose, and I recommend learning the basics of one called Vim.

Vim is one of the oldest text editors around and it is a time-tested gem. Vim stands for "VI i**M**proved" since it is the successor to a tool called Vi.

As mentioned, Vim is a text editor that was built to run directly in the terminal, so we don’t need to open a separate window to work in or use a mouse at all. Vim has a set of commands and modes that allow us to conveniently create and edit text content using only the keyboard.

Vim does have bit of a learning curve, but with a little bit of practice, the skills you learn will pay dividends throughout your coding career.

Vim is installed by default on many operating systems. To check if it’s installed on your computer, open the Command Line and type vim -v.

If Vim opens in your terminal and shows the version, you’re good to go! If not, you’ll need to install it on your system. (Note that you can quit Vim by typing :q! and pressing ). For more information on installing Vim, see https://www.vim.org.

In my opinion, the quickest and easiest way to learn how to use Vim is to use their built-in tutorial, the VimTutor. To run it, ensure that Vim is installed on your system, open the Command Line, type vimtutor, and press .

It is such a good tutorial that there is no reason for me to waste time trying to explain it here. So go do the VimTutor, like now! See you in the next section.

If you still have energy left after you've completed the VimTutor, check out these 7 Vim commands that will dramatically improve your productivity as you get started with Vim.

6) Take-up Some HTML

You can think of HTML – short for HyperText Markup Language – as the bones of a web page. It determines the structure of the page by specifying the elements that should be displayed and the order that they should be displayed in.

Every web page that you’ve ever visited in your browser has some HTML associated with it. When you visit a web page, the web server hosting the web page sends over some HTML to your browser. Your browser then reads it and displays it for you.

Most web pages contain a fairly standard set of content, including a title, text content, links to images, navigation links, headers and footers, and more. All of this information is stored as HTML that defines the structure of the page.

One thing to keep in mind is that HTML is not technically a programming language, although it is often referred to as "HTML code".

As we’ll see later, other programming languages enable us to write code that does stuff, such as running a set of instructions in sequence. HTML doesn’t do anything. We don’t run or execute HTML. HTML just sits there in a file and waits to be sent to a web browser which will display it to the end-user.

In fact, HTML is basically just data. It is data that defines what a web page should look like, nothing more.

So how do you write HTML? HTML uses a standard set of tags (basically just labels) to identify the available elements that make up a web page. Each tag is defined using angle brackets.

For example, the title tag is defined as <title>My Page Title</title> and the paragraph tag is defined as <p>A bunch of random text content.</p>.

Each HTML element is made up of a starting tag and an ending tag. The starting tag is just the tag label in between angle brackets, like this:

<tagname>

This opens the new HTML tag. The ending tag is essentially the same, but it uses a forward slash after the first angle bracket, to mark it as an ending tag:

</tagname>

Any text between the two tags is the actual content that the page will display.

Let’s cover a couple of the most common tags in use. The first is the <html> tag. This defines the start of an HTML page. A corresponding </html> tag (note the forward slash) defines the end of the HTML page. Any content between these tags will be a part of the page.

The second is the <head> tag. This defines additional information that the browser will use to understand the page. Most of the content in this tag is not displayed to the user. A corresponding </head> tag defines the end of the HEAD section.

Previously, we saw the <title> tag. It defines the title of the web page, which the browser will display in the browser tab. This tag needs to be placed inside the <head>...</head> section.

Next is the <body> tag. All content inside this tag makes up the main content of the web page. Putting these four tags together looks something like this:

<html>

    <head>
        <title>My Page Title</title>
    </head>

    <body>
        <p>A bunch of random text content.</p>
    </body>

</html>

The simple HTML snippet above represents a simple web page with a title and a single paragraph as body content.

This example brings up a point we didn’t mention in the last section. HTML tags can be nested inside each other. This just means that HTML tags can be placed inside other HTML tags.

HTML provides many other tags to provide a rich set of content to web users. We won't cover them in detail here, but below is a short list for reference:

• <p>: A paragraph of text starting on a new line.

• <h1>: A page heading usually used for page titles.

• <h2>: A section heading usually used for section titles.

• <hx>: Where x is a number between 3 and 6, for smaller headings.

• <img>: An image.

• <a>: A link.

• <form>: A form containing fields or inputs for a user to fill out and submit.

• <input>: An input field for users to enter information, usually within a form.

• <div>: A content division, used to group together several other elements for spacing purposes.

• <span>: Another grouping element, but used to wrap text phrases within another element, usually to apply specific formatting to only a specific part of the text content.

7) Tackle Some CSS

A web page without CSS – or Cascading Style Sheets – is like a cake without frosting. A frosting-less cake serves its purpose, but it doesn’t look appetizing!

CSS allows us to associate style properties such as background color, font size, width, height, and more with our HTML elements.

Each style property tells the browser to render the desired effect on the screen. Like HTML, CSS is not technically a programming language. It doesn’t let us perform actions, it simply lets us add styles to bare bones HTML.

Let’s see how to associate CSS styles with our HTML elements. There are three pieces to this puzzle:

The CSS selector: Used to identify the HTML element or elements we want the style to apply to.

The CSS property name: The name of the specific style property that we want to add to the matched HTML elements.

The CSS property value: The value of the style property we want to apply.

Here is an example of how these pieces come together to set the color and font size of a paragraph:

p {
  color: red;
  font-size: 12px;
}

Let’s start at the beginning, before the curly braces. This is where the CSS selector goes. In this case, it is the letter p which indicates the <p> (paragraph) HTML tag. This means that the styles inside the curly braces will apply to all <p> tags on the web page.

Let’s move on to what goes inside the curly braces – the styles we want to apply to the targeted elements.

Here we find pairs of CSS properties and values, separated by a colon. The properties (in this case "color" and "font-size") are on the left. The values of these properties (in this case "red" "12px") are on the right. A semicolon ends each property/value pair.

You can probably see how this works. The snippets of CSS code above tell the browser to use red, 12px size letters for all the text placed inside <p> tags.

So how does an HTML page know to include these CSS styles? Enter the <link> HTML tag. Usually, CSS styles are created in separate files (.css files) from the HTML. This means we need some way to import them into our HTML files so the browser knows that the styles exist.

The <link> element exists for this purpose. We include <link> elements in the <head> section of HTML files which allow us to specify the external CSS files to import:

<head>

    <title>My Page Title</title>

    <link rel="stylesheet" type="text/css" href="/home/style.css">

</head>

In this example, we are importing the CSS styles specified by the href attribute, in this case the file /home/style.css.

In the next 3 sections, we'll (finally) dive into some more technical programming languages!

We'll go over a general overview of JavaScript, Python, and Java, as well as walk through some of the essential coding concepts common to the 3 languages. We will compare and contrast the language features and example code so you can hopefully get a well-rounded understanding of the basics of all three.

8) Start Programming with JavaScript

Let’s start by answering the following question: if we can use HTML to build the structure of a web page and CSS to make it look pretty, why do we need JavaScript?

The answer is that we technically don’t. If we are happy with a static site that sits there and looks pretty, we are good to go with just HTML and CSS.

The keyword here is "static". If, however, we want to add dynamic features to our web pages, such as changing content and more complex user interactions, we need to use JavaScript.

What is JavaScript?

So what exactly is JavaScript? JavaScript is a programming language that was created specifically for websites and the Internet. As we mentioned in section 2, most programming languages are either compiled or interpreted, and programs are typically run in a standalone manner.

JavaScript is somewhat unique in this respect in that it was designed to be executed directly inside web browsers. It allows us to write code representing sets of actions that will be executed on our web pages to make our sites much more dynamic.

You can either write JavaScript code in text files named with a .js extension or inside <script> tags directly in the HTML.

For many years, JavaScript code was primarily relegated to running inside web browsers. But the Node.js project changed this paradigm by creating a standalone JavaScript environment that could run anywhere.

Instead of being trapped in a browser (that is, client-side), Node.js can be installed locally on any computer to allow the development and execution of JavaScript code. You can also install Node on web servers which allows you to use JavaScript as backend code for applications instead of simply as web browser frontend code.

Now that we've covered some background, let's dive into a few basics of the JavaScript language.

Variables and Assignment in JavaScript

Variables possibly represent the most fundamental concept in programming. A variable is simply a name or placeholder that is used to reference a particular value.

The word variable implies that the stored value can change throughout the execution of the program.

You can use variables to store numbers, strings of text characters, lists, and other data structures that we will talk more about in a minute.

All programming languages use variables, but the syntax varies between different languages.

Variables are useful since we can reference their values throughout our code. This enables us to check their values as needed and perform different actions depending on how the variable’s value changes.

In JavaScript, we declare variables using the let keyword, like this: let x;.

This declares x as a variable that we can use in our code. Note that we added a semicolon at the end of the line. In JavaScript (and many other languages) semicolons are used to specify the end of each code statement.

Now that we have created the variable x, we can assign a value to it using the equals sign, also called the assignment operator: x = 10;

Here we assigned the number 10 to the variable named x. Now any time we use x in our code, the value 10 will be substituted in.

Both variable declaration and assignment can be done in one line as follows:

let x = 10;

Data Types in JavaScript

In the last section, we stored an integer (whole number) value in the variable named x. You can also store decimal numbers, or floating-point numbers as they are known. For example, we could write: let x = 6.6;.

The different types of values we can store in variables are called data types. So far we have only seen numeric data types (integers and floating-point numbers), but we are just scratching the surface. We can store text data in variables as well.

In coding terminology, a piece of text is called a string. We can store a string value in our variable x by surrounding it in either single or double quotes:

let x = 'Hello there!';

let y = "Hey bud!";

The next data type we’ll discuss is the boolean. A boolean can only hold one of two values, true or false – and they must be all lowercase. In JavaScript, true and false are two keywords used specifically as values for boolean variables:

let x = true;

let y = false;

Note that the values true and false don’t appear within quotes the way strings do. If we surround them with quotes, the values would be strings, not booleans.

We often use booleans to control the flow of programs in conditional (if/else) statements which we’ll learn about next.

Program Flow Control Statements in JavaScript

Now that we have an understanding of variables and the basic JavaScript data types, let’s take a look at some things we can do with them.

Variables aren't that useful without being able to tell our code to do something with them. We can make our variables do things by using statements.

Statements are special keywords that allow us to perform some action in our code, often based on the value of a variable we have defined. Statements let us define the logical flow of our programs, as well as perform many useful actions that will dictate how our programs work.

If / Else Statement

The first statement we’ll discuss is the if statement. The if statement allows us to perform some action only when a desired condition is true. Here is how it works:

let x = 10;

if ( x > 5 ) {
    console.log('X is GREATER than 5!');
} else {
    console.log('X is NOT GREATER than 5!');
}

We defined a variable called x and set its value to 10. Then comes our if statement. After the keyword if, we have a set of parentheses containing the condition to evaluate, in this case, x > 5. We just defined x to equal 10, so we know that this condition is true in this example.

Since the condition in the parentheses is true, the code between the curly braces will be executed, and we will see the string "X is GREATER than 5!" printed to the screen. (We didn't discuss the meaning of console.log(), so for now just know that it prints the value in the parentheses to the screen).

In the same example, we also included an else statement. This allows us to execute specific code in the event that the condition in the condition is false.

While Loops

The next type of statement we’ll discuss is the while loop. Loops enable us to repeat a block of code as many times as we desire, without copying and pasting the code over and over again.

For example, let’s assume we need to print a sentence to the screen 5 times. We could do it like this:

console.log('This is a very important message!');
console.log('This is a very important message!');
console.log('This is a very important message!');
console.log('This is a very important message!');
console.log('This is a very important message!');

This works fine for only 5 messages, but what about 100, or 1000? We need a better way to repeat pieces of code multiple times, and loops allow us to do this. In coding terminology, repeating a piece of code multiple times is called iteration.

This following while loop will continue running the block of code inside it as long as the specified condition remains true:

let x = 1;

while ( x <= 100 ) {

    console.log('This is a very important message!');

    x = x + 1;

}

In this example, we initialize x to the value of 1. Then we write a while loop. Similar to the if statement, we add a condition in parentheses. In this case the condition is x <= 100. This condition will be true as long as x is less than or equal to 100.

Next we specify the block of code to execute in the curly braces. First, we print out our message to the console. Then we increment x by 1.

At this point the loop attempts to re-evaluate the condition to see if it’s still true. Variable x now has a value of 2 since it was incremented in the first loop run. The condition is still true since 2 is less than 100.

The code in the loop repeats until x gets incremented to the value of 101. At this point, x is greater than 100 so the condition is now false, and the code in the loop stops executing.

The HTML

• Taking a free or paid online programming course

• Reading a programming book

• Picking a personal project and hacking away to learn as you code

• Following along with an online tutorial project

• Keeping up to date with relevant programming blogs

Each of these methods will appeal to different people, and each one has elements that will definitely make you a better programmer. If you are an intermediate or advanced coder, it is almost certain that you've tried each of these methods at least once.

However, there is another method that the vast majority of developers overlook, which is a shame in my opinion because it has so much to offer. This method is to learn by reading, analyzing, and understanding existing, high-quality codebases!

We are lucky to live in a time where good code is often accessible for free via high-quality, free-and-open-source (FOSS) projects. And it takes less than a minute to clone down copies of these codebases to our local machines from sites like GitHub or BitBucket.

Furthermore, modern version control systems like Git allow us to view the code at any point in its development history. Clearly there is a wealth of information right in front of our noses!

In this article, we will discuss the original version of Git's code in order to highlight how reading existing code can help boost your coding skills.

We will cover why it's worth learning about Git's code, how to access Git's code, and review some related C programming concepts.

We will provide an overview of Git's original codebase structure and learn how Git's core functionalities are implemented in code.

Finally, we will recommend some next steps for curious developers to continue learning from Git's code and other projects.

Why Learn About Git's Code?

Git's codebase is an incredible resource for intermediate developers to further their programming knowledge and skills. Here are 7 reasons why it's worth digging into Git's code:

1. Git is probably the most popular software dev tool in use today. In short, if you're a developer, you probably use Git. Learning how Git's code works will give you a deeper understanding of an essential tool you work with every day.

2. Git is interesting! Git is a versatile tool that solves many interesting problems to allow developers to collaborate on code. As a curious human, I thoroughly enjoyed learning more about it.

3. Git's code is written in the C programming language, which offers a great opportunity for developers to branch out into an important language they may not have used much before.

4. Git makes use of many important programming concepts, including content-addressable databases, file compression/inflation, hash functions, caching, and a simple data model. Git's code illustrates how these concepts can be implemented in a real project.

5. Git's code and design are elegant. It is a great example of a functional, minimalist codebase that accomplishes its goal in a clear, effective way.

6. Git's initial commit is small in size – it is made up of only 10 files, containing less than 1,000 total lines of code. This is very small compared to most other projects and is very manageable to understand in a reasonable amount of time.

7. The code in Git's initial commit can be compiled and executed successfully. This means you can play with and test the original version of Git's code to see how it works.

Now, let's take a look at how to access the original version of Git's code.

How to check out Git's initial commit?

The official copy of Git's codebase is hosted in this public GitHub repository. However, I created a fork of Git's codebase and added extensive inline comments to the source code, to help developers easily read through it line by line.

Since I worked off of the very first commit in Git's history, I named this project Baby Git. The Baby Git codebase is located in this public BitBucket repository.

I recommend cloning the Baby Git codebase to your local machine by running the following command in your terminal:

git clone https://bitbucket.org/jacobstopak/baby-git.git

If you want to stick with Git's original codebase (without the extensive comments I added), use this command instead:

git clone https://github.com/git/git.git

Browse into the new git directory by running the command cd git. Feel free to poke around the folders and files in here.

You'll quickly notice that in the current version of Git – the version currently checked out in your working directory – that there are a lot of files containing a lot of very long and complicated-looking code.

Clearly this current version of Git is too big for a single developer to realistically get acquainted with in a reasonable amount of time.

Let's simplify things by checking out Git's initial commit, using the command:

git log --reverse

This shows a list of Git's commit log in reverse order, starting from Git's initial commit. Note that the first commit ID in the list is e83c5163316f89bfbde7d9ab23ca2e25604af290.

Check out the contents of this commit into the working directory by running the command:

git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290

This puts Git into a detached head state and places Git's original code files into the working directory.

Now run the ls command to list these files, and note that there are only 10 that actually contain code! (The 11th is just a README). Understanding the code in these files is totally manageable for an intermediate developer!

Note: If you're using my Baby Git repository, you'll want to run the command git checkout master to abandon the detached head and move back to the tip of the master branch. This will enable you to see all the inline comments describing how Git's code works line by line!

Important C Concepts that Will Help You Understand Git's Code

Before diving straight into Git's code, it helps to get a refresher on a few C programming concepts that appear throughout the codebase.

C Header Files

A C header file is a code file ending in the .h extension. Header files are used to store variables, functions, and other C objects that a developer wants to include in multiple .c source code files using the #include "headerFile.h" directive.

If you're familiar with importing files in Python or Java, this is a comparable procedure.

C Function Prototypes (or Function Signatures)

A function prototype or signature tells the C compiler information about a function definition – the function's name, number of argument, types of arguments, and return type – without providing a function body. They help the C compiler identify function properties in situations where the function body appears after the function is called.

Here is an example of a function prototype:

int multiplyNumbers(int a, int b);

C Macros

A macro in C is essentially a rudimentary variable that is processed before code compilation in a C program. Macros are created using the #define directive, such as:

#define TESTMACRO asdf

This creates a macro called TESTMACRO with a value of asdf. Wherever the placeholder TESTMACRO is used in the code, it will be replaced by the preprocessor (before code compilation) with the value asdf.

Macros are commonly used in a few ways:

• As a true/false switch by checking whether a macro is defined

• To store a simple integer or string value to be replaced in the code in multiple locations

• To store a simple (usually one-line) code snippet to be replaced in the code in multiple locations

Macros are convenient tools since they enable developers to update a single line of code which influences the behavior of the code in multiple locations.

C Structs

A struct in C is a grouped set of properties that are related to a single object.

You are probably familiar with Classes in languages such as Java and Python. A struct is a predecessor to a class – it can be thought of as a primitive class with no methods.

struct person {

    int person_id;
    char *first_name;
    char *last_name;

};

This struct represents a person, by grouping together an ID field, along with the person's first and last names. A variable can be instantiated and initialized from this struct as follows:

struct person jacob = { 1, "Jacob", "Stopak" };

Struct properties can be retrieved using the dot operator:

jacob.person_id
jacob.first_name
jacob.last_name

C Pointers

A pointer is a memory address of a variable – it is the memory address at which the value of that variable is stored.

A pointer to an existing variable can be obtained by using the & symbol, and stored in a pointer variable declared with the * symbol:

int age = 21;

int* age_pointer = &age;

This snippet defines the variable age and assigns it a value of 21. Then it defines a pointer to an integer called age_pointer, and uses the & to obtain the memory address that the value of the age variable is stored at.

Pointers can be dereferenced (i.e. obtain the value stored at the memory address), using the * as well.

int new_age = *age_pointer + 10;

Continuing from our previous example, we use the *age_pointer syntax to fetch the value stored in the pointer (21), and add 10 to it. So the new_age variable would contain a value of 31.

Now that our short segue into C programming is completed, let's get back to Git's code.

Overview of Git's Codebase Structure

There are ten relevant code files that make up Git's initial commit. We'll start by briefly discussing these two:

• Makefile

• cache.h

We'll discuss Makefile and cache.h first because they are a bit special.

Makefile is a build file that contains a set of commands used to build the other source code files into executables.

When you run the command make all from the command line, the Makefile will compile the source code files and spit out the relevant executables for Git's commands. If you're interested, I wrote an in-depth guide on Git's makefile.

Note: If you actually want to compile Git's code locally, which I recommend you do, you'll need to use my Baby Git version of the code mentioned above. The reason is that I made some tweaks to allow Git's original code to compile on modern operating systems.

Next up is the cache.h file, which is Baby Git's only header file. As mentioned above, the header file defines many of the function signatures, structs, macros, and other settings that are used in the .c source code files. If you're curious, I wrote an in-depth guide on Git's header file.

The remaining eight code files are all .c source code files:

• init-db.c

• update-cache.c

• read-cache.c

• write-tree.c

• commit-tree.c

• read-tree.c

• cat-file.c

• show-diff.c

Each file (except read-cache.c) is named after the Git command that it contains the code for – some probably look familiar to you. For example, the init-db.c file contains the code for the init-db command used to initialize a new Git repository. As you probably guessed, this was the precursor to the git init command.

In fact, each of these .c files (except read-cache.c) contains the code for one of the original eight Git commands. The build process compiles each of these files and creates an executable file (with matching name) for each one. Once these executables are added to the filesystem path, they can be executed similarly to any modern Git command.

So after compiling the code using the make all command, the following executables are produced:

• init-db: Initializes a new Git repository. Equivalent to git init.

• update-cache: Add a file to the staging index. Equivalent to git add.

• write-tree: Creates a tree object in the Git repository from the current index contents.

• commit-tree: Creates a new commit object in the Git repository. Equivalent to git commit.

• read-tree: Print out the contents of a tree from the Git repository.

• cat-file: Retrieve the the contents of an object from the Git repository, and store it in a temporary file in the current directory. Equivalent to git show.

• show-diff: Show the differences between files staged in the index and the current versions of those files as they exist in the filesystem. Equivalent to git diff.

These commands are executed individually in sequence, similar to how modern Git commands are executed as a part of standard development workflows.

The one file we haven't discussed yet is read-cache.c. This file contains a set of helper functions that the other .c source code files use to retrieve information from the Git repository.

Now that we've touched on each of the important files in Git's initial commit, let's discuss some of the core programming concepts that allow Git to function.

Implementation of Git's Core Concepts

In this section, we'll discuss the following programming concepts that Git uses to work its magic, as well as how they were implemented in Git's original code:

• File compression

• Hash function

• Objects

• Current directory cache (staging area)

• Content addressable database (object database)

File Compression

File compression, also know as deflation, is used for storage and performance efficiency in Git. This reduces the size of the files that Git stores on disk and increases the speed of data retrieval when Git needs to transfer these files across a network.

This is important since Git's local and network operations need to be as fast as possible. As a part of the data retrieval process, Git decompresses, or inflates, the files to obtain their content.

Source: https://initialcommit.com/blog/Learn-Git-Guidebook-For-Developers-Chapter-2

File deflation and inflation were implemented in Git's original code using the popular zlib.h C library. This library contains functions, structures, and properties for compressing and decompressing content. Specifically, Zlib defines a z_stream struct that is used to hold the content that is to be deflated or inflated.

The following zlib functions are used to initialize a stream for deflation or inflation, respectively:

/*
 * Initializes the internal `z_stream` state
 * for compression at `level`, which indicates
 * scale of speed versuss compression on a 
 * scale from 0-9. Sourced from <zlib.h>.
 */
deflateInit(z_stream, level);

/*
 * Initializes the internal `z_stream` state for
 * decompression. Sourced from <zlib.h>.
 */
inflateInit(z_stream);

The following zlib functions are used to perform the actual deflation and inflation operations:

/*
 * Compresses as much data as possible and stops
 * when the input buffer becomes empty or the
 * output buffer becomes full. Sourced from <zlib.h>.
 */
deflate(z_stream, flush);

/*
 * Decompresses as much data as possible and stops
 * when the input buffer becomes empty or the
 * output buffer becomes full. Sourced from <zlib.h>.
 */
inflate(z_stream, flush);

The actual deflation/inflation process is a bit more complex than this and involves setting several parameters of the compression stream, but we won't go into more detail here.

Next, we'll discuss the concept of hash functions and how they are implemented in Git's original code.

Hash Functions

A hash function is a function that can easily transform an input into a unique output, but makes it very difficult or impossible to reverse that operation. In other words, it is a one-way function. It is not possible with today's technology to use the output of a hash function to deduce the input that was used to generate that output.

Git uses a hash function – specifically the SHA-1 hash function – to generate unique identifiers for the files we tell Git to track.

As developers, we make changes to the code files in the codebase we are working on using a text editor, and at some point we tell Git to track those changes. At this point, Git uses those file changes as inputs for the hash function.

The output to the hash function is called a hash*.* The hash is a hexadecimal value 40 characters in length, such as 47a013e660d408619d894b20806b1d5086aab03b.

Source: https://initialcommit.com/blog/Learn-Git-Guidebook-For-Developers-Chapter-2

Git uses these hashes for various purposes that we will see in the following sections.

Objects

Git uses a simple data model – a structured set of related objects – to implement its functionality. These objects are the nuggets of information that enable Git to track changes to the files of a codebase. The three types of objects that Git uses are:

• Blob

• Tree

• Commit

Let's discuss each one in turn.

Blob

A blob is short for a Binary Large OBject. When Git is told to track a file using the update-cache <filename.ext> command, (the predecessor to git add), Git creates a new blob using the compressed contents of that file.

Git takes the content of the file, compresses it using the zlib functions we described above, and uses this compressed content as input to the SHA-1 hash function. This creates a 40 character hash that Git uses to identify the blob in question.

Finally, Git saves the blob as a binary file in a special folder called the object database (more on this in a minute). The name of the blob file is the generated hash, and the contents of the blob file are the compressed file contents that were added using update-cache.

Tree

Tree objects are used to link together multiple blobs that are added to Git at once. They are also used to correlate blobs with file names (and other file metadata like permissions), since blobs don't provide any information besides the hash and compressed binary file content.

For example, if two changed files are added using the update-cache command, a tree will be created containing the hashes of those files, along with the file name that each of those blobs corresponds to.

What Git does next is very interesting, so pay attention. Git uses the content of the tree itself as input to the SHA-1 hash function, which generates a 40 character hash. This hash is used to identify the tree object, and Git saves this in the same special folder that blobs are saved in – the object database we'll touch on shortly.

Commit

You're probably more familiar with commit objects than with blobs and trees. A commit represents a set of file changes saved by Git, along with descriptive information about the change such as a commit message, the author's name, and the timestamp of the commit.

In Git's original code, a commit object is the result of running the commit-tree <tree-hash> command. The resulting commit object includes the specified tree object (which remember, represents a collection of file changes via one or more blobs mapped to their file names), and the descriptive information mentioned in the previous paragraph.

Like blobs and trees, Git identifies the commit by hashing its content using the SHA-1 hash function, and saving it in the object database. Importantly, each commit object also contains the hash of its parent commit. In this way, the commits form a chain that Git can use to represent the history of a project.

Current Directory Cache (Staging Area)

You probably know Git's staging area as the place your changed files go after using the git add command, patiently waiting to be committed using git commit. But what exactly is the staging area?

In Git's original version, the staging area is called the current directory cache. The current directory cache is just a binary file stored in the repository at the path .dircache/index.

As mentioned in the previous section, after changed files are added to Git using the update-cache (git add) command, Git calculates the blob and tree objects associated with those changes. The generated tree object associated with the staged files is added to the index file.

It is called a cache because it is just a temporary storage location for the staged changes to reside before being committed. When the user makes a commit by running the commit-tree command, the tree from the current directory cache can be supplied. It also includes other commit information like the commit message for Git to create a new commit object with.

At that point the index file is simply removed to make room for new changes to be staged.

Content Addressable Database (Object Database)

The object database is Git's primary storage location. This is where all the objects we discussed above – blobs, trees, and commits – are stored. In Git's original version, the object database is simply a directory at the path .dircache/objects/.

When Git creates objects through operations such as update-cache, write-tree, and commit-tree, (the predecessors of git add and git commit), these objects are compressed, hashed, and stored in the object database.

The name of each object is the hash of its content, hence why the object database is also called a content addressable database*.* Each piece of content (blob, tree, or commit) is stored and retrieved based on an identifier generated from the content itself.

The modern version of Git works very much the same way. The difference is that storage formats have been optimized to use more efficient methods (especially related to data transfer over networks), but the basic principles are the same.

Summary

In this article, we discussed the original version of Git's code in order to highlight how reading existing code can help boost your coding skills.

We covered the reasons Git is a great project to learn from in this way, how to access Git's code, and reviewed some related C programming concepts. Finally, we provided an overview of Git's original codebase structure and dove into some concepts that Git's code relies on.

Next Steps

If you're interested in learning more about Git's code, we wrote a guidebook you can check out here. This book dives into Git's original C code in detail and directly explains how the code works.

I encourage any and all developers to explore the open-source community to try and find quality projects that interest you. Those projects will have codebases that you can clone down in a matter of minutes.

Take some time to poke around the code, and you might learn something you never expected to find.