Git: Difference between revisions

From Redbrick Wiki
No edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:


If you are looking for a guide on how to host your git repo on Redbrick, click [[Hosting_a_Git_Repo_on_Redbrick|here]]!
If you are looking for a guide on how to host your git repo on Redbrick, click [[Hosting_a_Git_Repo_on_Redbrick|here]]!
For this guide we will be using the Git CLI.


== What is Git? ==
== What is Git? ==


**Git** is a version control system, used by almost every developer. It allows you to see changes you've made to your code and roll back the project or specific files to previous versions. It is extremely useful for collaborating with several developers via a remote repository and for finding out what happened when a change breaks your project.  
Git is a version control system, used by almost every developer. It allows you to see changes you've made to your code and roll back the project or specific files to previous versions. It is extremely useful for collaborating with several developers via a remote repository and for finding out what happened when a change breaks your project.  


== How does it work? ==
== How does it work? ==
Line 12: Line 14:


There are three main states in a git repository:  
There are three main states in a git repository:  
- The Working Directory. This the code you are working on, and you can make changes as you like!
* The Working Directory. This the code you are working on, and you can make changes as you like!
- The Staging Area. These are the files that you plan for git to save a snapshot of.
* The Staging Area. These are the files that you plan for git to save a snapshot of.
- The Git Repository (repo). This is the ".git" directory made when you initialize a new repo. It tracks and saves the snapshots of your files.  
* The Git Repository (repo). This is the ".git" directory made when you initialize a new repo. It tracks and saves the snapshots of your files.  


In practice, it looks like this:
In practice, it looks like this:
- You work on your code and make changes
* You work on your code and make changes
- You "stage" the files you've changed
* You "stage" the files you've changed
- You then "commit" these staged files, adding them to the repository.
* You then "commit" these staged files, adding them to the repository.
 
== Creating Your First Repository ==
 
Say you have a project that you want to backup with git in ~/my/project. First we need to navigate to the project with the cd command:
    cd ~/my/project
 
Then we create the repository:
    git init
 
We can then stage the files. The * here means all of the files in the directory:
    git add *
 
Finally, we can commit the changes:
    git commit -m "initial commit"
 
If you have sensitive files you don't want to be added to the repository, such as .env files, you can use a '''.gitignore''' file at the project root.
    cd ~/my/project
    touch .gitignore
 
Any files or directories specified in the gitignore will not be added to your repository. For example:
    *.env # ignores any files with the extension .env
    hello.* # ignores any files starting with hello.
    /foo # ignores the entire directory foo
 
You can also specifically allow files or directories inside of ignored directories using an !:
    !/foo/bar # specifically allows the file bar in the foo directory, even though foo is in the gitignore file

Latest revision as of 21:42, 11 April 2026

Git is a distributed version control system, like Mercurial.

If you are looking for a guide on how to host your git repo on Redbrick, click here!

For this guide we will be using the Git CLI.

What is Git?

Git is a version control system, used by almost every developer. It allows you to see changes you've made to your code and roll back the project or specific files to previous versions. It is extremely useful for collaborating with several developers via a remote repository and for finding out what happened when a change breaks your project.

How does it work?

Git takes "snapshots" of your project whenever a change was made. To save on space, if a file was not changed it will link to the original file instead of making a copy. Think of it as copy and pasting a directory and making a change on the new one, but all of the unchanged files in the new copy are just shortcuts to the files in the old one.

There are three main states in a git repository:

  • The Working Directory. This the code you are working on, and you can make changes as you like!
  • The Staging Area. These are the files that you plan for git to save a snapshot of.
  • The Git Repository (repo). This is the ".git" directory made when you initialize a new repo. It tracks and saves the snapshots of your files.

In practice, it looks like this:

  • You work on your code and make changes
  • You "stage" the files you've changed
  • You then "commit" these staged files, adding them to the repository.

Creating Your First Repository

Say you have a project that you want to backup with git in ~/my/project. First we need to navigate to the project with the cd command:

   cd ~/my/project

Then we create the repository:

   git init

We can then stage the files. The * here means all of the files in the directory:

   git add *

Finally, we can commit the changes:

   git commit -m "initial commit"

If you have sensitive files you don't want to be added to the repository, such as .env files, you can use a .gitignore file at the project root.

   cd ~/my/project
   touch .gitignore

Any files or directories specified in the gitignore will not be added to your repository. For example:

   *.env # ignores any files with the extension .env
   hello.* # ignores any files starting with hello.
   /foo # ignores the entire directory foo

You can also specifically allow files or directories inside of ignored directories using an !:

   !/foo/bar # specifically allows the file bar in the foo directory, even though foo is in the gitignore file