Git Overview

Git is a powerful source code control system that allows developers to store their source code, collaborate, and manage changes. It is a key tool in any software engineer's toolbox.

Git uses some terminology that we need to remember:

• Working Tree: this is just a fancy name for the directory of your code, stored in directories.
• Repository: the Git database of your project's entire history. Everyone has a copy of the repository stored in a .git directory at the root of your working tree. You do not need to edit anything in there directly, only through a git command on the command line.
• Add: take the changes to your working tree and get ready to store them in the repository.
• Commit: store the changes from the add command into your local repository. When you commit, you need to write a descriptive message of the changes, and Git also records the timestamp.
• Push: take the commits stored in your local repository and place them in a remote repository, thereby integrating your work with others' work.

In this exercise, we will be focusing on how to use Git on the command line, including creating a repository, adding files, committing files, and pushing your changes to a remote repository.

Git in SWEN 250

In this course, Git is not just a tool for you to use, it's your submission system. So understanding how to use Git is critical for for this course. If you mess up your submission, you won't get credit for all your hard work.

You will be creating one personal repository for this entire course. As you work, you will be asked to make many commits at logical times. When you are ready to submit an assignment, then you will push your changes to your repository.

Setup Gitlab and Git

Let's set up our username in git. You only need to do this once for the entire semester. In your terminal (e.g., putty logged into hamilton), use the git config command for changing user.name and user.email, like this:

$ git config --global user.name "Bojack Horseman"
            
            $ git config --global user.email "bjh9999@rit.edu"
            

A neat feature in git command line is to use the coloring scheme to more easily spot the status of things:

$ git config --global color.ui true  
            

1. Now let's go and create our repository on GitLab. GitLab is a web application that allows you to have a remote Git repository, much like GitHub. RIT has its own installation of GitLab that we will be using for this course. Go to https://kgcoe-git.rit.edu/. Keep this link-- you will NEED to use it to log in to gitlab. Do not google gitlab and try to access from there; it will not work.
2. Sign into GitLab using your RIT (not SE) username and password.
3. Create a new "project, and name it swen-250. Make sure the repository is private. make sure the project name is swen-250 exactly. Same spelling, same capitalization, using a dash.
4. Give Reporter permissions to your instructor and course assistant(s). You may need their usernames - be sure to ask if they have not provided it. To do this, you need to have your project page open. An easy way to make sure you have it open is to modify this link with your username: https://kgcoe-git.rit.edu/(YOUR_RIT_USERNAME_HERE)/swen-250. Go to Project Information -> Members on the left side of the screen at the bottom. Add ALL of your TAs and Instructor as a member with Reporter as the type.
5. Make sure you did step #4 completely. If you are confused, ask your instructor or TAs for help.
6. Now let's add your ssh keys.
7. There is a useful help page on gitlab that you may also want to refer to GitLab and SSH Keys README
You need to give Gitlab your public SSH key so that it can authenticate when you use git commands from hamilton. To do this, go to the top rightmost of your screen. You should see a circular symbol with a dropdown arrow next to it. Click there, go to settings then on the left you should see ssh keys. Click on that. You should now see two text boxes. One for your key and one for a title.
8. Go back to the terminal window where you logged into hamilton. If you are logged out, log back into hamilton. Now type cat ~/.ssh/id_ed25519.pub again and copy that ENTIRE string starting with "ssh-ed25519" and ending with your email. Paste this string into the key textbox on the gitlab page. Enter a title for this key-- it can be anything; make it descriptive. Something like "hamilton ssh key".
9. Now that we've created a repository on GitLab and added our SSH key, let's clone your new swen-250 repository onto hamilton. Find the SSH URL for your swen-250 by clicking on Project . The SSH URL will look like git@kgcoe-git.rit.edu:(your_rit_username_here)/swen-250.git (your username will be in there)
10. Back in PuTTY/your terminal, use git clone to clone the url. Make sure you clone into your home directory. Your command will look something like this: git clone git@kgcoe-git.rit.edu:(your_rit_username_here)/swen-250.git
11. If everything worked, you should now have a swen-250 folder.

Pushing your first code

7. Change directories into your repository folder on hamilton, using cd
8. Let's add something to our working tree. Edit a text file called name.txt.

• If you have never used a command line text editor before, you should probably start with vi. Type vim name.txt to create and edit the file
  • Use i to start editing
  • Use Esc to stop editing and enter commands
  • Use :x to save your file and exit vim
• vi (or vim) is a very full featured editor but it's a little esoteric. You'll want to look up a guide on for the commands but the above information is enough to get you started.

9. In name.txt, write your full name (so the instructor knows who you are). Save and exit the text editor.
10. Ok, now that we've written some "code", we've completed our first task. So it's a logical time to add, commit, and push our changes. First, let's see where we stand. Type git status. You should get output like this:

            # On branch master
            #
            # Initial commit
            #
            # Untracked files:
            #   (use 'git add ...' to include in what will be committed)
            #
            #       name.txt
            nothing added to commit but untracked files present (use 'git add' to track)
            

11. Before we continue, let's create a new file which will save us some time in the future and prevent saving into the repository “stuff” we don't usually want. For now we will exclude the basics. Let's create this special file. Create a file in the root of your repository called .gitignore create and edit the file and add the following contents. Be careful that your copy/paste does not ruin the formatting:

• Note: If you are using vi remember to press i before you paste (rightclick) into the file.

Copy starting from line below:

# This file will prevent Git from adding files that match the following
# patterns to the repository. If you need to add a file anyway, you can use `git add -f [file]`
                
# Text editor swap files
*.swp
*.swo
*~
                
# Compiled binary files
*.o

(Copy up to line above)

Note that git will not ignore a file that was already tracked before a rule was added to this file to ignore it. In such a case the file must be un-tracked, usually with git rm --cached filename

As we expect, we've got our new file to add. Add your changes to git by typing git add . Running git status now gives us the following output:

# On branch master
                #
                # Initial commit
                #
                # Changes to be committed:
                #   (use "git rm --cached ..." to unstage)
                #
                #       new file:   name.txt
                #                     
                

12. Now it's time to commit. Committing your changes to source control generally means that you are in a relatively stable state. It does not mean that you are done with the assignment - that's not committing enough for this class. Commit when when your program is compiling, and a piece of your work is done. The more often you commit, the easier it is to roll back to a stable state, and the more atomic and understandable your changes are.
13. You can do your entire commit on the command line using:
    git commit -m"a meaningful commit comment" . Using the . at the end commits all files from the current directory and below.

Or, you can use the following approach:
To commit, type git commit. By default, git will open up the vim text editor for you to enter your commit message. (If you would rather use nano to edit your commit messages, then run git config --global core.editor "nano"). Git commit messages have this convention:

• The first line is the subject line, which is a concise description with a maximum of 50 characters
• The second line is always blank
• Anything on the third line and after is a more thorough description of the changes.
• For this class, the most important element is a well-written subject line. "A few changes" is the worst possible commit message - be descriptive without being verbose (50 characters is short - this parenthetical is 49).
• Write a descriptive message for adding the name file, such as "Recording my name for grading".
• Exiting out of the text editor will automatically finish your commit. When that is done, your output will look something like this:
  

  [master (root-commit) 5d859e9] Recording my name for grading
                          1 file changed, 1 insertion(+)
                          create mode 100644 name.txt             
                         

14. Now we have one more action: push. We need to push our commits to our remote repository on GitLab so the instructor can view it and grade it. Ok let's push now. The command is git push origin master. The output looks similar (but perhaps not exactly) to this:

Counting objects: 3, done.
                Writing objects: 100% (3/3), 278 bytes | 278.00 KiB/s, done.
                Total 3 (delta 0), reused 0 (delta 0)
                To kgcoe-git.rit.edu:cdnvse/swen-250.git
                   3063b61..3f82b4f  master -> master
                

15. Just to double-check that we pushed our code, head back to your browser view of your repository and find your new changes.

You're all set up! We've synchronized our repository with our GitLab so that the instructor can see our changes. From here on, we can continue to modify, commit, and push our code right up to the deadline. Now try out the workflow below and review our tips.

Your Typical Workflow

Here's the typical workflow we want you to use.

1. Start working by running git status. Commit or remove any changes you might have forgot to deal with before (i.e. start with a clean working tree).
2. Think about how you will break up this work into smaller tasks
3. Edit, compile, test (your typical programming workflow)
4. At the end of one of your mental tasks, add and commit.
5. Continue to complete your other tasks until the assignment is completed.
6. When you are ready to submit your assignment, push your changes.
7. Double-check that all of your changes are pushed with git status.
8. Double-check your changes are pushed to GitLab.

Learning this pattern of work is critical to your success as a future software engineer. Don't wait to do Git stuff until the very end of your work.

Git Tips for swen250

All of your assignment and projects will be in your personal repository for this course. To speed up grading, please name files and directories exactly as specified in the assignment or project description. Doing this properly is part of your grade.

To check that you have submitted, run these two commands

• git status - to make sure everything has been committed (should say "# On branch master nothing to commit (working directory clean)")
• git push origin master - if it says "Everything up-to-date", you have everything pushed and submitted
• Deleted a file? Use either git rm or git add -A . to record that deletion.
• Want to add, commit, push all in one command? Use: git add . && git commit && git push origin master
• Also, in bash, you can use the up arrow to bring that command back up quickly.
• If you realize you don't want to commit partway through, then exit your text editor with an empty commit message and everything aborts safely.
• Interested in more Git features? Ask your instructor! It's a very feature-rich tool.

Note: Git is not a misspelling of "get", it's a self-deprecating joke about Linus Torvalds

Submission

A correctly set up repository.

For this assignment, the instructor and graders will find your repository on GitLab and make sure it's set up properly.

Grading

10 points: Correctly set up repo (swen-250) with correct name.txt and .gitignore etc.