Wild Wonder S1 E2 — Remote GIT
Far off in a remote digital land! 📡
This next section steps into the remote parts of GIT. We will be using GitHub, other code hosting platforms for VCS’s are available at local stores. (See my previous article here!)
Remote GIT repos
Remote repos make GIT a collaborative powerhouse! You can use many different providers for remote repos including GitHub, GitLab and BitBucket. All work well and do what we need them to so again pick your flavour, make an account and enjoy! You can make remote repos through their websites choosing name, privacy options and other add-ons depending on the service you use. Once created you should get steps for linking the new repo to your local machine. You may even give you a set of pre-filled CLI commands to copy and paste. In the future, it’s up to your situation if you’re going to use them or not. Here we will go through the standard GIT commands to know what is doing what. All we will need from this page is the URL to the GIT repo which should be easy to find after you create the remote repo. In your terminal, you can run the command git remote to show the remote repos linked to this local project. In this case, none should show up so to connect it to the remote repo you made run the command git remote add origin <your-remote-repo-URL>. In this command origin is the name of the remote repo which is the default most of the time. Otherwise, add in the name you changed it to, and then you can paste in the URL of the repo you copied earlier! This then links it all together so if you run git remote it should show origin as the listed remote repo! You can also use the command git remote show origin to get some more info to see the URLs and the branches on the repo as well! There shouldn’t be any at the moment but we’ll get there!
GIT Push
Pushing in GIT is how we send our lovely collection of code from our local machine up into the cloud to our remote repo. This action takes all our commits and sends them to the remote repo so you’ll need to remember to add and commit your code before you try to push anything. A good practice to get into is to commit often and then push once your task is complete. The GIT command requires 2 arguments the name of the repo (origin usually by default) and the branch you want to push, in our case our only branch, master. So the command git push origin master will send our local branch up to our remote repo! BUT WAIT!!! The command we actually will use needs to be git push origin master -u this -u flag will set the origin remote repo as our upstream remote. We don’t need to worry about what exactly that means yet. Only that it will help us when we get to git pull in a little while. When you go back to the webpage for your remote repo you should be able to refresh the page and see your pushed code in the remote repo! In some remote repo websites, you may be able to edit this code online. It is great when you need to correct a typo or something small. You should be able to then commit that change right there on the remote repo no push needed!
GIT Merge
So you may have realised or might not even have thought about it but we now actually have 2 master branches! The remote and the local branch, if you didn’t make a change on the remote branch website and commit it then do so now so we can play around with merges! But first, we will need git fetch to tell our local repo to go grab the new data from the remote repo. It won’t put in place the changes into our local code as we are on our local branch, not our remote branch. If you take a look at the branch heads, you can usually use your IDE to see the branches, Master should be the local and origin/master for the remote. We will need to merge the remote branch on top of our local code. The command will be git merge origin/master giving you a nice update message in your CLI where you can see which files updated!
GIT Pull
If you have used GIT before or looked over the shoulder of a coder you may have seen they don’t use the git fetch & git merge very often. For a simple fetch and merge you can use a git pull origin master command instead! This does the beauty of both commands in one and saves the time of having to do 2 commands, Also remember that -u flag we used in our push command before? (git push origin master -u if you forgot and can’t scroll up). We don’t actually need to specify the origin master branch as that was set into the git config file so a simple git pull will do just fine! As long as you have no uncommitted changes on your local branch. Otherwise, you’ll need to commit them or stash them (more on stashing later). Additionally, if your local and the remote are changing the same line of code you will get a merge conflict that we will deal with a little later as well!
GIT Clone
Cloning is real and ready for anyone to use! This is perfect for when we are pulling down a new remote repo onto our local machine for the first time.isa When you clone a repo it will write all the files onto your local machine and a reference to the original repo. This means you can continue to pull and fetch from the remote to keep updated with any other changes pushed to that remote repo. Additionally, the history of the repo will pull in as well! To do this you can run the git clone <remote repo url> command to pull the repo down to the directory you’re currently in. You can also add a new name after the command and URL to give a name to the directory it will pull down and into a new directory. You can then do a nice git log command to see the history of commits for the repo and check what everyone has been up to!
This is the second section of the course I followed and my learning so far. I hope you have enjoyed and follow for the next part where I cover the collaborative powers of GIT!
Thank you for reading my second Wild Wonder! 💛
