3.0 Version Control with Git

Question 1

3.0 Version Control with Git

What is version control?

Answer 1

Practice of tracking and managing code changes

It enables multiple people to simultaneously work on a single project

Question 2

3.0 Version Control with Git

What is another name for version control?

Answer 2

source control

Question 3

3.0 Version Control with Git

How does version control help the development process?

Answer 3

Since code is hosted centrally on the internet, it enables multiple devs to simultaneously work on a single project.

Every developer has an entire copy of the code locally.

Question 4

3.0 Version Control with Git

What are some basic concepts of version control?

Answer 4

• Every code change and file is tracked
• Keeps a history of changes
• You can revert commits
• Each change is labelled with a commit message
• Git is the most used version control system

Question 5

3.0 Version Control with Git

What is the difference between remote and local Git repos?

Answer 5

• Remote repo is where the code is hosted on the internet (GitLab/GitHub)
• Local repo is a local copy of the code on your machine

Code is fetched (“pulled”) from remote repo and “pushed” to it

Question 6

3.0 Version Control with Git

What is a Git client?

Answer 6

UI or CLI that allows a user to interact with git

interact = connect and execute git commands

Question 7

3.0 Version Control with Git

What is a merge conflict?

Answer 7

It’s when Git tries to merge changes from multiple developers but the same line was changed and it doesn’t know how to handle it.

Question 8

3.0 Version Control with Git

How is a merge conflict resolved?

Answer 8

It is resolved manually through conversation between the developers to decide how the code should be written.

Question 9

3.0 Version Control with Git

How can merge conflicts be avoided?

Answer 9

Mainly Push and pull often from remote
repository to stay in sync

Also, it also helps if devs are aware of which part of the baseline each other is working on

Breaking changes doesn’t affect you until you pulled the new code.

Question 10

3.0 Version Control with Git

What are the different areas in git that code passes through?

Answer 10

• Working directory
• Staging area
• Local repository
• Remote repository

Question 11

3.0 Version Control with Git

Explain git add file

Answer 11

• Include the changes of a file into the next commit
• Moves the changes from “working directory” to the “staging area”

Question 12

3.0 Version Control with Git

Explain git commit -m "commit message"

Answer 12

• Moves changes from staging area to your local repository
• Creates a new commit, which you can go back to later if needed

Question 13

3.0 Version Control with Git

Explain git push remote-url branch-name

Answer 13

• After committing your changes to your local repo, you want to send your changes to the remote Git server
• Uploads your commits to the remote repo

Question 14

3.0 Version Control with Git

How do you authenticate your git client with GitHub/GitLab/etc?

Answer 14

Create an SSH key pair and add it to the remote platform.

GitLab: User Settings > SSH Keys > follow instructions

Question 15

3.0 Version Control with Git

What are two Git global config commands to set up username and email?

Answer 15

git config –global user.name “Your Name”
git config –global user.email “your@email.com”

Question 16

3.0 Version Control with Git

How do you clone a repo and add a README.md file?

Answer 16

git clone git@gitlab.com:username/your-project.git
cd your-project
touch README.md
git add README.md
git commit -m “add README”
git push -u origin master

Question 17

3.0 Version Control with Git

If you already have an existing project locally, how do you initialize a git repository and push it to your remote platform?

Answer 17

cd myproject
git init
git add .
git commit -m “Initial commit”
git remote add origin git@gitlab.com:group/project.git
git branch -M main
git push -u origin main

Question 18

3.0 Version Control with Git

What does it mean when Git says “fatal: not a git repository”?

Answer 18

You’re running Git commands in a folder that hasn’t been initialized. Run:

```bash
git init
~~~

Or navigate to the correct directory:

```bash
cd /path/to/project
~~~

Question 19

3.0 Version Control with Git

Why does git remote add origin ... fail with “remote origin already exists”?

Answer 19

A remote named origin is already configured. Fix with:

```bash
git remote set-url origin <URL>
~~~</URL>

or remove and re-add:

```bash
git remote remove origin
git remote add origin <URL>
~~~</URL>

Question 20

3.0 Version Control with Git

Why do I get “failed to push some refs” on first push?

Answer 20

The remote isn’t empty — it already has commits (like a README). Fix by pulling with unrelated histories allowed:

```bash
git pull origin main –allow-unrelated-histories
~~~

Resolve conflicts → commit → push again.

Question 21

3.0 Version Control with Git

Pushing fails with “src refspec main does not match any” — why?

Answer 21

You don’t have a branch named main yet, usually because nothing was committed. Fix:

```bash
git add .
git commit -m “Initial commit”
git branch -M main
git push -u origin main
~~~

Question 22

3.0 Version Control with Git

Why do I get authentication errors pushing over HTTPS?

Answer 22

GitHub/GitLab require Personal Access Tokens, not passwords. Fix: update the remote to use SSH or generate a PAT.
SSH example:

```bash
git remote set-url origin git@gitlab.com:group/project.git
~~~

Question 23

3.0 Version Control with Git

Why do I get “Permission denied (publickey)” when using SSH?

Answer 23

SSH key not loaded or not added to GitLab/GitHub. Fix:

```bash
ssh-keygen -t ed25519
ssh-add ~/.ssh/id_ed25519
~~~

Then add id_ed25519.pub to the platform.

Question 24

3.0 Version Control with Git

Pushing shows “repository not found” — why?

Answer 24

Usually:
* Wrong remote URL
* No access rights
* Repo deleted or private

Verify:

```bash
git remote -v
~~~

Correct with:

```bash
git remote set-url origin <correct-url>
~~~</correct-url>

Question 25

# 3.0 Version Control with Git Push fails with “**updates were rejected because the remote contains work that you do not have locally**.” Why?

Answer 25

Someone already pushed to the remote. Fix: pull first and merge: ```bash git pull origin main ``` or rebase: ```bash git pull --rebase origin main ```

Question 26

# 3.0 Version Control with Git Why is nothing being committed (“**nothing to commit, working tree clean**”)?

Answer 26

All files are already committed or ignored by `.gitignore`. Run to check ignored files: ```bash git status --ignored ```

Question 27

# 3.0 Version Control with Git Why does `git add .` do nothing for certain files?

Answer 27

`.gitignore` excludes them. Check which pattern is blocking the file: ```bash git check-ignore -v ```

Question 28

# 3.0 Version Control with Git What if I accidentally initialized Git in the wrong directory?

Answer 28

Remove the `.git` folder: ```bash rm -rf .git ``` Then re-run `git init` in the correct place.

Question 29

# 3.0 Version Control with Git How do I verify that my push actually updated the remote?

Answer 29

Check the remote branch: ```bash git log origin/main --oneline ``` Or use: ```bash git ls-remote --heads origin ```

Question 30

# 3.0 Version Control with Git What is the purpose of **branches** in Git?

Answer 30

Branches allow better collaboration by letting developers work independently without breaking the main branch. ## Footnote This facilitates parallel development and reduces conflicts.

Question 31

# 3.0 Version Control with Git What branch is created by default when a new repository is initialized?

Answer 31

The **main** branch (also historically called **master**). ## Footnote This is the primary branch where the stable code resides.

Question 32

# 3.0 Version Control with Git Why do developers create **temporary branches**?

Answer 32

To work on features or bugfixes safely without risking stability of the main branch. ## Footnote This allows for isolated development.

Question 33

# 3.0 Version Control with Git What is the best practice for using branches when developing features or fixing issues?

Answer 33

Create **one branch per feature or bugfix**. ## Footnote This simplifies tracking and merging changes.

Question 34

# 3.0 Version Control with Git Give common **branch name patterns**.

Answer 34

* `main` * `dev` * `feature/...` * `bugfix/...` ## Footnote These patterns help in identifying the purpose of branches.

Question 35

# 3.0 Version Control with Git Give an example of a **bugfix branch name**.

Answer 35

`bugfix/ticket-2134` ## Footnote This naming convention links the branch to a specific issue or ticket.

Question 36

# 3.0 Version Control with Git Where do new branches typically **start from**?

Answer 36

From the **main branch**, using the same initial code base. ## Footnote This ensures consistency in development.

Question 37

# 3.0 Version Control with Git What happens when a feature or bugfix branch is **complete**?

Answer 37

It is **merged back into the main branch**. ## Footnote This integrates the new changes into the stable codebase.

Question 38

# 3.0 Version Control with Git What is the goal of keeping the **main branch stable**?

Answer 38

Ensuring the main branch is always ready for **production deployment**. ## Footnote Stability is crucial for reliable software delivery.

Question 39

# 3.0 Version Control with Git What is a **merge request** (or pull request)?

Answer 39

A request to merge one branch into another, typically into the main branch. ## Footnote This facilitates code review and collaboration.

Question 40

# 3.0 Version Control with Git Why do teams use **merge requests**?

Answer 40

To review code, collaborate, and ensure quality before merging. ## Footnote This process helps catch issues early.

Question 41

# 3.0 Version Control with Git What can a reviewer do in a **merge request**?

Answer 41

View the changes and either approve or decline the merge. ## Footnote This is part of the quality assurance process.

Question 42

# 3.0 Version Control with Git Why should a **DevOps engineer** know Git?

Answer 42

DevOps involves writing configuration files and scripts that need version control, collaboration, and secure storage. ## Footnote Understanding Git is essential for effective DevOps practices.

Question 43

# 3.0 Version Control with Git Where should **IaC files** live?

Answer 43

In a **remote Git repository**, tracked and version-controlled. ## Footnote This ensures accessibility and collaboration.

Question 44

# 3.0 Version Control with Git What does **CI** typically do on each merge?

Answer 44

Checkout code → test → build application. ## Footnote This process ensures that new changes do not break existing functionality.

Question 45

# 3.0 Version Control with Git Which Git commands might a **CI/CD pipeline** need?

Answer 45

* Getting the commit hash * Checking if changes happened in certain directories (frontend/backend) ## Footnote These commands help in managing the build process.

Question 46

# 3.0 Version Control with Git Why must **DevOps engineers** understand Git in CI/CD?

Answer 46

Because pipelines require integration with Git for checking out code, detecting changes, and automating builds/deployments. ## Footnote This knowledge is critical for effective CI/CD implementation.

Question 47

# 3.0 Version Control with Git Initialize a new **Git repository** in the current directory

Answer 47

`git init` ## Footnote This command sets up a new Git repository in the specified directory.

Question 48

# 3.0 Version Control with Git Clone a **remote repository**

Answer 48

`git clone ` ## Footnote This command creates a local copy of a remote repository.

Question 49

# 3.0 Version Control with Git Stage all **changes**

Answer 49

`git add .` ## Footnote This command stages all modified and new files for the next commit.

Question 50

# 3.0 Version Control with Git Commit staged **changes**

Answer 50

`git commit -m "message"` ## Footnote This command saves the staged changes to the repository with a message.

Question 51

# 3.0 Version Control with Git Check **repository status**

Answer 51

`git status` ## Footnote This command displays the state of the working directory and staging area.

Question 52

# 3.0 Version Control with Git List all **branches**

Answer 52

`git branch` ## Footnote This command shows all branches in the repository.

Question 53

# 3.0 Version Control with Git Create a new **branch**

Answer 53

`git branch ` ## Footnote This command creates a new branch with the specified name.

Question 54

# 3.0 Version Control with Git Switch to a **branch**

Answer 54

`git checkout ` ## Footnote This command changes the current working branch to the specified branch.

Question 55

# 3.0 Version Control with Git Create and switch to a **branch**

Answer 55

`git checkout -b ` ## Footnote This command creates a new branch and switches to it in one step.

Question 56

# 3.0 Version Control with Git Delete a **branch**

Answer 56

`git branch -d ` ## Footnote This command deletes the specified branch.

Question 57

# 3.0 Version Control with Git Merge a **branch** into the current branch

Answer 57

`git merge ` ## Footnote This command integrates changes from the specified branch into the current branch.

Question 58

# 3.0 Version Control with Git Start a **rebase**

Answer 58

`git rebase ` ## Footnote This command reapplies commits on top of another base tip.

Question 59

# 3.0 Version Control with Git Abort a **rebase**

Answer 59

`git rebase --abort` ## Footnote This command stops the rebase process and returns to the original branch state.

Question 60

# 3.0 Version Control with Git Continue a **rebase** after resolving conflicts

Answer 60

`git rebase --continue` ## Footnote This command continues the rebase process after conflicts have been resolved.

Question 61

# 3.0 Version Control with Git Show **remote repositories**

Answer 61

`git remote -v` ## Footnote This command lists all remote repositories associated with the local repository.

Question 62

# 3.0 Version Control with Git Add a **remote**

Answer 62

`git remote add origin ` ## Footnote This command adds a new remote repository with the specified URL.

Question 63

# 3.0 Version Control with Git Change a **remote URL**

Answer 63

`git remote set-url origin ` ## Footnote This command updates the URL of an existing remote repository.

Question 64

# 3.0 Version Control with Git Fetch changes from **remote**

Answer 64

`git fetch` ## Footnote This command retrieves updates from the remote repository without merging.

Question 65

# 3.0 Version Control with Git Push current branch to **remote**

Answer 65

`git push` ## Footnote This command uploads the current branch's commits to the remote repository.

Question 66

# 3.0 Version Control with Git Push and set upstream **tracking**

Answer 66

`git push -u origin ` ## Footnote This command pushes the branch to the remote and sets it to track the remote branch.

Question 67

# 3.0 Version Control with Git Pull and **merge** changes

Answer 67

`git pull` ## Footnote This command fetches and merges changes from the remote repository into the current branch.

Question 68

# 3.0 Version Control with Git Pull with **rebase**

Answer 68

`git pull --rebase` ## Footnote This command fetches changes and rebases the current branch on top of the upstream changes.

Question 69

# 3.0 Version Control with Git Undo unstaged **changes** in a file

Answer 69

`git restore ` ## Footnote This command discards changes in the working directory for the specified file.

Question 70

# 3.0 Version Control with Git Unstage a **file**

Answer 70

`git restore --staged ` ## Footnote This command removes the specified file from the staging area.

Question 71

# 3.0 Version Control with Git Discard all unstaged **changes**

Answer 71

`git checkout -- .` ## Footnote This command reverts all unstaged changes in the working directory.

Question 72

# 3.0 Version Control with Git Soft **reset** (keeps changes staged)

Answer 72

`git reset --soft ` ## Footnote This command resets the current branch to the specified commit while keeping changes staged.

Question 73

# 3.0 Version Control with Git Mixed **reset** (default, unstages changes)

Answer 73

`git reset ` ## Footnote This command resets the current branch to the specified commit and unstages changes.

Question 74

# 3.0 Version Control with Git Hard **reset** (discard ALL changes)

Answer 74

`git reset --hard ` ## Footnote This command resets the current branch to the specified commit and discards all changes.

Question 75

# 3.0 Version Control with Git Modify the last **commit message**

Answer 75

`git commit --amend` ## Footnote This command allows you to change the message of the last commit.

Question 76

# 3.0 Version Control with Git Interactive **rebase** to rewrite multiple commits

Answer 76

`git rebase -i ` ## Footnote This command opens an interactive interface to modify commit history.

Question 77

# 3.0 Version Control with Git Force push **rewritten history**

Answer 77

`git push --force-with-lease` ## Footnote This command pushes changes to the remote repository, overwriting history if necessary.

Question 78

# 3.0 Version Control with Git Show **commit history**

Answer 78

`git log` ## Footnote This command displays the commit history of the repository.

Question 79

# 3.0 Version Control with Git Compact one-line **log**

Answer 79

`git log --oneline` ## Footnote This command shows a simplified view of the commit history.

Question 80

# 3.0 Version Control with Git Graph view of **commits**

Answer 80

`git log --oneline --graph --all` ## Footnote This command visualizes the commit history in a graph format.

Question 81

# 3.0 Version Control with Git Diff **unstaged changes**

Answer 81

`git diff` ## Footnote This command shows the differences between the working directory and the index.

Question 82

# 3.0 Version Control with Git Diff **staged changes**

Answer 82

`git diff --cached` ## Footnote This command shows the differences between the index and the last commit.

Question 83

# 3.0 Version Control with Git Diff between two **commits**

Answer 83

`git diff ` ## Footnote This command compares the changes between two specified commits.

Question 84

# 3.0 Version Control with Git Set global **username**

Answer 84

`git config --global user.name ""` ## Footnote This command sets the username for all repositories on the system.

Question 85

# 3.0 Version Control with Git Set global **email**

Answer 85

`git config --global user.email ""` ## Footnote This command sets the email address for all repositories on the system.

Question 86

# 3.0 Version Control with Git View all **configuration**

Answer 86

`git config --list` ## Footnote This command displays all Git configuration settings.

Question 87

# 3.0 Version Control with Git Stash current **changes**

Answer 87

`git stash` ## Footnote This command saves the current changes in a stack for later use.

Question 88

# 3.0 Version Control with Git Apply latest **stash**

Answer 88

`git stash apply` ## Footnote This command reapplies the most recent stashed changes.

Question 89

# 3.0 Version Control with Git Show list of **stashes**

Answer 89

`git stash list` ## Footnote This command displays all stashed changes.

Question 90

# 3.0 Version Control with Git Create a **lightweight tag**

Answer 90

`git tag ` ## Footnote This command creates a tag at the current commit.

Question 91

# 3.0 Version Control with Git Push **tags**

Answer 91

`git push --tags` ## Footnote This command pushes all tags to the remote repository.

Question 92

# 3.0 Version Control with Git Why should **commit messages** be descriptive and meaningful?

Answer 92

Because clear commit messages make history understandable and help others follow changes easily. ## Footnote This practice enhances collaboration and project management.

Question 93

# 3.0 Version Control with Git Why commit in **relatively small chunks**?

Answer 93

Smaller commits are easier to review, revert, and understand. ## Footnote This approach facilitates better tracking of changes.

Question 94

# 3.0 Version Control with Git What is the rule about **grouping work** inside a commit?

Answer 94

Commit only *related* changes in a single commit. ## Footnote This ensures clarity and coherence in the commit history.

Question 95

# 3.0 Version Control with Git What Git configuration should be set before committing?

Answer 95

Commit authorship information: * `user.name` * `user.email` ## Footnote This identifies the author of the commits.

Question 96

# 3.0 Version Control with Git How do you keep your **feature or bugfix branch** up to date?

Answer 96

Pull regularly from the remote main/master or develop branch. ## Footnote This practice minimizes merge conflicts.

Question 97

# 3.0 Version Control with Git Why shouldn't **branches stay open too long**?

Answer 97

Long-lived branches drift from main and cause merge conflicts; merging main often prevents this. ## Footnote Regular updates help maintain branch relevance.

Question 98

# 3.0 Version Control with Git What is a good practice to avoid **deviations** between local and remote repositories?

Answer 98

Sync frequently by pulling from the remote. ## Footnote This keeps your local repository aligned with the remote.

Question 99

# 3.0 Version Control with Git Why shouldn’t you **push straight to the main branch**?

Answer 99

It bypasses code review and risks breaking production. ## Footnote This practice ensures quality control.

Question 100

# 3.0 Version Control with Git When is it appropriate to use **`--force` push**?

Answer 100

Only when working alone on a branch—**never** on main or develop. ## Footnote This prevents unintended overwrites in shared branches.

Question 101

# 3.0 Version Control with Git What is the best practice for **naming branches**?

Answer 101

* `feature/` for features * `bugfix/` for fixes ## Footnote Consistent naming conventions improve clarity.

Question 102

# 3.0 Version Control with Git Why use **merge requests (pull requests)**?

Answer 102

For code reviews, collaboration, and ensuring code quality before merging. ## Footnote This process enhances team communication.

Question 103

# 3.0 Version Control with Git Why is a **`.gitignore` file** important?

Answer 103

It prevents committing unnecessary files like editor configs, build artifacts, or temporary folders. ## Footnote This keeps the repository clean and focused.