We will be using Github to submit your labs and assignments throughout this course. You will need a Github account, so if you don't have one already, go to Github and sign up.
Once you have signed up for an account, fill out and submit this Google form. Completing the form will be part of your grade for this lab.
The Professor will create a GitHub Classroom assignment for each homework assignment or lab, and provide the invitation URL for that assignment to you. If you want to try things out, here is a test invitation link(It's probably easiest to right click, and select "Open link in a new tab" so you can flip back to these instructions.)
When you navigate to the invitation link for the first time, GitHub Classroom will ask you if you wish to accept the invitation. When you answer "Yes", then GitHub Classroom will automatically create a private repository for you, initialized with any template code or instructions the Professor has provided. (You may need to log in to Git with your Git Userid and Password before the accept is complete, but once you've logged in once on the current system, you should get a cookie for Git that remembers your userid and password.) The repository name will start with whatever prefix the Professor has specified (usually "lab01" or "hw01" and so on), followed by a dash, followed by your Git userid. For instance, if you accept the test invitation above, you will get a repository called "test-userid", where userid is your Git userid.
If you navigate to the invitation link after you have accepted the invitation, GitHub Classroom will give you a hyperlink to your version of the repository instead of asking you to accept again.
When you open a view of your repository in the web, you are looking at the cloud version of your repository. The upper left of the screen has links to the organization (class) you belong to, the repository, and the repository used to initialize your private repository. Under that are several tabs, with the leftmost tab called "Code" highlighted. This is the tab we will use almost exclusively (although we may use the "Issues" tab for automated assistance from the CA's or professor.)
In the "Code" tab is a link to "commits". If you click on that link, you will see the history of this repository, showing each committed version of that repository. You can use this link to go back to earlier versions.
Underneath the "commit" line, on the right of the screen, is a green "Clone or download" button. If you click on that button, You will see the URL associated with this repository. Click on the clipboard icon to copy that URL to your cut/paste buffer. This is the URL that you will need to clone your repository.
If you keep reading down, you will see the list of files in the repository, including any java code provided by the instructor or added by you, once you commit new code files. These are hyperlinks so you can look at the code in those files.
The last thing in the "Code" tab is "README.md". The .md file type is "markdown", which enables the Professor to provide a formatted set of instructions that describe how to complete the assignment.
When you look at your repository using a web browser, you are looking at the master copy of your repository. You will need a local copy of the repository on disk in order to edit, compile, and test any changes to the repository. You make a local copy of your repository by cloning it.
Clone your repository by open a command line window on the machine where you want to create a cloned copy of the repsository. Then run the command git clone url, where url is the URL that describes your repository. You can get this URL by looking at your repository in the web browser, and clicking on the green "Clone or Download" button.
When you hit enter, Git may ask for your git Userid and password. Once you enter these, git will make a sub-directory of the current directory named with the repository name. If you "cd" to this subdirectory (make it your current directory), then you will see all of the files in that directory. You may edit these files, compile them, and test them in your local repository. Remember, you are updated the local cloned version of the repository, not the master copy.
See git clone for complete documentation of the git clone command.
Git keeps track of a specific list of files. If you create new files in a cloned repository, Git does not know about those files. You need to perform a special action to add those files to your repository. This is done by using the command git add file(s) where file(s) is the full file name of a specific file or list of files that you want Git to include as part of your repository.
See git add for complete documentation of the git add command.
You can use the git status command from your local repository to check the current status of your repository. The git status command will tell you:
See git status for complete documentation of the git status command.
Once you have made and tested all the changes to your repository (including adding files using git add if there are new files), use the git commit -a -m"commit comment" command to indicate that you are happy with your changes and you intend to move those changes to the master repository. The commit comment is a line of text that you want to associate with these changes so you can remember why you made those changes. The "-a" flag tells the commit command to commit anything that has changed. (If you don't specify the -a flag, then you need to include the names of all the changed files on the git commit command line.) You may want to run the "git status" command after running git commit to make sure everything has been committed corrrectly.
Remember, the git commit command does not update the master repository. You are only committing the changes in the local version of the repository. You still need a git push command to copy those committed changes to the master repository.
See git commit for complete documentation of the git commit command.
Once you have committed changes to yoru local repository, the next step is to copy those changes to the master repository. This can be done using the git push command. The git push command will copy any committed changes from the local copy of the repository and copy those changes to the master version of the repository. After you complete a git push, you may want to look at the master version of the repository on the web and make sure the changes you expected are reflected in the master version. You may have to hit the "refresh" button in your browser to see those changes, and GitHub warns that sometimes it takes up to 10 minutes for those changes to get reflected, although usually, changes seem to occur almost immediately.
You can also use a git status command to make sure you changes have been pushed to the master.
See git push for complete documentation of the git push command.
Most of the time, we will only be using a single local version (clone) of a repository, but if you ever have occastion to have mutliple local versions of a repository, and you use one local version to commit and push changes to the master, then the second copy of the repository will not reflect those changes. In this case, when you want to work on the second version of the repository, start off with a git pull command. The git pull command tells git to pull any changes in the master repository that have not been made to the local copy into the local copy.
If you don't remember to do a git pull in the second copy of your repository, and start making changes to the second copy, those changes could conflict with the changes made to the master, and could cause problems. To avoid these problems, it's best to always do a git status at the start of a session, and do a git pull if there are any changes to the master that need to be propagated locally when you are using multiple clones of a repository.
See git pull for complete documentation of the git pull command.