Learn the most used version control by programmers.
In this article we're gonna talk about the most common commands to get started with git.
We are going to use Github as our git remote repository of our project. Create your free account if you haven't yet and let's git started!
First, we need to install git by going on their website and following the instructions on how to install it. https://git-scm.com/downloads.
Open your terminal and let's configure git.
> git config --global user.name "YOUR NAME"
Set email: ( Use your email associated with your Github account )
> git config --global user.email "YOUR EMAIL"
You can double check them by entering command:
> git config --global user.name > git config --global user.email
Initialize Git In your Project.
First lets create a sample project directory which will be named
sample-git using the
mkdir command and directly going inside this newly created directory by using command
cd and we are going to combine those two command into a single command separated by
;: and cd into it:
> mkdir ~/sample-git; cd ~/sample-git
Now lets initialize our git:
> git init
Adding remote repository
Before we dive into commands about remote repository or 'remote' let's understand first what is a remote repository. A remote repository is just like a folder that was put somewhere in the internet hosted by an organization. A remote repository will store all the files that you've sent to it and it will create versions of those if modified so that programmers can roll back if there was a problem from the current version of their project. Programmers can pull and push files from the remote repository, pull means to retrieve and push means to send files to the remote.
So!...We can now dive into command examples about remote.
To show our remote repository:
> git remote
There are more than one type of remote repositories, or 'remote'.
For example, you might have a remote repository on Github, but there are also platforms like Gitlab or Bitbucket.
Right now, our project doesn't have a remote repository yet. However, we can create a local remote repository on our machine for now. We will learn to push files to a remote repository like Github a little later.
To create our custom local remote repository, first, let's create a directory for it and cd inside:
> mkdir ~/sample-remote; cd ~/sample-remote
Now, lets initialize this directory as our remote repository:
> git init --bare
We can now use this as our remote repository. Go back or cd into your project directory and let's add the local remote:
> cd ~/sample-git > git remote add local ~/sample-remote
Here, 'local' can be changed to whatever you prefer, but for my example, I will use 'local.'
touch is used for creating a file but it is only supported by Linux and Mac computers, so if you are a windows user then you can use the hacky way of it using the
At this point, we can now start making some changes to our project. For this article, we will be adding a README.md file.
To create a new file for mac and linux:
> touch README.md
> echo "" > README.md
Working Directory Status
To display the status:
> git status
The Command will display the following:
staged - a file that has been added.
unstaged - a file that has not been added, or a modified file.
untracked - a new file that did not exist before.
Since we're creating a new file, it should display the untracked files, for example, our README.md file.
Staging a file means that you are adding files to the local remote repository.
To stage a file:
> git add -A README.md
If you have a lot of unstaged or untracked files that you want to add at once, then you should stage them in this way:
> git add --all
Before we can push our project changes to our remote repository we need to commit the files. This means writing a message about what the file is for or what the changes are. This is what is called the commit hash.
> git commit -m "YOUR MESSAGE"
Show Commit History
Displaying the commit history:
> git log
The command will show the commit history. That includes the commit hash, author, and date.
Commit hashes can be used to pass commits from other branches or roll back to that commit change.
Push to Remote
Now that we have committed our changes we are now able to push the unstaged and untracked files to our remote repository.
To push changes:
> git push local master
Now we have learned the basics of storing our source code.
For more cool stuff, using Github as our remote repository also opens us up to lots of great features.
First login into your GitHub account and create a new repository. For now, name your repository as the same name as our example if you're following along.
Just copy the URL provided after creating the repository.
Remember how to add a remote from the above commands? You just have to change the Path and the name local to origin. Path can be the url of your remote repository which will be given by the remote repository service provider when creating a repository or path can be a directory in your machine that acts as a remote repository.
> git remote add origin PASTE_HERE
When you show remote repositories, you will now see two remote repositories: local, and origin.
To push our commits to GitHub we use origin. In this case, the command will be:
> git push origin master
If we want to push to our local or to any other services like Github we should use the name that points to that path of the remote repository.
Creating a branch is like duplicating your project in another version of it but still, you can merge branches to your main branch which will commonly be the Master branch.
> git branch YOUR_BRANCH_NAME
Use that branch:
> git checkout YOUR_BRANCH_NAME
If you don't want to use separate commands you can do shortcut:
> git checkout -b YOUR_BRANCH_NAME
It is the combination of two create branch and checkout branch.
Pulling / Fetching Changes
When working with multiple programmers sometimes your local copy of the project will get behind.
> git pull origin master --rebase
You should pull every morning or every time when there are changes because if you pull updates too often then you will suffer fixing bigger conflicts. That doesn't mean that if you always pull, you won't get any conflicts. But it is still possible to not have conflicts when you haven't started any changes yet if there might be then maybe it is not that bigger.
And that's it! I hope you can start using git in your everyday coding.
Thank you for your time reading this article and remember:
Always study and let curiosity do the work!