YuWebdesign



Git and GitHub Interview Questions

By YuwebDesign


Version Control Systens

  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 vs. SVN: Advantages of Git
  1. GIT is an open source version control system;
    it will allow you to run ‘versions’ of a project,
    which show the changes
    made to the code overtime.
  2. Also it allows you keep the backtrack
    if necessary
    and undo those changes.
  3. Multiple developers
    can checkout, and upload changes
    and each change
    can be attributed to a specific developer.
Git vs. SVN: Disadvantages of Git
  1. Git is less preferred for
    handling extremely large files
    or frequently changing binary files

    while SVN can handle multiple projects
    stored in the same repository.

  2. GIT does not support ‘commits’
    across multiple branches or tags.

    Subversion allows the creation of folders
    at any location in the repository layout.

  3. Gits are unchangeable,

    while Subversion allows committers
    to treat a tag as a branch
    and to create multiple revisions
    under a tag root.

Subgit
is a tool for a smooth, stress-free SVN to Git migration.

Subgit is a solution for a company-wide migration
from SVN to Git that is:

  1. It is much better than git-svn
  2. No requirement to change the infrastructure that is already placed
  3. Allows to use all git and all sub-version features
  4. Provides genuine stress–free migration experience.

Git

GIT
is a distributed version control system
and source code management (SCM) system
with an emphasis to handle small and large projects
with speed and efficiency.

Each version
captures a snapshot of the file system
at a certain point of time.

A collection of files
and their complete history
are stored in a repository.

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

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

  1. Data redundancy and replication
  2. High availability
  3. Only one .git directory per repository
  4. Superior disk utilization and network performance
  5. Collaboration friendly
  6. Any sort of projects can use GIT

Some of the best GIT clients for LINUX are:

  1. Git Cola
  2. Git-g
  3. Smart git
  4. Giggle
  5. Git GUI
  6. qGit

Git Instaweb
automatically directs a web browser
and runs webserver
with an interface into your local repository.

GIT is fast,
and ‘C’ language makes this possible
by reducing the overhead of runtimes
associated with higher languages.

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.

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.

Before completing the commits, it can be formatted and reviewed in an intermediate area known as ‘Staging Area’ or ‘Index’.

  1. A set of files, representing the state of a project at a given point of time
  2. Reference to parent commit objects
  3. SHAI name, a 40 character string that uniquely identifies the commit object.

A ‘head’ is simply a reference to a commit object.

In every repository, there is a default head referred as “Master”.

A repository can contain any number of heads.

Git Is-tree
represents a tree object
including the mode and the name of each item
and the SHA-1 value
of the blob or the tree.

This directory consists of Shell scripts
which are activated
after running the corresponding Git commands.

E.g., git will try to execute the post-commit script
after you run a commit.

Commit message
is a feature of git
which appears when you commit a change.

Git provides you a text editor
where you can enter the modifications
made in commits.

To fix any broken commit,
you will use the command
git commit—amend.

By running this command,
you can fix the broken commit message in the editor.

There are couple of reason

  1. The amend operation will destroy the state
    that was previously saved in a commit.

    If it’s just the commit message being changed
    then that’s not an issue.

    But if the contents are being amended
    then there are chances of eliminating something important.

  2. Abusing “git commit- amend”
    can cause a small commit to grow
    and acquire unrelated changes.

A repository
contains a directory named .git,
where git keeps all of its metadata
for the repository.

The contents of the .git directory
are private to git.

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.

Bare Repository
is used to co-ordinate
with the distributed development and developers team,
especially when you are working
on a project from multiple computers.

A bare repository
comprises of a version history of your code.

In Git, to create a repository,
create a directory for the project if it does not exist,
and then run command “git init”.

By running this command
.git directory will be created in the project directory,
the directory does not need to be empty.

  1. Pikacode
  2. Visual Studio Online
  3. GitHub
  4. GitEnterprise
  5. SourceForge.net

A ‘conflict’
arises when the commit that has to be merged
has some change in one place,
and the current commit
also has a change at the same place.

Git will not be able to predict
which change should take the precedence.

To resolve a conflict in git:

  1. edit the files to fix the conflicting changes
  2. and then add the resolved files by running “git add”
  3. after that run “git commit” to commit the repaired merge

Git remembers that you are in the middle of a merger,
so it sets the parents of the commit correctly.

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 Commands

Git comes with a tool called git config.

Git config command is a convenient way
to set configuration options for your Git installation.

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

Git config allows to customize your Git environment:

  1. behavior of a repository,
  2. user info,
  3. preferences etc.

You can view all of your settings and where they are coming from using:

git config ‐‐list ‐‐show-origin

Configuration 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.

The git clone command creates a copy of an existing Git repository.

To get the copy of a central repository,
‘cloning’ is the most common way used by programmers.

git remote add

just creates an entry in your git config
that specifies a name for a particular URL.

git clone

creates a new git repository
by copying an existing one located at the URI.

git add
adds file changes in your existing directory
to your index.

Command Description Example
STAGING CHANGES
git add [file-name] snapshots [file_name] in preparation for versioning
git add directory-name/\* snapshots directory-name/ in preparation for versioning git add conspects/\*
git add –A = git add ‐‐all add changes from all tracked and untracked files
git add [options] [‐‐] [pathspec]…

-n, ‐‐dry-run dry run
-v, ‐‐verbose be verbose

-i, ‐‐interactive interactive picking
-p, ‐‐patch select hunks interactively
-e, ‐‐edit edit current diff and apply
-f, ‐‐force allow adding otherwise ignored files
-u, ‐‐update update tracked files
‐‐renormalize renormalize EOL of tracked files (implies -u)
-N, ‐‐intent-to-add record only the fact that the path will be added later
-A, ‐‐all add changes from all tracked and untracked files
‐‐ignore-removal ignore paths removed in the working tree (same as ‐‐no-all)
‐‐refresh don’t add, only refresh the index
‐‐ignore-errors just skip files which cannot be added because of errors
‐‐ignore-missing check if – even missing – files are ignored in dry run
‐‐chmod (+|-)x override the executable bit of the listed files

Command Description Example
COMMITTING CHANGES
git commit record file snapshots permanently in file history
launches your editor of choice
remove comments and type your commit message, or you can leave them there to help you remember what you’re committing.
git commit -v record file snapshots permanently in file history
launches your editor of choice
puts the diff of your change in the editor
to see exactly what changes you’re committing.
git commit –m “descriptive message” record file snapshots permanently in file history
with the [descriptive message]
type your commit message inline with the commit command
esc:wq – if forgot [descriptive message]
git commit –a Skip the staging area
automatically stage every file that is already tracked
before doing the commit,
letting you skip the git add part
$ git commit -a -m ‘added new benchmarks’
git show [commit] Outputs metadata and content changes of the specified commit
git reset [file-name] unstages file but preserves its contents

Command Description Example
SYNCRONIZE CHANGES BETWEEN REMOTE (ORIGIN) REPO AND LOCAL (MASTER) BRANCH
git fetch remote fetches from remote repository
all the information remote has
but that you don’t yet have in your repository

downloads the data to your local repository
without modifying your working directory at all
doesn’t automatically merge data with any of your work
lets you merge it yourself.

when you do a fetch that brings down new remote-tracking branches, you don’t automatically have local, editable copies of them. You have only an origin/branch pointer that you can’t modify.

This command looks up which server “origin” is, fetches any data from it that you don’t yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position.

You have to merge this work manually into your current working branch by git merge origin/branch.

git fetch origin
fetches any new work that has been pushed to server since you cloned (or last fetched from) it.

$ git fetch pb
Paul’s master branch is now accessible locally as pb/master — you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it.

Command Description Example
SYNCRONIZE CHANGES BETWEEN REMOTE (ORIGIN) REPO AND LOCAL (MASTER) BRANCH
git pull Downloads bookmark history from the server you originally cloned from
and merges it into the code you’re currently working on.

It is essentially a git fetch immediately followed by a git merge in most cases.

If you have a tracking branch set up
either by explicitly setting it
or by having it created for you
by the clone or checkout commands

git pull will look up
what server and branch your current branch is tracking,
fetch from that server
and then try to merge in that remote branch.

Git clone automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from.

Generally it’s better to simply use the fetch and merge commands explicitly as the magic of git pull can often be confusing.

git push remote branch

git push remote branch-name1:branch-name2
push a local branch into a remote branch that is named differently

Uploads all local/master branch commits to remote/origin server

works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.

If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected.

You’ll have to fetch their work first and incorporate it into yours before you’ll be allowed to push.

$ git push origin serverfix
push up branch named serverfix that you want to work on with others

git push origin serverfix:awesomebranch
pushes your local serverfix branch to the awesomebranch branch on the remote project

Git push updates remote refs along with associated objects.

Command Description Example
SYNCRONIZE CHANGES BETWEEN REMOTE (ORIGIN) REPO AND LOCAL (MASTER) BRANCH
git push
git push remote branch

git push remote branch-name1:branch-name2
push a local branch into a remote branch that is named differently

Uploads all local/master branch commits to remote/origin server

works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.

If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected.

You’ll have to fetch their work first and incorporate it into yours before you’ll be allowed to push.

$ git push origin serverfix
push up branch named serverfix that you want to work on with others

git push origin serverfix:awesomebranch
pushes your local serverfix branch to the awesomebranch branch on the remote project

git rm
is used to remove the file from the staging area and also off your disk.

Command Description Example
DELETE FILES
git rm [-f] [files or directories or file-glob patterns] Deletes the file from the working directory and stages the deletion

If you simply remove the file from your working directory, it shows up under the “Changes not staged for commit” (that is, unstaged) area of your git status output.

To remove a file from Git,
you have to remove it from your tracked files
(more accurately, remove it from your staging area)
and then commit.

Git rm removes the file from your working directory so you don’t see it as an untracked file the next time around.

The next time you commit, the file will be gone and no longer tracked. If you modified the file or had already added it to the staging area, you must force the removal with the -f option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.

$ git rm –cached README

$ git rm log/\*.log
removes all files that have the .log extension in the log/ directory.

$ git rm \*~
This command removes all files whose names end with a ~.

git rm ‐‐cached [file] Keep the file in your working tree (locally on your hard drive) but remove it from your staging area (do not have Git track it anymore)

To see a commit history, use git log:

git log [option] [output limitations]

Git log allows to find specific commits in your project history:

  1. by author,
  2. date,
  3. content
  4. or history
Command Description Example
COMMIT HISTORY
git log Lists version history for the current branch
lists each commit with its SHA-1 checksum,
the author’s name and email,
the date written,
and the commit message.

By default, with no arguments,
git log lists the commits
made in that repository
in reverse chronological order
(most recent commits first).

git status
shows the difference between the working directory and the index,
it is helpful in understanding a git more comprehensively.

Command Description Example
CHECKING CHANGES
git status Checks the status of your files
list all new or modified files to be committed
tells which branch you’re on
informs if local branch (master) has diverged from the same branch on the server (origin)
git status -s
git status ‐‐short
short status flag
shows changes in a more compact way

git diff
shows the changes between commits, commit and working tree etc.

Command Description Example
CHECKING CHANGES
git diff Compares what is in your working directory with what is in your staging area.
Shows changes made but not yet staged.
git diff ‐‐staged
= git diff ‐‐cached
compares your staged changes to your last commit
Shows what you have staged that will go into your next commit.

It’s important to note that git diff by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. If you’ve staged all of your changes, git diff will give you no output.

git diff ‐‐name-only ‐‐cached Git list of staged files
git diff [branch1]…[branch2] Shows content differences between two branches

‘git diff’ is similar to ‘git status’,
but it shows the differences between various commits
and also between the working directory and index.

git checkout
is used to update directories or specific files in your working tree
with those from another branch
without merging it in the whole branch.

Command Description Example
UNDO CHANGES UNDO CHANGES IN THE WORKING DIRECTORY (NOT INDEXED, NOT COMMITED)
git checkout ‐‐file-name Unmodifying a modified file (previously added to git)
discard changes in working directory

If you don’t want to keep the changes to the files,
you can revert it back to what it looked like when you last committed

Dangerous command – any local changes you made to that file are gone — Git just replaced that file with the most recently-committed version. Anything that is committed in Git can almost always be recovered.

If you would like to keep the changes made to file but still need to get it out of the way for now, Git Branching is better way to go.

$ git checkout ‐‐ CONTRIBUTING.md
git checkout . Unmodify everything within the directory (previously added to git)
TRACK BRANCHES
git checkout branch-name switch to an existing branch
(moves HEAD [from master] to point to the branch-name).

Changes in new branch
will diverge from master branch of the project
so you can go in a different direction.

Changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready.

Switching branches changes files in your working directory.
If you switch to an older branch,
your working directory will be reverted
to look like it did the last time
you committed on that branch.

If your working directory or staging area
has uncommitted changes
that conflict with the branch you’re checking out,
Git won’t let you switch branches.
It’s best to have a clean working state
when you switch branches.
There are ways to get around this
(namely, stashing and commit amending).

git checkout testing
switch to branch named testing

git checkout master
switch to master branch
moves the HEAD pointer back to point to the master branch, puts files in working directory to snapshot that master points to.

git checkout ‐‐track remote/branch
= git checkout branch
set up tracking branches if you wish 
— ones that track branches on other remotes,
or don’t track the master branch.
$ git checkout ‐‐track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch ‘serverfix’

Same as

$ git checkout serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch ‘serverfix’

git checkout -b new-branch-name Creates a new branch
and switch to that new branch at the same time 
$ git checkout -b iss53
This is shorthand for:
$ git branch iss53
$ git checkout iss53
git checkout -b branch remote/branch

git checkout -b branch-name2 remote/branch-name1
sets up a local branch
with a different name than the remote branch

Creates a new branch
based off your remote-tracking branch
and switch to that new branch at the same time.

Checking out a local branch from a remote-tracking branch automatically creates what is called a “tracking branch” (and the branch it tracks is called an “upstream branch”).

Tracking branches are local branches that have a direct relationship to a remote branch.

If you’re on a tracking branch and type git pull, Git automatically knows which server to fetch from and which branch to merge in.

$ git checkout -b serverfix origin/serverfix

Create your own serverfix branch that you can work on, based off your remote-tracking branch
This gives you a local branch that you can work on that starts where origin/serverfix is

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch ‘sf’
Now, your local branch sf will automatically pull from origin/serverfix.

The function of ‘git reset’
is to reset your index
as well as the working directory
to the state of your last commit.

Command Description Example
UNDO CHANGES IN STAGING AREA/INDEX (INDEXED, NOT COMMITTED)
git reset ‐‐ file.txt Undoes last commit for file.txt preserving changes locally
UNDO CHANGES IN LOCAL BRANCH (INDEXED, COMMITTED)
git reset HEAD file-name unstages a file from being committed in the upcoming commit $ git reset HEAD CONTRIBUTING.md
Unstages changes after reset to CONTRIBUTING.md file
git reset HEAD^^
git reset HEAD~2
unstages last two commits (in local branch, not yet pushed to remote)
Number of caret signs (^) or a number after a tilda (~)represents the number of commits
git reset HEAD^^
git reset HEAD~2
Remove the last two commits from the local branch
git reset ‐‐soft HEAD^
git reset HEAD~1
unstage one commit preserving changes locally
(in local branch, not yet pushed to remote)
(return to “indexed”/”staged” state)
git reset HEAD^^
git reset HEAD~2
Remove the last two commits from the local branch
DIFFERENT KINDS OF RESET
git reset ‐‐soft Undo commit, preserving changes locally
(return to “indexed”/”staged” state)
git reset
same as git reset ‐‐mixed
Undoes all commits, preserving changes locally
(return to “not indexed”/”not staged” state)
git reset [commit] Undoes all commits afer [commit], preserving changes locally
git reset ‐‐hard Discards all history (without preserving changes locally)
Can not be undone.
git reset ‐‐hard [commit] Discards all history and changes back to the specified commit

Git reset can be a dangerous command,
especially if you provide the ‐‐hard flag

Git Branching

The purpose of branching in GIT
is that you can create your own branch
and jump between those branches.

It will allow you to go to your previous work
keeping your recent work intact.

Feature-Branch Workflow

The common way of creating branch in GIT
is to maintain one as “Main“ branch
and create another branch to implement new features.

This pattern is particularly useful
when there are multiple developers working on a single project.

  1. Centralized Workflow
  2. Feature-Branch Workflow
  3. Gitflow
  4. Integration-Manager Workflow
  5. Dictator and Lieutenants Workflow
  6. Forking Workflow

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

To bring a new feature into the main branch,
you can use a “git merge” or “git pull command”.

Command Description Example
INTEGRATE CHANGES: MERGE
git merge branch-name Combines branch-name’s history into the current branch

Recursive merge: Git performs a three-way merge
between the two latest branch snapshots
and the most recent common ancestor of the two,
creating a new snapshot (and commit).

Fast-forward merge: when merging 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.

Because we’re recording the parents when we commit,
finding a proper merge base for merging
is automatically done for us
and is generally very easy to do.
This encourages developers to use branches often.

$ git checkout master
Switched to branch ‘master’
$ git merge iss53

git merge master

git merge hotfix

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)

git branch ——merged

lists the branches that have been merged into the current branch

git branch ——no merged

lists the branches that have not been merged

Read more about git branch >>>

“Rebasing” is an alternative to merging in git.

git rebase [new-commit]
Command Description Example
INTEGRATE CHANGES: REBASE
$ git rebase base-branch-name Takes all the changes
that were committed on one branch
and replay them on a different branch.

Now you will be able to do a fast-forward merge.

Never rebase commits that exist outside your repository and people may have based work on them.

Rebasing makes for a cleaner history.
If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.

This operation works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.

$ git checkout experiment
$ git rebase master
check out the experiment branch,
and then rebase it onto the master branch

At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment

$ git rebase –onto branch1 branch2 branch3

Now you can fast-forward branch1

$ git rebase –onto master server client

Take the client branch,
figure out the patches
since it diverged from the server branch,
and replay these patches in the client branch
as if it was based directly off the master branch instead.

Now you can fast-forward your master branch
$ git checkout master
$ git merge client

Once your development branch is merged into the main branch,
you no longer need the development branch.

To delete a branch use, the command

git branch –d [head]
Command Description Example
DELETE LOCAL BRANCHES
git branch -d branch-name Deletes the specified branch $ git branch -d hotfix
git branch -D branch-name Force-deletes the specified branch $ git branch -D hotfix
DELETING REMOTE BRANCHES
git remote remove branch-name

git remote rm branch-name

Removes a remote
all remote-tracking branches and configuration settings associated with that remote are also deleted.
$ git remote remove paul
git push origin ‐‐delete branch-name Deletes a remote branch

Basically all this does is remove the pointer from the server.
The Git server will generally keep the data there for a while
until a garbage collection runs,
so if it was accidentally deleted,
it’s often easy to recover.

$ git push origin ‐‐delete serverfix

Git Stasging

Git Stash

Git stash
takes the current state
of the working directory and index
and puts in on the stack for later
and gives you back a clean working directory.

So in case if you are in the middle of something
and need to jump over to the other job,
and at the same time you don’t want to lose your current edits
then you can use Git stash.

When you want to continue working where you have left your work, ‘git stash apply’ command is used to bring back the saved changes onto the working directory.

Command Description Example
BRING STASH BACK AND LEAVE IN STASH
git stash apply Bring stash back and leave in stash

Command Description Example
BRING STASH BACK AND REMOVE FROM STASH
git stash pop Bring stash back
and remove from stash

When you are done with the stashed item
or want to remove it from the list,
git stash drop command
will remove the last added stash item by default,

It can also remove a specific item
if you include it as an argument.


Sources: Pro Git book by Scott Chacon and Ben Straub, EPAM, career.guru99.com


Leave a Reply or Comment

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