Getting Started with Git for CS304

Git is a very important tool for modern software development, especially when you have

Before Class:

    0.  If you’ve never worked with Git before, watch: Git Explained in 100 Seconds.    

         For a more in depth, interactive visualization, check out: Learn Git Branching 

  1. Make a GitHub account with your @wellesley.edu email on github.com (it’s pretty straightforward, but here’s tutorial in case you get lost: How to Create an Account on GitHub )

In Class:

  1. On VSCode, open up the terminal and enter the following commands with your name and Wellesley email:
  1. git config --global user.name "Wendy Wellesley"
  2. git config --global user.email ww1@wellesley.edu
  1. Make sure to use the same email you made your GitHub account with
  1. Next, you’re going to clone[1] your first repo[2]! Using this https://github.com/scott-anderson-wc/flask-starter to navigate to a page that looks like the first screenshot, then select the green code button and copy the HTTPS link.

  1. For the record, you can also start a repo from scratch, using git init in the command line to either create an empty repository or to convert an existing project to a Git repository.

  1. Ok, so now you have the link to the starter code. To *actually* clone it for your personal usage, (1) open the terminal in VSCode, (2) Navigate to the folder you want your project to be in (e.g. crud, lookup, or draft), (3) Type git clone followed by a space and the link you just copied (4) Press enter and voila! You have a version of the starter code saved locally.

  1. Next we are going to make some changes to the README.md[3] file and publish the new and improved repository to your personal GitHub. First, cd into the flask-starter folder and open up the README file in the VSCODE editor (for example, by navigating to the directory and typing code README.md in the command line)

  1. Edit the file so it better describes your assignment and then save it. In the right side of VSCode, the Source Control tab will indicate a change was made.

  1. Next you need to stage[4] your changes (following the selections of the first screenshot) and commit[5] the staged changes (following the second screenshot).
  1. It’s important to write a message to explain the purpose of your edit when you commit your staged changes. For this set of changes, you can use the standard message for the first commit of a repo, initial commit

  1. In the command line, the equivalent is to type git add . followed by git commit -m “message to describe commit”
  1. Finally, you are ready to push your commits to a remote repository on GitHub. After making your first commit, you should see your source control tab updated with a “Publish Changes” button. Click it, and then follow the trail of pop-ups and prompts to connect your VSCode to your GitHub account. The purple bordered screenshots show some of the screens you should be prompted with.
  1. Note: This stage is assuming that you are not already signed to GitHub on VSCode (if you’re not sure, just click the user icon on the bottom left corner of VSCode to see if you are logged in anywhere). If you are already logged in to the correct GitHub account, you can scroll down and do steps 10-12 on page 8 instead.

This last step is going to publish your local git repository to GitHub. In the prompt, name the repository something simple but informative. You can select the public repository option for this example.

  1. Great, you did it! Now you can see the changes reflected in your remote GitHub repository by opening the README.md file on GitHub. Next time you edit this repository, you can save the changes and complete step 7 again. After step 7, you will first pull from the remote repository and then push your changes (using the menu in the screenshot below). This will ensure that the changes made locally will be stored remotely.

  1. The git commands here are: git pull followed by: git push
  1. Know that in the future, you will use branching and will need to specify the branch after the push/pull terms.

Alternative method to creating a new repository:

Instead of pushing your local copy out and creating a new repo, you can create a new, empty repo on Github and then push your commits out.

  1. First, you will need to create a blank repository on GitHub by first selecting “New Repository”, then naming the repository something simple but informative (like the name of the assignment or your project). Make sure all the boxes are unchecked, and then select create repository.

  1. Next, you’ll need to add a remote origin to your local repository, which is a fancy way of saying connect what’s on your computer to what’s on GitHub. Use these commands to do so:
  1. git remote add origin https://github.com/username/repoName.git
  1. To  get the proper link, repeat step 2 for the repo you just made on your GitHub account.
  1. git branch -M main
  1. This command creates the main branch, which is used to hold your more polished code. More on branching later!

3. Time to send your local updates to the remote repository! Your final command is simply git push -u origin main

Good Git Habits

  1. After pushing your initial commits to a repository, when you are ready to push to remote in the future, it’s important to first git pull to make sure your local branch has the most up to date code before pushing your updates to the remote repository. The  git pull command is how you get the updates others have committed to the remote repository.
  2. Generally, pushing directly to main is frowned upon, as it kind of defeats the purpose of version control. When working on a project, it's more typical to create a new branch from main whenever you work on a new feature or are fixing a bug, and when you are certain it’s working, you make a pull request to merge your branch into the main. Then, you resolve whatever merge conflicts that arise (and for best practices, have someone else on your team review your code). This prevents many irreversible issues, and also helps you to more easily keep track of progress.
  3. While you use the command git add to stage files that have changes for the next commit, it may be useful to use git status as well to keep track of what files you have staged (using git add <filename>)before committing.

[1] You can think of cloning like copying a file– new edits don’t impact the original, but you don’t have to manually copy and paste all the content you want to reuse, either.

[2] Repo is short for repository, which is the term for the collection of files

[3] A README.md is standard for a repository and is where you store general information about the project, like what it’s about, who created it, and other helpful information you’d want people looking at your code to read.

[4] Staging your changes is important, because sometimes you don’t want to officially commit all your changes, for example when one file is still a work in progress but another is updated and ready to be shared with others.

[5] Commit is the command you use to save changes to your local repository-- you can think of the message as a way to describe the changes made so that if you needed to revert to an earlier version of the project it would be easy to do so. You will later send all your commits to a remote repo on GitHub, and all the different versions will be labeled by these messages.