Git 102 - Working On A Repo
Tags: tips, git
Published: 2023-02-06 18:07:37

---
title: Git 102 - Working On A Repo
description: Create a repository and start using git with ease
tags: ['tips, git']
---

Since you have already have a basic knowledge of what is Git and a few tools and providers to start with, it is time to get on with working on your repository.

## Creating A Repository

To work on git, you have to create a repository first. Depending on your choice, GitHub, Bitbucket, GitLab, etc. creating a repository may differ, but the main principles are the same. For instance, for GitHub and  Bitbucket interface you can click the plus icon and select "New Repository". When the page loads;

*   Choose a repository name (will be called MyRepo from now on)
*   Set the repo visibility either private or public (depending on your provider, private repositories may not be free)
*   Click Create Repository

Now you have a repository to work with!

## I Got The Repo!

Now it is time to clone your repository MyRepo from remote to your local. To do that, you have to find the "link" to that repository. Beware: if you have SSH keys already set up, you can use the SSH version. Otherwise, if you have no idea how to do it, you can use HTTPS. It is pretty unsecure compared to SSH, but for this tutorial series, we are only getting into basics.

*   SSH Example: `git@github.com:YourUserName/MyRepo.git`
*   HTTPS Example: `https://github.com/YourUserName/MyRepo.git`

Now time to get those links:

*   GitHub: Click the green button "Clone or Download" and copy the link below
*   Bitbucket: Copy the link on the overview page
*   GitLab: On the Project page, copy the link

## A Clone Of My Own...

Time to clone your repository! Since GUI clients have their tutorials, I will explain the CLI version using terminals instead. Don't worry, even if they are commands they are the common terminology and I will explain them step by step. So, I recommend you to read them to have a better understanding of what GUI clients do in the background. Here we go! First, find a place for your git projects. Find somewhere cozy, easy to reach, and without funky characters in the path. Change your directory to your Git folder

```bash
cd Git
```

Clone your repo into your Git folder. Don't worry, it will create the repo's folder inside. It will ask for your password since it already knows that you are trying to clone your repo.

```bash
git clone https://github.com/YourUserName/MyRepo.git
```

Now you should see a folder called MyRepo inside your Git folder. If you have enabled to view hidden folders by default, you should see a .git folder. This folder encapsulates lots of information related to your repository. Simply put, this is the bridge between your local repo and remote repo.

## First Of All...

You have a repository where you can share everything with collaborators. I mean, literally everything within your repository folder. Consider yourself struggling to find files to share within temp files, test codes, etc... Git has a solution for that! With an ignore file, you can simply filter out anything you do not want to share. Depending on your project, ignoring files can differ. You can already find a collection of [.gitignore file examples](https://github.com/github/gitignore) for different projects on GitHub which you should download and use on your repository root (within MyRepo folder). You can also add your filters to it by opening the .gitignore file with your favorite code editor.

## A Real Commitment

Since you have changed something, we can talk about git in depth. Git "stalks" all your files. Even if you change a string, git knows it. To see what your git stalked, use

```bash
> git status
On branch master

Initial commit
Untracked files:
    (use "git add <file>..." to include in what will be committed)

    .gitignore

nothing added to commit but untracked files present (use "git add" to track)
```

```bash
git add .gitignore
```

Now you have added your first file, it is also tracked by git, and ready to be committed. If you check your status by 'git status' again, you will see something different now:

```bash
> git status
On branch master

Initial commit

Changes to be committed:
    (use "git rm --cached <file>..." to unstage)

    new file:   .gitignore

```

This means you have tracked the .gitignore file and git recognizes it as **staged**. If you hear "stage your files", it means to add your files. You can add as many files as you can into a staging area. With this, you can share all your project or only a modified file with a single commit. We will get into this now. Now that you have added a file to the staging area, it is time to commit. Commit is simply put your staged files are done and ready to be published. To do so;


```bash
git commit -m ".gitignore added"
```

The command above saves all changes into a commit, so you can share it. The -m is short for --message and the string in between quotation marks are your messages, to be read by other collaborators to see what you are up to without checking your code. Be brief about your messages! You can see your commits by

```bash
git log --pretty=oneline --graph --decorate --all
```

This is a modified version of the 'git log' command, better for the eyes. Right now, since only you contributed a file, it only shows your commit. There are lots of aliases you can use to prevent injuries on your fingers, typing all these commands. 

We haven't uploaded our commit yet, so nobody can see what you did so far. The before-mentioned upload is called 'push' in git terminology. To push;

```bash
git push
```

Now, your local repository should push the commits to your remote repository. Any collaborator already cloned should now have access to your push. Now you can add your project files and commit them as mentioned above easily:

*   If you have a project already, simply put all your project files into your repository root.
*   If you are starting a brand new project, put your base project files to your repository root.

Now, your .gitignore file should take care of unnecessary files by not tracking them by default. When it comes to working with multiple collaborators, things get a little nasty. I will cover up that with new commands branching, fetching, pulling, and merging in my next post!