If you're reading this you probably already know or at least have an idea of what git is and it's history, but if you don't, well... shame on you! Git is this awesome tool that allows developers to time travel
In this very brief article I'm gonna cover the basics of how Git works, more specifically, I'll unpack 4 Git commands and their use cases. This will be a continued "series" post so you can keep an eye out for more Git wizardry.
- Git init
- Git clone
- Git add
- Git commit
Git Init
Getting inside an existing directory on our machine and running:
git init
will create a new subdirectory named ".git" which effectively changes our directory into a git repository. Okay, what does that mean exactly?...
Firstly, "directory" is just a posh term for "folder" and "subdirectory" obviously refers to a folder inside a folder, you get the idea. Secondly a git repository is a folder whose contents are being watched or tracked by the ".git" folder we just created with git init
, this is what version control is. At this point git can see changes being made to the repository contents, the ".git" folder contains everything git needs to perform its wizardry, in here you'll find whats commonly refered to as the skeleton of the repository, if you're interested in knowing what exactly this folder holds, here's a cool read I found
Git Clone
git init
allows us to create a git repo on our local machine, but what if we don't want to create a repo from scratch, what if we want to just take an existing repo from somewhere and bring it to our machine locally, thats where git clone
comes in.
99.9999999..% chance of the time you'll find a git repository on the web from sites like Github, Gitlab or Bitbucket. Cloning is exactly what it sounds like, its git's version of copy-paste. After initializing or cloning a repository we probably want to start doing some work, adding files, changing file contents, removing, including media, documents or anything we might be working on. git status
asks git to show us the status of our repo. Git will show all changes to the repo as "unstaged" and "untracked" for new files.
Git Add
Now that we have a working repo and we've made some changes to it's contents, ideally we'd want to capture the current state or version of the work we've done, we do this by committing our changes, but before we can commit we must:
git add
This will stage changes made, we specify what we want to stage by providing the name of the relevant files git add filename
or we can just make our lives easier by adding everything all at once with git add .
When our changes have been staged, that means we're ready to commit or capture the version of our work before we move onto adding more things to our repo.
Git Commit
So up to this point we've done some basic things with git, we haven't done any of the cool things that git allows us to but thats kinda beyond the scope of this article. We began by Initialinzing a repository, we tried another approach of working in a repository which is Cloning from a host, we then started adding and modifying our repo's contents and Staged everything we did. Now finally we want to Capture the current version which we're happy with. For that we run:
git commit
Git commit will prompt us to enter something called a "commit message", this is where we'd want to describe what we worked on and why, in future articles I will explain the commit message a bit more but for now just know that we want to say what we've done here. If we don't want to be prompted we can add a flag to git commit
like so:
git commit -m "our message here"
The characters after "master" in [square brackets] represent our current version, this is the ID of our commit to which we can always "time travel" back to in the future, but that again is beyond the scope of this article.
A visual representaion of what we just did so far might look something like this:
Top comments (0)