1.
git --v
2.
git --version
3.
git --option
4.
git --current
Q 1 / 102
The command is git remote add. The new added connection can be named origin or new. The only constraints, although it is not documented AFAIK, is that the connection name needs to be acceptable to git-check-ref-format, and it cannot be repeated. If the LinkedIn assessment asks this and you can choose just one option, then leave feedback.1.
git remote add new
2.
git remote add origin
3.
git remote new origin
4.
git remote origin
Q 2 / 102
bash git reset --hard HEAD~5 git merge --squash HEAD@{1} **Explanation:**1.
Reset the HEAD to the 5th commit in the repo, then merges to the master branch
2.
Reset the commit branch back before the last 5 commits, then squashes them into a single commit
3.
Delete the last 5 commits
4.
Merges the last 5 commits into a new branch
5.
undefined
6.
undefined
Q 3 / 102
1.
Checkout the push-notifications branch and run git merge beta
2.
Checkout the master branch and run git merge beta -> push-notification
3.
Delete the push-notification branch and it will be committed to the master branch automatically
4.
Checkout the beta branch and run git merge push-notification
Q 4 / 102
`git add -A`1.
All new and updated files are staged
2.
Files are staged in alphabetical order.
3.
All new files are staged
4.
Only updated files are staged
Q 5 / 102
`git remote -v`1.
A list of remote repositories and their URLs
2.
The current git version you're running
3.
An inline editor for modifying remote repositories
4.
The last 5 git versions you've installed
Q 6 / 102
bash git checkout feature-user-location git cherry-pick kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231 **Explanation:** Commits aren't copied when cherry picking, they are cherry picked. The changes introduced by the commit are applied and a new commit is then created. This allow us to get specific changes as if they were patches (in the GIT's book, this is actually called [Patching](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Patching "See this in the GIT's book")). As a new commit is created upon feature-user-location, HEAD also changes to match it. You can see this in `cat .git/HEAD` and `cat .git/refs/heads/feature-user-location` for this case. See `man git-cherry-pick` for details. **NOTE**: There are two versions of this question so far. The task is always "describe what is happening", the commands are always a `checkout` and a `cherry-pick`, and the correct answer is always the same.1.
The commit is being tagged for release on the feature-user-location branch
2.
A commit is being copied from its original branch over to the feature-user-location branch
3.
The commit is being cherry picked as the new HEAD of the commit history
4.
A commit is being copied from the feature-user-location branch to the master branch
5.
The branch is switched to the feature-user-location branch, and the specified commit is applied to the branch.
Q 7 / 102
`git reset --soft HEAD^`1.
It deletes all previous commits and reset the repository history back to its initial state.
2.
It resets the working branch to the first commit.
3.
It keeps the HEAD at the current commit, but clears all previous commits.
4.
It sets HEAD to the previous commit and leaves changes from the undone commit in the stage/index.
Q 8 / 102
1.
Manually backtrack through your commit history.
2.
Use git search -diff to compare all commits in your repository history.
3.
Run a git rebase to find the buggy commit.
4.
Use git bisect to compare the buggy commit to an early commit that works as expected.
Q 9 / 102
`git rebase -i HEAD~10`1.
To run a comparative search of the last 10 commits for differences
2.
To list the last 10 commits and modify them with either the squash or fixup command
3.
To delete the last 10 commits and reset the HEAD
4.
In order to locally cache the last 10 commits
Q 10 / 102
1.
You wouldn't, you would use it in the local repository
2.
To execute a script when a remote receives a push that is triggered before any refs are updated
3.
To fire a script after updates are made to the remote repository
4.
To debug all commit tags and release versions
Q 11 / 102
1.
`--all`
2.
`--master`
3.
`--global`
4.
`--update`
Q 12 / 102
1.
Caching
2.
You can't. git merge --squash is the only git command for that operation.
3.
Rebasing
4.
Reflogging
Q 13 / 102
1.
A new copy would overwrite the central repository
2.
A copy of the repository would be created on your local machine
3.
Nothing, cloning is not a supported git function
4.
A copy of the repository would be created on the hosting platform
Q 14 / 102
1.
Find the commit in the remote repository, as that's the only place that kind of information is stored.
2.
Use the `diff-tree` command with the commit hash.
3.
Run `git commit --info` with the commit hash.
4.
Access the commit stash data with `git stash`.
Q 15 / 102
shell #.swift build/ *.txt *.metadata A line starting with `#` serves as a comment. Hence `# .swift` does not do anything. See `man gitignore`.1.
All files with a .swift, .txt, or metadata file extension, as well as the entire build directory
2.
Only the build directory
3.
All files in the build directory, as well as files ending with .txt or .metadata
4.
Only files with .swift and .txt extensions.
Q 16 / 102
`git commit -a -m "Refactor code base"`1.
Nothing, you can't use multiple options in the same command
2.
Adds all new files to the staging area
3.
Commits all new files with a message
4.
Adds all modified files to the staging area, then commits them with a message
Q 17 / 102
shell 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.js1.
There were two copies of beta-notes.js but one was deleted
2.
beta-notes.js was staged, then modified afterwards, creating two different versions of the file
3.
Two copies of beta-notes.js were created, but only one is being tracked
4.
There are two tracked copies of beta-notes.js, but one was removed from the commit
Q 18 / 102
1.
Saved files
2.
git documents
3.
Staging area
4.
git cache
Q 19 / 102
bash git pull --all git reset --hard origin/master bash git pull -u origin master git reset --hard master bash git pull origin master git reset --hard origin/myCurrentBranch bash git fetch --all git reset --hard origin/master1.
⠀
2.
⠀
3.
⠀
4.
⠀
5.
undefined
Q 20 / 102
1.
Only new files in the working directory are staged to the index.
2.
All new and updated files from the working directory are staged to the index.
3.
All files in the working directory are staged to the index in alphabetical order.
4.
Only updated files in the working directory are staged to the index.
Q 21 / 102
1.
use git show refs/push-notifications
2.
use git show push-notifications
3.
use git show heads/refs/push-notifications
4.
use git show refs/heads/push-notifications
Q 22 / 102
1.
git rebase -log
2.
git rebase -i
3.
git rebase -verbose
4.
git rebase -all
Q 23 / 102
git bisect start git bisect bad 5d41402abc4b2a76b9719d911017c592 git bisect good 69faab6268350295550de7d587bc323d1.
It runs a merge of a good commit that is discovered using a known bad commit and known good commit
2.
It marks a commit for deletion using a known bad commit and known good commit to determine which commit introduced a bug
3.
It defines a bad commit and resets the HEAD using a known bad commit and known good commit
4.
It performs a binary search using a known bad commit and known good commit to determine which commit introduced a bug
Q 24 / 102
1.
Cherry pick the related commits to another branch.
2.
Delete the task commits and recommit with a new message.
3.
Squash the related commits together into a single coherent commit.
4.
Stash the related commits under a new hash.
Q 25 / 102
1.
By default a push doesn't send tags to the remote repository.
2.
Commits can only be tagged when they are created.
3.
Tags are pushed to the remote repository with their respective commits.
4.
Only annotated tags are automatically pushed to the remote repository with a commit.
Q 26 / 102
bash git push -u origin master1.
git push master
2.
git push origin
3.
Same as before, git push -u origin master
4.
git push
Q 27 / 102
1.
Run git hotfix with the shortcut name.
2.
Assign a shortcut or command using git options file.
3.
Use the git custom-key command.
4.
Create an alias usin the git config command.
Q 28 / 102
shell 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.js1.
beta-notes.js is untracked and has been modified.
2.
beta-notes.js is a tracked file and has been modified, but has not been added to the current commit.
3.
beta-notes.js is untracked but has been added to the current commit.
4.
beta-notes.js is tracked, and the modified file has been added to the current commit.
Q 29 / 102
1.
--fix
2.
--quickfix
3.
--modify
4.
--amend
Q 30 / 102
1.
Data array
2.
Data log
3.
Data snapshot
4.
Data dictionary
Q 31 / 102
`git rm --cached testfile.js`1.
testfile.js will be removed from the staging area and its changes no longer tracked.
2.
testfile.js will be removed from the staging area but its changes will still be tracked.
3.
A copy of testfile.js will be cached on your desktop.
4.
The current copy of testfile.js will be saved in the staging area.
Q 32 / 102
1.
Use the git reset --soft HEAD to roll back one commit.
2.
Run git branch -d `<branch name>` to delete the merged branch.
3.
Use git clear-all to clean up any hanging files.
4.
Run git rebase to move the current commit to its original location.
Q 33 / 102
1.
This is not possible, as you cannot save locally without committing.
2.
Run git hold to save a local copy of what you're doing to return to later.
3.
Save your work with git local-cache.
4.
Use git stash to save your work and come back later and reapply the stashed commit.
Q 34 / 102
1.
git add
2.
git start
3.
git new
4.
git init
Q 35 / 102
1.
The "-all" option isn't added to the command.
2.
"rerere.enabled" isn't enable in the config file.
3.
The commit hash is missing.
4.
The filepath isn't specified.
Q 36 / 102
1.
core.page
2.
page
3.
pager
4.
core.pager
Q 37 / 102
1.
A set of files, representing the state of a project at a given point of time.
2.
Reference to parent commit objects.
3.
An SHA1 name, a 40-character string that uniquely identifies the commit object.
Q 38 / 102
1.
%ce
2.
%cr
3.
%cd
4.
%cn
Q 39 / 102
`In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase.`1.
3
2.
5
3.
2
4.
4
Q 40 / 102
1.
git
2.
admin
3.
root
4.
None of these
Q 41 / 102
1.
git tag 'v1.4.2'
2.
git tag -I 'v1.4.2.*'
3.
git tag-list 'v1.4.2*'
4.
git tag 'v1.4.2*'
Q 42 / 102
1.
lieutenants
2.
benevolent dictator
3.
Depends upon project type
4.
Depends upon data
Q 43 / 102
1.
add
2.
addfile
3.
begin
4.
track
Q 44 / 102
1.
All of these
2.
SSH
3.
Git
4.
HTTP
Q 45 / 102
1.
Control
2.
Shift
3.
Tab
4.
Alt
Q 46 / 102
1.
Distributed Version Control System
2.
Issue Tracking System
3.
Integrated Development Environment
4.
Web-Based Repository Hosting Service
Q 47 / 102
1.
duplicate
2.
replicate
3.
copy
4.
clone
Q 48 / 102
1.
File
2.
None of these
3.
Snapshot
4.
Folder
Q 49 / 102
1.
%am
2.
%ad
3.
%ae
4.
%an
Q 50 / 102
1.
1.7
2.
1.6
3.
2.0
4.
1.8
Q 51 / 102
1.
LIFO
2.
recursive
3.
FIFO
4.
octopus
Q 52 / 102
1.
SHA-1 value
2.
None of these
3.
Branch name
4.
Project name
Q 53 / 102
1.
C
2.
C++
3.
C#
4.
Java
Q 54 / 102
1.
ssh
2.
pub
3.
key
4.
pk
Q 55 / 102
1.
Bare repos store their git history in a .git subfolder.
2.
Bare repos do not have the .git extension.
3.
Bare repos do not come with working or checked-out source files.
4.
Bare repos should be used for local rather than remote repos.
Q 56 / 102
1.
any number of commits
2.
only one commit local per repository
3.
only three commits per branch
4.
only one commit per HEAD
Q 57 / 102
1.
heavy and concise
2.
lightweight and immutable
3.
heavy and annotated
4.
lightweight and annotated
Q 58 / 102
1.
git diff --cached
2.
git diff
3.
git diff --HEAD
4.
git status -v -v
Q 59 / 102
1.
removes the most recent stash entry
2.
deletes the stash
3.
lists everything in the stash
4.
throws away the oldest entry
Q 60 / 102
1.
`git -b checkout <nameOfBranch>`
2.
`git branch`
3.
`git checkout <nameOfBranch>`
4.
`git checkout -b <nameOfBranch>`
Q 61 / 102
1.
Use git reset HEAD^.
2.
Use git reset myFile.txt.
3.
Use git -rm myFile.txt.
4.
Use git reset.
Q 62 / 102
bash git checkout -b beta-test1.
The beta-test branch will be checked out of the current commit.
2.
The beta-test branch will be checked out and deleted.
3.
A new branch called beta-test will be created and switched to.
4.
The beta-test branch will be merged with the master branch.
Q 63 / 102
1.
by creating a pointer to the most recent snapshot/commit for the branch.
2.
by creating a data array of branches in the same repository.
3.
by creating a data dictionary of code changes.
4.
be creating a debug log that stores repository changes.
Q 64 / 102
1.
git help reset
2.
git -h reset
3.
git options reset
4.
git reset help
Q 65 / 102
1.
a version of the repository that mirrors changes made in the local repository's master branch for open-source collaboration efforts
2.
the lead repository elected by the Git arbitrator found within local repositories of collaborating team members
3.
a read-only version of the repository stored on a backup server in case local repositories become lost or corrupted
4.
a version of the repository hosted on the internet or network that is pushed to or pulled from by collaborators
Q 66 / 102
1.
git restore
2.
git undo
3.
git clean
4.
git checkout
Q 67 / 102
1.
Use git restore -p.
2.
Use git merge -u.
3.
Use git merge --abort.
4.
Use git merge --undo.
Q 68 / 102
1.
Use git stash to consolidate the commits under a new hash.
2.
Use git squash to consolidate the commits together into a single coherent commit.
3.
Delete the task commits and recommit with a new message.
4.
Use git cherry-pick to place the commits in another branch.
Q 69 / 102
1.
`git tag v3.8.1`
2.
`git tag --light "v3.8.1"`
3.
`git tag v3.8.1 —-annotate -m "<tagMessage>"`
4.
`git tag -l v3.8.1`
Q 70 / 102
1.
Rebase affects only your repository and creates a diff in the master branch.
2.
Rebase creates a temporary copy of the master branch in the remote repo.
3.
Rebase moves the HEAD of the remote master branch one commit forward.
4.
Rebase deletes all commit history for the new feature branch.
Q 71 / 102
1.
Git flow
2.
Mainline flow
3.
Trunk-Based Development
4.
GitHub flow
Q 72 / 102
1.
`--since`
2.
`--sinceWhen`
3.
`-<n>`
4.
`--afterDate`
Q 73 / 102
1.
`git cache --obsolete <time>`
2.
`git branch --rebase <time>`
3.
`git delete --inert <time>`
4.
`git prune --expire <time>`
Q 74 / 102
1.
The remote master branch could have existing changes overwritten.
2.
The origin URL will be reset to its default value.
3.
The current HEAD will be deleted and can't be reinstated.
4.
Nothing, it's common practice to force a push after rebasing.
Q 75 / 102
`git reset --soft HEAD^`1.
It resets the working branch to the first commit.
2.
It sets HEAD to previous commit and leaves changes from the undone commit in the stage/index.
3.
It deletes all previous commits and resets the repository history back to its initial state.
4.
It keeps the HEAD at the current commit, but clears all previous commits.
Q 76 / 102
1.
Git works only on Linux, while SVN works on all operating systems.
2.
SVN works only on Linux, while Git works on all operating systems.
3.
SVN is a centralized system, while Git is a distributed system.
4.
Git a centralized system, while SVN is a distributed system.
Q 77 / 102
`git tag -a v1.4 -m "ABCD v1.5"`1.
verbose
2.
annotated
3.
lightweight
4.
deferred
Q 78 / 102
1.
A soft reset only changes the commit that HEAD points to, while a hard reset resets the index and working tree to match the specified commit, discarding any changes.
2.
A soft reset caches the old HEAD pointer, while a hard reset deletes it entirely.
3.
A hard reset changes only where the HEAD is pointing, while a soft reset changes the HEAD and index.
4.
A hard reset caches the old HEAD pointer, while a soft reset deletes it entirely.
Q 79 / 102
 Which of the following options is correct ?1.
`1. Develop 2. Release 3. Hotfix 4. Feature 5. Master`
2.
`1. Master 2. Release 3. Hotfix 4. Feature 5. Develop`
3.
`1. Develop 2. Master 3. Hotfix 4. Feature 5. Develop`
4.
`1. Master 2. Hotfix 3. Develop 4. Feature 5. Release`
Q 80 / 102
1.
shell scripts and flags
2.
keychain and account information
3.
local and global repository options
4.
pre-compile scripts and settings
Q 81 / 102
1.
a type of architecture used to manage large databases
2.
a system that shows, tracks, and controls changes to a set of files over time
3.
a programmatic design pattern used to manage code between multiple engineering teams
4.
a type of software that links a project with a GitHub repository
Q 82 / 102
1.
git stash removes a commit from the repo history, while git stash pop saves changes to multiple branches.
2.
git stash saves changes to multiple branches, while git stash pop removes a commit from the repo history.
3.
git stash removes the most recent commit, while git stash pop saves current changes.
4.
git stash creates a stash entry, while git stash pop places the saved state onto the working directory.
Q 83 / 102
1.
git master --status
2.
git branch --status
3.
git branch --merged
4.
git status --merged
Q 84 / 102
1.
Create a post-commit shell script that triggers the action.
2.
Create a post-commit hook to trigger the script.
3.
Create a pre-commit hook to trigger the script.
4.
Create a pre-commit shell script that triggers the action.
Q 85 / 102
1.
state dependent environment changes
2.
continuous integration
3.
increasing code coverage
4.
enforcing commit rules
Q 86 / 102
1.
`git clean -f`
2.
`git rm .`
3.
`git reset HEAD`
4.
`git checkout .`
Q 87 / 102
1.
shell script pointers and keychain credentials
2.
updates to branch tips and other references in the local repository
3.
release notes and hook script values
4.
tag and versioning information
Q 88 / 102
1.
`git push --overwrite`
2.
`git push --update`
3.
`git push --assert`
4.
`git push --force-with-lease`
Q 89 / 102
1.
`git fetch` creates a new branch off the master branch, while `git pull` creates a new branch off the local repository's master branch.
2.
`git pull` downloads new data from a remote repository without integrating it into local files, while `git fetch` updates the current HEAD branch with the latest changes from the remote server.
3.
`git fetch` updates remote tracking branches with changes from a remote repository, while `git pull` updates remote tracking branches with changes from a remote repository and merges them into their corresponding local branches.
4.
`git fetch` downloads and merges data from the local repository, while `git pull` informs your colleagues you are about to make changes to the master branch.
Q 90 / 102
1.
`git current`
2.
`git status`
3.
`git local`
4.
`git context`
Q 91 / 102
1.
Check out the beta branch and run git merge push-notifications.
2.
Check out the push-notifications branch and run git merge beta.
3.
Check out the master branch and run git merge beta -> push-notifications.
4.
Delete the push-notifications branch; it will be committed to the master branch automatically.
Q 92 / 102
1.
Use git branch <stash hash>.
2.
Add the stashed commits to the current commit, then create a new branch.
3.
Use git checkout -b.
4.
Run git stash branch <branch name>.
Q 93 / 102
1.
-D deletes the local branch, while -d deletes the branch regardless of push and merge status.
2.
-d deletes the current commit head, while -D deletes the entire branch.
3.
-d deletes the local branch, while -D deletes the local branch regardless of push and merge status.
4.
-D deletes the current commit head, while -d deletes the entire branch.
Q 94 / 102
1.
git stash show -p stash@{2}
2.
git stash list
3.
git stash show -p stash@{1}
4.
git stash show -p
Q 95 / 102
1.
By default, a push doesn't send tags to the remote repository.
2.
Only annotated tags are automatically pushed to the remote repository with a commit.
3.
Tags are pushed to the remote repository with their respective commits.
4.
Commits can be tagged only when they are created.
Q 96 / 102
1.
Use `git --delete <branch_name>`.
2.
Use `git push <remote_name> --d <branch_name>`.
3.
Use `git push <remote_name> --D`.
4.
Use `git push <remote_name> --delete <branch_name>`.
Q 97 / 102
1.
delete
2.
expire
3.
show
4.
update
Q 98 / 102
1.
It causes tracked files in the parent directory to be included in the staged files.
2.
It allows developers to interactively choose which changes to tracked files are staged and outputs the differences for review.
3.
It automatically pushes changes to the corresponding branch on the remote repository.
4.
It allows developers to interactively choose which files are committed and outputs the differences for review.
Q 99 / 102
1.
You are not working on the most recent commit of a branch.
2.
A teammate has flagged the code with an issue.
3.
The commit does not have a parent.
4.
The branch has not been pushed to the remote repository.
Q 100 / 102
1.
It cannot be recovered.
2.
Find the hash of the branch with the `log` command, then execute `git checkout -b <branchname> <hash>`.
3.
Find the hash of the branch with the `reflog` command, then execute `git checkout -b <branchname> <hash>`.
4.
Execute `git checkout -b <branchname>`.
Q 101 / 102
bash Changes 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.js1.
There were two copies of beta-notes.js but one was deleted.
2.
There are two tracked copies of beta-notes.js but one was removed from the commit.
3.
Two copies of beta-notes.js were created, but only one is being tracked.
4.
beta-notes.js was staged, then modified afterwards, creating two different versions of the file.
Q 102 / 102