Scribd
Upload
55 views3 pages

Git Qa

The document discusses different git branching strategies like GitFlow, GitHub Flow, GitLab Flow and trunk-based development. It also talks about maintaining feature branches, resolving merge conflicts, PR approval process, difference between git pull and fetch. Types of branches used in projects like master, develop, release, hotfix, feature branches are also explained.

Uploaded by

likhithgowdadevops
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
55 views3 pages

Git Qa

The document discusses different git branching strategies like GitFlow, GitHub Flow, GitLab Flow and trunk-based development. It also talks about maintaining feature branches, resolving merge conflicts, PR approval process, difference between git pull and fetch. Types of branches used in projects like master, develop, release, hotfix, feature branches are also explained.

Uploaded by

likhithgowdadevops
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

1 * Git branching strategies

We have multiple branches called master, release, develop, hotfix and feature
branches.
where master is the main branch where we kept our deployed code or the code
currently in production environment,
from master we will create a branch called release and from release we will create
a branch called develop,
developers will be working on the feature branches which got created from develop
branch, once develpoers
completes the coding they will create merge request to develop branch ,
reviewer/approver will review the
code and they merge to develop branch if there is no conflicts, from the develp
branch our CICD job will
get trigger and will deploy to lower environments for testinng from develop
branch, if qa teams reports any bugs,
developers will fix it in the develop branch, once QA team sign ofs with no bugs,
we will merge the code from
develop to release branch and will deploy the code to preprod environment, once
everything is good we will merge the
code to master and will deploy to prod environment and wil create a tags for the
release, if we found any bugs in the
prod environment, we will fix it in the hotfix environment and will merge the code
back to master, release and develop.

2 * From which branch u release to prod


Master Branch
3 * How u maintain branches for different features?
We Create an Features Branches for different features from the Devlopment
Branch.once develpoers
completes the coding they will create merge request to develop
branch.reviewer/approver will review the
code and they merge to develop branch if there is no conflicts

4 * Merge conflict ? How you resolve it ?

5 * PR Approval process ?
6 * Diff between Git pull and git fetch
-7 * Types of branching strategy?-
https://www.abtasty.com/blog/git-branching-strategies/

GitFlow

* The main and develop branches are considered to be the main branches, with an
infinite lifetime,
while the rest are supporting branches that are meant to aid parallel development
among developers, usually short-lived.
* Perhaps the most obvious benefit of this model is that it allows for parallel
development to protect
the production code so the main branch remains stable for release while
developers work on separate branches.
*It is also ideal when handling multiple versions of the production code.

GitHub Flow

* This strategy is particularly suited for small teams and web applications and it
is ideal when you need to maintain a single production version.
* This strategy is not suitable for handling multiple versions of the code.
* You start off with the main branch then developers create branches, feature
branches that stem directly from the master,
to isolate their work which are then merged back into main.The feature branch is
then deleted.

GitLab Flow

* GitLab Flow is a simpler alternative to GitFlow that combines feature-driven


development and feature branching with issue tracking.
* With GitFlow, developers create a develop branch and make that the default while
GitLab Flow works with the main branch right away.
* GitLab Flow is great when you want to maintain multiple environments and when you
prefer to have a staging environment separate from the production environment.
Then, whenever the main branch is ready to be deployed, you can merge back into
the production branch and release it.
* Thus, this strategy offers propers isolation between environments allowing
developers to maintain several versions of software in different environments.

Trunk-based development

* Trunk-based development is a branching strategy that in fact requires no branches


but instead,
developers integrate their changes into a shared trunk at least once a day.
This shared trunk should be ready for release anytime.
* The main idea behind this strategy is that developers make smaller changes more
frequently and thus the goal is to limit long-lasting branches
and avoid merge conflicts as all developers work on the same branch.
In other words, developers commit directly into the trunk without the use of
branches.

8 * Which type branching strategy you are using in your project


We are using Git Flow Branching Strategy.

9* how do you change git remot url to loc al url

git remote set-url origin https://gitlab.com/KodeKloud/repository-1.git(New URL).


why? To Connect to New Remote Repository? Due to Migration in hosting Service or
Switching the Remote Repository

10* git architecture

11* Git merge vs Git rebase

12* Git statsh ?

13* About version control tool


Vesrion Contril Tool is Used to Maintain and Track the Version of the Files and
Directories.
There are Two Type of Version Control Tools centralized and distributed.
Difference in Notes.

14* git statsh drop

15* how to fix broken commit in git


git commit --amend

16* how to check branch name


git branch -a
git branch -vv ->Detailed Information about the Branches.

17* creating branch and merging and push , pulling how you do it.
18* git diff -tree?
git-diff-tree is a git command that compares the content and mode of blobs found
via two tree objects.

19* how u check diff b/w previous & current commit?


git diff current commitid previous commitid.

20* what is git rebase ? why cant u use rebase instead of merge?

-21* what is read.me file?


A README is often the first item a visitor will see when visiting your repository.

README files typically include information on: What the project does. Why the
project is useful. How users can get started with the project.

-22* Git webhooks


Webhooks provide a way for notifications to be delivered to an external web server
whenever certain events occur on GitHub.

-23* Where do you fix bug , vl u create a new branch and later how you manage with
next release

-24* how many repo you have in github

-25* explain all types of branches in your project


master — this branch contains production code. All development code is merged into
master in sometime.

develop — this branch contains pre-production code. When the features are finished
then they are merged into develop.

During the development cycle, a variety of supporting branches are used:

feature-* — feature branches are used to develop new features for the upcoming
releases.
May branch off from develop and must merge into develop.
hotfix-* — hotfix branches are necessary to act immediately upon an undesired
status of master.
May branch off from master and must merge into master anddevelop.
release-* — release branches support preparation of a new production release.
They allow many minor bug to be fixed and preparation of meta-data for a release.
May branch off from develop and must merge into master anddevelop.

-26* How many reviewers are there

-27* what is git rev parse ? whats the use


The “$ git rev-parse” command can be utilized for getting the SHA hashes of
branches or HEAD.
For instance, the “$ git rev-parse HEAD” command can be used to get the HEAD SHA
hash.
The “$ git rev-parse <remote-branch>” command can print the specified branch SHA
hash.
By using the “$ git rev-parse –abbrev-ref HEAD”, users can get the HEAD working
branch.
https://linuxhint.com/what-does-git-rev-parse-do/

You might also like