YuWebdesign



Git and GitHub Interview Questions

By YuwebDesign


  1. File Server
    A file server allows multiple users to access a centralized file system called a repository.

    The repository appears as a local drive or directory to each user.

    The file server prevents users from writing to the same repository file at the same time.

  2. Version Control System
    A version control system (VCS) is like a file server, except it also keeps track of the revision history of the repository.

    This makes it possible for users to track changes to the repository.

Revision History

A revision history can be viewed as a partially ordered collection of repositories.

Each repository in the collection is called a revision.

Each time a user makes or commits a change to a file or directory in the repository, the VCS creates a cheap copy of the entire repository.

A cheap copy of a directory only copies the files and directories that have changed.

Branching

  1. It is also possible for a user to make a copy of the current repository.
    This copy may then undergo several revisions independent of the original.
    This is called a branch.
  2. The subsequent revision history of the original repository is called the trunk.
    Later the branch can be merged with the trunk.
Version Control Clients and Servers
  1. A VCS is the client-server application.
  2. The VC server manages repositories and users for multiple projects.
  3. Users access the VC server using a VC client.
  4. The VC client allows a user to copy files between the repository and a local directory.
  5. The files in the local directory are called working copies.
  6. Copying a file or directory from the repository to a working directory is done using the checkout command.
  7. The copy in the working directory is called a working copy.
  8. The update command replaces the contents of the working directory with the latest versions from the repository.
  9. Copying files from the working directory back to the repository is done using the commit command.
VCS Goals
  1. Backup and restore
  2. Synchronization
  3. Undo
  4. Track changes and ownership
  5. Sandboxing
  6. Branching

VSC Types

The Readers and Writers Problem

What happens if two users are working on the same file?
It’s possible that their versions might get out of synch.

There are two ways to solve this problem:

  1. The Lock-Modify-Unlock solution requires users to first lock a file before modifying it, then unlock the file afterwards. Only one user can lock a file at a time.
  2. The Copy-Modify-Merge solution requires users to modify a copy of the file. The modified file is then merged with the repository file, which may have been modified by another user.

Git is a Version Control System (VCS) that allows:

  1. revert selected files back to a previous state
  2. revert the entire project back to a previous state
  3. compare changes over time
  4. see who last modified something that might be causing a problem
  5. see who introduced an issue and when, and more
  6. Using a VCS also generally means that if you screw things up or lose files, you can easily recover.

The first thing you should do when you install Git
is to set your user name and email address.

This is important
because every Git commit uses this information,
and it’s immutably baked into the commits you start creating.

You need to do this only once if you pass the ‐‐global option,
because then Git will always use that information
for anything you do on that system.

If you want to override this
with a different name or email for specific projects,
you can run the command without the ‐‐global option
when you’re in that project.

Git has a number of different transfer protocols you can use:

  1. Local
  2. HTTP

    https:// protocol,
    e.g., https://github.com/libgit2/libgit2 mylibgit

  3. Secure Shell (SSH) transfer protocol,
    e.g., git:// or user@server:path/to/repo.git,
  4. Git

Every project on GitHub is accessible over HTTPS as https://github.com// ,
and over SSH as git@github.com:/ .
Git can fetch from and push to both of these URLs,
but they are access-controlled based on the credentials of the user connecting to them.

It is often preferable to share the HTTPS based URL for a public project, since the user does not have to have a GitHub account to access it for cloning. Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL. The HTTPS one is also exactly the same URL they would paste into a browser to view the project there.

Git comes with a tool called git config
to customize your Git environment.

Git config that lets you
get and set configuration variables
that control all aspects
of how Git looks and operates.

These variables can be stored in three different places:

Unix/Linux
Location
Windows
Location
Description
/etc/gitconfig file Git will look for /etc/gitconfig,
although it’s relative to the MSys root,
which is wherever you decide to install Git on your Windows
when you run the installer.
Contains values applied to every user on the system and all their repositories.

If you pass the option ‐&#8208system to git config,
it reads and writes from this file specifically.

(Because this is a system configuration file, you would need administrative or superuser privilege to make changes to it.)

~/.gitconfig or ~/.config/git/config file On Windows, Git looks for the .gitconfig file in the $HOME directory

(C:\Users\$USER for most people).

Values specific personally to you, the user.

You can make Git read and write to this file specifically
by passing the ‐&#8208global option,
and this affects all of the repositories
you work with on your system.

config file in the Git directory (that is, .git/config) of whatever repository you’re currently using Git for Windows version 2.x or later,
has a system-level config file at
C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP,
and in C:\ProgramData\Git\config on Windows Vista and newer.
This config file can only be changed by git config -f [file] as an admin.
Specific to that single repository.

You can force Git to read from and write to this file
with the ‐&#8208local option,
but that is in fact the default.

(Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.)

Each level overrides values in the previous level,
so values in .git/config trump those in /etc/gitconfig.

You can view all of your settings and where they are coming from using:
$ git config ‐‐list ‐‐show-origin

Each file in your working directory can be in one of two states: tracked or untracked:

  1. Tracked files are files that were in the last snapshot;
    tracked files are files that Git knows about.
    They can be

    • unmodified,
    • modified,
    • or staged.
  2. Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area.

Git file lifecycle

When you first clone a repository,
all of your files will be tracked and unmodified
because Git just checked them out
and you haven’t edited anything.

As you edit files,
Git sees them as modified,
because you’ve changed them since your last commit.

As you work, you selectively stage these modified files
and then commit all those staged changes,
and the cycle repeats.

To be able to collaborate on any Git project, you need to know how to manage your remote repositories.

Remote repositories are versions of your project that are hosted on the Internet or network somewhere.

You can have several of them, each of which generally is either read-only or read/write for you.

Remote repositories can be on your local machine.
It is entirely possible that you can be working with a “remote” repository that is, in fact, on the same host you are.

The word “remote” does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote.

Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.

Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more.

When you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.”

(branch you merged in was directly ahead of the commit you’re on)

Centralized Workflow

Branching Strategies: Git Workflow Types

In centralized systems, there is generally a single collaboration model — the centralized workflow.

One central hub, or repository, can accept code, and everyone synchronizes their work with it.

A number of developers are nodes — consumers of that hub — and synchronize with that centralized location.

Git Centralized Workflow Type


Read more >>>

Feature-Branch Workflow

Git Feature Branch Workflow

Central Main Master Branch and separate branches per feature.
After feature is complete it is merged back into upstream.

Gitflow

Gitflow Branching Strategy

Centralazed development branch and separate branches per feature.
After feature is complete it is merged into development branch.
Master Branch stores only production code (for release).
Hotfixes branch may also be introduced.

Read more >>>

Integration-Manager Workflow

Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the “official” project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.

Integration-Manager Git Workflow

The process works as follows:

  1. The project maintainer pushes to their public repository.
  2. A contributor clones that repository and makes changes.
  3. The contributor pushes to their own public copy.
  4. The contributor sends the maintainer an email asking them to pull changes.
  5. The maintainer adds the contributor’s repository as a remote and merges locally.
  6. The maintainer pushes merged changes to the main repository.

This is a very common workflow with hub-based tools like GitHub or GitLab, where it’s easy to fork a project and push your changes into your fork for everyone to see. One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. Contributors don’t have to wait for the project to incorporate their changes — each party can work at their own pace.


Read more >>>

Dictator and Lieutenants Workflow

This is a variant of a multiple-repository workflow. It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull.
Benevolent dictator workflow

The process works like this:

  1. Regular developers work on their topic branch and rebase their work on top of master.
    The master branch is that of the reference repository to which the dictator pushes.
  2. Lieutenants merge the developers’ topic branches into their master branch.
  3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
  4. Finally, the dictator pushes that master branch to the reference repository so the other developers can rebase on it.



Read more >>>

Forking Workflow

Forking Workflow


Leave a Reply or Comment

Your email address will not be published. Required fields are marked *