LEFT.Io Git Best Practices Quiz
-
What should you do before sharing your commit with colleagues? (choose at least 3 options)
-
Add files from the working copy to the staging area
-
Commit changed files to the local repository
-
Push changes to a shared remote repository
-
Push changes to the master branch
-
Push changes to development branch
-
About This Quiz
Before taking this quiz make sure that you have read and understood this document:
https://nvie. Com/posts/a-successful-git-branching-model/
Quiz Preview
- 2.
Is it beneficial to have long running branches other than Master and Development?
-
True
-
False
Correct Answer
A. FalseExplanation
People have a hard time figuring out which branch they should develop on or deploy to production.Rate this question:
-
- 3.
The developers must use the development branch and not master. Master branch is reserved for code that is released to production.
-
True
-
False
Correct Answer
A. TrueExplanation
The explanation for the given correct answer is that the master branch is typically used for stable and production-ready code that is ready to be released to users. On the other hand, the development branch is used for ongoing development and testing of new features or bug fixes. By using the development branch instead of the master branch, developers can ensure that any changes they make do not interfere with the stable code in the master branch and avoid any potential issues when releasing the code to production.Rate this question:
-
- 4.
What should you do if you want to receive a feedback on your work, but not ready yet to merge the changes with the main branch?
-
Create a Jira ticket requesting a review session.
-
Create a merge request without assigning it to anyone. Mention the people who might help you in the comment. (/cc @ingvar)
-
If you are not ready to merge the changes, you should not ask for review.
Correct Answer
A. Create a merge request without assigning it to anyone. Mention the people who might help you in the comment. (/cc @ingvar)Explanation
Your team members can comment on the merge request in general or on specific lines with line comments. The merge requests serves as a code review tool and no separate tools such as Gerrit and reviewboard should be needed. If the review reveals shortcomings anyone can commit and push a fix. Commonly the person to do this is the creator of the merge/pull request. The diff in the merge/pull requests automatically updates when new commits are pushed on the branch.Rate this question:
-
- 5.
If you see problem in somebody else's code, is it OK to commit and push a fix without asking the author?
-
Yes
-
No
Correct Answer
A. YesExplanation
It is not okay to commit and push a fix without asking the author if you see a problem in somebody else's code. It is important to communicate and collaborate with the author to understand their intentions and discuss potential solutions. Making changes without permission can lead to misunderstandings, conflicts, and potentially introduce new issues. It is respectful to involve the author in the decision-making process and work together to find the best solution.Rate this question:
-
- 6.
What would be the first step to start any significant change to the code?
-
Create a feature branch.
-
Create an issue in Jira where the goal of the change is described.
-
Make the change in the local repository first.
Correct Answer
A. Create an issue in Jira where the goal of the change is described.Explanation
Having a reason for every code change is important to inform everyone on the team and to help people keep the scope of a feature branch small. If there is no issue yet it should be created first provided there is significant work involved (more than 1 hour).Rate this question:
-
- 7.
What's the minimal amout of work for which you should create a feature branch?
-
1 day
-
1 hour
-
1 month
-
1 week
Correct Answer
A. 1 hourExplanation
Creating a feature branch allows for isolating the development of a specific feature without affecting the main codebase. The minimal amount of work for which a feature branch should be created is 1 hour. This ensures that even small changes or additions to the code can be done in a separate branch, providing a clean and organized workflow. It also allows for easier collaboration and code review, as changes can be reviewed and merged back to the main branch once completed.Rate this question:
-
- 8.
The name of the feature branch should start with the Jira issue number.
-
True
-
False
Correct Answer
A. TrueExplanation
The explanation for the given correct answer is that using the Jira issue number as the starting point for the feature branch name helps in organizing and tracking the development process. It provides a clear connection between the feature being developed and the corresponding Jira issue, making it easier to identify and manage the progress of the work. Additionally, it ensures that each feature branch is unique and easily identifiable, reducing the chances of conflicts or confusion when working with multiple branches simultaneously.Rate this question:
-
- 9.
When the author thinks the code is ready the merge request is assigned to reviewer.
-
False
-
True
Correct Answer
A. TrueExplanation
The reviewer presses the merge button when they think the code is ready for inclusion in the main branch.Rate this question:
-
- 10.
Why the feature branch should be deleted after merging with the main branch?
-
Because it is no longer needed
-
It's a trick question and feature branches should not be deleted after every merge.
Correct Answer
A. Because it is no longer neededExplanation
The feature branch should be deleted after merging with the main branch because it is no longer needed. Once the changes from the feature branch have been successfully merged into the main branch, keeping the feature branch would only clutter the repository and make it harder to manage. Deleting the feature branch helps maintain a clean and organized repository, ensuring that only relevant and active branches are present. Additionally, deleting the feature branch helps avoid confusion and prevents potential conflicts or issues that may arise from having multiple branches with similar changes.Rate this question:
-
- 11.
After merging the feature branch the problem still occurs. Is it ok to re-open feature branch with the same name?
-
Yes
-
No
Correct Answer
A. YesExplanation
Yes, it is okay to re-open the feature branch with the same name after merging if the problem still occurs. This allows for further modifications and fixes to be made on the branch without affecting the main branch. It also helps to maintain a clear and organized version control history.Rate this question:
-
- 12.
Is it possible that one feature branch solves more than one issue.
-
Yes
-
No
Correct Answer
A. YesExplanation
Yes, it is possible for one feature branch to solve more than one issue. A feature branch is a separate branch created from the main branch to work on a specific feature or task. It allows developers to isolate their changes and work on multiple issues simultaneously. By merging these changes back into the main branch, multiple issues can be resolved at once. This approach promotes efficiency and flexibility in software development.Rate this question:
-
- 13.
Developers are encouraged to commit often and to frequently push to the remote repository so other developers are aware what everyone is working on.
-
False
-
True
Correct Answer
A. TrueExplanation
Developers are encouraged to commit often and push frequently to the remote repository to ensure that other developers are aware of the work being done. This practice helps in maintaining transparency and collaboration within the development team. By committing and pushing regularly, developers can keep the codebase up to date and avoid conflicts or duplications in their work. It also allows for easier tracking and reviewing of changes made by different team members.Rate this question:
-
- 14.
What should you do if you reverted a merge and changed your mind?
-
Merge again.
-
Revert the revert.
Correct Answer
A. Revert the revert.Explanation
If you revert a merge and you change your mind, revert the revert instead of merging again since git will not allow you to merge the code again otherwise.Rate this question:
-
- 15.
What message is the good one?
-
Git commit -m "bug fix"
-
Git commit -m "fix the issue with location id in rental_properties core"
Correct Answer
A. Git commit -m "fix the issue with location id in rental_properties core"Explanation
The correct answer is "git commit -m 'fix the issue with location id in rental_properties core'". This message provides a clear and specific description of the commit, stating that it fixes a specific issue related to the location id in the rental_properties core. This level of detail helps in understanding the purpose and context of the commit, making it easier for other developers to track changes and troubleshoot any related problems.Rate this question:
-
- 16.
When should you commit your changes?
-
In the end of the working day.
-
Each time you have a functioning set of tests and code.
-
On or before the due date.
-
When all the changes are made before the testing.
Correct Answer
A. Each time you have a functioning set of tests and code.Explanation
Committing changes each time you have a functioning set of tests and code is the correct answer because it ensures that the code is stable and working properly before being added to the main codebase. This approach allows for better collaboration and integration with other developers' work, as well as easier identification and resolution of any issues that may arise. It also helps in maintaining a clean and organized version control history, making it easier to track changes and revert if necessary.Rate this question:
-
- 17.
What's the advantage of frequent commits?
-
It's easy to revert to a working version if an extension of refactor goes wrong.
-
Everyone can see your mistakes.
-
Helps to increase the number of lines that you have written.
Correct Answer
A. It's easy to revert to a working version if an extension of refactor goes wrong.Explanation
Frequent commits provide the advantage of being able to easily revert to a previous working version if a refactor or extension goes wrong. By committing changes frequently, each commit represents a snapshot of the code at a specific point in time, making it easier to track and undo any problematic changes. This helps in maintaining a stable and functional codebase, as any mistakes or errors can be quickly identified and rectified by referring to previous commits.Rate this question:
-
- 18.
What should you write in the commit message?
-
Contents of your commit.
-
Your intention.
Correct Answer
A. Your intention.Explanation
The commit message should reflect your intention, not the contents of the commit. The contents of the commit can be easily seen anyway, the question is why you did it. An example of a good commit message is: "Combine templates to dry up the user views.". Some words that are bad commit messages because they don't contain munch information are: change, improve and refactor. The word fix or fixes is also a red flag, unless it comes after the commit sentence and references an issue number.Rate this question:
-
- 19.
When initiating a feature branch, you should always start with an up to date master to branch off from.
-
False
-
True
Correct Answer
A. TrueExplanation
When initiating a feature branch, it is important to start with an up to date master branch. This ensures that any changes made to the master branch are included in the feature branch, avoiding conflicts and keeping the codebase consistent. Starting from an outdated master branch may lead to merging difficulties and inconsistencies in the code. Therefore, it is recommended to always begin a feature branch from an up to date master branch.Rate this question:
-
- 20.
What is the purpose of supporting branches? (Choose as many as you like)
-
To aid parallel development between team members
-
To ease tracking of features
-
To prepare for production releases
-
To assist in quickly fixing live production problems
Correct Answer(s)
A. To aid parallel development between team members
A. To ease tracking of features
A. To prepare for production releases
A. To assist in quickly fixing live production problemsExplanation
Supporting branches serve multiple purposes in software development. They aid parallel development between team members by allowing multiple individuals to work on different features or bug fixes simultaneously without interfering with each other's code. They also ease tracking of features, as each branch can be dedicated to a specific feature or enhancement, making it easier to monitor progress and manage changes. Additionally, supporting branches help prepare for production releases by allowing for testing and quality assurance before merging into the main codebase. Finally, they assist in quickly fixing live production problems by providing a separate branch to address urgent issues without disrupting the ongoing development work.Rate this question:
-
- 21.
Select the types of supporting branches
-
Feature branches
-
Test branches
-
Deployment branches
-
Release branches
-
Hotfix branches
Correct Answer(s)
A. Feature branches
A. Release branches
A. Hotfix branchesExplanation
The correct answer is Feature branches, Release branches, and Hotfix branches. These types of branches are commonly used in software development workflows. Feature branches are created to work on new features or enhancements, allowing developers to work independently without affecting the main codebase. Release branches are used to prepare a stable version of the software for deployment. Hotfix branches are created to quickly fix critical issues in the production environment. Test branches and Deployment branches are not mentioned as options and therefore are not considered as types of supporting branches in this context.Rate this question:
-
- 22.
Feature branches may branch off from what branch:
-
Development
-
Master
Correct Answer
A. DevelopmentExplanation
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).Rate this question:
-
- 23.
Feature branches must merge back into:
-
Development branch
-
Master branch
Correct Answer
A. Development branchExplanation
The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).Rate this question:
-
- 24.
When merging feature branch with development branch what should you do to avoid losing information about the historical existence of a feature branch?
-
Keep the feature branch in the git tree.
-
Create a new commit object using --no-ff flag.
Correct Answer
A. Create a new commit object using --no-ff flag.Explanation
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.Rate this question:
-
- 25.
Release branches may branch off from:
-
Development branch
-
Master branch
Correct Answer
A. Development branchExplanation
Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the development branch is cleared to receive features for the next big release.Rate this question:
-
- 26.
Release branches must merge back into:
-
Development branch
-
Master branch
-
Master and Development branch
-
Release branches should not be merged back
Correct Answer
A. Master and Development branchExplanation
Release branches must merge back into both the Master and Development branches. This is because the Master branch represents the stable and production-ready version of the software, while the Development branch is where new features and bug fixes are implemented. By merging the release branch into both branches, any changes made during the release process can be incorporated into both the stable and ongoing development versions of the software. This ensures that any bug fixes or improvements made during the release are included in future development iterations.Rate this question:
-
- 27.
Hotfix branches may branch off from:
-
Development branch
-
Master branch
-
Either development or master branches
Correct Answer
A. Master branchExplanation
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.Rate this question:
-
- 28.
Hotfix branches must merge back into:
-
Development branch
-
Master branch
-
Master and Development branch
-
Hotfix branches should not be merged back
Correct Answer
A. Master and Development branchExplanation
Hotfix branches must merge back into both the Master and Development branches. This is because hotfixes are typically urgent bug fixes that need to be deployed quickly. By merging the hotfix branch into both the Master and Development branches, any fixes made can be immediately deployed to production (Master branch) while also being incorporated into ongoing development work (Development branch). This ensures that the hotfixes are implemented in both the current production version and the future release.Rate this question:
-
- 29.
When a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of development and master.
-
True
-
False
Correct Answer
A. TrueExplanation
Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into development too, when the release branch is finished. (If work in development immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)Rate this question:
-
- 30.
What's the git command that downloads your repository from GitHub to your computer?
-
Git push
-
Git fork
-
Git clone
-
Git commit
Correct Answer
A. Git cloneExplanation
The correct answer is "git clone." This command is used to download a copy of a repository from GitHub to your computer. It creates a local copy of the repository, including all of its files, commit history, and branches. This allows you to work on the project locally and make changes before pushing them back to the remote repository.Rate this question:
-
- 31.
What's the opposite of 'git clone', the command that uploads your changes and code back to Git?
-
Git push
-
Git add
-
Git upload
-
Git status
Correct Answer
A. Git pushExplanation
The opposite of "git clone" is "git push" because "git clone" is used to download a copy of a repository from Git, while "git push" is used to upload and push your changes and code back to Git.Rate this question:
-
Quiz Review Timeline (Updated): Mar 22, 2023 +
Our quizzes are rigorously reviewed, monitored and continuously updated by our expert board to maintain accuracy, relevance, and timeliness.
-
Current Version
-
Mar 22, 2023Quiz Edited by
ProProfs Editorial Team -
Mar 09, 2016Quiz Created by
Staysvrs
Back to top