git --v
git --version
// Correctgit --option
git --current
git remote add new
git remote add origin
// Correctgit remote new origin
git remote origin
git reset --hard HEAD~5
(Reset the current branch to the commit just before the last 5)
git merge --squash HEAD@{1}
(HEAD@{1} is where the branch was just before the previous command.
# This command sets the state of the index to be as it would just
# after a merge from that commit)
- Reset the HEAD to the 5th commit in the repo, then merges to the master branch
- Reset the commit branch back before the last 5 commits, then squashes them into a single commit <<--Correct
- Delete the last 5 commits
- Merges the last 5 commits into a new branch
Q4. Your current project has several branches; master, beta, and push-notifications. You've just finished the notification feature in the push-notification branch, and you want to commit it to beta branch. How can you accomplish this?
- Checkout the push-notifications branch and run git merge beta
- Checkout the master branch and run git merge beta -> push-notification
- Delete the push-notification branch and it will be committed to the master branch automatically
- Checkout the beta branch and run git merge push-notification <<--- Correct
git add -A
- All new and updated files are staged
- Files are staged in alphabetical order.
- All new files are staged << -- Correct
- Only updated files are staged
git remote -v
- A list of remote repositories you are connected to <<<--- Correct
- The current git version you're running
- An inline editor for modifying remote repositories
- The last 5 git versions you've installed
git checkout feature-user-location
git cherry-pick {kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231}
- The commit is being tagged for release on the feature-user-location-branch.
- A commit is being copied from its original branch over to the feature-user-location-branch
- The commit is being cherry picked as the new HEAD of the commit history <<<--- Correct
- A commit is being copies from the feature-user-location branch to the master branch
git reset --soft HEAD^
- Delete all previous commits and reset the repository history back to its initial state.
- Resets the working branch to the first commit.
- Keeps the HEAD at the current commit, but clears all previous commits.
- Undoes the last commit in the working branch and sets the HEAD back one commit. <<<--- Correct
Q9. You find a bug in your project, but can't locate where it was introduced in the commit history. How would you diagnose this problem?
- Manually backtrack through your commit history.
- Use git search -diff to compare all commits in your repository history.
- Run a git rebase to find the buggy commit.
- Use git bisect to compare the buggy commit to an early commit that works as expected. <<<<---Correct
git rebase -i HEAD~10
- To run a comparative search of the last 10 commits for differences
- To list the last 10 commits and modify them with either the squash or fixup command <<<---Correct
- To delete the last 10 commits and reset the HEAD
- In order to locally cache the last 10 commits
- You wouldn't, you would use it in the local repository
- To invoke a hook script when commits are pushed but before any references are updated <<<---Correct
- To fire a script after updates are made to the remote repository
- To debug all commit tags and release versions
--all
--master
--global
// Correct--update
- Caching
- You can't. git merge --squash is the only git command for that operation
- Rebasing <<<<---Correct
- Reflogging
- A new copy would overwrite the central repository
- A copy of the repository would be created on your local machine <<<<---Correct
- Nothing, cloning is not a supported git function
- A copy of the repository would be created on the hosting platform
Q15. Suppose you needed to see a list of all files that had been modified or added to a specific commit over the course of a project. How would you accomplish this?
- Find the commit in the remote repository, as that's the only place that kind of information is stored.
- Use the diff-tree command with the commit hash. <<<<---Correct
- Run git commit --info with the commit hash.
- Access the commit stash data with git stash.
- All files with a .swift, .txt, or metadata file extension, as well as the entire build directory <<<---Correct
- Only the build directory
- All files in the build directory, as well as files ending with .txt or .metadata
- Only files with .swift and .txt extensions.
git commit -a -m "Refactor code base
- Nothing, you can't use multiple options in the same command
- Adds all new files to the staging area
- Commits all new files with a message
- Add all modified files to the staging area, then commits them with a message <<<---Correct
Q18. After checking your git status you get the following output, which shows the file beta-notes.js in the commit but also unstaged. How can this situation occur?
Change to be committed: (use "git reset HEAD <file>..." to unstage) modified: beta-notes.js Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout --<file>..." to discard changes in working directory) modified: beta-notes.js
- There were two copies of beta-notes.js but one was deleted.
- beta notes.js was staged, then modified afterwards, creating two different versions of the file <<<---Correct
- Two copies of beta-notes.js were created, but only one is being tracked
- There are two tracked copies of beta-notes.js, but one was removed from the commit.
- Saved files
- git documents
- Staging area <<< ---Correct
- git cache