CSCI 265 Quiz 1 (2024) Sample Solutions

Question 1: git in your team project

In your own words, outline the process your team is using for to organize the branching/merging/pulling of your team's git repository.

Quiz 1 (2024) Sample solution For this one the mark was based primarily on how clearly you articulated your team's process and if it was reasonably consistent with the rest of your team. I did include comments if I thought there were concerns with the actual process, but didn't take off marks for those.
A sample process might look like this:

Our team is using github for our shared project repository
One team member has been designated the team git lead and will set up the github project
Another team member has been designated the team test lead
The main project branch will be used for the current stable release
A dev branch will be created for work currently in development
Each team member will clone the dev branch, and will only pull from/push to that branch (never to/from main)
When a team member thinks they're ready to push changes to dev they will follow these steps:

do a pull from dev and resolve any conflicts
check the team discord to see if anyone else has a push in progress
if so then wait for them to post that they've finished
once they post that they're finished do another pull and resolve any conflicts
check the discord again to make sure no one has jumped in while you were resolving conflicts
post your intention to push
carry out the push
post that you have completed your push

When the team thinks that the current dev state is suitable for migration to main, the git lead will do the following:

create a fresh clone of main, referred to below as staging
pull dev's changes into staging
notify the test lead that staging is ready for test

The test lead will then apply the team's test plan to staging, and either notify the team with the test results
If all tests passed then the git lead will push staging's changes into main as the new stable version.

Question 2: git for an individual scenario

Consider the following scenario where you're working for a client on a git repository, but you are the only developer involved:

You have the current client version in the master branch, and a dev branch for mainstream development. At the moment master is up to date with dev.
You are meeting with the client in about a week for some short term fixes they need soon, but you have some long term revisions you want to get started on the side that the client specifically wants *later*, not now.
You create a new branch, longTerm, off of dev, and work in that branch, managing to finish it up before the client meeting.
After the client meeting you go back to working in dev, finishing and testing their desired changes.
Once those are ready you get them back into master for the client to use.
Finally you merge longTerm back into dev for the combined changes (but not moving those into master until the client is ready for the switch).

Provide precise git commands (branch, checkout, add, commit, merge), in sequence, to work through that event sequence.
(Presumably file edits would be taking place prior to each add, but you don't need to show commands for those.)

Sample solution

check if we're in the right branch, dev, using
   git branch
switch to dev if we're not
   git checkout dev

create and checkout the longterm branch and carry out the updates there
   git branch longTerm
   git checkout longTerm   (or git checkout -b longTerm to do both in one step)
   ...do the modifications...
   git add filename  (for each of the modified files)
   git commit

switch back to the dev branch and carry out the client updates there
   git checkout dev
   ...do the modifications...
   git add filename (for each of the modified files)
   git commit

switch to master and merge in the dev changes
   git checkout master
   git merge dev
   ... resolve conflicts, if any ...

switch to dev and merge in the longterm changes
   git checkout dev
   git merge longTerm
   ... resolve conflicts, if any ...

Question 3: git in a team scenario

Consider the following scenario where three developers are working on code from a shared repository, and all happen to be editing file X as part of the changes they're making:

The shared repository has a master branch and a dev branch.
The three developers, Dev-A, Dev-B, and Dev-C, each clone the dev branch into their own space to work on.
(Aside: the clone command would be along the lines of "git clone LocationOfOriginal --branch dev")
Each makes their own set of changes to X and does a git add X and a git commit.
Dev-C is the first to be ready with their changes, they do a git pull and a git push
Dev-B is the next to be ready, so they then also do a git pull and a git push
Dev-A is the last to be ready, but they skip the git pull, i.e. they just do git push
Dev-C comes back to do more work on the project, and does a git pull before they start making any more changes.

(i) Which, if any, of the git pulls simply say X is already up to date and why?
(ii) Which, if any, of the git pulls actually update content in file X but without causing a conflict and why?
(iii) Which, if any, of the git pulls result in a conflict in file X and why?
(iv) Which, if any, of the git pushes encounters a conflict in file X and why?

Sample solution

First we'll walk through what happens at each of steps 4-7
   then use that as the basis for our answers

(step 4) Dev-C does a git pull, but nothing has changed in dev so pull says up-to-date
            (pull's 'up-to-date' check is only commenting on whether the source we're
             pulling from has changed).
         Dev-C does a push, which updates the content in dev.

(step 5) Dev-B does a git pull, which brings in the changes Dev-C pushed earlier.
         These changes conflict with the changes B made in step 3,
            so B must resolve the conflict.
         Dev-B does a push, which updates the content in dev

(step 6) Dev-A doesn't do a git pull, and instead tries to push immediately.
         git actually rejects the push, telling A there would be a conflict,
             so effectively A can't get their content into dev without doing
             the pull first (or applying dangerous options to override).
         When A relents and does the pull they'll have to resolve conflicts
             for the same reason as B in (step 5), after which they could push.

(step 7) Dev-C does a pull, which brings in the changes pushed earlier by B
             (and those by A if A got around to doing the pull-then-push).
         This does not create a conflict since C has not changed X since
             they last pushed (step 4).

Thus the answers to the questions are
(i) step 4: C gets the 'up-to-date' message in their first pull
(ii) step 7: C gets new content but no conflict in their second pull
(iii) step 5: B gets a conflict during their pull
(iv) step 6: A gets a conflict when they try to push without pulling
             (the push is thus denied and they are forced to pull *then* push)