How to Use Git

When I was first introduced to Git and Github, I was taken aback by the complexify of just trying to do version control. I thought there were too many intricacies needed to just change one thing. Looking back at that time, I wish I would have had a simple guide of everything that Git is comprised of. This is what this post is supposed to be. I hope it helps.

You can use Git on the command line to do version control or close, fork, pull, and merge repositories. With Git, you can always roll back to a previous version and you can go as far forward or back as you want.

Using Git in the Terminal

You can use your regular terminal or use the terminal in your IDE to follow these instructions.

Default Process

1. Open your terminal and navigate to the file you want to do version control on is.
2. git init
   1. This initializes an empty Git repository in your current directory
   2. This will create a .git file in your current directory (Only visible if you adjust your view or ls -a in the terminal). It will be used to track your changes, commit changes and do version control.
3. git status
   1. In order to start tracking the changes of the files, you need to add the files to a staging area. This is an intermediate place where you can pick and choose which files in your directory you want to commit.
   2. Files in red here are files in your current directory but are not yet in the staging area
4. git add .
   1. . adds all of the files. You can also specify what file you want to add by typing the name of the file.
5. git status (again)
   1. You will now see the file in green meaning that the file is now in the staging area and is ready to be committed.
6. git commit -m “initial commit”
   1. -m stands for message and should be included in every commit. The message helps keep track of what changes you’ve made on each commit. Be as explicit as possible about what changes have been made.
   2. These messages are written in present tense by convention. (ex: Complete chapter 1 instead of Completed chapter 1).

Review commits

1. git log
   1. Shows you what was committed, at what time, and by who.
   2. Also includes a hash, to identify each commit.

If you already initialized git and are making modifications

1. git status
   1. See what new files are in the directory that are not being tracked aka not in the staging area.
2. git add .
3. git status
4. git commit -“complete second and third commit”
   1. remember to write your message in present tense.
5. git log
   1. View all of your commits
   2. (HEAD –> main) is the current state that we are in.

Check the differences between your current version and the last save point

1. git diff filename.txt
   1. Part in red is what has been deleted
   2. Part in green is what has been added

Revert back to the last commit in your repository

1. git checkout filename.txt
   1. This command rolls back the file to the last version that was committed in our local repository.

Pushing Local repository to [[GitHub]] remote repo

1. git remote add < origin/name> < url >
   1. Telling your local git repository that I’ve created a remote repository somewhere on the internet and I want to transfer all of my commits there.
   2. Theoretically, you can name origin anything you want. It’s just the name of your remote, but origin is used by convention and highly recommended to use.
   3. Reason is because programmers are used to the conventional naming.
   4. In URL you will just paste the url of our remote repository on GitHub.
2. git push -u < remote name/origin > < branch name/main >
   1. This line of code will push your local repo (.git) to the remote Github repo using the -u flag which will link up your remote and local repos.
   2. Main is the most common branch name, others use master instead.
   3. Depending on the size of your local repo this can take some time.

![[Pasted image 20231110201451.png]] The local repository is the .git file inside of our finder directory and the remote repository is GitHub which hosts our code and hosts all of the changes that were made between all of the different commits.

Why have a staging area and not straight from the working directory to the repository?

• Because you might not want to add all of your files to be tracked and committed. Staging area is a good place to tell git what to ignore and what you do want tracked.

Each version is given a name via the commit message.

Remove Files From Staging Area

1. git rm –cached -r .
   1. Removes all of the files in the staging area
   2. The -r flag stands for recursive
   3. The . means that all of the files from the staging area should be removed

.gitignore

You can add files you don’t want to commit to GitHub to the .gitignore file. These files could be secret files, or anything else you don’t want in the open.

1. Open a terminal
2. touch .gitignore
   1. Git is looking for this specific file so the exact same case and wording.
   2. Touch creates a file
3. ls -a to view the file in the command line
4. Inside of .gitignore
   1. Specify the file you want to ignore in each line of the file
   2. You can comment using a #
   3. You can use an * as a wilcard which will ignore all of the files with a certian extension is used as follows: * .txt, * .log. (With the asterisk and dot together. Can’t do it in Obsidian)
5. When you git add now, the files in .gitignore will note be added to the staging area.

Git Clone

Cloning a GitHub repository will take a repo hosted in GitHub and download it to your local repo on your computer.

1. git clone url
   1. The URL will typically be from GitHub
      1. Go to the repo and click on ‘Code’ and copy the HTTPS clone URL
   2. A way to pull all of the versions and all of the commits of a remote repo and store them in your local directory.
   3. This allows you to stand of the shoulders of giants and continue where they left off.
   4. You will continue on your own branch of that project.
   5. You will have your own copy of a program that someone else wrote.
2. The objects will be received and loaded on your present working directory. You can then cd into the repo’s folder.

Pull Requests Merging & Branching

You can create a branch and start committing to the branch to experiment on an experimental branch. Simultaneously, you can commit code to the main branch. If you end up wanting to merge the new feature you can easily merge them back into the main branch.

• Usually, there are many branches being worked on simultaneously. This is because people are developing new features, fixing bugs, and all of these things may break the main project. Only put into the main branch once you know everything is working fine.

Branching

1. git branch name-of-branch
2. You can check what branches you have by just writing git branch without the branch name
   1. The asterisk * will show you which branch you are currently on
3. git checkout name-of-branch
   1. Switch to the branch you specify

Merging

1. git merge name-of-branch
   1. This opens up the Vim text editor and allows you to type out a merge message or you could just leave it empty.
   2. To close out Vim type :q! to save and quit.
   3. The previous branch will still exist.
2. git push origin main -u

Forking and Pull Requests

Forking: Copy others repositories. You can then clone the repository to work on it localy. Pull Request: If a GitHub user only has read access to a repo, they will need to do a pull request (Kind of like a suggestion for the repo owner). We can’t push because we are not owners of the repository.