Introduction to the Git CLI - Simple Commands

So I'll admit it, I've never been much of a CLI or terminal guy, however times are changing. As I've started to use JavaScript frameworks more frequently, it seems only natural to start using the terminal more frequently. Now I want to do all things in the terminal, but one last hold out I've had was using Git in the terminal. As a prior GUI interface user, it was always just easier to use VSCode or Visual Studio to do all the underlying commands for me and just push buttons instead. But like I said, times are changing and I wanted to become more of a power user via the CLI. As I've learned new things, I wanted to take you along for that journey.

Getting Started

So technically I am using Github for a large portion of my Git development these days, and technically there is a CLI for Github specifically, but for this, I'm going to stick to git commands directly. If you haven't configured Git for your local development machine, follow this guide.

So I'm going to walk through the generalized steps to getting started with git, as if you are using Github for an open source project. So the first most basic step to getting working with a repository, is to clone that repository locally:

More Information (+ Definition): Learn More Here

  git clone https://github.com/username/some-repo.git

If you want, you can optionally append a path to the above command, to specify where the system will clone the files. You can also specify just . to have it clone into your current folder. So for example:

  git clone https://github.com/username/some-repo.git .

Getting Your Code Added

So cloning is the most basic step to getting started with Source control, and honestly this was one command I've always used the CLI to accomplish, because it's just easier. The alternatives were always way more complicated. But now lets explore the world of committing changes to Source control.

So once you've cloned, this is usually where you'll start making your changes. Obviously if you've cloned an existing repository or a Template repository, you'll already have files in your repo, but for this exercise, we'll explore the initial steps to add files to be tracked by Git.

With a blank repository, it's time to start adding files. This could mean adding a Next Js app to your repository or just a simple Html file. Here I'll leave this a little up to you on how you choose to go. Now that you've got some files, it's important to understand the types of files that you might have. With any source control project, there is likely to be files that you want to share with the team, and local files that either has specific environment variables for your local environment, or build files etc. Committing those to source control will create issues, because every time anyone on the team needs to commit changes, they will commit their local environment changes or build configuration, leading to either unnecessary changes being in Source Control, or even worse than that, everyone's local environment breaking everytime they get latest changes from the rest of the team.

This we do not want, so lets explore the file that can help you get around these changes. The .gitignore file will allow us to commit a file that instructs git not to commit specific paths. Another useful file is the .gitkeep since you cannot commit empty folders into source control. If you have folders that are used for build output etc., you'll want these folders present, but empty, so the .gitkeep is your path to keeping everything present for your team of developers.

Once you've determined what you want to commit or what you don't, your first step is to instruct Git that you want these files added to source control. They will not be tracked until they have been added to Git to be tracked. Now this is where the Gui changes, it technically combines this step into one step (Add + Committing), so if you are used to the GUI, you will likely make changes and see even new files, ready to be committed, this is because it will handle both steps as one. But with the CLI, this flow is now a little different. (Although part two when we discuss Aliases, could be a better option to combine your commands)

You can add all files or just one files. Since we are just getting started, we'd like to just get everything added.

But Wait! How do you know if all your git ignore configurations are set correctly. Sure you can always add and then remove, but that just adds extra work, and no one likes that. You can actually do a dry run first, just to see what it would add if you did run the command for real:

  git add . --dry-run

So the above command will add all items, that's what the . represents, and then pass in the flag --dry-run just to see what your actions might do. If you see errors, nows your chance to update the .gitignore to ignore the correct files. But if you've run the dry run and everything looks good, now lets run the command for real:

git add .

So now you've added your changes, which basically means that they can now be tracked by source control, but you have not committed or pushed those changes to the remote repository yet. Another useful command is this:

git status

This command will give you a status of your situation. In my case, it tells me the branch that I'm working on (I'll cover branching in part two of this series), what commits I've made, and finally the changes waiting to be committed (and sitting in staging).

What is "Staging" you might be asking. Well there is an official definition, but really its just a queue where the files you want to commit to source control sit. But there is two queue's, one where files have changes and are ready to commit, and then staged changes which will be committed with your next commit command. So why is there a distinction there? Well sometimes you might not be ready to commit all of your changes, or you might want to committ your changes in multiple commits, either case, I have found this feature extremely helpful at times.

But once you are ready to commit your changes, its actually quite easy to do so, by using the following command:

  git commit -m "Commit Message"

I won't go into specifics of the art of naming your commit, but it should be descriptive of the changes that you are making. Working on a specific Jira ticket, go ahead and mention it. Make it clear so that any other devs working on this project later on, will understand what you changed and why. Once you've run that command, your local file system should no longer show any pending changes. But you aren't quite yet done. There is one last task to be completed. You need to push your changes up to the remote repository so that others can access your changes as well.

It's really actually quite easy to do that via the CLI as well. Just run the following command:

  git push

With pretty much every CLI command that you might run, it's possible to add the flag --dry-run to just see what the command might do. That way you can be sure what actions these commands will take.

That pretty much completes this guide. These are the basic steps needed to clone, add and commit changes to source control, using the CLI.