Background

Ok, it's been a long time since I wrote a post. I thought maybe something super easy would be helpful for me to get going again. A few months back I did my first hackathon for an open-source project with Code4Sac. It was a great experience and one of the best things I gained was working with git for the first time on a project with other people. I know there are many ways that teams use git together, but I thought I would write up a quick list of commands you would want to know to get started working with others, as well as what they do. Finally, I'll sum it all up with a basic workflow example using all the commands.

Getting Started

Ok, first things first. You want to start a new project. Where do you start? If I was new to git/GitHub and wanted to have the easiest setup, I would start by creating a repo on Github. Starting this way will allow you to avoid having to hook up your existing project on your local machine with the remote repository on GitHub. (Yes there are sites other than Github, but if you are starting that's probably where you are)

So, head over to Github, make a new repository for your project then let's get started with the commands...

The Commands

git clone

With a brand new repo, you get an area that says "Quick Setup with a link to your repo. Copy that.

Alternatively, in an older repo, you'll have a nice green button that says "Clone or Download". There you can copy a link.

Head over to your terminal, then navigate to the directory you would want to have your new project in. Here you are going to enter the command:

 clone your_repo_link_here

Typing this command will make a copy of the entire repo on your local machine within a directory that has the repository name, and link it to the repository.(You can also copy the repo into the current directory, just place a "." at the end of the command)

git pull origin master

With a new project, you wouldn't need to pull, but after you start working on your project, or once you are working with others contributing to a project you'll need to make sure your repo is up to date. You do this by "pulling" the code down from your remote repository. We do this with:

 pull origin master

A quick note on what a REMOTE repository is. When you have git running on your computer locally, that's a repository just like the repository on Github. The term remote refers to a repository somewhere else. Most often when starting out, especially in this tutorial, the remote repository is also the "origin," where the repository was originally cloned from. But you could have multiple remote repositories, set up across different computers for example, and be able to update all of them from one computer. In this case, the remote repository just means the repo on Github we started with

So, basically this is the command you would use to make sure your local repo is up to date with the repo on Github. In this case, we are pulling from the origin, which is the remote repository that the project was cloned from (we cloned it from Github, so it's the origin of the repo) and we want to pull the code thats in the master branch.

In the future, you might work on other branches on the repository, in that case, you could pull down the code from Github by typing git pull origin whatever_branch_name_here.

git checkout

Ok! so let's says you're going to be doing some work now in your project. Generally, you want to do your work on a branch. A branch is essentially a copy of the project at a given point in time, and it allows you to work on the codebase without actually working on THE codebase. In a production environment, the idea is you wouldn't want to be directly editing the code that's running the show, so you take a copy, work with that, and later on combine your edits into the master branch, where all the magic is actually happening.

My favorite way to make a new branch is to use the command git checkout -b new-branch-name. Technically there is the git branch command to make a branch, and git checkout command to switch to a branch, but the git checkout -b with a name after allows you to make a new branch and switch to it all at once!

git add

Alright, so it's been a few minutes now and you've got some code typed up. You want to get that code on your local machine up to Github now everything is synced up. First, you need need to add the files you want to the "staging" area. Basically, up until this point, git knows you have made changes to some files but you have to say, "OK, not I am going to do something with all of these files here."

Super important note, you probably want to add a .gitignore file at the root of your project. In here you can add files to automatically ignore. You would definitely want to put in node_modules, as well as other things yo don't want to be tracked such as .env variables, or generated folders from things like Next, Gatsby, create-react-app, etc. You do this by typing the name of the file and/or folder on each line, separately.

I typically try and do this regularly as I work on each particular aspect/feature, so usually I add all my files at once to the staging area by typing in git add * but if you want to, you can add files individually by using git add filepath/name_here.

git commit

Once files are in the staging area, it allows us to make a commit, which kind of like saving everything at a point in history in git. Commits are nice because we can easily go back to certain commits if needed, as well as leave comments about what changes we made to help keep track of changes in our code.

So to make a commit, we use the command:
git commit -m 'descriptive message here'

That's basically it. The -m allows us to add a description immediately after.

git push

Now the part that actually syncs things up!

Thus far, basically everything has been on your local machine, but once you've made a commit (or a few) we can push all of the commits up to Github and the origin/remote repo online will mirror what we have on our machine.

Since you SHOULD be working on a branch, you would use the command:
git push origin the_branch_name

After pushing to the branch, you would be able to Github, see the branch, and do a pull request (or PR to the cool kids) that will pull the code from your branch into the master branch. Pulling your code into the master is what merges your changes to the master branch, which would be the main source of truth for everyone and the code in production (in most cases).

If you're being naughty or just working on your own project you might also do:
git push origin master
which bypasses the PR process and immediately pulls your new code into the master branch. Don't do that.

Workflow

Alright, so that's basically what I've used to get things done. But here is a scenario where you use all of them...

You're working on a project with a few people, it's been a few hours or days since you've worked on the project. You sit down on your comp and...

1. git pull origin master: Make sure everything is up to date! You might also pull from a branch you are working on instead of the master branch by using git pull origin branch_name.
2. git checkout -b some-branch-name: Make and checkout (go to) and new branch for your work, so you don't mess up what others are doing.
3. git add *: Add all the files you changed so you can make a commit once you've actually done something.
4. `git commit -m 'some helpful comment': Commit your changes so you can send the changes to the remote repository.
5. git push origin branch-name: Push all your commits up to the remote repository on Github to your specific branch.
6. Make a PR on Github. Your code after pushing is still in a separate branch online, so you need to make a pull request to merge it into the master codebase.

Nice job! You did work, kept everything synced up, and hopefully didn't screw up someone else's code!