INTRODUCTION – Collaboration
This module will further elaborate on the collaboration tools by Git. You are going to look into tools that assist in improving the quality of your code as well as better tracking for your code such as pull requests with a typical workflow of a pull request on GitHub. You will learn how to squash changes in your code also. Lastly, a study guide will be provided at the end on forks and pull requests.
Once that is done, we will proceed to consider code reviews including the code review workflow. You learn how to conduct code reviews on GitHub successfully. The last chapter for this module will deal with project management, the best practices for project management, and facilitating collaboration among these projects. This will also have to do with various methods of tracking issues, plus an ending discussion on what continuous integration really is for your projects.
Learning Objectives:
- Understanding and using the code review workflow
- Create, edit and manage pull requests on GitHub
- Explain what code reviews are for
- Use code reviews on GitHub
Build on the importance of project management and accept or reject changes - Use issue trackers effectively
- Explain the methodology behind continuous integration
PRACTICE QUIZ: PULL REQUESTS
1. What is the difference between using squash and fixup when rebasing?
- Squash deletes previous commits.
- Squash combines the commit messages into one. Fixup discards the new commit message. (CORRECT)
- Squash only works on Apple operating systems.
- Fixup combines the commit messages into one. Squash discards the commit message.
Awesome! In contrast to easy merge with a non-distracting commit message, the fixup operation affects the initial message while ignoring all others in the fixup commit. Squashing, on the other hand, puts all the commit messages together in one.
2. What is a pull request?
- The owner of the target repository requesting you to add your changes.
- A request sent to the owner and collaborators of the target repository to pull your recent changes. (CORRECT)
- A request to delete previous changes.
- A request for a specific feature in the next version.
Right on! You submit a pull request to the owner of the repository, asking them to merge your changes into their codebase.
3. Under what circumstances is a new fork created?
- When you want to experiment with changes without affecting the main repository. (CORRECT)
- When you clone a remote repository to your local machine.
- During a merge conflict.
- When there are too many branches.
Nice work! For instance, when you want to ask someone to implement changes in a project that is their own, or when you want to create something on behalf of that project but in your way.
4. What combination of command and flags will force Git to push the current snapshot to the repo as it is, possibly resulting in permanent data loss?
- git push -f (CORRECT)
- git log –graph –oneline –all
- git status
- git rebase -i
Awesome! The command git push -f replaces the old commits with the new ones forcibly and sends the current snapshot of the repository to remote as it is. This is dangerous because it can result in the loss of remote changes forever. It is highly not recommendable unless the person doing it is pushing fixes to his own fork, where no one else is using it, such as after an interactive rebase to squash many commits into a single one-as illustrated in the example.
5. When using interactive rebase, which option is the default, and takes the commits and rebases them against the branch we selected?
- squash
- edit
- reword
- pick (CORRECT)
Great job! The pick keyword in a rebase operation specifies the commits that are to be applied on top of the branch you selected, with the changes made in that commit.
PRACTICE QUIZ: CODE REVIEWS
1. When should we respond to comments from collaborators and reviewers?
- When their comments address software-breaking bugs
- No need, just resolve the concerns and be done with it
- Always (CORRECT)
- Only when a code correction is necessary
Excellent! It is a good behavior and also a proper way of conduct to respond, even it is just an acknowledgment.
2. What is a nit?
- A trivial comment or suggestion (CORRECT)
- A couple lines of code
- A repository that is no longer maintained
- An orphaned branch
Good work! A nit is typically a very small issue or complaint over some tiny detail about some code in git terms (and in tech in general) not affecting functionality but could relate to style, readability, or best practices.
3. Select common code issues that might be addressed in a code review. (Check all that apply)
- Using unclear names (CORRECT)
- Following PEP8 guidelines
- Forgetting to handle a specific condition (CORRECT)
- Forgetting to add tests (CORRECT)
Excellent! Unclear names can make our code hard to understand.
Alright! If there is a specific condition that could cause a problem and we don’t address it, the result could be catastrophic.
Woohoo! Tests are an important addition to our code to ensure it runs smoothly.
4. If we’ve pushed a new version since we’ve made a recent change, what might our comment be flagged as?
- Accepted
- Resolved
- Outdated (CORRECT)
- Merged
Nice job! If we publish a newer version after changing the text, Old comments are marked as Outdated, meaning that the content they referred to has gone under some modifications or been replaced.
5. What are the goals of code review? (Check all that apply)
- Make sure that the contents are easy to understand (CORRECT)
- Ensure consistent style (CORRECT)
- Build perfect code
- Ensure we don’t forget any important cases (CORRECT)
Reviewing the code will allow us to identify those places where clarity and readability could be improved.
Exactly-right! Comparing your code with the style guidelines is maintaining consistency within the code and also means that the code will be easy to follow.
Congratulations! Code review is also a good source for cases and conditions that need to find their way into our code for making it robust and error-free.
PRACTICE QUIZ: MANAGING COLLABORATION
1. How do we reference issues in our commits with automatic links?
- By using one of the keywords followed by a hashtag and the issue number.
- By using an asterisk (*) after the issue number.
- By typing the issue number inside braces ({}).
- By using a special keyword. (CORRECT)
Right on! You can tell Git to link to the issue with specified ID for example, preceded by keywords “closes” or “resolved,” followed by a hashtag and the number of the issue; for example, by using “closes #123” in a commit message, such a commit will close issue number 123 and create a link to it automatically.
2. What is an artifact in terms of continuous integration/continuous delivery (CI/CD) pipelines?
- An old and obsolete piece of code or library.
- Any file generated as part of the CI/CD pipeline. (CORRECT)
- An unintended minor glitch in a computer program
- An automated series of tests that run each time there is a new commit or pull request.
Awesome! Artifacts can be composed of logs, test results, compiled code, or any other files that got generated during pipeline execution. Such files are generally retained for reasons associated with tracking, debugging, or deployment.
3. Which of the following statements are good advice for project maintainers? (Check all that apply)
- Coordinate solely via email
- Reply promptly to pull-requests (CORRECT)
- Understand any changes you accept (CORRECT)
- Use an issue tracker (CORRECT)
Yay! The longer the pull request is left unattended, the more likely it is that new commits will conflict when trying to merge them.
Awesome! We don’t even know now if the original coder will be around to carry out maintenance on such functions. And of course, we need to also prevent feature creep to keep the codebase manageable.
Great! With the expansion of our project, an issues tracker will become even more valuable for effective collaboration. We’ll be able to organize and stay on top of tasks.
4. Which statement best represents what a Continuous Integration system will do?
- Run tests automatically (CORRECT)
- Update with incremental rollouts
- Assign issues and track who’s doing what
- Specify the steps that need to run to get the result you want
Nice job! A continuous integration system will build and test our code every time there’s a change.
5. Which statement best represents what a Continuous Delivery (CD) system will do?
- Run tests automatically
- Update with incremental rollouts (CORRECT)
- Assign issues and track who’s doing what
- Specify the steps that need to run to get the result you want
Right on! Continuous delivery means frequently making new code available on production servers, so that there are never huge releases with many differences between two versions. This has the advantage of smaller and more manageable updates, minimizing the risk that they will introduce bugs and making the code much easier to maintain and test.
PUSH LOCAL COMMITS TO GITHUB
1. Which command will you use to check the states of your Git repository?
- git check
- git status (CORRECT)
- git update
- git repo-status
Correct
2. What are the best practices for writing a commit message? Select all that apply.
- Include an appended line that tells GitHub which issue to close. (CORRECT)
- Number all of your commits to keep track of how many there are.
- Format all of your commits in a consistent way. (CORRECT)
- Describe what the commit does and why it was made. (CORRECT)
Correct
3. Which of the following can be achieved using GitHub’s Pull Request feature? Select all that apply.
- Request reviews from your peers (CORRECT)
- Clone a repository
- Undo changes you’ve made to your repository
- Merge changes from another branch (CORRECT)
- Propose changes to someone else’s code (CORRECT)
- Preview changes before merging them (CORRECT)
Correct
4. You have received feedback on a pull request you created and need to make changes. What is the correct method to update your pull request?
- Create a new pull request with the changes
- Push the changes to your branch and they will automatically update the pull request (CORRECT)
- Delete the pull request and start again
- Directly edit the files in the main branch
Correct
5. In GitHub, what is the primary purpose of the “Conversation” tab within a pull request?
- Code formatting
- Discussion and comments (CORRECT)
- Code review approval
- Real-time code execution
Correct
6. What happens when you fork a repository?
- The original repository is moved to your GitHub account.
- A new branch is created in the original repository.
- A duplicate of the original repository is created in your GitHub account. (CORRECT)
- The original repository is deleted.
Correct
7. Consider you have made some changes to your local copy of a Git repository. What happens to the remote repository?
- The remote repository remains unchanged until you push your changes (CORRECT)
- The remote repository is automatically updated
- The remote repository duplicates your local changes without you pushing
- The remote repository is deleted
Correct
8. What does git status do in the context of a merge conflict?
- It shows the files with merge conflicts. (CORRECT)
- It discards the merge and reverts to the previous commit.
- It merges the changes without resolving the conflicts.
- It automatically resolves merge conflicts.
Correct
9. What is the purpose of the “Merge” button in a Git pull request on platforms like GitHub or GitLab?
- To finalize the pull request, merge the changes into the target branch, and close the pull request. (CORRECT)
- To edit the pull request description and update the proposed changes.
- To delete the pull request and discard all proposed changes.
- To revert the changes made in the pull request and restore the target branch to its previous state.
Correct
10. What should you look for in a code review on GitHub?
- The clarity and readability of the code
- The presence of any bugs or errors
- The use of best coding practices and standards (CORRECT)
- All of the above
Correct
11. What does it mean when a GitHub pull request has a green ‘Merged’ badge?
- The pull request has been declined
- The pull request has been merged into the base branch (CORRECT)
- The pull request has no conflicts with the base branch
- The pull request has been approved but not yet merged
Correct
12. When forking a repository, what does the phrase “upstream repository” mean?
- The local copy of the fork on your computer
- A repository located higher in the GitHub directory structure
- The original repository from which the fork was created (CORRECT)
- The forked repository itself
Correct
13. Why is it important to push your local changes to the main project? Select all that apply.
- It helps you avoid tracking divergent lines of development. (CORRECT)
- It allows you to coordinate work with teammates. (CORRECT)
- It is a requirement of the GitHub workflow.It ensures everyone is pulling from the same source material. (CORRECT)
Correct
14. What is the main benefit of using pull requests in Git?
- To propose changes, facilitate code review, and ensure quality before merging them into the target branch. (CORRECT)
- To create a backup of the repository before making changes.
- To automatically merge changes from one branch to another.
- To revert changes made in a branch back to a previous commit.
Correct
15. Which of the following actions should be taken during a code review? Select all that apply.
- Accept all changes
- Offer suggestions for improvements (CORRECT)
- Provide constructive feedback (CORRECT)
- Skim the code for major mistakes
Correct
16. What is the primary purpose of a pull request in Git?
- To revert the changes made in a specific branch.
- To merge changes from the local branch to the remote repository without review.
- To create a new branch in the remote repository.
- To propose changes and initiate a discussion before merging them into a branch. (CORRECT)
Correct
17. Why is git status the first command in the process to commit your changes?
- It shows the states of your previously committed files.
- It shows the states of your collaborators’ commits.
- It shows the states of the files in the main branch of your project.
- It shows the states of the files in your working directory and staging area. (CORRECT)
Correct
18. Why is it important to include a descriptive message with each commit to a Version Control System?
- To allow the system to automatically sort commits
- To make the commit process faster
- To help other developers understand the changes (CORRECT)
- To reduce the size of the commit
Correct
19. Why is it important to execute pull requests instead of directly pushing changes to the main branch?
- To keep a clean history of code changes.
- To review the code changes before they are merged. (CORRECT)
- To track the time spent on coding.
- To avoid conflicts with other developers’ changes.
Correct
20. Which of the following is NOT a benefit of using pull requests in GitHub?
- They provide a history of changes made to the project
- They allow for code review before changes are merged
- They facilitate collaboration between multiple contributors
- They automatically resolve merge conflicts (CORRECT)
Correct
21. What does a code review in GitHub involve?
- Critiquing the coding style of another developer
- Evaluating the quality of the code and suggesting improvements (CORRECT)
- Checking the code for any potential security vulnerabilities
- Reviewing the comments written in the code
Correct
22. Why is it important to review code before merging it into the master branch?
- To make the author feel bad about their code
- To make sure the code is perfect
- To find and fix potential bugs and ensure the code aligns with the project’s standards (CORRECT)
- Because it’s a requirement
Correct
23. When writing a commit message, which of the following is considered a best practice?
- Use casual language
- Include a lengthy breakdown of the reasons for every change
- Include a detailed description of the changes (CORRECT)
- Keep it short to save time
Correct
24. When reviewing a pull request, what is important to look for?
- The readability of the code. (CORRECT)
- The color scheme of the code.
- The size of the code changes.
- The complexity of the code changes.
Correct
25. You’re reviewing a colleague’s code on GitHub and you find a significant issue. What is the best way to provide feedback?
- Directly commit a fix to the code without discussing
- Ignore the issue since it’s not your code
- Email the colleague privately about the issue
- Leave a comment on the code with a respectful, constructive suggestion (CORRECT)
Correct
CONCLUSION – Collaboration
This learning module is an engrossing one on the collaboration tools introduced in Git and their efficiency in terms of code quality and tracking. One of the most essential aspects of the study prepared in it is pull requests, which are indicative of the existing GitHub workflow systems as linked to this collaboration feature. Besides that, the module has made it very helpful regarding merging change in the code, such as providing a short guide on forks and pull requests to you.
The subsequent sections discussed and elaborated on code reviews, focusing on the concept and indicating the workflow for successful implementation of them. Important guidance on applying code reviews in GitHub has been shared, creating the collaborative experience in coding richer. The last lesson in the module was mainly on project management. It revisited the best practices and approaches for the effective collaboration of the projects. Different methods of issue tracking were also discussed in it; the module was finally completed with learning about continuous integration and how to apply it to your projects. Having gone through this module, you are quite ready with diverse skills to thrive in a collaborative coding environment.