ITC515 Professional Programming Practice Assignment-Charles Sturt University Australia.

Pull the project code baseline setup:
1.Make sure your project code baseline on the master/remote repo.
2.Create a folder for the project in your PC.
3.Create the project folder inside the folder.
4.Initialise your local repo inside the project folder (git init).
5.Synchronise your local repo with the remote repo (git remote add origin your remote repo URL)
6.Pull the remote repo to your local repo (git pull origin master).
7.Checkout to your branch (git checkout your branch name).
8.Start doing the changes in your branch and after you finish, see below Merging protocol.
ITC515 Professional Programming Practice Assignment-Charles Sturt University Australia.

Merging FROM and merging TO Master:

1.Complete any changes you are supposed to make in your branch at your working directory. (using IDLE)
2.Commit the changes in your branch. (git add . / git commit -m “Your message”)
3.Checkout master. (git checkout master)
4.Pull master – you now have the latest version of master in your local repository – and any updates on the server have been applied in the local master branch. (git pull) OR (git pull origin master)
5.Checkout to your branch again. (git checkout your branch name)
6.Merge master INTO your branch. (git merge master)
7. Deconflict/debug in your branch. Your branch now contains all your changes INTEGRATED with the latest version of master – which is what needs to be reviewed. (using IDLE)
8.Commit and push any additional changes caused by the deconflict/debug up to the tracking branch on the server. (git add . / git commit -m “Your message”/ git push)
9.On your tracking branch on the server perform pull request and select the reviewer.
10.Notify the moderator, and the reviewer to review the changes.
11.After the reviewer did his work then will inform the moderator and you that the review completed.
12.When you are notified by the reviewer that it is YOUR TURN to approve the pull request and merge to master in case if there are no changes required by the reviewer.
13.Do the changes on IDLE if you are notified of any defects by the reviewer- make the changes and commit them IN YOUR BRANCH – commit per defect, and identify the defect. Push the changes to the server, and they will UPDATE the pull request.
14.It may need to do the STEP from 4 to 8 if someone updates master on the server during the time you are fixing the changes.
15.Once the review is completed (with all defects remedied and approved) – complete the pull request i.e. someone approve it, and someone merges it. Master should now contain EXACTLY the same code as the latest commit in the merged branch. (Remember – as a reviewer – checkout and RUN the branch to make sure it won’t break master – BEFORE approving the request)
16.Update your team charter.

ITC515 Professional Programming Practice Assignment-Charles Sturt University Australia.

This is the whole point of this protocol – there should be NO changes in the master which have not been reviewed, and the result of the merge is already COMPLETELY KNOWN. If you don’t merge FROM before merging TO, then even if there are no conflicts between merging branch and master, the result of the merge is UNKNOWN – and even non-conflicting changes can cause bugs. So, if you just merge TO, you can break master WITHOUT REALISING IT.

If you merge FROM before merging TO, and deconflict/debug in your branch BEFORE issuing the pull request, then all changes that will affect master get reviewed, and if you do this correctly, then you should NEVER BREAK MASTER ON THE SERVER.

Once the pull request is completed on the server, you are ready to repeat the process for the next person who is ready to merge their changes. They start the process again by pulling the latest version of master – which now contains the results of the just-completed pull request.

ITC515 Professional Programming Practice Assignment-Charles Sturt University Australia.

The point is that pull requests and merges into master need to be coordinated, and every one of them needs to be based on the LATEST version of master – and that means the version of the master as updated by the previous pull request.