Git: Difference between revisions

From Redbrick Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Git is a version control system, like Mercurial with slightly more confusing commands, or like Subversion on steroids. It's a distributed VCS (DVCS), which you can google to find out more about, but if you've only ever used subversion and CVS, you'll find it a little different (hopefully more pleasant) to work with then you're used to.
Git is a distributed version control system, like Mercurial.


At some stage, someone might put up a full tutorial showing how to use git, but for now, here's a badly written and terribly phrased guide on how to get and use a repository on redbrick's git hosting area.
If you are looking for a guide on how to host your git repo on Redbrick, click [[Hosting_a_Git_Repo_on_Redbrick|here]]!


== Getting a git repository on Redbrick ==
For this guide we will be using the Git CLI.


=== Creating an SSH key pair ===
== What is Git? ==
Before you can use redbrick's git repositories from one of your computers (or from your redbrick shell), you need to create a public/private SSH keypair there if you haven't already. You'll need to do this for every device/place that you want to access git from. This might sound annoying, but it also lets you use git without having to type a password every time you need to clone/push/pull.


To do this on a Unixey (Linux/Mac OS X/on redbrick) system, run:
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.


  ssh-keygen -t rsa
== How does it work? ==


You'll probably want to hit enter for most/all of the default options. Especially the first one (where to save the key). When it's done, you'll probably see something like this:
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.


<pre>
There are three main states in a git repository:
[you@your-computer ~]$ ssh-keygen -t rsa
* The Working Directory. This the code you are working on, and you can make changes as you like!
Generating public/private rsa key pair.
* The Staging Area. These are the files that you plan for git to save a snapshot of.
Enter file in which to save the key (/Users/you/.ssh/id_rsa):
* 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.  
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/you/.ssh/id_rsa.
Your public key has been saved in /Users/you/.ssh/id_rsa.pub.
The key fingerprint is:
58:06:86:0c:83:5e:4e:ab:75:93:96:37:76:42:73:07 you@your-computer.local
The key's randomart image is:
+--[ RSA 2048]----+
| .oo .o  E.      |
|.  +o. + . .    |
|. + . + = .      |
| . + * O .      |
|  o o = S        |
| .              |
|                |
|                |
|                |
+-----------------+
[you@your-computer ~]$
</pre>


(the little ascii art bit might not show up on older versions of SSH).
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.


This has created two files on your computer - id_rsa and id_rsa.pub. id_rsa is your '''private''' SSH key, and id_rsa.pub is the corresponding public key. You keep id_rsa to yourself, and you can give id_rsa.pub to admins to allow you to access a repository. You can also upload it to a remote server (like redbrick) and put it in a specific location to allow you passwordless logins, but you can google for how to do that.
== Creating Your First Repository ==


=== Ask the admins ===
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:
Find an admin, and ask him/her/it if they'll add your repository to the system. They'll need the name of the repo, and any SSH '''public''' keys (not the private ones) belonging to devices that you want to be able to access your repository from sent to them. For example, if you want to be able to access the repository from your laptop, send them the id_rsa.pub file that you generated on your laptop (you'll find it in ~/.ssh). If you want to get at it from your desktop and your redbrick account, send them the id_rsa.pub files from your redbrick account and your desktop.
    cd ~/my/project


If you want to add more devices later, you can always ask the admins to add (or remove) some public keys.
Then we create the repository:
    git init


=== Create the repository ===
We can then stage the files. The * here means all of the files in the directory:
Once the admins have done their work, you need to actually create the repository. You do this on your own computer (or redbrick account, or wherever one of your keys came from). If you asked the admins to create you a repository named "awesomeproject", you'd do the following:
    git add *


  mkdir awesomeproject
Finally, we can commit the changes:
  cd awesomeproject
    git commit -m "initial commit"
  git init
  git remote add origin git@git.redbrick.dcu.ie:awesomeproject.git
 
At this point you should do some work, like create a file and put something into it, or whatever. This is where a proper guide to git would be handy. Then commit your changes and do a first push:


  git commit -a -m "My first 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.
  git push origin master:refs/heads/master
    cd ~/my/project
    touch .gitignore


''Things to look out for:'' When you're doing the "git remote add origin" command, make sure you add ".git" to the end of the repository name. The system that redbrick uses (called Gitosis, if anybody cares) to manage repositories needs that there. Also, in "git@git.redbrick.dcu.ie", the "git" user isn't a placeholder. You need use that user, not your own redbrick username.
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
Retrieved from "https://wiki.redbrick.dcu.ie/index.php?title=Git&oldid=11301"