(Yet another) Terminal and Git Basics Guide

Photo by Hendri Brits on Unsplash

The Terminal and Git might sound terrifying at first, but they’re tools created by human beings like you and me in the end, and once you get used to some of their concepts they will become powerful tools in your arsenal, it doesn’t matter if you’re a developer or not.

This is an extension on my other post: (Yet another) Basic git guide.

Terminal

A computer terminal is a tool that allows us to interact with a computer’s Operating System in a very simplified way, using commands (kind of like keywords) to communicate with the OS and have it perform tasks for us.

In general the most common actions you’ll be using the terminal for are traversing your filesystem and opening files (using commands like vim/nano or invoking programs with a UI like VS Code). Some of the most commonly used commands are:

  • vim <file_path>: Open a file in vim. Good luck getting out of there.
  • nano <file_path>: Open a file in nano. Easier to get out of that vim.
  • code <file_path>: Open a file in VS Code. Sometimes using a text editor with a regular UI helps.
  • pwd: Displays the absolute path to the current directory you're on.
  • cd <directory>: Switch directories. You can specify absolute (the ones that start with a /), relative directories (they don't start with a /, might use . or ..) or special symbols/wildcards like .. (go one level up) or ~ (shorthand for your home directory)
  • ls <directory>: Works the same as cd but lists contents of directories instead of navigating into them. Takes multiple flags, like -a to display hidden files, and more.
  • (Mac OS) open <directory>: Opens a directory in Finder.

For more commands take a look at this terminal command cheat sheet:‌

Git

Git is a version control system, currently the most popular of all available and the de-facto way of storing code and documentation in general. It helps in both ease of tracking changes and for concurrent work between teams.

Git is distributed, which means it doesn’t exist on a single server/computer. Each person working on a repo has a local copy of it in their computers which needs to be conciliated, or updated, with the destination computer before pushing changes to it. This destination computer is called a remote in git terms.‌

The most common commands are:

  • git status -s: Lists all file changes in the repo since the last commit. (Using the -s flag is a personal preference. It displays a clean and concise list of changes).
  • git checkout [-b] <branch_name>: Used to checkout (or switch) to another branch. When specifying the -b flag it will create a new branch and switch into it.
  • git add [path_to_file_or_directory]: Used to stage a file. Or start tracking it when it's a new file. You can specify a directory instead of a file too. Using the . wildcard will add all changed/new files under your terminal's current directory.
  • git stash: This will take all changes in your working directory (i.e. anything that's not committed) and save it aside in what's called the git stack, which is a parallel storage structure to the git log.
  • git commit [-m "<commit message here>"]: Used to commit your changes to the git log. After executing this command the newly created commit only exists in your local repo. If you want to push it you need to use git push.
  • git push: This will push any new local commits to the remote server. bringing it up to date with your local copy of the repo/branch. Depending on how you setup git locally you'll need to specify a remote and a branch, or specify nothing. In most cases your push configuration will be set to simple, and git push will only push the current branch to the remote.
  • git reset: A complex command that allows you to reset or restore previous state. There are multiple arguments this command can take depending on which action you want to perform. Read more on "Undoing things" and git reset Usage.‌

Further information on:‌

Pull Requests

Pull requests are not part of git but a layer on top of it, provided by Github. PRs allow teams to review, make comments, suggestions, etc in a simple and very visible way to changes being introduced into the codebase by other members of the team. As well as adding an extra verification step to the process of making changes to code in the master branch, that's usually the code that's deployed in production.

Further documentation: About Pull Requests — Github

--

--

--

Senior Software Engineer and Web Developer. Specialty Coffee Enthusiast. I write about software development, project management and other stuff occasionally.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to update your Linux Kernel to the latest version (or older)

Data migrations in Ruby on Rails

A Futures Library for Asynchronous Programming in C++

How to add chat in Flutter app, fast, and also make it beautiful?

Drupal And Wordpress

Versus

Webdesign is dead, long live Webdesign!

Edit /etc/hosts file in Ubuntu Command line using nano IDE

Asset Protection Law

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Fernando De Freitas

Fernando De Freitas

Senior Software Engineer and Web Developer. Specialty Coffee Enthusiast. I write about software development, project management and other stuff occasionally.

More from Medium

Knowing These 10 Secrets Will Make Your Website Look Amazing

.NET is not a programming language!

Create Pickup & Delivery App Like Makespace (On-Demand Storage)

Best 5 Technology News Websites