Repl.it + Git Tutorial
GIT on repl.it
Git is a version control system for programmers. It allows programmers to collaborate easily, and makes sure the integrity of the project stays intact. Git is used all the time in professional environments, and now houses millions of projects programmers like you have made. Although alternatives exist, nun of them have reached the same level of fame as git.
How do I get started?
Create a new repl, or open an existing one. Then on the sidebar, click the git icon (it looks like a branch) and you'll be greeted with a warm welcome.
Click "Create a git repository", and tons of buttons and words will popup. At first it's a lot to take in, but by the end of this tutorial it'll make sense. Repl.it integrates with GitHub so you can host your code online. If you don't have an account, you can make one here. Once you've done that, we need to connect your repl.it project to a repository. Repositories are simply folders that contain your code, just like your own computer would. You can decorate your repo with 'badges' and links, but we'll save that for another tutorial. Click the "Connect to Github" button and you'll see this popup.
Repl.it will fill in the github name with the repl's name, however you can change that if you so choose. Then provide a description for the repo. Make it short and sweet, as you'll have a chance to add a longer description later. You now have the option to make your repl public, or private. If your project is public, anyone can see your cool work, and if they really like it, they add or change some of your code to make it even better. Of course, you'll first need to approve the change before it's applied, or make changes to their change. Being public isn't for everyone though, and you may want to keep your code to yourself. The choice is up too you, but won't effect how repl.it interacts with your repo.
So, what do all these buttons do?
Let's start from the top. You should see a branch dropdown, which looks like this:
Branches are used so that people can organize their changes. Your master branch is your current, working code. Instead of pushing changes to master, create a new branch by clicking the "+", and create a branch named "development". This way, you can organize your thoughts, which is very useful if you want other people to contribute.
After working on your project for a while and you're ready to finish, click "commit & push".
Now, if you switch branches, you'll see that master does not have the same code as the development branch, this is not a mistake. To "merge" the code back into master, you need to create a "Pull request". Go to your GitHub repository, and you should see something like this:
Click "Compare and pull request", and write a description of the change. Once you're done, click the green "Create pull request" button.
Congrats! You made a pull request! Now people and comment and review the changes. GitHub will tell you if your changes are compatible with the master branch. Some times this is not the case, which at that point you'll have to merge the code by hand. Thankfully, this does not happen often, and GitHub makes it easy to do anyways. Any further changes made to the development branch will be reflected in this pull request, allowing changes to be made if people have made suggestions. When the pull request has been reviewed, you can click the green "Merge pull request" button. This will combine the development branch into the master branch. Github will then ask if you want to delete the development branch, which you can always recreate later if you'd like.
If you return to you repl, and switch to the master branch, you should see a new button appear.
Repl.it has detected that changes have been made to the repository, and your current program is out-of-date. Click "Pull <-" to update your code. Repl.it will update your code to reflect your repo, and you can continue to work!
Congrats! That's the basics of git!
Git is a massive program, it's impossible to cover everything at once. Checkout the GitHub tutorial for even more information. In your search, you may see tutorials that explain the usage of git on the command line. Just know that instead of using the nity grity git commands, repl.it does most of the work for you. I hope you found this tutorial useful, and be sure to comment any questions you have. Happy gitting!
Hi great feature, but can you please add buttons to unlink and change Github repo for repl's version control?
Many times i need to change Github repo or remove them. Also when i fork repl the old one Github repo is there still linked.
I think that this would be helpful for many others people.
Suppose, I already have a github repo and already have a repl too. Now I want to merge the 2, any options for that?
Great to see this.
Are there any plans to support some other source for remote repositories, like own ssh or other providers like GitLab?
I just imported a web app from github, and then forked it to create a brand new web app, but the version control is still tied to the old repo. How do I fix this?
Thanks for the helpful tutorial, I have a couple of questions.
When you merge a pull request and delete the branch on GitHub, is the branch deletion supposed to be synchronized also to the local Repl.it repo? Do
git commands run from the REPL shell affect the local repo and the remote repo on GitHub?
1. Currently the branch sticks around. It will be gone if you clone again via a new repl. I'll take a look at preventing the branch from appearing after a delete
2. if you do an action that affects the origin in any way (e.g. git push origin master), it will effect github when connected. Read/local actions (e.g. git checkout, git stash etc.) will only affect the local repository. An important thing to keep in mind is that currently any actions done via the shell that edit your files will not persist if you refresh the page.
For #1 it would be useful to synchronize such branch actions. Without the ability to syncrhonize at least manually (e.g. by running Git shell commands), the local and remote repos may quickly diverge. And the Repl.it branch selector may become cluttered and not scale well to the amount of development, experimental, and bugfix branches of typical projects.
Which brings me to #2. Are there any plans to eventually make Git shell actions persist?
@PaoloAmoroso I definitely hear you on #1. Branches will always syncable with remote via the pull button (which you only see if you're behind), but we should support removal of branches once they are deleted from the remote.
#2 yes! but this is tied to an underlying architectural change so I don't know when we'll be able to do it.
It does not appear that repls are synced with GitHub. Having worked on Visual Studio Code on a different device, committing my changes, and then opening replit to continue my work on a different device, my changes were not reflected on replit. However, upon creating another replit based on the same repository, the changes were reflected just fine.
Unfortunately not working for me the right way it should. Yesterday everything worked, then today I made some new changes to the GitHub and it doesn't update the code in the repl when I go pull.
Can you make it so that when we use the Download as Zip option, the .git folder is also included so the repo information doesn't get lost? As of now, it seems the files are just downloaded as they are in the current working tree, all the repo information is left out.
How can I remove branch from the version control branch list??
Question: I created a new repl based on:
Now I have an Version-control entry: freecodecamp (this is not my account)
How can I change Version-control to my own github-account?
@21natzil Thanks for your answer. I created a fork - actually the fork created itself automatically (my username was shown in the repl.it-path correctly). I even tried forking it a second time but it didn't help, there was always the same version-account.
But I found another solution: I forked that github-repository (in github), created a new repl and imported the forked github-repository. That worked!