Getting started with Git and Github

As a software developer, collaborating and interacting with other developers is frustrating sometimes that’s why we have Git and GitHub.

Git is a version control software. It was created by Linus Torvalds, the guy who invented Linux. You don’t have to be running Linux to use git–you can use it on Windows and Mac, too. Git lets you easily keep track of every revision you and your team make during the development of your software. You all share one repository of code that is worked on independently and then merged back together. You also do not need to be connected all the time because the project is both saved locally on each machine and remotely.

Terms you need to know:

Repository: Often referred to as a repo. A repository is the collection of files and folders that you’re using git to track.

Commit: Think of this as saving your work. When you commit to a repository, it’s like you’re gathering up the files as they exist at that moment and putting them in a time capsule.

Push: Pushing is essentially syncing your commits to the cloud (again, probably Github). You can push multiple commits at once, too. You can work offline, commit lots of work, and then push it all up to Github.

Branch: You can think of your git repo as a tree. The trunk of the tree, the software that goes live, is called the Master Branch. That’s the one that goes live. The branches of that tree are, well, called branches. These are separate instances of the code that offshoots from the main codebase.

Merge: When a branch is free of bugs (as far as you can tell, at least), and ready to become part of the primary codebase, it will get merged into the master branch. Merging is just what it sounds like: integrating two branches together. Any new or updated code will become an official part of the codebase.

Clone: Cloning a repo is pretty much exactly what it sounds like. It takes the entire online repository and makes an exact copy of it on your local machine.

Fork: Forking is a lot like cloning, only instead of making a duplicate of an existing repo on your local machine, you get an entirely new repo of that code under your own name. This feature is mainly used for taking an existing codebase and going an entirely new direction with it, which happens a lot in open-source software; developers see a base idea that works but want to go a different way with it.

Pull Request: A pull request is when you submit a request for the changes you have made (either on a branch or a fork) to be pulled (or merged) into the Master Branch of the repository. This is where the magic happens. If the pull request is approved, you will have officially contributed to the software, and Github will forever show exactly what you did.

GETTING STARTED:

How to Install Git:

For Linux, open the terminal and type sudo apt-get install git-all.

On Windows, it’s just as simple. You download the installer and run it.

On Mac, you just need to open up the terminal and type git.

Using Git:

After installing Git, create a GitHub account.

Now go to your terminal and introduce yourself to Git! To set your username for every repository on your computer, type

git config — global user.name “<your_name_here>”

Now tell Git your email, and make sure it’s the same email you used when you signed up for GitHub

git config — global user.email “<your_email@email.com>”

After that, you are ready to create your first repository. Go to GitHub. Click on the plus sign(+) on the upper right corner and select “New repository”.

Type your repository name and click on “Create repository” and you are all set.

Commands to clone a Repo from GitHub:

• git clone https://github.com/username/myfirstrepo.git
• cd myfirstrepo — or whatever you named your repo.

Adding and committing to a Git Repository:

• git status — This command will show you what files have not been added to the list for the next commit. In most terminal apps, the unadded/added files will be red/green, respectively.
• git add . — by adding a . at the end of the command, you’re telling git to include everything in the directory. If you want to add a single file, just use its filename. Such as functions.php.
• git status — Depending on if you used the . or the filename, whatever you added should be green now.
• git commit -m “add empty files” — When you commit these files, you should also leave a quick message to let your teammates (or your future self) know exactly what was in that commit. Standard git conventions say that you should be as concise and specific as possible, and start the message using the present tense of the verb.

Pushing to a Remote Git Repository like Github:

• git status — You should always check to see how things look and to make sure you’re on the correct branch.
• git push
• Enter your username and password for Github — Be aware, the password field will remain empty, even as you type. It’s okay. Just type it out and hit enter. If you used SSH, you will skip this step.

You can go to your Github account and check the repo, and your files will be there, commit messages and all!.

Branching and Merging:

The final two commands you’ll need to be familiar with deal with branching and merging.

• git checkout -b “branch1” — This command will both create a new branch that you title and swap you over to it as your working branch. It combines both the git checkout and git branch commands into one handy-dandy line of code.
• Create index.html — a new HTML file that I will merge back into the master.
• And like before, you will git status, git add index.html, git commit -m “create index.html”
• git status again will let you see that everything is as it should be.

If you try to push it before you merge, you will get a message that you need to set the repo’s origin. Origin is a strange naming convention for what your computer considers the remote repo.

You can switch back to the master branch with git checkout master (there’s no checkout -b this time because you only use that on the creation of a new branch, not swapping.

At last merging:

• git status — As always.
• git merge branch1 — Since everything in that branch is fine, we can go ahead and merge.
• If we git status again, we will see that we’re ahead of origin/master by 1 commit. That means that we haven’t pushed all the changes we’ve made to Github.
• git push to sync things up!

And that’s it! Congratulations! You just rocked your basic git workflow.