My text editor of choice is Emacs. What I like about it is that everything in emacs is text. There is never any need for me to touch my mouse or trackpad when I'm inside of emacs. Some people may think that's crazy, but I find it really helps speed up my workflow and adds to my enjoyment when writing code. The first lab for this class goes into greater detail explaining how you can use it too. I suggest that you really do give it a try. It's not for everyone, but I think some students really take to it so it's worth the effort.

The second best thing about emacs is that it is inherently customizable. Not to confuse things too much, but Emacs itself is an interpreter of emacs lisp, a dialect of the lisp programming language. When I do code demos in class you will see me using an emacs that looks different than the default version installed on the remote servers that you might use (or the default installation that you may have performed on your own machine). This is because I have a few different packages installed on my personal copy. You can take a look at the manual page on installing packages here. Here's a list of the packages I like to use on my emacs:

magit

Github integration

marginalia

Adds marginalia to the minibuffer completions

markdown-mode

Full emacs mode for editing markdown files

treemacs

Tree layout file explorer

vertico

Vertical minibuffer command completion

Integrated Development Environments, or IDEs, are souped-up text editors. They are complex programs dedicated to helping software developers write code for large projects. Here are a few examples of IDEs:

• Eclipse
• IDLE
• VSCode
• etc.

IDEs go a bit further than the standard text editors. In addition to editing source code and highlighting the containing text, they also provide navigable directory trees, in-program terminals, debugging options, integration with popular tools, object browsers, and more. Compared to basic text editors like notepad or nano, IDEs are heavy duty weaponry.

Even though IDEs provide many more features than the humble text editor, I don't suggest you use any for this course. There is nothing inherently wrong with using an IDE, and I am not preventing anybody from doing so in the class; however, I think that IDEs should only be used after you have become familiar with the basics of the coding process. Far too often I see students make mistakes in their workflow that could have been avoided if they had actually bothered to learn all of the steps the go into the IDE code, run, debug cycle.

Due to the infinite customizability of emacs, it doesn't take too long¹ to convert it from a simple text editor to a power IDE. All of the advantages provided by the IDEs listed above can be matched by an intelligent combination of freely available packages.

One way to fix this issue is to save a copy of old versions before you change them:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example$ cp ex.c ex_old.c #Copy before making changes
josephraskind@josephraskind-ThinkPad-T470:/tmp/example$ emacs ex.c #New changes

This works, but think about what happens when I want to make another change, and then another, and another. I would need a different file for each change, or I would have to accept the fact that I'll lose the history of my changes. Both of these are not particularly satisfying solutions. This is where bespoke version control software can helped.

Git is an incredibly powerful version control tool. It is also a bit unintuitive to use, especially for people who are not used to entering commands onto a command line. Despite first appearances, it's not too difficult to wrap your head around (at least for simple use-cases). I highly, highly suggest you flip through the Pro Git book, particularly the introductory chapters. Let's see how we can address the issue we had with our little hello world program.

First, I need to make a git repo:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example$ git init my_repo/
Initialized empty Git repository in /tmp/example/my_repo/.git/  

In Listing 6 I tell git that I want to create a new repo in a directory called my_repo. All git repo files are stored in a hidden directory at the base, or root, of the repo called .git/.

I can check the status of my_repo by moving inside of the directory and using the git status command:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/$ cd ./my_repo
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        ex.c

nothing added to commit but untracked files present (use "git add" to track)

You'll notice that ex.c is listed as an untracked file despite the fact that we just put it in the repo. This is because git will only track the files you tell it to!

Next, I need to add my ex.c file to the repository:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git add ex.c 
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   ex.c

Git is telling me that I have a file called ex.c in my repo, but it hasn't been committed yet. When a file is committed that means a snapshot of that file has been recorded onto the internal git repo data structure stored within the .git/ directory. I can store a snapshot of all my files by using the git commit command:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git commit -m "Adding ex.c to the repo"
[master (root-commit) 40d18f3] Adding ex.c to the repo
 1 file changed, 4 insertions(+)
 create mode 100644 ex.c
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git status
On branch master
nothing to commit, working tree clean

Now let's try making a change and committing that change:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ emacs ex.c #making change
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ cat ./ex.c 
#include<stdio.h>
int main(){
  printf(Salutations, World!\n");
}
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git add ex.c 
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git commit -m "Updating printf message"
[master f5c21c7] Updating printf message
 1 file changed, 1 insertion(+), 1 deletion(-)

I can check and see what's been changed using the git log command:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git log
commit f5c21c7aa6865f53c8fa8b4e6f678ef7bb74c8f1 (HEAD -> master)
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:36:59 2026 -0400

    Updating printf message

commit 40d18f3d5de5b48e074a179728affcb48828f5ef
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:31:27 2026 -0400

    Adding ex.c to the repo

This is nice, but it doesn't really show me what's different about the code itself. I can add a couple flags to my command to get some more information:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git log -p -1
commit f5c21c7aa6865f53c8fa8b4e6f678ef7bb74c8f1 (HEAD -> master)
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:36:59 2026 -0400

    Updating printf message

diff --git a/ex.c b/ex.c
index e50b95b..862b3be 100644
--- a/ex.c
+++ b/ex.c
@@ -1,4 +1,4 @@
 #include<stdio.h>
 int main(){
-  printf("Hello, World!\n");
+  printf(Salutations, World!\n");
 }

This command tells git to look at the last snapshot, compare it with the current snapshot on the active branch, and generate a diff, or a set of comparisons indicating differences between the two files. Finally, I can rollback my changes with the following command:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git revert HEAD
[master 650e2cb] Revert "Updating printf message"
 1 file changed, 1 insertion(+), 1 deletion(-)
josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ cat ex.c 
#include<stdio.h>
int main(){
  printf("Hello, World!\n");
}  

And just like that I'm back to my old version! We can check the changelog to see this new update reflected:

josephraskind@josephraskind-ThinkPad-T470:/tmp/example/my_repo$ git log
commit 650e2cb7c8ad8bddfe2b5a8facc2deb34efffec2 (HEAD -> master)
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:49:40 2026 -0400

    Revert "Updating printf message"

    This reverts commit f5c21c7aa6865f53c8fa8b4e6f678ef7bb74c8f1.

commit f5c21c7aa6865f53c8fa8b4e6f678ef7bb74c8f1
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:36:59 2026 -0400

    Updating printf message

commit 40d18f3d5de5b48e074a179728affcb48828f5ef
Author: Joe Raskind <[email protected]>
Date:   Wed Jun 10 18:31:27 2026 -0400

    Adding ex.c to the repo

This is likely a lot to take in at once. I suggest you try your best to pay attention to the first lab as closely as possible and cross reference with this lecture and the Pro Git book.

If you get stuck or are confused, always reach out to me or the CAs!

Github, unlike git, is not free and open source software. Github is a proprietary, online developer platform owned by Microsoft which uses git as its basis. All of the labs and projects for this class use Github as it is the easiest way for me to track your assignment submissions without you zipping up files and submitting them through Brightspace. The only extra wrinkle that Github adds is the need to pull from and push to a remote repository. The first lab details how exactly that's done.