Git & GitHub Q&A

Interview Answer: In my project, we used Git for version control. Every developer worked on a separate branch, committed their changes locally, and pushed them to GitHub. After code review through a Pull Request, the changes were merged into the main branch. This helped us collaborate without affecting the production code.

Interview Answer: Our workflow was: Clone the repository → Create a feature branch → Make code changes → Commit the changes → Push to GitHub → Create a Pull Request → Code Review → Merge into the main branch → Deploy the application.

Clone
Copy the repository
locally
Feature Branch
Create a branch for
work
Code & Commit
Make changes and
commit
Push & PR
Push, open pull
request

Interview Answer: git push uploads all committed changes from the local repository to the remote GitHub repository. It allows other team members to access the latest code. Usually, after pushing the code, we create a Pull Request for review before merging.

Interview Answer: We create branches to develop new features or fix bugs without affecting the main code. Every developer works on their own branch. Once the work is completed and reviewed, it is merged into the main branch.

Interview Answer: A Pull Request is a request to merge code from one branch into another. It allows team members to review the code, suggest changes, and approve it before merging. This helps maintain code quality and avoid production issues.

Interview Answer: A merge conflict occurs when two developers modify the same part of the same file. Git cannot decide which change to keep automatically. I resolved it by reviewing both changes, keeping the correct code, testing it, and then committing the resolved version.

Commit
ResolvedTest Code
Keep
Correct
Code
Review
Changes

Interview Answer: In my daily work, I mostly use git clone, git status, git add, git commit, git pull, git push, git branch, git checkout, and git merge. These commands are enough for most day-to-day development tasks.

git clone git status git add
git commit git pull git push
git branch git checkout git merge

Interview Answer: First, I would run git pull to fetch the latest changes from the remote repository. If there are any conflicts, I would resolve them, test the code, and then push my updated changes back to GitHub.

Interview Answer: I use the git status command to check modified, staged, and untracked files. If I want to see the exact code changes, I use git diff before committing.

git status
Check modified, staged, and untracked files
git diff
See the exact code changes before committing

Interview Answer: One issue I faced was a merge conflict when two developers modified the same file. We resolved the conflict by reviewing both changes, testing the final code, and then merging it. After that, we informed the team to pull the latest code before making further changes.

Interview Answer: git fetch only downloads the latest changes from the remote repository but does not merge them. git pull downloads the changes and automatically merges them into the current branch. I usually use git pull to keep my branch updated.

git fetch
Downloads the latest changes from the remote repository but
does not merge them
git pull
Downloads the changes and automatically merges them into
the current branch

Interview Answer: If the commit is only in my local repository, I can undo it and recommit the correct files. If it has already been pushed, I would use Git commands like git revert or create a new commit to fix the mistake, depending on the team's process.

These questions closely match the Git topics covered in your PDF (workflow, commands, branching, merging, tracking, and merge conflicts) and are well suited for Data Engineer interviews.