Task 1.1: Version control fundamentals

• AOnly edit files offline, because each commit has to be registered on GitHub when it is made

  Incorrect

  Commits are recorded in the local repository; only pushing needs the remote.

• BRead the history only after reconnecting, because the history lives on GitHub's servers

  Incorrect

  Every clone has the full history, so she can read it offline.

• CCommit locally, since her clone holds the full history, and push once she is back online

  Correct

  Git is a distributed version control system: each clone is a full copy of the project and its history, so committing needs no connection.

• DWork offline only if the repository was cloned with GitHub Desktop, which keeps an offline copy of the history

  Incorrect

  Any clone is a complete repository, whatever tool made it.

In a distributed version control system such as Git, every developer has a full copy of the project and its history. Unlike centralized systems, a DVCS doesn't need a constant connection to a central repository: you commit locally and push to the remote when you choose.

• AThey keep using Git; GitHub hosts the repositories and adds issues, pull requests and code review

  Correct

  GitHub is built on Git: it hosts Git repositories in the cloud and adds planning and collaboration tools.

• BGitHub replaces Git with its own version control format, so every repository has to be converted before the move

  Incorrect

  GitHub hosts ordinary Git repositories; nothing is converted to another format.

• CDevelopers stop using Git commands, because GitHub keeps history only through its web interface

  Incorrect

  Git commands keep working against GitHub, which hosts the same Git repositories.

• DGitHub keeps only the latest version of each file, so the history stays on the old file server

  Incorrect

  A Git repository carries its full history, and GitHub hosts all of it.

Git is the version control system that tracks changes to files. GitHub is a platform based on Git: it hosts Git repositories in the cloud and adds tools for planning and collaboration, such as issues, pull requests and code review.

• Agit clone

  Incorrect

  Clone makes a new copy of the whole repository; it doesn't update his existing one.

• Bgit pull

  Incorrect

  Pull fetches and then merges into the current branch, which he wants to avoid for now.

• Cgit fetch

  Correct

  Fetching downloads the new remote-tracking branches and tags without merging them into his branches.

• Dgit push

  Incorrect

  Push sends his local commits to the remote; it doesn't bring the teammate's commits down.

git fetch retrieves new work from a remote, the new remote-tracking branches and tags, without merging those changes into your own branches. You can inspect them and merge later. git pull combines fetching with a merge into your current branch.

• APush again with the force option, so that the local branch replaces the remote branch and the push succeeds

  Incorrect

  Replacing the remote branch would drop the other developer's commits, which must be kept.

• BDelete the branch on GitHub and push the local branch under the same name

  Incorrect

  Deleting the remote branch also throws away the other developer's commits.

• CClone the repository again and copy the edited files into the new clone before committing

  Incorrect

  That loses the local commit history and is far more work than merging the remote changes.

• DPull the remote changes into the local branch, resolve any conflicts, and push again

  Correct

  Fetching and merging the remote work first lets the push go through without losing anyone's commits.

A non-fast-forward error means the local branch is behind the remote branch, so Git refuses the push to avoid losing history. Fetch and merge the remote changes, or run git pull to do both, then push again.

• AIn a .gitignore file committed at the repository root

  Incorrect

  A committed .gitignore is shared with everyone who clones the repository.

• BIn ~/.config/git/ignore on her computer

  Incorrect

  The global ignore file applies to every repository on her computer, not to this one only.

• CIn a .gitignore file inside the editor's settings folder of her home directory

  Incorrect

  Git doesn't read ignore rules from an editor's settings folder outside the repository.

• DIn the repository's .git/info/exclude file

  Correct

  Rules in .git/info/exclude are never checked in and apply only to her local copy of this repository.

A .gitignore file committed to the repository shares its rules with everyone who clones it. For rules you don't want to share, such as files created by your own editor, use .git/info/exclude in the repository: those rules are not checked in and only ignore files for your local repository. The file ~/.config/git/ignore holds rules for all repositories on your computer.

• AIt is the branch Git checks out locally when someone clones the repository

  Correct

  The default branch is the initial branch checked out after a clone.

• BIts name is fixed when the repository is created and can't be changed later

  Incorrect

  The default branch of an existing repository can be changed.

• CIt is the base branch for new pull requests unless a different branch is chosen

  Correct

  Unless you specify another branch, the default branch is the base for new pull requests and commits.

• DIt is the only branch in a repository that can be protected

  Incorrect

  Branch protections can apply to other important branches too.

• EIt must be named master so that Git tools and GitHub features recognize it as the default

  Incorrect

  GitHub names the default branch main in new repositories, and it can be renamed.

When you create a repository with content, GitHub creates it with a single branch, the default branch, named main by default. It is the branch shown to visitors, the branch checked out on clone, and the base for new pull requests unless you choose another. You can change the default branch of an existing repository.

• ARun git commit first, then stage the two finished files afterwards

  Incorrect

  Only changes staged before the commit become part of it.

• BRun git push with the names of the two finished files

  Incorrect

  Push sends commits to the remote; it doesn't choose which files go into a commit.

• CStage the two finished files with git add, then run git commit

  Correct

  Only staged changes go into the commit, so the third file stays out.

• DCreate a branch with git branch so that the unfinished file is left out of the commit

  Incorrect

  A new branch doesn't decide which changes are committed; staging does.

Git records changes in two steps: git add stages a change, and git commit takes only what has been staged. Staging and committing separately lets you choose exactly which changes go into each commit.

• AA copy of a repository under another account

  Incorrect

  That describes a fork.

• BA request to merge the changes from one branch into another branch

  Incorrect

  That describes a pull request.

• CA name that marks one point in the history, such as v1.0

  Incorrect

  That describes a tag.

• DA snapshot of staged changes saved to the history, with a message

  Correct

  A commit saves the staged snapshot, and each commit carries a message.

git commit saves the staged snapshot to the project history and completes the change-tracking process. When you make a commit, you include a message that briefly describes the changes.

• ATo make a backup copy of the repository under their own account

  Incorrect

  That describes a fork.

• BTo give other people permission to change the repository

  Incorrect

  Branches don't grant access.

• CTo keep the work separate from the main line of development

  Correct

  Branches give a contained area for developing a feature.

• DTo publish a new release of the project

  Incorrect

  A branch is a place to work on changes; it doesn't publish anything.

Branches let you develop features, fix bugs or experiment with new ideas in a contained area of your repository. You create a branch from an existing branch, usually the default branch, and work on it in isolation from other people's changes.

• AThe branch the changes would be merged into

  Correct

  A pull request compares the head branch's changes with the base branch.

• BThe branch that contains the proposed changes

  Incorrect

  That is the head branch.

• CThe first branch ever created in any repository on GitHub

  Incorrect

  The base branch is chosen per pull request.

• DA branch that only administrators can see

  Incorrect

  Base branches are ordinary branches.

A pull request compares the proposed changes on the head branch with the base branch. When you create the pull request, you can change the base branch you are comparing your changes against.

• Agit clone

  Incorrect

  Clone copies a remote repository.

• Bgit merge

  Correct

  Merging combines lines of development, such as a feature branch into main.

• Cgit branch

  Incorrect

  git branch shows the local branches; it doesn't combine them.

• Dgit add

  Incorrect

  git add doesn't combine branches.

git merge merges lines of development together. It is typically used to combine changes made on two distinct branches, for example to bring a feature branch into the main branch for deployment.