Skip to main content

0. Git, Markdown, and Bash

Assignment Overview

Before diving into the rest of the course material, it is important to be familiar with a few fundamental tools of the trade that developers use every day. This assignment will cover the basics of Git, Markdown, and Bash. While can complete this assignment using graphical tools (such as finder on mac of file explorer on windows), please use the command line, as it is a fundamental skill needed for software development. Additionally, the tests will ensure that you have run a certain commands by looking at your command history.

Bash

In this section of the assignment, all bolded text will be correspond to a command that you should run in your terminal. If you are forgetting which command to use, you can refer back to the bash quick reference.

note

MacOS uses zsh (Z-shell) by default. Zsh is extremely similar to bash, and all of the commands in this assignment will work in zsh.

  1. Open up a terminal window. On Mac, you can use the built-in Terminal app. On Windows, use Git-Bash.
  2. Print "Hello Bash!" to the console. This will ensure that we know when you started the assignment.
  3. Print the current working directory to see where you are in your file system (most likely the root).
  4. Change directories into the folder you would like to store your assignments for 61D (like desktop or documents).
  5. Make a folder called to store all of your assignments then change directories into the folder. Make another folder for this assignment titled bash-assignmentand change directories into that folder.
  6. Make a file called README.md and make another file meaning-of-life.txt
  7. List the files in the current directory to verify that you have created the files.
  8. We lied. We don't know the meaning of life. Rename the meaning-of-life.txt file to history.txt.
  9. Open the current directory in vscode. You can do this by running code . in the terminal.

Congrats! You know now a few basic bash commands. We will use a few more in later parts of the assignment, but now let's move on to Markdown.

Markdown

Open up your README.md file in vscode. Include the following markdown features in any order you like. If you forget any of the syntax, reference the markdown cheat sheet.

As you are editing the file, you can preview the markdown by clicking the "Open Preview" button in the top right corner of the vscode window.

  1. Include an h1 header with the title "Assignment 0"
  2. Add a fun fact about anything you would like in bold
  3. Include a question you have about coding or 61d in italics
  4. Include a link to the website of your favorite restaurant
  5. Include a image of a cute animal like this one:

pig

  1. Include a code including a bash command you used in the previous section. Be sure to specify the language of the code block as bash after the three backtick to get appropriate syntax highlighting.
echo "Hello Bash!"

There are a few other pieces of markdown syntax you may use at some point, but you have now covered the most common ones. Now let's move on to Git.

Git

Like the bash section, each bolded text will correspond to a git command you should run in your terminal. If you are forgetting which command to use, you can refer back to the git quick reference. We will also have you use a few additional bash commands.

Basic Git Usage

  1. Initialize a git repository within your current directory
  2. Check the status of your repository. You should see that you have untracked files.
  3. Add all files to the staging area so that git will begin to track them.
  4. Check the status of your repository again. You should see that you have files ready to be committed.
  5. Commit the staged changes with the message "Initial commit"
  6. Create a new branch titled new-feature and switch to it. It is possible to do this in a single command or in two separate commands.
  7. View your branches and verify that you are on the new-feature branch.
  8. Create a new file called feature.txt and some text to it. Add and commit the file to the new-feature branch. Remember that all commits require a message.
  9. Switch back to the main branch and you should see that the feature.txt file is no longer visible in your working tree.
  10. Merge the changes from the new-feature branch into the main branch and delete the new-feature branch.

You now know the basics of git! It can be difficult to remember all of the commands initially, but soon they will become second nature. Our final step is to push the changes to GitHub and investigate what happens when git can't automatically merge two branches.

GitHub

  1. Create a new repository on GitHub with whatever title you would like. Make sure that it is public, or the autograder will not be able to access it. Do not add a README.md file, as we already have one locally and do not add a .gitignore file, as we will create one later.
  2. Follow the instructions to push an existing repository from the command line. Add the remote and push the changes to GitHub You should now be able to refresh the page and view your code!

Next we will show what happens when git is unable to automatically merge two branches. This typically does not happen when working on your own, is very common when collaborating with large groups of people on a repository.

  1. Create and check out to a new branch called conflict1. Add some text to the first line of feature.txt and some text above your h1 header in your README.md before adding, committing, and pushing the changes. When pushing, be sure to specify the branch name.
git push origin conflict1
  1. Switch back to the main branch and create a new branch called conflict2. You should not see the text you added to feature.txt in your conflict2 branch, since those changes were not merged into the main branch. Add some different text to the first line of feature.txt and some text below your h1 header in your README.md before adding, committing, and pushing the changes. When pushing, be sure to specify the branch name.
  1. Open the repository in GitHub and create a pull request to merge conflict1 into the main branch. You should be able to preview the changes before merging. Merge the pull request and delete the branch.

  2. Checkout to the main branch on your local repository and pull the changes from GitHub. You should see the changes you made in conflict1 in your local repository.

  3. Create a pull request to merge conflict2 into the main branch. You should see a merge conflict.

Merge conflicts arise when two diverging branches have made changes to the same lines of code and Git does not know which changes to keep. Git can detect when and automatically merge changes to different parts of files, which is why there is no conflict in the README.md file.

<<<<<<< HEAD
conflicting changes 1
=======
conflict changes 2
>>>>>>> conflict2

Git displays the changes made on each branch, and leaves it up to the user to decide which to keep.

  1. Click Resolve Conflicts to open up the web editor. Decide if you want to keep your changes from conflict1 or from conflict2 or keep both of the changes. Delete the conflict markers (the <<<<<<<, =======, and >>>>>>> lines), select mark as read, and complete there merge. Merge the pull request and pull the changes back into your local main branch.

.gitignore

Very often you will want to have files in your repository that you don't want to track with git. We can specify these files in a .gitignore file.

  1. Create a file called .gitignore in your repository. Add the following lines to the file:
secrets/
no-commit.txt

and commit the contents.

  1. Now, any file called no-commit.txt or any file in a folder called secrets will not be tracked by git. Try creating a no-commit.txt. You should see that it is greyed out in the vscode sidebar, and running git status will not show it as an untracked file. Push your changes to GitHub and verify that the no-commit.txt file is not in the repository.

You can specify more complex .gitignore patterns but most of the time specifying individual files or folders is sufficient.

Submission

The auto grader will check the contents of your README.md file, your git history, and your bash history. To "upload" your bash history, run the following command to write out your most recent commands to your history.txt file:

# Write 200 most recent bash commands to history.txt
history | tail -n 200 >> history.txt

Then make sure that your initial echo >> "Hello Bash!" command is in this file. If not, try deleting the contents of the file and running the command again but with more lines. Commit and push the updated history.txt file to GitHub.

Then, clone the starter code. The starer code repository has tests which will make sure that you used the command line for this assignment, and that you merged two pull requests on GitHub. All you need to do to run the tests is add the link to your repository to the repo.txt file.