ENTR-451

Practice: GitHub

Ben Block -

In class you ran the loop once: a branch, a file, a commit, a pull request, somebody else's review, a merge. You did it in a room with forty other people doing the same thing and an FA two seats away.

This week you do it again, alone, on a repository of your own where nothing can go wrong. That is the entire point of this exercise. The first time you follow along. The second time you find out what you actually know.

It should take about thirty minutes. There is nothing to turn in.

Part 0: get your own copy

If you already made your own hello-world during class, skip this.

Go to github.com/dsgn425-fall2026/hello-world, click the green Use this template button, then Create a new repository. Owner: your own account, not the class organization. Name: hello-world. Leave the visibility on Private. Click Create repository.

Check the name at the top left of the page. It should read your-username/hello-world. If it still says dsgn425-fall2026/hello-world, you are looking at the template, not your copy; go back and click Use this template.

It is yours now. You cannot break anything that belongs to anyone else, which is why we are doing this here rather than in the class roster repo.

Part 1: the loop, by yourself

Open your copy and follow its README from step 2 to step 6. Do not read ahead and do not copy what you did in class from memory. Work it through.

Branch, change something, commit with a real message, publish, open a pull request, merge it, delete the branch.

Two differences from class, and both are worth noticing:

You are the whole team. In the class repo a classmate had to approve your pull request. Here nobody does, so you get to read your own change on the Files changed tab and merge it yourself. Read it anyway, properly, as though somebody else wrote it. That habit is the one this course is really trying to build.

Nothing is protected. Your repo has no rule stopping you from committing straight to main. You could skip the branch entirely and it would work. Make the branch anyway. The habit has to survive the absence of a rule enforcing it, or it is not a habit.

If you want the reasoning behind any of it, rather than the buttons, that is in Git and GitHub.

Part 2: the same loop, from the terminal

Now do it a second time without touching the file explorer. Everything below happens in the Codespace terminal, which you open with View > Terminal from the hamburger menu.

This half exists because the command line is the part of the first class that fades fastest if you never touch it again. Ten minutes now is worth an hour later.

Start on a new branch. Bottom-left corner, Create new branch..., call it terminal-practice.

Find out where you are.

pwd

It prints your current directory, which should end in /hello-world. Then:

ls

lists what is in it. You should recognize the files from the Explorer. Now:

ls -a

The same list, plus the hidden files, the ones whose names start with a dot. There are more files in a repository than the Explorer shows you by default, and .devcontainer is how your Codespace knew what to build.

Run the programs that are already there.

ruby code/hello.rb

prints a greeting. Then:

ruby code/infinite-tacos.rb

which does not stop on its own. Press Ctrl-C to kill it. You need this more often than you would think, and nobody tells you about it until you need it.

Make something.

mkdir notes

creates a folder. Confirm it with ls. Then:

touch notes/week-01.md

creates an empty file inside it. Open notes/week-01.md from the Explorer, write two or three lines about anything from the first class, and save with Ctrl-S.

Move something.

The repo has an images folder with a couple of files in it. Pick one and move it to the top level, then move it back:

mv images/grogu.jpg .
ls
mv grogu.jpg images
ls

The . means "here, the directory I am in." Watch the Explorer on the left as you run each one. The file jumps. You can of course do all of this by dragging with a mouse. The point is that you now know the other way, and the other way is the one that works over a terminal connection to a server at two in the morning.

One useful trick each. Start typing a directory name and press Tab; the shell finishes it for you, and if nothing happens it is telling you that what you typed does not exist. Press the up arrow to bring back the last command you ran, which saves you retyping a long one with a typo in it.

Then put it through the loop. Source Control, stage, commit with a message that says what you did, Publish Branch, open the pull request on github.com, read the diff, merge, delete the branch.

Before you close the tab

Stop your Codespace. On the repo page, Code > Codespaces, the three dots, Stop codespace. It stops itself after thirty minutes idle, but doing it yourself is the habit, and Codespaces hours come out of your own monthly allowance.

What to check before you call it done

  • Your repository's main branch contains both changes.
  • The commit history shows how they got there, and the messages say what happened. If any of them says update or tried again, go and look at why that is useless to you two weeks from now.
  • Both branches are gone, because you deleted them after merging.
  • You can say, without looking anything up, what the difference is between a commit and a pull request.

That last one is the actual assessment. The rest is just evidence.

If you got stuck

Post in #fall-2026 on Slack and say where it stopped working. Getting stuck is not a failure mode here, it is the expected experience of week one, and the stuck point is usually the same three or four things. The troubleshooting list at the bottom of the class roster repo's README covers most of them.