Advanced Version Control Version Control with git Recall

Advanced Version Control

Version Control with git - Recall

Without Branching - Scenario All team member push to master Susan is updating the backend Will take weeks Stable when complete Intermediate changes have unpredictable consequences elsewhere John is making changes to the frontend Sees side effects caused by Susan’s pushes Thinks his code caused the changes

Without Branching - Scenario Tempting solution Don’t push to the remote repo until all changes are complete Changes only exist locally during development One hard drive error away from losing weeks of work! If there are 10+ developers with different tasks on the same codebase? Complex interactions between modules can multiply issues

Without Branching – Worse Scenario Someone pushes code with errors Code breaks Who broke it? Everyone’s workflow halts and the search begins It happens All code functions locally ex: A function header is changed

Branching New commits are only added to the current branch Can implement experimental code without affecting others When the life of the branch is over Merge it into the primary codebase Branching is crucial on large teams

So far, you have used only a single branch (master) for synchronizing code Synchronizing frequently-changing code requires merging Merge conflicts result when the same code is simultaneously modified by >1 developer EXAMPLES? ? ? git push results in errors if someone else worked on the same code and modified/pushed it before you did. Merge conflicts can often be resolved automatically if the code modifications are sufficiently separated git pull automatically merges modifications when possible Merge conflicts sometimes need manual resolution git pull fails to resolve the conflict, and you must manually edit the file(s) containing the conflict indicators (<<<, >>>) git commit stores your manually-merged file(s) git push uploads the file(s) to the remote branch 7

The master branch should only be used for maintaining production-ready code Code modified or created during a Sprint should be maintained on separate branches A second standard branch – often named “dev” is typically used to maintain code that is being actively worked on At the beginning of a phase of development, the dev branch is identical to master During development, the dev branch maintains the evolving code After a feature has been tested, the dev branch contains the completed code. The dev branch is then merged into the master branch, and the process repeats Version 1 Version 2 Version 3 master branch merge dev We can reduce the amount of synchronization we need to do, as well as the number of merge conflicts, by using branches. 8

There are two ways to create dev branch 1. Create a local dev branch and then push that branch to the remote $ $ git branch dev << Note: the command executes silently>> git checkout dev # and add, commit… git push -u origin <branch> #ONLY USE –u THE FIRST TIME! 2. Create a remote dev branch (using the Bitbucket web interface), and then pull that branch locally $ git fetch && git checkout dev From bitbucket. org: se 2800/My. Repository * [new branch] dev -> origin/dev Branch dev set up to track remote branch dev from origin. Switched to a new branch dev' 9

Branching • You can create a branch through the bitbucket GUI • Pull the branch using • Checkout NOTE: If you currently have nothing to commit, and you switch branches, the code in your working directory will be replaced with the code that is in the branch you’re switching to. 10

Wait! Won’t we still run into the same kind of merge conflicts if we all develop on the dev branch? 11

Yes! So teams usually use additional feature and defect branches to isolate their work Additional branches – often named for the story or defect number, are typically used to maintain code that is being actively worked on Usually, only one person works at fixing a defect Often, different story features are worked on in parallel by only a few people on a team When a story or defect is complete (and tested), its branch is merged into the dev branch. When all stories and defects have been merged into dev, dev is merged into master Version 2 Version 1 master branch merge dev branch defectfix branch merge feature. A 12

Merging back into a branch Suppose you have finished fixing a defect on the defectfix branch You have fully tested it and verified the fix You have pushed your local work to the remote with a git push, and since you’re the only one working on the defectfix branch, you didn’t get any merge conflicts. You want to merge your defect fix into the dev branch so that it later gets merged into master. You want (need) to have your teammates review your fix and approve it before the merge can take place. You initiate a Pull Request to begin the merge process. Version 1 master branch dev branch merge defectfix Pull Request here! 14

Executing a Pull Request Select Create Pull Request. Enter a title and add all team members as reviewers. Leave the Close branch box checked. Note that the differences between the two branches are shown in on the Overview tab. Your teammates will get a message from Github indicating that they have code to review. They will review the differences, and either approve or decline the request. Once all have reviewed the request, you can click on the Merge button, and the defectfix branch will be merged into dev. The defectfix branch, since it is no longer needed, will be automatically deleted from the remote (since you selected Close branch above). 15

Best Practices for Branching 1. Create a Feature branch off of Master or dev as appropriate a. Master should always be kept in a ‘production-ready’ state. 2. Make your changes. a. Commit — saves a version of your code locally b. Push — sends your branch/commits to Git 3. Create a Pull Request when you are ready for a review

Very Large projects Consider “Git-Flow” Features get pushed to a Develop branch, which the tests are ran against and deployed to a testing server for QA, before being pushed to Master, and later deployed to Production. Feature Develop Master

Hotfixes Production release contains a defect Create a hotfix branch from master Fix the defect merge fix into: Next production release Develop

Release Branch off develop when approaching a release No features added Extensive testing and defect fixes Merge all changes back to develop When confidently stable Merge into master as a release

Versioning Tag the current state of the code Can easily work with a previous version if needed Use versioning on master

Perspective • Windows development uses Git! • There approximately 8500 commits per day • 1760 builds per day! • 200 pull requests to the master branch per day (500 engineers) • https: //arstechnica. com/information-technology/2017/05/90 -of-windows-