CS 3410
There are a variety of good Git tutorials on the web (Codecademy, Github, and Bitbucket, to name a few). This one will provide a basic intro to the most essential features of Git that you will be using in this course, but you are highly encouraged to delve into more depth, as you will definitely use Git or another version control software quite often as you continue in CS. If you are already familiar with Git, feel free to skim this tutorial, but you will be expected to know the basics of using Git.
Git is a version control software, and its primary purpose is to ensure that as you make incremental changes to your project, you will always be able to revert to, see, and combine old versions. When combined with a remote repository (in our case Github), it also ensures that you have an online backup of your projects. It also allows features to be developed separately from the "master" branch, and only included when they are ready. This can all be done concurrently and distributed among multiple people.
Navigate to the repository that you were provided for this course, and locate the green button on the right that says "Clone or Download". Click it, then copy the link provided. In a terminal, navigate to the folder you would like your project, and type git clone https://github.coecis.cornell.edu/course/myrepository.git This will download the repository from the remote to your computer - you will need to type in your Cornell password in order to download it (and every time you make changes or pull down others' changes).
Enter cd my_repository_name to enter the repository.
Enter git status to see an overview of your repository. This command will show the status of your repositories and the files that you have changed.
There are 3 steps to track a file with Git. All changes start out unstaged - this means Git is not aware of the changes to the file. Create a new file in the root directory of the git repository, then type git add file_name from the directory containing the file to stage the file.
Now enter git status again, and you will see the file you added highlighted in green. This means that it is staged. You can stage as many files as you'd like - this is simply a temporary step before you make a commit, which is saving the state of all the staged files as they are right now.
A commit is a record of the state of the repository at a specific time. To make a commit, enter git commit -m "commit message here", where the commit message is an explanation of the changes that you have made since you last committed.
This commit is now on your local computer, but to add it to the remote (Github), enter git push. This will add your new commit to the remote repository, where you or anyone else who has access to the repository can view it.
Now, if someone has made changes since you last began work, enter git pull to pull down those changes and bring them into your local repository. If all goes well, this will bring your local repository up to date with the master, and you can continue making your own changes to later be pushed.
Finally, enter git log to see the history of the current repository. This will show you the author, time, and commit message for every commit, along with the commit hash, which is how Git labels your commits and how you reference them if need be.
Git was primarily created for software projects, but we will also be using it for Logisim this semester. This is a somewhat non-typical usage, but it provides great benefits in that it ensures that every student has a backup of their circuits, and that they can revert to a previous version if something goes wrong.
Logisim circuits do not respond well to Git's merge functionality. Normally, if you have made changes on your local repository and then try to pull down changes from the remote repository, Git will merge the two together, combining the changes where it can. This works very well for code, but it does not work at all for Logisim circuits. So, do not work on your circuit without first pulling from remote, and do not work on your circuit concurrently on two computers and expect Git to merge the circuits for you. If you do, use Logisim's copy/paste feature to combine the two circuits manually, then commit the result to Git.
If you did make local changes but did not commit them and do not need the changes, you can type git stash to revert the changes back to the last commit. This does not delete your changes, but "stashes" them away. They can be retrieved, but it is often a bit of a process to do so, so make sure you've copied all the changes you'd like to keep first.
If you did commit these changes, enter git reset COMMIT_HASH, where commit hash is the hash of the commit that the remote repository is at (something like eb6a5a8ad3b0e7cc0d694d44d3ab866129db5965), found using git log. This will undo the last commit, but leave the changes there, so see the section above for what to do from here.
If you did git pull without realizing that you had made changes or that there were new changes in the remote repository, things get a bit tricky, so try to avoid this. If you did git pull and now see CONFLICT (content): Merge conflict in FILE, this means you have a merge conflict - the changes that were made conflicted with each other. Type git merge --abort then see the first paragraph in this section. If you don't see that, then Git thinks the merge was successful, but it almost certainly wasn't - your circuit is likely not going to work in Logisim. Use the section above to revert the merge commit and the commits before that.
It takes a long time to master Git. If you run into real trouble, don't be afraid to ask a TA or simply reclone the project. It's very easy to make Git do very strange things very quickly, but ultimately Git is an invaluable tool for any large project.