COURSE 3 – INTRODUCTION TO GIT AND GITHUB

Module 4: Collaboration

GOOGLE IT AUTOMATION WITH PYTHON PROFESSIONAL CERTIFICATE

Complete Coursera Study Guide

Enroll in Coursera Google IT Automation with Python Here

Last updated:

TABLE OF CONTENT

INTRODUCTION – Collaboration

In this module, you’ll continue to explore the collaboration tools available in Git. You’ll learn about the tools that are available to help improve the quality of your code and to better track your code. This includes an overview of pull requests and how the typical workflow of a pull request looks like on GitHub. Next, you’ll dive into how you can squash changes in your code. We’ll finish up by providing you with a study guide on fork and pull requests.

Next up, we’ll cover what code reviews are and what the code review workflow looks like. Then, you’ll learn about how to use code reviews on GitHub. The final lesson of this module will focus on managing projects. We’ll take a rundown of best practices on managing projects and how to manage collaboration within those projects. We’ll explore different ways of tracking issues and finish up by discussing the concept of continuous integration with your projects.

Learning Objectives

  • Utilize the code review workflow
  • Create, update, and execute pull requests on GitHub
  • Explain what a code review is
  • Use code reviews in GitHub
  • Explain the importance of managing projects and accepting or rejecting changes
  • Utilize issue trackers
  • Describe 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! The fixup operation will keep the original message and discard the message from the fixup commit, while squash combines them.

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 send a pull request to the owner of the repository in order for them to incorporate it into their tree.

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 propose changes to someone else’s project, or base your own project off of theirs.

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! git push with the -f flag forcibly replaces the old commits with the new one and forces Git to push the current snapshot to the repo as it is. This can be dangerous as it can lead to remote changes being permanently lost and is not recommended unless you’re pushing fixes to your own fork (nobody else is using it) such as in the case after doing interactive rebasing to squash multiple commits into one as demonstrated.

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 takes the commits and rebases them against the branch we have chosen.

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 good manners and proper conduct to respond, even when it’s simply an acknowledgement.

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! In git jargon (and elsewhere in the tech world), a nit is a minor “nitpick” about a piece of code.

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 push a new version after making a change, old comments are marked with the “Outdated” flag.

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)

Right on! By reviewing our code, we can identify where we can make our code more clear and easy to understand.

Awesome! By comparing our code to style guidelines, we can keep our style consistent and readable.

Good job. Code review can reveal cases or conditions we need to handle in our code.

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! Keywords such as closes or resolves followed by a hashtag and the issue number will tell Git to autolink to the issue with the provided ID number.

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 include compiled code, test results, logs, or any type of file generated as part of the pipeline.

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)

Woohoo!  The more time that passes until a pull-request gets reviewed, the more likely it is that there’s a new commit that causes a conflict when you try to merge in the change.

Nice job! Not only do we not know whether the original coder is going to be around to maintain those functions, we also want to avoid feature creep and unmanageable code.

Excellent! The larger our project grows, the more useful an issue tracker can be for collaborating.

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 new code is often deployed with the goal of avoiding rollouts with lots of changes between two versions.

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

In conclusion, this module has offered an in-depth exploration of collaboration tools within Git, focusing on optimizing code quality and enhancing the efficiency of code tracking. The thorough examination of pull requests has provided valuable insights into the typical GitHub workflow associated with this collaborative feature. Additionally, the module has guided you through the process of consolidating changes in your code, with a study guide on fork and pull requests serving as a helpful resource.

The subsequent section delved into the crucial aspect of code reviews, elucidating the concept and detailing the workflow involved in a productive code review. Practical insights on leveraging code reviews on GitHub have been shared, contributing to a more enriched collaborative coding experience. The final lesson of the module centered on project management, offering a comprehensive review of best practices and effective strategies for collaboration within projects. The exploration of various approaches to issue tracking was insightful, culminating in a discussion on the concept of continuous integration and its practical application in your projects. Overall, this module equips you with a comprehensive skill set to navigate collaborative coding environments successfully.

Previous Week
Next Course

Subscribe to our site

Get new content delivered directly to your inbox.

Quiztudy Top Courses

Popular in Coursera

Liking our content? Then, don’t forget to ad us to your BOOKMARKS so you can find us easily!

Subscribe