Beginning Git and GitHub by Mariot Tsitoara

Beginning Git and GitHub

A Comprehensive Guide to Version Control, Project Management, and Teamwork for the New Developer
Mariot Tsitoara

---

$ git init # Initialize a new git database
$ git clone # Copy an existing database
$ git status # Check the status of the local project
$ git diff # Review the changes done to the project
$ git add # Tell Git to track a changed file
$ git commit # Save the current state of the project to database
$ git push # Copy the local database to a remote server
$ git pull # Copy a remote database to a local machine
$ git log # Check the history of the project
$ git branch # List, create or delete branches
$ git merge # Merge the history of two branches together
$ git stash # Keep the current changes stashed away to be used later

---

Basically Git works as follows: you modify the files, add each file you want to include in the snapshot to the staging area (git add), then take the snapshot and add them to the database (git commit). For the terminology, we call a modified file added to the staging area “staged” and a file added to the database “committed.” So, a file goes from “modified” to “staged” to committed.”

---

You can create a new branch by using the “branch” command and checking it out with the “checkout” command.
git branch add-new-dev-name-to-readme
git checkout add-new-dev-name-to-readme

---

Navigate back to the master branch by using the “checkout” command.
git checkout master

---

To get the changes from the remote server (also called origin).
git pull origin master

---

You can merge your branch with the “merge” command.
git merge add-new-dev-name-to-readme

---

The PATH environment is a variable that holds a list of directories where executable programs are located in their value. It’s needed so you don’t have to type in the full path to an executable when you want to execute it in the console; you just have to type its name. For example, to launch Visual Studio Code from the console, I should type C:\Program Files (x86)\Microsoft VS Code\bin\code. But since I have C:\Program Files (x86)\Microsoft VS Code\bin in my PATH, I just have to type code to launch it.

---

To set up Git, open Git Bash (for Windows systems) or the default console window (for Linux/MacOS or Windows systems that modified their PATH environment). In the command prompt, just tell Git your name and email address:
$ git config --global user.name "Mariot Tsitoara"
$ git config --global user.email "mariot.tsitoara@gmail.com"
Notice the “global” argument; it means that the setup is for all future Git repositories, so you don’t have to set this up again in the future.

---

With the config command, you can also change your default editor. If you ever want to change your editor because you found a new one or uninstalled yours, the config command is there to help you. For example, to change the default editor to Nano, you would type
$ git config --global core.editor="nano"

---

You can find the file recording your Git configuration on your home folder. For Windows, you can find it in :\Users\YourName.gitconfig. For Linux and Mac OS, you can find it in /home/yourname/.gitconfig.

Next to the .gitconfig file, you might find another file called .bash_history that records all the commands you type on the console. You can check this document if you want to check back on a command you forgot.

---

$ mkdir mynewproject
$ cd mynewproject/
$ git init

mkdir is a command used to create a directory; it is short for “make directory.” cd is the command used to navigate between directories; it is short for “change directory.”Finally, git init means initializing a git repository.

mkdir and cd are system commands; they are managed by the OS,
whereas init is a Git command. Every Git command begins with “git.”

---

The empty area outside the “.git” directory is called the Working Directory, and the files you will be working on will be stored there. Generally, your most recent version will be on the Working Directory.

---

touch README.md
// creating a file

---

Before taking a snapshot of the project, you select which changed files to take account of. A change in a file can be creating, deleting, or editing.

---

If we wanted to stage a file named README.md, we would use “git add README.md.” Or if you created multiple files, you can add them one after another or together like “git add file1 file2 file3.”

---

use git rm --cached <file>... to unstage

---

Since a commit is a snapshot from the state of the project, the previous state of the project is another commit called “parent.” The very first commit is created by Git when the repository is created, and it’s the one commit that has no parents. All future commits are then linked to each other via parentage. The ensemble of those commits that are parents to each other is called “branch.”

---

If a commit has two parents, that means that it was created by merging two branches.

---

A commit is identified by its name, a 40-character string that is obtained by hashing the commit. It is a simple SHA1 hash so multiple commits with the same information will have the same name.

---

A reference to a specific commit is called “head,” and it also has a name. And the head you are currently working on is called “HEAD” (see the previous section).

---

If a file was part of the previous commit and you didn’t modify them, they will automatically be part of the next commit. A modified but unstaged file is considered as unmodified. You have to ask Git to track them by staging those files.

---

Remember that the .gitignore global file should be placed at the root of your repository. If you put it in a directory, only the matching files in that directory will be ignored. Generally, having multiple .gitignore files in multiple directories is considered as a bad move unless your project is enormous. Prefer listing them into a single .gitignore file placed at the root of your repository.

---

If you are using a computer language or framework, you can go to https://github.com/github/gitignore to get a template of the .gitignore file you should use.

---

If your commit history is very long, you can use the keyboard and go
• Forward or backward one line: key up and down OR j and k
• Forward or backward one window: f and b
• At the end of the log: G
• At the beginning of the log: g
• Get help: h
• Quit the log: q

---