In this article we will learn how to use git and git hub. When it comes to development most tools that you come across have a limited shelf life but there’s one thing that remains consistent and that’s git it’s easy to take it for granted. But when you take a step back you’ll find that git has completely revolutionized the software world. It’s essentially a history book of your code and services like github make open source software accessible to the world.
What is Git? How to use git and github
So what is git exactly it’s a version control system but really what that is a system for managing your files. Building software is a series of small milestones where each milestone is just writing code a bunch of different files. Your app will constantly move from a state of chaos to stability. And git gives you a way to keep track of all of these changes. And it does so in a way that allows you to create multiple branches or paths. That you can go down and then merge them in later facilitating collaboration between large groups of developers.
So today I’m going to show you how this all works by building a piece of open source node software that we can all collaborate on. The software itself is a command line utility. That will allow you to encrypt your mailing address and then add it to the github repo. So I can mail you a sticker in my current working directory I just have an index.js file and a package.json.
I’ll go ahead and click on the source control icon and you’ll notice it says no source control provider is registered. The first thing we’ll need to do is initialize git to start tracking our files. There are two ways we can do this we can either do it directly in vs code or we can do it from the command line.
You should definitely try to memorize all the commands. it’s often faster to run them with vs code’s integrated tooling.
Initialize Git It – How to use github
First we’ll go ahead and run “git init” from the command line. You’ll see that initializes an empty git repository in our current working directory. You’ll notice it adds our two files to the changes list in the source control panel. This tells us which files have changed since the previous snapshot of the source code. Because we’re in a brand new project both these files have a “U” icon. Which means untracked or that their newly created on this working directory. When you initialize it get repo it creates a hidden get directory if you want to completely uninitialized it or remove it from your project.
you can just remove that directory using this command: “rm -rf .git” but be careful with that one.
Second thing is to install the GitLens plugin for vs code. It embeds all kinds of useful information directly in your code and gives you this extra panel where you can easily navigate your git history.
Git Ignore File
The next important thing when setting up a github repo is to create a gitignore file. You don’t want everything in source control. For example you definitely want to keep out any sensitive private API keys. And you’ll also want to filter out the source code for your dependencies like your node modules. Any unnecessary log files. Git will automatically look at this gitignore file and filter out anything that matches the file path or pattern.
You can create this file manually. But the pro way to do it is to use a VS code plugin to automatically generate all the defaults for your environment. That saves us a bunch of time and now we can move on to the next concept. How do I take a snapshot or a commit of my current working directory. A commit is like a page in a history book that has its own unique ID and can’t ever be changed.
Stage File
Without get knowing about it the first thing. We want to do is stage the files that we want included in this commit. Use stage files by running “git add” and you can add individual files or the entire working directory by just using a period. VS code makes it really easy to stage or unstaged files by just clicking the plus or minus button. You can unstaged files from the command line by running “git reset” but be careful with this one. Because there’s a hard flag and if you use it. It will not only unstaged the files but delete them forever. If we run that one right now on our new project it will delete everything. And we’ll have to start over from scratch.
And with that I’ll give you one of my most important pro tips which is to make many small commits. This practice will not only help prevent catastrophic losses of code but it will also just make your code changes a lot easier to follow.
Commit
Now we’re ready for our first command the first thing we want to do is run “git add” to stage our files. Then we run “git commit -m” flag to add a descriptive message about what we changed in our code a pro tip. Here is to use an emoji to get more github stars on your project. Because github stars are the best way to tell how good a software project really is.
And you can also make your comments multi line to provide a summary on the first line and then a more descriptive set of changes on the second line. You’ll notice that that takes the files out of the stage changes and gives us a clean working directory. It will tell us exactly which files were created modified or deleted as part of this commit.
Now if we go into our gitlens plugin you can see we have a history of code changes. That we can navigate through and see exactly which lines of code changed up. Until this point we’ve been working on what’s called the master branch. Which is like the main trunk on the tree that contains the actual source code that you’re releasing and delivering to your customers. So what happens when you have a stable code base and you need to fix a bug or you want to experiment with a new feature.
Branch
What you’ll typically do in git is create a new branch based on your most recent commit. And go and fix the bug on the separate branch and then merge it back into the master branch. Once it’s ready this means we can have multiple developers working on the same code base on their own branches without stepping on each other’s toes.
You can see all the current branches in your codebase by running “git branch” which for us would just be the *master.
you can switch between branches and git by running the check out command in our case the branch hasn’t been created yet. So we’ll go ahead and create it by using the -b flag. And we’ll give it a name of
“feature” so now any code that we write in here will be isolated to this branch.
Now we can fast forward into the future. You’ll see I’ve written a bunch of code in this branch so currently this code is just sitting in the working directory.
So I need to commit it to this feature branch this time I’ll run my commit directly in vs code.
Then we can switch back to the master branch. You’ll see that all of our new files disappear and we’re back to the original state on the master. At this point I’d like to point out that you don’t necessarily have to commit your files before switching to the master branch. There’s a another mechanism to save your work in progress if you’re working on something that’s half-finished or experimental.
Stashing
You can use a command called “git stash” this will save all of your current changes without committing them. Then revert back to a clean working directory. Then later at some point in the future when you want to get back to work. You can either pop or apply the changes in that stash to your current working directory.
It’s sounds like you’re stashing away your current changes to be used at some later point. So stashing is just a handy thing to know and an alternative to committing your code. If you’re not quite ready to do so in our case we’re all done building our feature. So what we want to do now is merge that feature into the master branch.
Merging
Now we’ll go ahead and check out the master branch. And then if we run “get merged” with the name of our “feature” branch it will merge the latest commits from the feature into the master. You’ll notice the commit ID is the same for both the feature and master branch.
So that was a pretty simple use case but merging is the place you’re most likely to run into problems. Because you might be working on a feature branch and then the master branch has changes. That eventually lead to merge conflicts. On the Left we have a line of code that we implemented in our feature branch. And then on the right we have a new change that happened in the master branch. While we are working that affected the same line of code. So merging these files is not possible out of the box because git doesn’t know which change to use.
When to merge
VS code will give you some options to resolve these conflicts. For example you might accept the current change, accept the incoming change or Both. When you run into a conflict you’ll want to first review it. And then a lot of times it’s best to just abort the merge all together. And fix the files manually I already mentioned that it’s a good practice to implement a lot of small commits. Because it’s easier to fix a conflict on one file as opposed to a hundred files.
Then in the previous example we merged a feature branch into the master branch. But a lot of times when you’re working on a feature you’ll want to merge the master branch back into your feature to get the latest code. Because if something on the master branch changes. It means someone could have been writing code in the same place that you’re writing code. Or there might be some breaking changes that changed the way your feature is going to work. So if you’re working on a feature for an extended period of time. You’ll want to merge in the master branch any time it changes or maybe once a day if it’s a really active repo.
Now there’s one last pro tip that I want to give you that’s related to merging a lot of times on a feature branch. You’ll create a lot of different commits and these commits are kind of irrelevant to what’s going on in the master branch.
You can see here that our feature branch is three commits ahead of our master branch. And it has a bunch of comments about adding useless emojis to the code instead of merging all of these commits into the master branch.
Squash Command for git or github
You can use the squash flag to squash them down into a single commit. When you do your merge this will keep the change history nice and concise on the master branch. But still preserve all of the original commits on the feature branch itself.
When you merge with the squash flag it won’t actually change the head commit on the master branch. So you’ll need to add an additional commit on your own that says something like merged in feature branch. And that gives us a nice compact change history on the master.
Push to Github – how to use git
So now that we know how to do all this get stuff locally. Let’s see how we can do it remotely with github pushing a repo to github is actually really easy.
First we just need to create a repository on github.
Then it will give us the commands to run to push our code to this location.
The first command is get remote which connects your local code to this remote repository. And the second command is get push which will actually push the files to the remote repository. So if we run the commands and then refresh the page. We should see our code is now on github that how we use git.
But the next thing I want to show you is how to take someone’s existing code. Fork it create some changes and then create a pull request to merge your code into another person’s project. And that’s exactly what you’ll need to do to get the free sticker. So this is the typical pattern that you’ll see when contributing to any open-source project. Step one is to fork the existing project forking will copy the code from the source. And make it a repo under your own github account. After you fork it you’ll then want to clone your fork to your local machine. So you can start making changes to it.
The git clone command just allows you to copy the code from a remote repository to your local computer once you have that cloned.
You can open it up in vs code. And in this case serial first want to run npm install to install the dependencies.
Then you can run git checkout -b flag with mysticker as the branch name which again will create and move you into this new branch.
Mailing Address
And then i’ve added a special command to this repo called “npm run address”. And that’s going to prompt you for the information that i need for your mailing address.
When you’re done with that it will print out an encrypted base64 string from there you’ll go into the stickers directory. And create a new file that’s your github username.txt.
Then you’ll copy and paste this encoded string into that file. so just a side note on security your address is going into a public repo but it’s encrypted with the RSA algorithm. This means that you are able to encrypt data with the public key. But I’m the only one with the private key that can decrypt it. I have the private key on a thumb drive which I’ll destroy after this giveaway. And hacking the private key by brute force is essentially impossible unless someone physically steals the private key. Your address should be safe in this public format but I do feel obligated to give you that disclaimer first. Now go ahead and save the text file.
Then run git add and get commit with whatever message you want to put in there. Now we have all of the necessary changes committed on our local machine.
Pull Request
We’ll need to push this branch to our remote fork for that we can just say git push origin with the branch name and that will push the branch to github.
Then on github you’ll see the option to create a new pull request a pull request in git is just like a merge. But it has the additional step of needing to pulling the remote changes. In other words a pull request is like saying pulling my remote changes and then merge them into the master branch.
So that’s how you contribute to an open-source project. I’m gonna go ahead and wrap things up there hopefully that leaves you with some of the basic tools needed to contribute to open source software.
Today you learn how to use git and github. For learning more article you can go to our blog page.
