Module 7.5- Code Maintenance- Version Control Systems & Branching

Question 1

Understanding what Version Control Systems (VCS)

Answer 1

• imagine working on a project where you can track every change you make, revert to a previous version, or collaborate with others seamlessly without worrying about overwriting each other’s work
• that’s exactly what a version control system does-it helps you manage and keep track of your project’s history
• Track Changes Over Time- every modification to your code is recorded, so you can see what changed, when, and by whom
• Revert to Previous Versions- if something goes wrong, you can easily roll back to an earlier state of the project
• Collaborate Efficiently- multiple developers can work on the same project at the same time without interfering with each other’s progress

Question 2

Types of VCS

Answer 2

• Local VCS- a local VCS is one that stores the entire version history of a project on your own computer
• this method is simple but lacks the collaboration features found in more modern systems
• Centralised VCS- in a centralised VCS, like Subversion (SVN), there is a single central repository where all the code is stored
• users check out the code, make changes, and then commit those changes back to the central repository
• while it supports collaboration, it can be a single point of failure-if the server goes down, no one can work on the project
• Distributed VCS- in a distributed system, every developer has a complete copy of the project’s history
• changes can be made and committed locally, and then shared with others through a remote repository, such as GitHub or GitLab

Question 3

Benefits of a Distributed VCS

Answer 3

• Greater Flexibility- can work offline and sync your changes when ready
• Collaboration Made Easy-developers can work on their own copies of the code and merge changes back into the shared repository when they’re ready
• e.g. if you’re using Git, you’ll have a complete local copy of the project and can work on it even without an internet connection- once you’re done, you can push your changes to a shared repository for others to access

Question 4

Using Git for VC

Answer 4

• with Git, you can track every change in your project and collaborate with others smoothly

Question 5

How does Git work?

Answer 5

• operates by creating snapshots of your project, called commits
• each commit represents a specific point in the history of your project
• these commits can be shared with other developers through a remote repository, such as GitHub

Question 6

The Basic Git Workflow

Answer 6

• Initialise the Repository- start by creating a new Git repository with git init
• Stage Changes- as you make changes to your project, you use git add to stage the files you want to include in your next commit
• Commit Your Changes- after staging, use git commit to create a snapshot of the current project state
• add a meaningful commit message, like git commit -m “Fix login bug”
• Push to a Remote Repository- when you’re ready, push your changes to a remote repository like GitHub with git push
• Pull Changes from Others- if your teammates have made updates, you can use git pull to incorporate their changes into your local repository
• e.g. after fixing a bug, you can create a commit like “Fix issue with user authentication” and push it to GitHub, where others can pull your changes and test them

Question 7

Branching in Git

Answer 7

• branching lets you work on a separate version of your project without affecting the main codebase
• branches are essential when you want to experiment with new features, fix bugs, or collaborate without breaking the main project- they allow you to:
• Isolate Work
• Collaborate on Different Features
• Keep the Main Codebase Stable
• Create a Branch
• Work on your Branch
• Merge your Changes
• e.g. if you’re adding a new login feature to a website, you could create a feature-login branch, work on it without affecting the live site, and merge the branch once the login system is fully functional

Question 8

Isolate Work

Answer 8

• keep your experimental changes in a separate branch and merge them into the main project only when they’re ready

Question 9

Collaborate on Different Features

Answer 9

• multiple developers can work on separate branches, avoiding conflicts and ensuring the main project stays stable

Question 10

Keep the Main Codebase Stable

Answer 10

• by working on feature branches, the main branch (often called main or master) remains free from bugs or unfinished features

Question 11

Create a Branch

Answer 11

• let’s say you’re working on a new feature; you can create a new branch with git checkout -b feature-login

Question 12

Work on your Branch

Answer 12

• make changes, commit them, and test your feature in this isolated branch

Question 13

Merge your Changes

Answer 13

• once you’re happy with your work, you can merge your feature branch back into the main branch using git merge feature-login

Question 14

Handling Merges & Conflicts

Answer 14

• merging is when you integrate changes from one branch into another-often from a feature branch back into the main branch
• while Git usually handles merging automatically, sometimes changes in different branches conflict with each other- this results in a merge conflict

Question 15

How to handle Merge Conflicts?

Answer 15

• Git will highlight the conflicting sections in your files
• you’ll need to manually review and decide which changes to keep
• after resolving the conflict, you can continue with the merge and commit the resolved code
• if two developers modify the same line of code in different ways, Git will flag this as a conflict, and you’ll need to decide which version to keep or how to combine the two changes

Question 16

Best Practices for Code Maintenance

Answer 16

• Commit Frequently- regular, small commits make it easier to track your progress and pinpoint bugs if they arise
• Write Meaningful Commit Messages- a clear commit message helps others (and future you understand what changes were made and why
• Use Branches for Features- keep your main branch clean by developing new features in their own branches
• Pull Changes Regularly- if you’re working in a team, frequently pull changes from the remote repository to ensure you’re always working with the latest version of the project
• Test Before Merging- always test your changes before merging them into the main branch to avoid introducing bugs