Learn to Code via Tutorials on Repl.it!

← Back to all posts
Complete Git, GitHub, and Version Control Tutorial with Replit.
OldWizard209 (1638)

Introduction.

This tutorial is a complete guide to get going with Git, GitHub, and understanding Version Control. Sometimes you don't always work on replit. Let's say you have to work on a project locally on your computer, using VSCode, and later you need that code on replit to share it with a friend or submit an assignment. This would be really tedious if everything was done manually, but now, along with Replit and Git/GitHub, this is a very easy task.

Prerequisites.

Because this tutorial is for general purposes, I am going to ask you to install Hyper Terminal. To use Git, we need a terminal, on Mac, its different, on Windows, it's different. So to generalize things, go ahead and install Hyper so that you can follow along. Also, to use Git, we need to install Git, so do that also.

Install Hyper.

Install Git.

GitHub

Git and GitHub are the same things, except that Git uses commands and everything happens locally and is updated into your GitHub account. Everything you can do on Git can be done directly on GitHub, but explanations for both interfaces will be done simultaneously.


Version Control.

What is Version Control?. The answer is on the words themselves. When you have a code file that you are constantly working on, you continuously need to keep updating the code. Let say I have a code file like this:

def func(name):
  print(name)

func("Leo DiCap")

This is version 1 of your code uploaded to your repl, but later, as your code progresses, you change it into this:

def intro(name:str, age: int):
  print(f"Your name is {name}, and you are {age} years old.")

intro("Leo DiCap", 46)

Now, this is version 2, but let's say, you don't like this bit of code, and you want to go back to the previous version. To do that, you can just ask Git to roll back to version 1, and you are all set. This is Version Control in its simplest form.

Quick Setup.

Let's get started on Version Control with Git. To begin, open up a HyperTerminal Window:

Firstly, I am going to go into my Desktop, and make a sample directory for this project using the commands cd and mkdir:

[email protected] MINGW64 ~
$ cd Desktop/

[email protected] MINGW64 ~/Desktop
$ mkdir sample_dir

You should see a folder with the name "sample_dir" on your desktop. Now, cd into the "sample_dir" directory and create three files, using the touch command: f1.txt, f2.txt, f3.txt.

[email protected] MINGW64 ~/Desktop
$ cd sample_dir/

[email protected] MINGW64 ~/Desktop/sample_dir
$ touch f1.txt f2.txt f3.txt

Now, write some random sentences in the txt files for reference. Of course in the real world, it is code, but for now, let's keep it simple.

To use Git now, we initialize it using git init which will create a git file in your directory. Now we are all set up.

Version Control with Git.

Now, to use Version Control we need to track changes on the files. To do that, we bring all the files we need to track onto the staging area. To see untracked files, use the git status command, and all the files in red are untracked. To add on the staging area, we use git add. For now, we will only add f1.txt. So far:

[email protected] MINGW64 ~/Desktop/sample_dir
$ git init
Initialized empty Git repository in C:/Users/blurred/Desktop/sample_dir/.git/

[email protected] MINGW64 ~/Desktop/sample_dir (master)
$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        f1.txt
        f2.txt
        f3.txt

nothing added to commit but untracked files present (use "git add" to track)

[email protected] MINGW64 ~/Desktop/sample_dir (master)
$ git add f1.txt

Now, git status will show f1.txt in green. Let's commit these changes using git commit -m "<message>". You might need to use a git config command to authorize. To see all the commits, use git log

[email protected] MINGW64 ~/Desktop/sample_dir (master)
$ git commit -m "first commit"
[master (root-commit) 0ea04f3] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 f1.txt

git status now shows f2.txt and f3.txt as red. Lets add them all into the staging area using git add . and now the status should be green. Finally, once again, commit the files, git commit -m "committed f2, f3".

NOW. There is a big issue. You had commited these files onto your repository, but mistakenly, you fell asleep on your keyboard and your file is now all gibberish.

This version is now destoyed. How do you fix it? That is where our "savior" comes in: VESION CONTROL.
que dramatic music.

On git status our modified file is red. That is because it is not comitted. Now to check the difference, we use the command: git diff. Th red shows the previous version, the green shows the changes.

But to actually rollback, we will use git checkout f1.txt, and our file is restored.

A simple visualisation:

GitHub and remote repositories.

If you don't have a GitHub account, go ahead and make one.

Remote repositories(repo for short) are basically hosted on GitHub. To create one, click the plus button on your GitHub account and click "New repository".

Now create a new repository by the name of "Sample", and give a description of anything. After you've done this, you will be greeted by a page that shows you how to set up a repo from the command line:

We are going to push an existing repository from the command line. To do so, first copy the link on the top of the screen.

Next, in the command line, to add all the commits we did on the Local Repository, we use the command, git remote add origin <the link you copied.>. The word origin in the command can be changed to anything, like potato, but origin is the programming convention, and its best to stick with it. The link in my case will be https://github.com/OldWizard209/Sample.git, so the entire command will be:

git remote add origin https://github.com/OldWizard209/Sample.git

Now that this is done, we need to push our local rep onto the remote repo that we created. This is done with this command:
git push -u origin master. The u command links up our repos and transfers/copies the files onto your remote repository. master basically is the main branch in your repo. Branches will be talked about in detail later. Next, if you reload you repo on GitHub, you should see all the files uploaded there:

You will also be able to see your commets on Insights > Network:

Gitignore.

Gitignore is a feature in Git that can allow you to prevent committing specific files. This is useful when you have personal API Keys, Tokens, Passwords etc, and you don't want to upload them on GitHub as other people can easily see them. To test Gitignore, lets create a sample directory with a bunch of files.

[email protected] MINGW64 ~
$ cd Desktop/

[email protected] MINGW64 ~/Desktop
$ mkdir Project

[email protected] MINGW64 ~/Desktop
$ cd Project/

[email protected] MINGW64 ~/Desktop/Project
$ touch file1.txt file2.txt file3.txt secrets.txt

[email protected] MINGW64 ~/Desktop/Project
$

Our secrets fies contains this:

API Key: 85NSWF41898RBXD5Q27FDNX
Password: jhYRFb5547!vv$

To actually use gitignore, we need to create a gitignore file, and put in all the files we don't need to show others. Gitignore files are created traditionally; touch .gitignore. Now in the gitignore file, we write down the names of the files we want to ignore.

Now if we add all our files into the staging area, you will see that secrets.txt has not been added:

Cloning

Cloning is one of the simplest concepts in Git. Cloning is simply getting any remote repository from GitHub and bringing it into your own local repository. To clone a repository, go to a particular repo, and copy the link on the left side of the interface:

Now to bring it into your local repo, run the command git clone <link>, in our case:

git clone https://github.com/yenchenlin/DeepLearningFlappyBird.git

Branching and Merging.

Let's say you are working on a project and you ahve already commited once to your repo with the base essential code. Now you commit once more with the main logic of your program. But now you don't want to mess with the already written code, but you still want to try new features.

Thats is when branching comes in. You will create a new branch and start committing into that one without disturbing your main branch with all the meat and potatoes. Later, as your feature development in your side branch finishes, you can merge the two commits creating one single file:

Now lets put this to the test. cd onto the sample_dir we made in the beginning. To create a new branch, we will use the git branch <name of branch> command. Lets do that in the terminal: git branch change_plot. If you want to check out the branches you have, just run the git branch command.

But we are still on the master branch. To switch branches we use git checkout change_plot. And now if I change some text from the files, it will still be the same in the master branch.

change_plot branch:

master branch:

Make sure to add and commit before changing branches.

Now if we want to merge the two branches, we use the git merge change_plot while in the master branch. Similarly, if you want to merge two branches, you can do that while being in a specific branch. Now if we put this up into the remote repo, git remote add origin https://github.com/OldWizard209/Sample_Dir.git, and go into the Insights > Network, we will see our beanches, and merges:

Forking and Pull Requests.

Lets say you work in a team and you need to collaborate with your team members. But the problem is, you own a repository and your team members can't change anything in it. This is where Forking comes in.

Forking allows other users to take a copy of your repo, and clone it into their own local repository, make changes to to it. After this they can commit the changes, and push them into her remote repository. Now if they want to bring the changes into your repo, they have to make a Pull Request.

A Pull Request is like a suggestion or a branch created by another user. If the owner is OK with the changes, they accept the Request and merge it with their own branch. To create a Pull Request, you have to go to the Pull Request tab and create one from there.

GitHub Repos with Replit.

Replit provides Version Control in the command line as well as in the user interface tab on the left. You can import an existing GitHub repo by navigating to the 'Version Control'. After making changes, you can even commit and push.

Creating Repos:

Commiting And Pushing

But to do this, you have to first connect GitHub on REPLIT. Do this by going to Profile > Edit > Connected Services > GitHub:

Thats it for me. Do me a favor and Star this on GitHub

Comments
hotnewtop
OlauPla (162)

I haven't read it already but I've been meaning to read one of this thanks!

RayhanADev (2621)

Is this a repost? I feel like I've seen this before...

OldWizard209 (1638)

yes it is, I had to change a few things in the post, but it got all messy to a point where i thought i'do rather delete it and make a new post. @RayhanADev

OldWizard209 (1638)

once again, one of the most deserving mods. @RayhanADev

Whippingdot (681)

SINCE WHEN WHERE YOU A MOD @RayhanADev

RayhanADev (2621)

@Whippingdot I think sometime last week? It's a pretty recent thing lol.

Whippingdot (681)

@RayhanADev :O you finally listened to me LES GOOOOOOOOO RAYHAN NEW MOD ~~but now i am indecisive you are my best and first friend on replit yet dynamic is an awesome mod...who is better...🤯