Git for the New Developer - Three Ways (Part One)
And then, you are introduced to the command line.
Most new developers are unfamiliar with the command line (check out my series on The Command Line and You) and are baffled by its inconsistent command names, abbreviated option parameters. Throw in SSH or sudo and you quickly discover why GUIs (Graphic User Interfaces) were invented.
It seems strange that our operating systems are collections of icons, window and menus, but we still have to use the command line, with virtually the same set of instructions it was born with, to use something that seems so basic.
The primary reason why Git is a command line program is that developers like to make Bash or Powershell scripts to automate tasks, and in order to do that, the program needs a CLI (Command Line Interface).
Some new developers turn around and try something else, giving up before they even get started. The Command Line can be daunting. People who understand how to get the most out of it -- those who know the intricacies of grep and ssh and all the other tools that empower you to control the low-level aspects of your operating system, or that of a remote server -- make it seem easy. But for the average developer, especially the beginner, all you want to do is write some code. Why is it so complicated? Isn't there an easier way?
The answer to that last question is yes. There are actually sever very robust GUIs for Git that can keep you off the command line, and a couple simple solutions that are free and easy to use, especially for the novice developer.
The First Way - Git CLI
In Part One, we'll look at GitHub Deskopt, but first let's review the basic git commands that one needs to get started.
git clone - this is where you start. You grab the URL for your repository, either in ssh or https format and append it to this command to make a copy of your original repository on your local computer.
git status - the most helpful of the Git command line commands. Gives you information about the status of your repository, and hints about what you should do next.
git add - Git needs to know about files you want it to track. You tell it which ones with this command. You can feed it a list of file names, or use the -A option to take them all.
git commit - This creates a commit or version of your repository. Don't forget the -m "commit message" option (with the message text in quotes) otherwise it'll throw you into some funky text editor that's even more alien than the command line. (Mac users, it's [Esc]:q! to get out of it.)
git push - just like you'd guess, this pushes your changes to the remote origin (GitHub in our case).
git pull - and if you need to pull changes from the remote origin, use this.
Here are a couple of resources that go into detail about using the Git CLI. Some of them touch on branching and other features, but for this article, I'm just going to focus on cloning, committing, pushing and pulling.
Okay, I promised to make your lives easier using Git. Actually, GitHub is going to do that for us. They have a nice little GUI called GitHub Desktop. Here's a link to Downloading and Installing GitHub Desktop.
The Second Way - GitHub Desktop
The Second Way - GitHub Desktop
Once it's installed and launched, you'll see this very inviting welcome screen.
The very first big helpful button is Cone a repository from the Internet...
This is exactly what we want to do. (You should create your repository on GitHub before you try to clone it.)
When you click on that button, you'll see a dialog box that gives you options of where to clone your repository from. We're going to keep it simple and stick with GitHub for now.
Then Sign in with your GitHub username and password.
Next, you'll see a list of your repositories on GitHub! Here's where the easy part comes in.
Select the repository you want to clone, then click on the Clone <username>/<repositoryname> button at the bottom.
GitHub Desktop will fill out the form with the URL from GitHub. All you need to do is make sure the Local path points to the appropriate location. I always select the GitHub folder I keep in my Documents folder. This way, I know where all my GitHub repositories are on my hard drive, and I reduce the risk of putting one repository inside another one.
You'll see a progress bar telling your what's happening. Then, you'll see what your repository looks like in GitHub Desktop.
Across the top, you'll see three large tabs. The first one allows you to select any of the repositories GitHub Desktop knows about. (You can add more either through cloning or if you have previously cloned via the CLI, you can add an existing repository to the GitHub Desktop environment.)
The second tells you what your current branch is. You always start with a master branch. For this post, we're not going to do any branching, we just want to keep to the basics.
The third is an action button that changes depending on what you need to do with your repository. Fetch means that GitHub Desktop wants you to check with GitHub to see if there are any changes there that we don't know about yet.
The left sidebar had two tabs of its own. Changes, and History. Initially, there are no changes, but if you click on the History tab, you'll see the first commit that was made when you created your repository on GitHub.
Switch back to Changes. In the main panel, you see the status of your repository on your local computer and some actions you can take. If you have Visual Studio Code installed (and you should!) you can click on the button to open this repository directly into that editor. You can also view the repository with Explorer (or Finder on Mac) or view it on GitHub.
It gives us some key information: "No local changes" and then offers some friendly suggestions for what to do next. It's basically the GUI version of git status. One of the options is to "Open the repository in your external editor." If you have Visual Studio Code installed, you should see a button that will open your project (repository) in Visual Studio Code. If not, you can go to the menu and select File > Options, then click on the Advanced tab and select Visual Studio Code as your external editor (assuming you have it installed)
So, let's pretend that you've opened your project in VS Code, made some changes, added some files and folders. Let's come back and see what GitHub Desktop looks like then.
So, once you press the Commit to master button, you've done the equivalent of git add -A, git commit -a -m "Created initial site files". Do you know how to undo a commit? I confess I would have to look it up. But if I made a mistake, GitHub Desktop gives you the option to Undo.
Let's do some more work on the project and come back to GitHub Desktop after we've made some changes and added some more files.
Here we can see in our login.html file that some lines have been removed, others have been added. You might notice that I actually just edited the <input> tags and added a name attribute. But Git doesn't recognize changes at the character level, it does so at the line level. So from Git's perspective, you deleted those original versions and added new lines.
Let's assume I want to do another commit at this point. Now, when I look at the tabs at the top, I still see Push Origin, but the it's telling me there are 2 commits ready to go.
You'll see the progress of the bush overlaid on the tab.
And that's it. You've created a couple of commits, updated GitHub, and we never once visited the command line.
One more thing before we leave GitHub Desktop that may come in handy for you. Click on the History tab of the left sidebar and you'll see a list of your commits, the newest on top. From here, you can see what files were added, updated or deleted from your repository, and for text files, the lines that were changed.
You can do this on the GitHub website, but it's much easier and faster to review your commits from GitHub Desktop than the Code view of your Repository.
In Part Two, we'll look at the Third Way - VS Code
That could come in handy!
Now that I've made some changes, GitHub Desktop has added a new option to the "friendly suggestions." I can now Push 1 commit to the origin remote. You'll also see that the action tab at the top is now labeled, "Push origin." Clicking on either will do a git push for you. (I'm going to not do that yet so I can show you something else about it a little later.)
Here we can see in our login.html file that some lines have been removed, others have been added. You might notice that I actually just edited the <input> tags and added a name attribute. But Git doesn't recognize changes at the character level, it does so at the line level. So from Git's perspective, you deleted those original versions and added new lines.
Let's assume I want to do another commit at this point. Now, when I look at the tabs at the top, I still see Push Origin, but the it's telling me there are 2 commits ready to go.
You'll see the progress of the bush overlaid on the tab.
And that's it. You've created a couple of commits, updated GitHub, and we never once visited the command line.
One more thing before we leave GitHub Desktop that may come in handy for you. Click on the History tab of the left sidebar and you'll see a list of your commits, the newest on top. From here, you can see what files were added, updated or deleted from your repository, and for text files, the lines that were changed.
You can do this on the GitHub website, but it's much easier and faster to review your commits from GitHub Desktop than the Code view of your Repository.
In Part Two, we'll look at the Third Way - VS Code
Comments
Post a Comment