by Ryan Irelan
When starting out with Git, it’s much easier to understand how to use it if we also understand the basics of what Git is.
By that I mean what Git is beyond the commands. Conceptually speaking.
Git is a version control system. You’ll hear this referred to as a VCS sometimes. This is a general term to describe tools that track changes to files over a period of time. The reason we track the changes is so we can revert to previous versions, have a log of the work that was completed, as well as have an incremental backup of the project.
Version control systems aren’t just for code but that’s where they got their start and are most widely used.
You could–and I have–use version control for a book you’re writing.
You could use version control for designs you’re creating for a project.
You could use version control for a series of documents, like proposals, contracts, or agreements.
If it’s a file, it can be tracked by a version control system.
Okay, great. So why should use a version control system for your projects?
First and foremost is because it’s a reliable way to track changes to your files. You might’ve used a simple version control system in the past where you zipped up a project and put a date on it, thereby capturing that day’s work. A version control system also lets you snapshot changes to the project but in a more structured and reliable way.
There are lot of other version control systems out there and perhaps you’ve used one or two before. In the past I’ve used CVS, Subversion, and Mercurial, in addition to Git. I prefer Git because it is local, simple, and fast.
So let’s talk briefly and at a high level of how Git works.
When you initialize a new Git repository, you are telling Git to track a set of files.
This set of files will be in a common directory (and subdirectories).
Git now cares about what happens to those files.
At first Git will just tell you that it sees a bunch of files but isn’t yet tracking them. It’ll be up to you to add those files so Git will care about them on an individual basis. After that, Git will notice every change to the file.
By initializing a Git repository, you tell Git: “Hey I want you to pay attention to this set of files. If you don’t know about a file yet, please tell me. If something changes in a file, please tell me. In return, I’ll commit those changes to your repository so you are aware.
Let me try an analogy and see if this works.
Imagine you’re a summer camp counselor. Your job is to take care of, educate, and otherwise entertain a specific group of kids. The kids are organized into groups.
You arrive at the camp on Day 1 and you know you’re responsible for a group of kids. You walk into the room and your supervisor says: “Okay, Ryan, this is your group.”
You look out at the group of kids and say “Okay, ya’ll are mine. I will take care of you.”
“First order of business. I see I have 15 kids here. But I don’t know your names. I need you to form a line and then give me your names so I can write them on this list. This is the list I will use to track your progress at camp so I can report back to your parents when they pick you up on Sunday.”
The kids form a line and, one by one, they give you their name and you write it down on the paper attached to your clipboard. You now have them tracked and know exactly who the kids are.
As summer camp goes on, you watch your campers and their actives. If Suzanne swims a 1km lap in the lake, you mark that change down next to her name on the list.
If Albert gets sick because he ate too many bowls of chocolate pudding after dinner, then you mark that down next to his name to track his health.
The bottom line is: you are watching these kids and tracking how they change during their time at camp.
This analogy may be a little thin but I hope you get the idea. Key takeaway: Think about Git as a system that watches a set of files you tell it to.
This is the
git init command.
Once you tell it to watch a set of files, you then have to introduce it to each file.
This is the
git add command.
(I go over the actual commands in my Git Essentials course bundle.)
Just like with the campers and and counselor, think about your Git repository as the set of files. Every time you make a change to a file and commit that change (record it as a change), Git snapshots the state of the entire collection of files at that moment.
This might sound like Git is just zipping up the files and such. It’s much more nuanced than that (and it’s something we cover in the Git: Under the Hood course).
Git only saves and records changes to the files that have changed. For the other files, the snapshot simply points to the previous snapshot. This allows Git to efficiently store files without becoming unnecessarily large over the lifecycle of a project.
So, what is Git doing?
It’s caring about your project files because you told it to. Every time you work with Git think of it in this way. Git cares a lot and sometimes you have to tell it no longer care (git ignore), too.
And, as you’ll learn in a different video on merging branches in Git, Git cares so much that it won’t let you lose changes or work. It really is looking out for you.
Learn everything you need to be proficient in Git. 40+ videos, 6 hours of learning, a better understanding of Git.
by Ryan Irelan
Now that Craft 3 is available (as of this writing it is still in public beta), it’s time to learn how to install it.
There is one pre-requisite to installing Craft 3:
What’s Composer? It’s a dependency management tool for PHP that helps manage software needed for individual projects (as opposed to traditional package managers that let you install software on your computer or server globally.)
Don’t have it installed yet? Watch my video install Composer.
After that you’re ready to install Craft 3. Here’s how:
by Ryan Irelan
As far as the Git workflow is concerned, there are three pieces of Git that we should be aware of before moving forward with some slightly more complex (but totally doable!) explanation.
Let’s cover each one in a bit more detail.
A repository is a collection of commits, and a record of what the project’s working tree looked like at one time. You can access the history of commits via the Git log.
There’s always a current starting point in a repository and that’s called the HEAD. A repository also contains tags and branches.
The job of the repository is to be the container that tracks the changes to your project files.
This is a directory on your file system that is associated with a repository.
You can think of this as the filesystem manifestation of the repository. It’s full of the files you edit, where you add new files, and from which you remove unneeded files. Any changes to the Working Tree are noted by the Index (see below), and show up as modified files.
This is a middle area that sits between your Git repository and your Working Tree.
The Index keeps a list of the files Git is tracking and compares them to your Working Tree when you make changes. These changed files show up as modified before you bundle them up into a commit.
You might have heard this called the staging area where changes go before they are committed to the repository as commit objects.
If you ever use the
-a flag when committing, then you are effectively bypassing the Index by turning your changes directly into a commit without staging them first.
To learn more about Git check out our Git courses, lessons and tutorials.
by Ryan Irelan
The Element API is a first-party plugin by Pixel & Tonic that allows you to create an API for sharing your data from Craft CMS. The responses are formatted as JSON (what is JSON?).
Using the plugin you can create an API that exposes Craft Elements via a JSON-formatted responses. The API only is read-only. You cannot write to Craft using this API and there’s no authentication built in. Be careful what you share!
The Element API is made up of the following pieces:
elementapi.phpfile you have to create
To use the Element API plugin you need to meet these requirements:
Installing the Element API plugin is like installing any other Craft plugin: drag the plugin file to the
plugins directory and then install the plugin via the Craft Control Panel.
by Ryan Irelan
In a recent lesson, I walked through how to use the Element API Plugin from Pixel & Tonic to create a JSON API that shares your website’s data (only that data which you choose, of course) for consumption by another website or service.
The free lesson is a fundamental approach to building a read-only API using the default ElementTypes (entry, category, asset, etc) in Craft. As long as you follow my steps, you can get an API up and running quickly.
Toward the end of the lesson, we also learn how to expose your Craft Commerce order data via an API so you can have an outside tool (like a Goole Spreadsheet or reporting tool) ingest it and use it create some sort of report.