Version control Flashcards
You have been editing the code on a branch you have created on the Git repository for the function getParcelPosition(). In the meantime, somebody else has been editing the same piece of code. Specifying the Git commands used, describe the process of merging your branch back into the master branch.
Ensure your local master branch is up to date:
git checkout master
git pull origin master
Switch to your feature branch:
git checkout
Merge the changes from the master branch into your feature branch:
git merge master
Resolve any merge conflicts and stage the resolved files:
git add
Commit the merge
git commit -m “Merge changes from master branch”
Switch to master branch
git checkout master
Merge feature branch into master
git merge
git add
This command adds file changes in the working directory to the staging area.
git commit
This command records the changes made to the files in the staging area and saves them as a new commit in the Git history.
git push
This command uploads local repository commits to a remote repository, allowing you to share your changes with others or synchronise your work across multiple devices.
Distributed Version Control
Enables offline work: Users can continue making changes and commits even when disconnected from the internet or the central server.
Branching and Merging
Enables parallel development: Multiple developers can work on different features simultaneously without interfering with each other’s work.
Explain the process of submitting your code to the original developer on GitHub to improve the repository, and why you would do this.
Fork the repository.
Make improvements.
Submit a pull request to the project owner.
Your improvements may add new features or fix existing bugs, improving the overall usability and reliability of the software.
By contributing your changes back to the original repository, you facilitate collaboration among developers and foster a sense of community around the project.
Commit History and Versioning
Provides a detailed history: Developers can review the evolution of the codebase, including who made changes, when they were made, and the nature of the changes.