Goals

• practice with using git! It is not as scary as it seems!

Collaboration

For assignments in CIS 3990, you will complete each of them on your own. However, you may discuss high-level ideas with other students, but any viewing, sharing, copying, or dictating of code is forbidden. If you are worried about whether something violates academic integrity, please post on Ed or contact the instructor(s).

WARNING

Setup

In this assignment the setup will be a bit different. To setup your assignment you will have to go to gradescope and there should be an assignment called HW05: git [REPO CREATION]. You should submit to this assignment a file called account.txt containing your e-mail on the first line and git account on the second line of the file. (This is the same file you submitted when you created your repo for the course earlier in the semester.)

The gradescope assignment will then create a new repo for you to use just for this assignment. this new repo will have a similar name as your “normal” course repo. The only difference is that it will have the prefix git-hw- (e.g. git-hw-25fa-cis3990-tqmcgaha.

Once you have that repository created, you should go inside of your docker container, navigate to a directory outside of your already existing repo and clone the new repo. (To change directory in the terminal, use cd. You likely want to use cd .. to go to the parent directory [and thus, leave the current directory] if you are already in the repo).

To clone a repo, you need to run the git clone command, with the link copied you will copy from GitHub:

git clone <copied url>

If you are unsure of how to do this, feel free to either look at “Step. 3 Pull repository from github” in the setup document or post on ed.

Instructions

Inside of your new repo, you will notice four files, some of which we will be editing in this assignment. There is one file that is of particular importance: git-hw-script.sh. This is a small script that is important for setting up the different “scetions” of this assignment. The other files are all just files that serve as a “setting” for us to do some things with git.

This assignment is broken up into four sections. You should complete each section one-at-a-time, and after you complete each section you should submit to gradescope to make sure that you are passing the tests for that section.

To submit to that section you will need to tag and push your changes:

tagging

Whenever you are done with a section and want to submit it and/or move onto the next section you MUST “tag” the current state of the repo, which will act as a sort of “checkpoint” of your work. To tag a repo with the tag name basic-done, we would run the following commands to make the tag and push it:

git tag basic-done
git push --tags

If for some reason you want to delete the tag (e.g. you tagged the wrong commit or made some other mistake) then you should run:

git tag -d basic-done
git push origin :refs/tags/basic-done

resetting

If you encounter any issues in a section you can either undo your previous aciton(s) or reset the whole section. To undo a command will vary based off of what you are doing. Removing a tag is easy and is described above. If you want to undo a commit that hasn’t been pushed yet, you can do git reset HEAD~. To reset a file to what it was at the last commit you can do git checkout -- <filename>. If you are doing something more complex than these, you may just want to reset that section using the instructions below.

To reset your progress on whatever section you are on, then there are a few steps you must do:

1. If you have already created a tag for the section you want to reset because you thought you were done, then you must delete the tag (instructions in the tagging section above)
2. You must run git reset --hard <tag-name> where the tag name is the name of the tag from BEFORE the section you are working. To be more clear:
   • If you are working on the basic section, you must run git reset --hard initial
   • If you are working on the auto-merge section, you must run git reset --hard basic-done
   • If you are working on the merge-conflict section, you must run git reset --hard auto-merge-done
   • If you are working on the pull-request section, you must run git reset --hard merge-conflict-done
3. If you are not working on the last section skip this step. If you are working ont he last section and have already created a branch and want to reset, you should run git push origin <branch-name> --force-with-lease, then git checkout main and run the command from step 2 again before moving on to step 4.
4. You must then run git push origin main --force-with-lease
5. Finally you should run git-hw-script.sh with the correct argument for the section you were working on (the same as when you first run this file when starting a section)

Overview

basic

To start this, you should be inside the repository for this homework assignment and run the command ./git-hw-script.sh basic to set things up. Doing so will create a folder (outside of this one) called DO_NOT_TOUCH_repo_copy. As the name suggests, you should not touch that folder (if you want, you can delete it after you are done with the assignment).

The first one is kept simple to make sure that things are working correctly and to start off “easier”. For this section, your job is to only do a few things:

1. create and populate a .gitignore that makes it so that the result of compliation (all .o files and main) are ignored by git and will not be pushed.
2. add, commit and push the .gitignore
3. fix main.cpp so that it compiles, add the file, commit it, and push it.
4. Finish off by tagging the repo with the tag basic-done and pushing it. Make sure you pass the autograder, and if you do, you are done with this section.

auto-merge

This next section will show you the basics of how to handle a merge in git. We will start simple by looking at a common (but easy) case with git merge: the case where git is smart enough to resolve any conflicts for you.

1. first you should make sure you passed the autograder for the previouss part we are serious about this, make sure you pass the autograder for the first part.
2. Run ./git-hw-script.sh auto-merge
3. edit the main.cpp file again to remove the first print that prints “hello”.
4. try adding, committing and pushing your change.

At this point, your command line will print something like the following to show that a merge will need to take place:

type git pull and another error will come up:

This will only show up the first time you try to merge in a repo, and is ok! We will go with merging, so run the first command listed: git config pull.rebase false.

From here you can run git merge and you will notice something like the following:

This indicates that the merge was successful automatically (since different lines in our program changed) and there is nothing for us to do. You can type a commit message by just hiting enter and typing in the terminal. Once you are done typing a message hit CTRL + X to exit nano. It may prompt you to save what you wrote, can you can confirm that by typing Y then hitting the enter key.

From here, all you need to do is push and the “merge” will be resolved and pushed to your repo!

From here try tagging your repo with auto-merge-done, pushing the tag, and make sure that you pass the autograder on gradescope

merge-conflict

This section will take a look at how to resovle a merge conflict that git cannot do for you and thus requires human intervention.

1. first you should make sure you passed the autograder for the previouss part we are serious about this, make sure you pass the autograder for the first part.
2. Run ./git-hw-script.sh merge-conflict
3. edit the main.cpp file again. This time, we are editing lines 22 through 27 (your line numbers may change, it is a block of code that has push_back in the first line) to remove all explicit calls to the json constructor (which are unecessary since the constructrs support implicit conversion). These are any instance of json that are followed by a parenthesis and something to construct the json object from. e.g. json(4.0). There should be one change you need to make on each line. Make sure your code compiles and works properly afterwards!
4. try adding, committing and pushing your change.
5. after pushing you will again you will get an error. Try repeating steps similar to what we did in the previous section until you get a message like Automatic merge failed; fix conflicts and then commit the result.. It should look something like this:

From here you should open main.cpp and you will see something weird like this:

<<<<<<< HEAD (Current Change)
  some code here
=======
  some other code here
>>>>>>> update-score (Incoming Change)

The commit and push we just made conflicts with another commit made just before us. In the previous section git could resolve it automatically. Here it is uncertain so it leaves it to us. The code between the <<<<<<< HEAD (Current Change) and the ======= is the code we pushed. The code between ======= and >>>>>>> is the change pushed before us, which was to update the scores from 4.0 to 5.0.

To resolve this conflict, all you need to do is make main.cpp look the way you want it to be. You should change it so that it has the updated score (5.0) and also doesn’t have the json constructor calls we removed earlier (in other words, we are incorporating the changes from both commits manually). Afterwards there should be no <<<<<<<, ======= or >>>>>>> line in your code anywhere, only the lines of code that should be in the code. You program should be able to compile and run sucessfully. From here, add, commit, push, tag (with tag merge-conflict-done) and test on the autograder. If you pass these tests, then move on to the next section.

pull-requet

For this last section, we will use a feature that is not part of git, but supported by most git hosts (like github). You will be creating a pull request and then assigning the course staff to review it.

1. first create and checkout a new branch called echo-bravo.
2. change the name of the variable the_json (and all usages of that variable) to instead be test_results).
3. add, commit and push your changes. It may tell you that our new branch is not on upstream. run the command it suggests so that our newly created branch also appears in the github repository.
4. Now we will create a pull request. To do this:
   • go to the github page for your repository, and click the Pull Requests tab near the top (after “code”, and issues”)
   • hit the green “New pull request” button in the upper right
   • It will then take you to a page titled “Compare changes”. Near the top but beneath the “Compare Changes” title it will say something like base:main <- compare: main with either side of the arrow being a drop down menu. Select the compare drop down and change it from main to echo-bravo

Once you have created the pull request, all you need to do is again submit to the autograder (no tagging needed this time!) and the autograder will confirm the changes you made and merge your branch into main.

This is an example of how most organizations maintain their code. Pushing to main is forbidden in most cases, and instead you create a new branch with all your work, then create a pull request (assigned to a co-worker) to merge those changes into main. The co-worker then reviews your changes and confirms the pull request if it looks good to them. If it looks bad then they will reject it and give feedback on what you need to fix.

Grading & Testing

This assignment is entirely autograded. To test your code (and you should test after every section), you just need to make sure you have the proper tag created, pushed and then you submit your repo following the directions below to the autograder.

There is no style grading for this assignment. If you are passing the autograder, then you are done!

Submission

Submitting for this assignment is also a bit different. Please submit a file called repo.txt that just has the name of your repo. This should be something like git-hw-25fa-cis3990-tqmcgaha. Submit this repo.txt to Gradescope.