- set up your software development environment,
- learn the basics of programming in Java, and
- learn basic version control with Git.
To learn Java, you will read Reading 2 and complete the reading exercises on that page, and you will do Java Tutor exercises to practice writing code.
11am before class: Problem Set 0 Part I due, including all steps and GitStream exercises on this page. You must have Java, Eclipse, Constellation, and Git set up and working on your laptop.
See the course calendar for the full schedule of office and lab hours. Regular office hours will begin Monday, February 11. Lab hours may change depending on deadlines, so always check the calendar to see when lab hours are scheduled.
From Java Development Kit 11 Downloads, download Java SE Development Kit 11.0.2 and run the installer. On macOS using Safari: right-click and open the link in a new tab, do not follow Safari’s prompt to use Java on web pages.
You can use OpenJDK 11 instead of the Oracle JDK, but OpenJDK downloads require manual installation.
To install Git: from the Git project page, follow the link on the right side to download the installer for your platform.
Follow the instructions in the README file in the downloaded
- use Git from the Windows command prompt,
- checkout Windows-style, commit UNIX-style line endings, and
- add a shortcut to the Desktop
- Eclipse IDE for Java Developers
- Java Tutor, our plug-in for learning the syntax and semantics of Java
- Constellation, our plug-in for working on in-class programming exercises
From Eclipse Downloads, download the Eclipse IDE 2018-12 installer (orange button).
If the installer does not find it automatically, manually select the Java 11 JDK you installed in step 1.
When you run Eclipse, you are prompted for a “workspace” directory, where Eclipse will store its configuration data. You should not run more than one copy of Eclipse at the same time with the same workspace.
While you can store your code in the workspace directory, we do not recommend it. Instead, put your code elsewhere (in 6.031, you will do that with Git in the terminal), then import it into Eclipse by following assignment instructions.
On the left side of your Eclipse window is the Package Explorer, which shows you all the projects in your workspace. The Package Explorer looks like a file browser, but it is not. It rearranges files and folders, includes things that are not files or folders, and includes projects stored anywhere on your hard drive that have been added to the workspace.
The 6.031 technical FAQ has some tips and tricks to help you make the most of Eclipse.
If you don’t see it: go to Window → Show View → Other…, select Java Tutor → Java Tutor and press OK. Then drag the Java Tutor view so it stacks with the Package Explorer, filling up the left side of the window.
If you see a “Waiting for pair…” dialog but your browser does not open, or if the wrong browser opens and you do not have certificates: first set a different browser as your default (e.g., make Safari your default browser if you want to use Chrome), then go back and set the desired browser as the default. Cancel “Waiting for pair…” and do “Set up Constellation” again to make sure the correct browser opens.
A command-line is an interface to your computer, similar to the Mac Finder or Windows Explorer, except that it’s text-based. As the name implies, you interact with it through “commands” — each line of input begins with a command and has zero or more arguments, separated by spaces. The command-line keeps track of what directory (folder) you’re in, which is important to many of the commands you might be running.
On Windows, Git for Windows includes Git Bash. Run Git Bash to open a terminal where you can run all the commands below, in addition to Git commands.
On a well-configured system, your current directory is displayed as part of the prompt that the system shows when it’s ready to receive a command. If that’s not the case on your system, post on Piazza to get help configuring your prompt.
Who are you?
nano is a simple text editor. It does not come with the Windows version of Git, so Windows users should choose a different option.
will configure Git to use the nano editor. The commands to use the text editor (like copy, paste, quit, etc.) will be shown on the bottom of the screen. The
^symbol represents the
ctrlkey. For example, you can press
ctrl-Oto save (nano calls it “write out”) and then
On macOS and Windows, your default editor will be Vim.
in the terminal.
As we’ll see in step 7 of this guide,
git logis a command for looking at the history of your repository.
Visit github.mit.edu and log in.
Follow the GitHub Enterprise instructions to set up SSH:
You can find general instructions and a list of exercises on the GitStream page. If you encounter a problem, please post on Piazza.
Git is a version control system (VCS). The Pro Git book describes what Git is used for:
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. […] It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover.
add (or “stage”): Before changes to a file can be committed to a repository, the files in question must be added or staged (before each commit). This lets you commit changes to only certain files of your choosing at a time, but can also be a bit of a pain if you accidentally forget to add all the files you wanted to commit before committing.
clone: Since Git is a “distributed” version control system, there is no concept of a centralized Git “server” that holds the latest official version of your code. Instead, developers “clone” remote repositories that contain files they want access to, and then commit to their local clones. Only when they push their local commits to the original remote repository are other developers able to see their changes.
pull: The act of retrieving commits made to a remote repository and writing them into your local repository. This is how you are able to see commits made by others after the time at which you made an initial clone.
git clone URI-of-remote-repo
git clone URI-of-remote-repo project-name
URI-of-remote-repo with the location of the remote repository, and replace
project-name with the appropriate project name, like
The result will be a new directory
project-name with the contents of the repository.
This is your local repository.
Cloning problem sets: for each problem set in 6.031, you will have a Git repository on Athena.
The most important of these is
Run it any time to see which files Git sees have been modified and are still unstaged and which files have been modified and staged (so that if you
git commit those changes will be included in the commit).
Note that the same file might have both staged and unstaged changes, if you changed the file more after running
When you have unstaged changes, you can see what the changes were (relative to the last commit) by running
Note that this will not include changes that were staged (but not committed).
You can see those by running
git diff --staged.
What’s going on here is that Git won’t let you push to a repository unless all your commits come after all the ones already in your remote repository. If you get an error message like that, it means that there is a commit in your remote repository that you don’t have in your local one (on a project, probably because a teammate pushed before you did). If you find yourself in this situation, you have to pull first and then push.
It downloads the changes and stores them in its internal state. At this point, the repository doesn’t look any different, but it knows what the state of the remote repository is and what the state of your local repository is.
If you made some changes to your repository and you’re trying to incorporate the changes from another repository, you need to merge them together somehow. In terms of commits, what actually needs to happen is that you have to create a special merge commit that combines both changes. How this process actually happens depends on the changes.
If you’re lucky, then the changes you made and the changes that you downloaded from the remote repository don’t conflict.
For example, maybe you changed one file and your project partner changed another.
In this case, it’s safe to just include both changes.
Similarly, maybe you changed different parts of the same file.
In these cases, Git can do the merge automatically.
When you run
git pull, it will pop up an editor as if you were making a commit: this is the commit message of the merge commit that Git automatically generated.
Once you save and close this editor, the merge commit will be made and you will have incorporated both changes.
At this point, you can try to
git push again.
Sometimes, you’re not so lucky.
If the changes you made and the changes you pulled edit the same part of the same file, Git won’t know how to resolve it.
This is called a merge conflict.
In this case, you will get an output that says
CONFLICT in big letters.
If you run
git status, it will show the conflicting files with the label
You now have to edit these files and resolve them by hand.
First, open the files in Eclipse.
The parts that are conflicted will be really obviously marked with obnoxious
Everything between the
<<<< and the
==== lines are the changes you made.
Everything between the
==== and the
>>>> lines are the changes you pulled in.
It’s your job to figure out how to combine these.
The answer will of course depend on the situation.
Maybe one change logically supercedes the other, or maybe they can be merged somehow.
You should edit the file to your satisfaction and remove the
>>>> markers when you’re done.
Once you have resolved all the conflicts (note that there can be several conflicting files, and also several conflicts per file),
git add all the affected files and then
You will have an opportunity to write the merge commit message (where you should describe how you did the merge).
Now you should be able to push.
You can see the list of all the commits in the repository (with their commit messages) using
You can see the last commit on the repository using
This will show you the commit message as well as all the modifications.
Long output: if
git log or
git show generate more output than fits on one page, you will see a colon (
:) symbol at the bottom of the screen.
You will not be able to type another command!
Use the arrow keys to scroll up and down, and quit the output viewer by pressing
Commit IDs: every Git commit has a unique ID, the hexadecimal numbers you see in
git log or
The commit ID is a unique cryptographic hash of the contents of that commit.
Every commit, not just within your repository but within the universe of all Git repositories, has a unique ID (with extremely high probability).
You can reference a commit by its ID (usually just by the first few characters).
This is useful with a command like
git show, where you can look at a particular commit rather than only the most recent one.
We will revisit Git and learn more about version control in future classes. If you’ve installed the software, set up Eclipse, and completed the GitStream exercises above, you’re ready to move on to Problem Set 0.