CMSC 210: Lecture 3

Lecture 3

Local Development, Command-line Interfaces, & Git

Announcements

Assignment 1 is due next week (Wednesday, February 16, before midnight)
Office hours Monday (by appointment)

What is local development?

It's how most software is written
...but probably not how you wrote software.
You write, test, build, & run software on your own computer.
You share and publish your code using a version-control system (VCS).

By contrast, what you did in CMSC 201, using SSH to connect to a Linux server (GL) where you would edit and run your files is called remote development.

Remote VS.	Local
Pro: Everything is installed for you by the administrator.	Con: It's up to you to learn to install and configure what you need to run your code.
Pro: Backups are handled for you.	Con: You're responsible for backups.
	Pro: ...but a VCS provides powerful ways to backup & share code once you learn it (more on that later...)
Con: You can't develop without an internet connection	Pro: You can develop with no or slow internet
Con: Using emacs over SSH is a primitive, painstaking, slow way to program	Pro: You have and incredibly rich set of tools to help you write code.
	Pro: you can configure your development environment however you like
	Con: you can configure your development environment however you like

But what is local development?

Is it working on the command line?
Or using programs with a graphical user interface?
Yes!

Let's start with the command line.

You have two options on OS X

The terminal program that comes with OS X:
iTerm (download from iterm2.com):
They run the same shell (BASH) but iTerm looks nicer and has more features.

You have two options on Windows

The command prompt (aka CMD): 👎🏻
PowerShell: 👍🏻

Command Prompt 👎🏻
- is an interface used to basically execute older DOS (Disk Operating System) commands
- allows the execution of batch files (.BAT)
PowerShell 👍🏻
- Runs a totally different shell
- is available by default (i.e. doesn't need to be installed) starting with Windows 10
- can run Command Prompt commands, but the opposite is not necessarily true
- a lot of commands share names and behaviors with Unix commands
- is also a scripting language

Purpose	Windows	Mac or Linux
Get help	`help command command /?`	`man command command --help`
Show current directory	`cd`	`pwd`
Change directory	`cd new_dir_path`	`cd new_dir_path`
Show files in directory	`dir`	`ls`
Create a new directory	`mkdir new_dir`	`mkdir new_dir`
Delete a directory	`rmdir new_dir_path`	`rmdir new_dir_path`

Purpose	Windows	Mac & Linux
Show total file content	`type some_file.txt`	`cat some_file.txt`
Page through file contents	`more large_file`	`more large_file`
Create a new file	`echo "text" > new_file`	`echo "text" > new_file`
Add to a file	`echo "text" >> existing_file`	`echo "text" >> existing_file`
Rename/Move a file	`# Rename in place ren old_file new_file mv old_file new_file`	`mv old_file new_file`
Copy a file	`copy old_file new_file`	`cp old_file new_file`

Purpose	Windows	Mac	Linux
Python (check version)	`python -V`	`python3 -V python -V # YMMV`	`python -V`
Python (interactive shell or REPL)	`python`	`python3 python`	`python`
Running a Python script	`python some_script.py`	`python3 some_script.py`	`python some_script.py`

Python 2 VS. 3

Version Control Systems

What are they? What are they good for?

A version control system (VCS) is...

A tool that manages files + directories and how they change over time
A tool that allows you to recover older versions of your data and examine its history
A tool that allows you to group a collection of files and directories together into a single repository (or repo for short).
A tool that allows you to synchronize your copy of a repo with a remote copy (push and pull)
A tool that allows you to fork and merge branches from your repo.

A VCS is good for...

Allowing you to access a history of your project from its earliest beginning to the present state
Allowing you to experiment with changes to your code and back out of these if necessary
Allowing a team of software engineers collaborate on a single codebase without stepping on each other's code
Allowing a team of software engineers to develop separate components or functionality independently.

Git

“The information manager from hell”
— Linus Torvalds

Git: key concepts

repository/repo: a database containing all the information needed to retain and manage the revisions and history of a project (this is hidden in .git/objects, don't touch!)

hash: a unique identifier for each and every version of an object Git tracks. Example: 9da581d910c9c4ac93557ca4859e767f5caf5169. The hash is generated from the contents of a file, because Git tracks file content, not file names

commit: a set of one or more changes to your repo that are grouped together and uniquely identified. Think of it like a snapshot you take of your project that is saved forever or like a save point in a video game.

Each commit will also have its own hash. The user, commit date, and an optional comment will be stored in the repo as well.

head: the latest commit in your history

branch: a way of launching a separate line of development within a project. Think of it as an alternate timeline, but you can merge it back to the original

master/main: every project has at least one branch, and it's this one. Think of it as the "original" timeline and you can branch and rejoin it as many times as you want

remote/origin: a clone of your repo that exists on some other machine

clone: a copy of a repository. A clone contains all the objects from the original, meaning the whole history of the repo is contained in every clone

working copy/working directory: a clone of your repo that exists on your machine. You do your work—creating, editing or removing files and folders—in the working directory

push: push your commit(s) from your working copy to a remote

pull: pull someone else's commit(s) from a remote to your working copy

staging area: part of the repository that stores information about what will go into your next commit

In git you have to stage files before you commit them.

Think of git-add as being like writing in pencil. git commit is like writing in pen.

Working in Git

Create a new repo (git init) or clone an existing one (git clone).
Make some changes until you reach a good save-point.
Stage the changes (git add)
Commit the changes (git commit)
Push the changes to the remote (git push)
Go back to step 1.

Telling git to ignore files

Some files you don't want to version (like .pyc files, editor/IDE config, etc).

Create a .gitignore file in the root of you project to tell Git which files it should ignore:


*.pyc
.DS_Store
.idea/

Git Tips

Commit your work often.
Try to write useful commit messages.
Git commits are more-or-less immutable. Try very hard to avoid committing passwords, private keys, or anything else sensitive to your repo because it will be discoverable.