Tag: github

Basic Git Commands:

• git init: Initialize a local Git repository
• git clone [url]: Create a local copy of a remote repository
• git status: Check the status of your changes as untracked, modified, or staged
• git add [file]: Add a file to the staging area
• git commit -m “[message]”: Commit changes to head (but not yet to the remote repository)
• git push [alias] [branch]: Transmit local branch commits to the remote repository branch
• git pull: Update your local repository to the newest commit
• git merge [branch]: Merge a different branch into your active branch
• git branch: List your branches. a * will appear next to the currently active branch
• git branch -d [branch]: Delete a branch
• git checkout [branch-name]: Switch to a different branch and check it out into your working directory
• git cherry pick: It introduces certain commits from one branch into another branch within the repository.
• git checkout -b [branch-name]: Create a new branch and switch to it
• git stash: Stash changes in a dirty working directory
• git stash pop: Apply stashed changes to your working directory
• git rebase: Reapply commits on top of another base tip
• git reset: Undo commits or unstage files
• git log: Display the entire commit history using the default format
• git fetch [alias]: Fetch down all the branches from that Git remote
• git config -l: List all the settings Git can find at that point

Scenario-based Git Interview Questions

What’s the difference between git fetch and git pull?

git fetch downloads the latest changes from the remote repository to your local repository but doesn’t merge them into your current branch. It’s a safe way to see the changes before integrating them.

git pull, on the other hand, is essentially a git fetch followed by a git merge, where it fetches the remote changes and immediately merges them into the current branch.

How would you temporarily store your current changes that you’re not ready to commit?

I would use git stash to temporarily store the changes:

git stash

Later, when I’m ready to work on them again, I would use git stash pop to apply the stashed changes to the current working directory.

How would you revert a commit that has just been pushed and made public?

 To revert a public commit, I would use the `git revert` command which creates a new commit that undoes the changes made in the pushed commit, without altering the project history. This is important for public or shared repositories because other users may have already pulled the changes. The command would be:

How will you know if a branch has just been merged into master in Git?

To check if a branch has been merged into master, I can use the following command:

git branch --merged master

This will list all the branches that have been merged into the master branch. If I want to check if a specific branch has been merged, I can use:

git revert <commit-hash>
git push origin <branch-name>

git branch --merged master | grep <branch-name>

Can you explain the difference between git revert and git reset? Provide examples and discuss when to use each command.

git revert and git reset are commands used to undo changes in a Git repository, but they work differently and are suited for different situations.

Git Revert:

• Purpose: Creates a new commit that reverses the effect of earlier commits without altering the existing history.
• When to Use: Ideal for public branches to undo changes while maintaining a clean project history. It ensures that other collaborators are not affected by history changes.

git revert abc1234

This command reverts the changes made by the commit abc1234 and creates a new commit with the reverted changes.

Git Reset:

• Purpose: Resets the current branch head to a specific commit, optionally clearing changes in the staging area and working directory.
• When to Use: Useful for local cleanup before pushing changes, as it can alter commit history, which can be disruptive if used on public branches.
• Types of Reset:
  • --soft: Only moves the HEAD, keeping the working directory and staging area unchanged.
  • --mixed: Resets the staging area but keeps the working directory unchanged (default).
  • --hard: Resets the staging area and the working directory, potentially leading to data loss.

git reset --hard def5678

• This resets everything to the commit def5678, discarding all changes in the staging area and working directory.

Summary: Use git revert to safely undo changes in shared branches, preserving history for collaboration. Use git reset for correcting local changes or reorganizing commits before they are shared with others.

What would you do to squash the last N commits into a single commit?

To squash the last N commits into a single commit, you can use the `git rebase` command with the interactive option:

git rebase -i HEAD~N

Where `N` is the number of commits you want to squash. In the text editor that pops up, you’ll see a list of commits. You should leave the first commit as `pick` and change the word `pick` to `squash` or `s` for all other commits you want to combine. Then, save and close the editor. Git will combine all the specified commits into one. After that, you can edit the commit message for the new single commit.

How would you remove a file from Git without removing it from your file system?

To remove a file from Git without deleting it from the local file system, you can use the `git rm` command with the `–cached` option:

git rm --cached <file-path>

After running this command, the file will be removed from version control but will remain in your working directory. Then you can commit this change.

When would you choose “git rebase” instead of “git merge”?

`git rebase` is typically used when you want to create a clean, linear project history without the merge commits that `git merge` would introduce. You would choose to rebase when:

– You’re working on a personal branch and want to update it with the latest changes from the main branch without a merge commit.
– You want to clean up your commit history before merging your changes into the main branch.
– You’re working in a workflow that values a clean history, like the rebase workflow.

Rebase rewrites the project history by creating new commits for each commit in the original branch, which can be a cleaner approach. However, it’s important to avoid rebasing branches that are public and shared with others, as it can cause confusion and complicated merge conflicts for other developers who have based their work on the original branch commit

You’ve made a typo in your last commit message. How do you correct it?

If it’s the very last commit and it hasn’t been pushed to the remote repository yet, you can use:

git commit --amend -m "New commit message"

If you’ve already pushed the commit, you will need to force push, but this should be done with caution if other team members are working on the branch.

Describe the steps you would take to resolve a merge conflict.

When a merge conflict occurs, I would:

1. Identify the conflicting files with git status.
2. Open the conflicting files and manually resolve the conflicts by editing the file to remove the <<<<, ====, >>>> conflict markers and making the appropriate code changes.
3. After resolving the conflict, I would add the files to the staging area with git add.
4. Finally, I would complete the merge with git commit, which will open an editor for a commit message confirming the merge conflict resolution.

Could you describe the Git branching strategy that is utilized in your company and how it contributes to your development and release process?

Our company uses a Git Flow branching strategy. This includes:

• Feature Branches: Created from develop for new features and bug fixes, merged back after completion.
• Develop Branch: Serves as the main integration branch for features.
• Main Branch: Represents the production-ready state of our code.
• Release Branches: Used for preparing a new production release, allowing only bug fixes and essential tasks.
• Hotfix Branches: Address urgent issues in production, later merged into both main and develop.

This structure keeps our main branch stable, allows for organized development, and facilitates smooth releases.

What is a ‘pull request’?

A ‘pull request’ is a feature in version control systems like GitHub that lets you notify a repository’s owners that you want to make some changes to their code. It’s a request to review and then merge these changes into the main codebase.

How can you download a specific branch from a Git repository using the command line?

To download a specific branch from a Git repository, you can use the following command:

git clone -b <branch_name> --single-branch <repository_url>

Replace `<branch_name>` with the name of the branch you want to download and `<repository_url>` with the URL of the Git repository. This command clones only the history of the specified branch, reducing the amount of data downloaded and stored locally.