The cliché about programmers is that we are reclusive introverts who prefer to interact primarily with our several computer monitors, preferably in a gloomy environment. We only leave our battle station/fortress of solitude/code dojo when we have a biological need to eat, sleep, or go to the toilet. We never communicate with others unless it is (a) absolutely required or (b) as our online RPG avatar self (irresistibly well-endowed high-level mage/warrior). This, like other stereotypes, has some basis in fact. Our interests as programmers push us to interact with machines more, and probably more effectively, than with other humans.
However, living as a software engineer is far more social and collaborative than clichés would have non-coders assume, and can be frustrating at times. Fortunately, there is git: version control software that allows project team members to collaborate on the command line.
This “Git for Dummies”-style course is intended for non-programmers who need to cooperate and communicate successfully with coders. We’ll begin with the fundamentals of what git is, why we use it, and how to get started. You should be able to approach a developer in their native habitat by the end of this tutorial!
What Exactly Is Git?
Git is version-control software used to collaborate on group projects. Collaboration as in group dynamics, equitable project burden distribution, and who ate the last jelly doughnut, but in the real mechanics of passing work back and forth. When a week’s worth of shared project progress is unintentionally destroyed or rewritten, or when a failed file transfer consumes hours of work, things can get, well, nasty.
git is a computer program that allows multiple coders (and project managers, testers, content providers, and anyone else on the team) to collaborate on a single project, similar to how Google Drive allows multiple contributors to write, edit, and add to the contents of a single text file.
If you have little or no programming expertise, learning git can be frightening, but simply think of it as a funny-looking Google Docs and you’ll be great! Linus Torvalds, the same Linus who founded the Linux open-source operating system that now powers enormous swaths of the internet, including Google and Facebook, invented git.
So, git is a piece of software that you install on your computer to manage version control. So, what exactly is version control?
What Exactly Is Version Control?
Assume you have a completely fresh project. Obviously, you intend to keep all linked files in a single new directory. These files will evolve as the project advances. A lot. Things will become unorganized, even untidy, and, at some time, utterly messed up. If only it were possible to go back in time to the most recent not-messy, still-working version of your project at that point!
It is now, thanks to git. When you install git on your computer, you enable version control. Git is designed to generate that new project directory and track all changes you make to any and all files in that directory. As you make changes and additions, git takes a “snapshot” of the current version. That is version control, my friends: make a minor change, take a snapshot, make another small change, take a picture…Also, keep all of your photographs in chronological order. You may then use git to go back and forth through each version of your project directory as needed.
When you make a mistake, git is like having the magical ability to go back in time to the last decent version before you messed up. As a result, version control is used. Git is not the only version control system available, but it is most likely the most popular. It is also required for accessing GitHub, the most widely used public website and platform for hosting and sharing projects. It is not the same as git; rather, it is a repository for projects that use git version management.
We’ll simply go over GitHub briefly because it’s vital to grasp what git performs first. However, using GitHub requires a completely different learning curve, which we will cover in our upcoming course.
Working together with Git
As a single person working alone on a single project, it’s simple to understand. Consider working with a large group of people who all need to use the same project directory. You will make modifications to your share of the project while working locally on your laptop, and your colleagues will do the same on their respective PCs. How do you share changes with collaborators while also having their modifications appear in your local working version? How can you ensure that anything you’re working on doesn’t clash with or crash something else you’re working on?
Git is a version control system that is distributed. This means that git includes commands for “pushing” your modifications to other people’s machines and “pulling” their changes to yours. Meanwhile, GitHub keeps a master version of the project — technically, a master library of all the versions ever — to protect things from going too wild and crazy.
It also allows everyone to push and pull changes from a centralised repository, so if one of your coworkers is off ill for a week, things don’t get bogged down because you can’t access their portion of the project because their laptop is at home with them in Flu Central. Again, more on this in “Getting Started with GitHub” next time.
Getting Git
Step 1: Download Git
Select the appropriate one for your favourite operating system: Mac OS, Linux, or Windows. It will install itself. Don’t be concerned if it appears like nothing is happening.
Step 2: Launch Terminal
I’m sorry, but you’ll have to resort to the command line. So, keep quiet and shell: You already know what to do, Linux users. It’s Finder -> Applications -> Utilities -> Terminal for Mac users. Windows users (why are you still here?) will need to download and install a terminal emulator.
If you’re paralysed in fear because you have no idea what to do or how to do it, head straight to the fantastic Command Line Crash Course and work through it (it only takes a couple hours and will leave you feeling like a code commando, I guarantee!).
Step 3: Inform git that you exist
It is now time to enter your name and email address. Enter the following, substituting the values with your own name and email address.
global user.name “John Doe”
global user.email johndoe@example.com git config
global colour.ui ‘auto’ git config
Please keep in mind that the last line is optional; it instructs git to automatically color code any output of git commands in the terminal, making it much easier to read and understand. We put “-global” in front of each to prevent having to type these configuration commands the next time we start a git project on our machine. So, git will always know who you are.
Step four: Make a new directory.
It’s now time to practice creating a sample project. Create an empty directory to contain all of your lovely, soon-to-be-existing project files (hint: $mkdir). (yourDirectoryNameHere). Then insert a CD and enter the magic words “git init”:
“git init” generates a new git Repository, also known as a “repo.” Consider it your project’s folder, but with git superpowers. A repository contains all of your project files as well as extra, mostly invisible information generated by git to track and keep the revision history of each file.
Enter the Git Workflow
You have now built a repository on your own computer. The extra stuff git added consists of three distinct “trees” — don’t worry, these are completely controlled and maintained by git. The Working Directory, which includes your real project files, is the major location you interact with. There’s also the Index, which serves as a sort of temporary holding area for your most recent modifications and additions. And the Head, which points to the most recent saved version — the latest Commit.
Pro tip: every git command you type into the terminal must start with “git”: the format is often “git do whatever.” This instructs your computer that you wish to activate git rather than the other terminal options available.
Step 5. Add a “README” file and project files
It’s a good idea to start by writing a “README” file that explains what your project is, what might be found there, and so on. (A project README does not need to be exhaustive — just the essentials, ma’am. It is also not written at this point — we are just setting up the directory). By the way, this is a basic command line task, not a git-specific one: “touch README.md”:
You are in charge of adding the real project files because you are the one who knows your project parameters. Simply repeat the preceding steps with the relevant file names.
Step 6: Make a copy of your repository.
In this stage, we make a working copy of your local repository — your current project — so you can play around with it without fear of breaking anything.
Working from a copy is essential, especially when working in a group! You save everything as you go if your task goes smoothly. (that will be our next step). Finally, all of the changes/additions you just made are added back to the original repository, and the current version is created. Meanwhile, others are doing the same thing in their own cloned versions, which rapidly diverge from your copied version.
The beauty of git is that it keeps track of everything for you — who changed what when and where — and orchestrates it all.
So use the command “$git clone /path/to/your_repository:” to duplicate — or clone, in git-speak — your repo.
(If you want to begin by cloning a file that someone else has already started, from any remote/server, your command will be “$git clone username@host:/path/to/repository”).
Notice how we now have a copy directory of git-for-dummies inside our original git-for-dummies directory. (next to our README). It’s telling us that we appear to have copied an empty repository because we haven’t stored our new items yet. (staged our commits).
Step 7: Check the status
(Behind the scenes, I added a placeholder file called “my_file.md” so we have something other than the readme in our repo). Now that we’ve added some files to our repository, let’s see how git handles them. Type “git status” to see the current status of your repository:
Step 8: Instruct git to include your modifications.
Git status informs us that there are new files that have not yet been added to the git tracking process. We add them to git to notify git that, sure, please be the sweet delicious concierge of these files. This is referred to as “staging” them, despite the fact that the command is “git add (file name here)”:
Take note of how the text colour has changed from red to green: you have made git very pleased! You can commit your files to git after staging them with “git add.”
Step 9: Make a git commit!
Consider each commit to be a snapshot of a point in time to which you can return if necessary to access your repository in a previous state.
A commit message is used to identify each of these snapshots. This is a brief summary of what transpired between the previous version and this, the latest and greatest. Provide a useful commit message since it assists you in determining what you modified in that commit — this is the sole place where viewers can see not only what has changed, but also why. So it’s important giving each commit message some thought — consider what you’d like to know about the material you just added or updated in the future. This is a fantastic essay about writing useful commit messages; read it, do the things, and you will be grateful in the future.
Having said that, your first commit message when creating a new repository is always “Initial commit.” A commit message is written in the following format: “$git commit -m “my commit message”:
Git assigns a lengthy hexadecimal number to each unique commit in order to identify it. Notice in the snapshot that “313b28b” is our first commit. This is similar to the caption on your photograph. It’s known as the hash of your commit. You can consider of it as your commit’s id. This is the “name” you would use to identify the version you want if we needed to go back in time and retrieve this specific version of our project.
Step 10 does not exist since YOU DID IT!!!!
In the snapshot above, we did a “git status” after the commit. The nice message “Nothing to commit, working tree clean” was returned by git (remember our trees? If not, return to the git Workflow section above). This indicates you’re fully caught up and up to date. Your project’s snapshot has been taken and saved by git. Though at this stage, it looks like a baby photo.
However, as your project evolves and flourishes, you will take numerous snapshots to chronicle the experience. That is, commit frequently. So you can literally go back in time to when your project was younger and more innocent… ah, if only there was a human version…
Ahem. So, Git has your back…at least on your own computer for now.
Coming up next is Part 2 : How — and-What — to-Gitignore
#YouAreAwesome #StayAwesome
