git Walkthrough
Demonstrating a simple workflow.
Introduction
This is a introductory-level walkthrough of creating a repository, making changes, and pushing those changes to a remote/central repository with git.
It was presented to a small (60) group of developers in March of 2017 and can be viewed on YouTube. The slides can be viewed on Slides.com.
It was produced to demonstrate a developer workflow in which a developer works alone, on one task at a time.
git init
Let’s start off in an empty directory called things (prove it with an ls -a). This is my “things” project. I’ve decided I want to track this project with a git repository. We run git init to accomplish that.
git init
the .git folder
This command “initialized” a git repository right inside the “things” directory. Notice (by running the ls -a command) that a folder named .git was created. This folder is the git repository. If you delete it, your no longer have a git repository. Conversely, if the only thing you have is the .git folder, they you have the entire git repository with both the data and the metadata.
keep out ☠️
You shouldn’t modify the contents of the .git folder.
distributed
We mentioned that git is “distributed”. This means in part that the repository we created is a fully functional git repository and that a server component is optional.
git status
git status will be your best git friend. It tells you the status of your local repository. You’ll use this command a lot. (Enough that you could justify a shell alias to save a few characters of typing each time.)
git status
The output of git status tells us which branch of the repository we currently have checked out. By default a “master” branch is created. The “master” branch is always created by default.
I’m not sure why it says “Initial commit” since we haven’t committed anything yet. It might be a placeholder produced when we initialized the repo.
It then tells us that there is “nothing to commit…” and gives us some hints about what to do next.
The orange and green line is not command output. It’s my shell prompt configuration. But notice I’ve configured it to tell me what directory I’m in (orange), and what git branch I’m on (green).
don’t ignore the output
Unlike the output of a successful npm i command, git message typically provide important information. git will sometimes make suggestions if you mistyped a command, and in some cases git will tell you why it couldn’t perform the requested command and even explain how to correct the problem. I’ve helped more than one person that thought they pushed their code up to the master repository even though they hadn’t.
git add
Let’s add a file to our project. This project is contrived. But the git commands and process we follow are real world. Thing 1 and Thing 2 are Dr. Seuss characters in The Cat in the Hat book. Let’s model one in JSON. Run the following commands.
touch thing1.json
Add some content…
{ "name": "Thing 1", "color": "orange" }
git status
untracked files
Git now tells us that we have an untracked files which means it’s new.
staging area
Git has a handy “staging” area. Files in the staging area will be included in the next commit. We add files to the staging area with the git add command. If you run it with a period as the last parameter it tells git to add everything. There are other options including naming the files individually. You don’t have to add all the files to the staging area, and often you won’t. In our simple contrived example we want everything.
git add .
In this case, “no news is good news” and the add command was successful. git status is our friend so let’s verify.
git status
Now the new files are listed in the “Changes to be committed:” section. This means they are in that “staging” area and so will be included in the next commit.
git commit
Use the git commit command to record changes in the staging area into the repository. Commit requires a message describing the changes. You can supply the message with the -m'message' parameter, or you can omit it and an editor will be launched and git will wait for you to save and exit the editor taking the contents of the editor as the commit message.
git commit -m'Add model for Thing 1'
The commit was successful and git provided a bit of statistics for us.
git log
To see a history of commits use the git log command.
git log
git remote
Now that we have something in our repository, let’s hook it up to a remote or central repository. Git is “distributed”, so you could work peer-to-peer, but I’ve always seen it used with a central repository. Go create a repository in GitHub, Bitbucket, or another provider, then come back here and we’ll hook them together.
We use the git remote add command to tell our local repository about the existence of a remote repository. It’s typically called “origin”. Use the URL provided by GitHub/Bitbucket…
git remote add origin <url>
If successful this command will not produce output. Run git remote if you want to verify.
git push
We’ve told our local git repository where to find the origin, now let’s push the code there.
git push -u origin master
The first time we push we need to tell git that there is a relationship between our local master branch and the master branch on origin. The -u origin master flags do that. The git terminology is set upstream. Future push (and pull ) commands on master can be done with just git push
Next
In the next article I introduce a workflow that supports team collaboration and continuous integration. It demonstrates branching and a rebase.
