What is BitBucket
Bitbucket is a version control solution developed by Atlassian. It provides access restrictions to the source code and project workflows. The in-class Jira and Trello integrations of Bitbucket are used to bring the complete software team together to work on the Project.
Version Control System
A Version Control System is also called a source control or revision control system. It is a software application that traces and handles modifications to a file system. The VCS also provides some interactive applications that exchange and integrate these modifications with other VCS users. A VCS will trace all the additions, modifications, and deletions implemented on a file system.
BitBucket Terminology
1. Branch
The branch is a generalization for the operations like a stage, edit, and commit process. It is considered a new approach to request a new working directory.
2. Fork
Generally, a single server-side repository acts as a central repository, but a fork provides a server-side repository to every developer. So, every developer will contribute to a server-side repository.
3. Pipes
To perform strong operations, we put some code parts into our pipelines, and they are known as Bitbucket Pipes. Pipes are useful in building strong and automated workflows.
4. Bitbucket Pipelines
Bitbucket Pipelines is an incorporated CI/CD Service, made into Bitbucket. It enables you to develop, test automatically, and further deploy the code, according to the configuration file present in the repository.
5. Head
The Head is used to refer to the current snapshot. The git checkout upgrades the HEAD to refer to either a commit or a particular branch.
6. Master
Every time you create a repository, a default branch called Master is created, and automatically it becomes a working branch.
7. Pull request
Pull request is a feature provided by Bitbucket, and developers use it for interaction purposes. Developers use this tool to address the proposed changes before incorporating them into the Project.
8. Working Tree
The working tree is defined as a tree of existing checkout files. Generally, it contains HEAD Commit's tree contents and changes you have done but not saved.
9. Project
A project is considered a container for repositories. By arranging repositories into projects, the Project makes it easy for the team to emphasize on product, goal, or process.
BitBucket Pipelines
As we discussed earlier, bitbucket pipelines is an incorporated CI/CD service. It enables us to develop, test, and further deploy the code. Containers are created in the cloud to execute the commands. The clouds are configured based on our requirements.
To establish the pipeline, we need to configure and create the bitbucket-pipelines.yaml file in the root directory of our repository. This file is versioned using configuration-as-code, and it is synchronized with our code.
The Bitbucket-Pipelines.yaml contains the configuration of our repository. Yaml is the file repository that is easy to read, but we should be careful while developing it. The important keywords used in the Bitbucket-pipeline.yaml file is as follows:
i) Default: It includes the steps that need to be executed for every push.
ii) Script: Script contains a list of commands that need to be executed in order.
iii)Pipelines: It includes pipeline definitions.
iv)Step: Each step initiates a new docker container.
How to use BitBucket step by step
1. To start the Version control system Project in Bitbucket, we need to create a project, and then it groups several repositories. Log into BitBucket and click on create Project present in the Project tab.
2. After creating the Project, click on the "+" symbol to create a repository.
3. After creating a new repository, we have to follow the below instructions to clone the Git repository to a local machine.
· In the repository, click the clone button, and then BitBucket shows clone this repository dialog.
· Copy the clone command and then select the directory where you want to clone the repository.
· After that, we should create a branch. For creating a branch, we will click on the branches button, and we will see one branch called "Master" is active. Click on the Create branch present in the right-side corner.
· Make some changes to the branch as per your requirement.
4. After cloning the repository to the local machine, we will add the files to the repository.
Pull Request
After the software is delivered, some defects or improvements will be suggested, and the developer's team has to integrate them. When developers have to integrate the improvements, they should take feedback from stakeholders.
So developers will create a bugfix branch to do the required fixes and create a pull request to notify all the reviewers regarding bug fixes and ask them to review to integrate the changes.
Steps for creating a Pull request
· Step1) A defect is reported. Now the developer will create a bugfix branch for making the required changes for fixing the defect and pushes the modifications to the repository.
· Step2) Now the bugfix branch exists in the Bitbucket repository.
· Step3) Before changes are integrated into the master repository, they should be reviewed by the stakeholders. For that purpose, the developer should create a pull request.
· Step4) we will create a pull request by clicking on the create pull request button. In the Pull Request, Bugfix is selected as the source branch.
· Step5) Now the reviewers are assigned to the default reviewers list.
· Step6: Now the reviewers log in to their account, and they will review the submitted changes.
· Step7) If the changes are essential, they will approve of them.
· Step8) Now the developer will log in as the user who created the pull request. They will integrate the approved changes into the master repository.
Fork Repository
In Bitbucket, the Fork repository is a method to clone the complete repository for creating a new copy to the repository. It is considered an experiment to conduct testing without troubling the initial repository.
BitBucket Markdown
Every Project has to keep some documentation to have data regarding releases or requirements or any other information about the Project.
So, the project team should assure that the project documentation should have a standard format. BitBucket uses Markdown to format the documentation file called Readme.md and ".md" is the file extension.
Advantages of BitBucket
1. BitBucket Provides Unlimited private repositories.
2. Bitbucket gives financial support to private support.
3. BitBucket supports continuous integration.
4. BitBucket can easily integrate with Jira and Trello.
5. We can create an issue tracker in our Git Repository.
Git VS BitBucket
Conclusion
The software development teams use bitBucket for CI/CD service. Through Bitbucket, we can clone the git repository for integrating the post-delivery changes. In DevOps practices, we can use BitBucket along with the Git tool.
Now that we’ve covered the mechanics behind Git branches, we can discuss the practical impact that they have on the software development process. Instead of introducing new commands, this module covers how the typical Git user applies this workflow to real projects, as well as some of the problems that arise in a branched environment.
The software development teams use bitBucket for CI/CD service. Through Bitbucket, we can clone the git repository for integrating the post-delivery changes. In DevOps practices, we can use BitBucket along with the Git tool.
Now that we’ve covered the mechanics behind Git branches, we can discuss the practical impact that they have on the software development process. Instead of introducing new commands, this module covers how the typical Git user applies this workflow to real projects, as well as some of the problems that arise in a branched environment.
To Git, a branch is a branch, but it’s often useful to assign special meaning to different branches. For example, we’ve been using a master as a stable branch for our example project, and we’ve also used a temporary branch to add some CSS formatting. Temporary branches like the latter are called topic branches because they exist to develop a certain topic, then they are deleted. We’ll work with two types of topic branches later in this module.
Amid our exploration of Git branches, we’ll also discover that some merges cannot be “fast-forwarded.” When the history of two branches diverges, a dedicated commit is required to combine the branches. This situation may also give rise to a merge conflict, which must be manually resolved before anything can be committed to the repository.
DOWNLOAD THE REPOSITORY FOR THIS MODULE
If you’ve been following along from the previous module, you already have everything you need. Otherwise, download the zipped Git repository from the above link, uncompress it, and you’re good to go.
If you’ve been following along from the previous module, you already have everything you need. Otherwise, download the zipped Git repository from the above link, uncompress it, and you’re good to go.
Continue the Crazy Experiment
Let’s start by checking out the crazy branch.
git branch git checkout crazy git log --oneline
The crazy branch is a longer-running type of topic branch called a feature branch. This is fitting, as it was created with the intention of developing a specific feature. It’s also a term that makes Git’s contribution to the development workflow readily apparent: branches enable you to focus on developing one clearly defined feature at a time.
This brings us to my rule-of-thumb for using Git branches:
Note that the CSS formatting we merged into master is nowhere to be found. This presents a bit of a problem if we want our experiment to reflect these updates. Conveniently, Git lets us merge changes into any branch (not just the master branch). So, we can pull the updates in with the familiar git merge command. Remember that merging only affects the checked-out branch.
The crazy branch is a longer-running type of topic branch called a feature branch. This is fitting, as it was created with the intention of developing a specific feature. It’s also a term that makes Git’s contribution to the development workflow readily apparent: branches enable you to focus on developing one clearly defined feature at a time.
This brings us to my rule-of-thumb for using Git branches:
- Create a new branch for each major addition to your project.
- Don’t create a branch if you can’t give it a specific name.
Note that the CSS formatting we merged into master is nowhere to be found. This presents a bit of a problem if we want our experiment to reflect these updates. Conveniently, Git lets us merge changes into any branch (not just the master branch). So, we can pull the updates in with the familiar git merge command. Remember that merging only affects the checked-out branch.
git merge master git log --oneline
As of Git 1.7.10, this will open your editor and prompt you for a message explaining why the commit was necessary. You can use the default Merge branch ‘master’ into crazy. When you save and close the file, you’ll notice an extra commit in your project history. Recall that our first merge didn’t add any new commits; it just “fast-forwarded” the tip of the master branch. This was not the case for our new merge, which is shown below.
Take a moment to examine why the current merge couldn’t be a fast-forward one. How could Git have walked the crazy pointer over to the tip of the master branch? It’s not possible without backtracking, which kind of defeats the idea of “fast-forwarding.” We’re left with a new way to combine branches: the 3-way merge.
As of Git 1.7.10, this will open your editor and prompt you for a message explaining why the commit was necessary. You can use the default Merge branch ‘master’ into crazy. When you save and close the file, you’ll notice an extra commit in your project history. Recall that our first merge didn’t add any new commits; it just “fast-forwarded” the tip of the master branch. This was not the case for our new merge, which is shown below.
Take a moment to examine why the current merge couldn’t be a fast-forward one. How could Git have walked the crazy pointer over to the tip of the master branch? It’s not possible without backtracking, which kind of defeats the idea of “fast-forwarding.” We’re left with a new way to combine branches: the 3-way merge.
A 3-way merge occurs when you try to merge two branches whose history has diverged. It creates an extra merge commit to function as a link between the two branches. As a result, it has two parent commits. The above figure visualizes this with two arrows originating from the tip of a crazy. It’s like saying “this commit comes from both the crazy branch and from a master.” After the merge, the crazy branch has access to both its history and master history.
The name comes from the internal method used to create the merge commit. Git looks at three commits (numbered in the above figure) to generate the final state of the merge.
This kind of branch interaction is a big part of what makes Git such a powerful development tool. We can not only create independent lines of development, but we can also share information between them by tying together their histories with a 3-way merge.
Style the Rainbow Page
Now that we have access to the CSS updates from the master, we can continue developing our crazy experiment. Link the CSS stylesheet to rainbow.html by adding the following HTML on the line after the element.
Stage and commit the update, then check that it’s reflected in the history.
Now that we have access to the CSS updates from the master, we can continue developing our crazy experiment. Link the CSS stylesheet to rainbow.html by adding the following HTML on the line after the element.
Stage and commit the update, then check that it’s reflected in the history.
git status git commit -a -m "Add CSS stylesheet to rainbow.html" git log --oneline
Notice that we skipped the staging step this time around. Instead of using git add, we passed the -a flag to git commit. This convenient parameter tells Git to automatically include all tracked files in the staged snapshot. Combined with the flag, we can stage and commit snapshots with a single command. However, be careful not to include unintended files when using the -a flag.
Link to the Rainbow Page
We still need to add a navigation link to the home page. Change the “Navigation” section of index.html to the following.
Notice that we skipped the staging step this time around. Instead of using git add, we passed the -a flag to git commit. This convenient parameter tells Git to automatically include all tracked files in the staged snapshot. Combined with the flag, we can stage and commit snapshots with a single command. However, be careful not to include unintended files when using the -a flag.
Link to the Rainbow Page
We still need to add a navigation link to the home page. Change the “Navigation” section of index.html to the following.
Navigation
Fork an Alternative Rainbow
Next, we’re going to brainstorm an alternative to the current rainbow.html page. This is a perfect time to create another topic branch:
- The Orange Page (orange.html)
- The Blue Page (blue.html)
- The Rainbow Page (rainbow.html)
Fork an Alternative Rainbow
Next, we’re going to brainstorm an alternative to the current rainbow.html page. This is a perfect time to create another topic branch:
git branch crazy-alt git checkout crazy-alt
Remember, we can do whatever we want here without worrying about either crazy or master. When the git branch creates a branch, it uses the current HEAD as the starting point for the new branch. This means that we begin with the same files as crazy (if we called the git branch from master, we would have had to re-create rainbow.html). After creating the new branch, our repository’s history looks like this:
Emergency Update!
Our boss called in with some breaking news! He needs us to update the site immediately, but what do we do with our rainbow.html developments? Well, the beauty of Git branches is that we can just leave them where they are and add the breaking news to master.
We’ll use what’s called a hotfix branch to create and test the news updates. In contrast to our relatively long-running feature branch (crazy), hotfix branches are used to quickly patch a production release. For example, you’d use a hotfix branch to fix a time-sensitive bug in a public software project. This distinction is useful for demonstrating when it’s appropriate to create a new branch, but it is purely conceptual—a branch is a branch according to Git.
Remember, we can do whatever we want here without worrying about either crazy or master. When the git branch creates a branch, it uses the current HEAD as the starting point for the new branch. This means that we begin with the same files as crazy (if we called the git branch from master, we would have had to re-create rainbow.html). After creating the new branch, our repository’s history looks like this:
Emergency Update!
Our boss called in with some breaking news! He needs us to update the site immediately, but what do we do with our rainbow.html developments? Well, the beauty of Git branches is that we can just leave them where they are and add the breaking news to master.
We’ll use what’s called a hotfix branch to create and test the news updates. In contrast to our relatively long-running feature branch (crazy), hotfix branches are used to quickly patch a production release. For example, you’d use a hotfix branch to fix a time-sensitive bug in a public software project. This distinction is useful for demonstrating when it’s appropriate to create a new branch, but it is purely conceptual—a branch is a branch according to Git.
git checkout master git branch news-hotfix git checkout news-hotfix
Change the “News” list in index.html
Change the “News” list in index.html
News
And, create a new HTML page called news-1.html
And, create a new HTML page called news-1.html
Blue Is The New Hue
Blue Is The New Hue
European designers have just announced that Blue will be this year's hot color.
Return to the home page (index.html)
We can’t use git commit -a to automatically stage news-1.html because it’s an untracked file (as shown in git status). So, let’s use an explicit git add: git add index.html news-1.html git status git commit -m "Add 1st news item"
Test these additions in a browser to make sure that the links work, it’s typo-free, etc. If everything looks good, we can “publish” the changes by merging them into the stable master branch. Isolating this in a separate branch isn’t really necessary for our trivial example, but in the real world, this would give you the opportunity to run build tests without touching your stable project.
Publish the News Hotfix
Remember that to merge into the master branch, we first need to check it out. git checkout master git merge news-hotfix
Since master now contains the news update, we can delete the hotfix branch: git branch -d news-hotfix git branch
The following diagram reflects our repository’s history before and after the merge. Can you figure out why was this a fast-forward merge instead of a 3-way merge?
Also notice that we have another fork in our history (the commit before master branches in two directions), which means we should expect to see another merge commit in the near future.
Complete the Crazy Experiment
Ok, let’s finish up our crazy experiment with one more commit. git checkout crazy
Note that the news article is nowhere to be found, as should be expected (this branch is a completely isolated development environment).
We’ll finish up our crazy experiment by adding a news item for it on the home page. Change the news list in index.html.
News
Our New Rainbow (rainbow.html)
Astute readers have probably observed that this directly conflicts with what we changed in the news-hotfix branch. We should not manually add in the other news item because it has no relationship with the current branch. In addition, there would be no way to make sure the link works because news-1.html doesn’t exist in this branch. This may seem trivial, but imagine the errors that could be introduced had news-hotfix made dozens of different changes.
We’ll simply stage and commit the snapshot as if there were no conflicts: git commit -a -m "Add news item for the rainbow" git log --oneline
Look at all those experimental commits (marked with asterisks below)! *42fa173 Add news item for rainbow *7147cc5 Link index.html to rainbow.html *6aa4b3b Add CSS stylesheet to rainbow.html b9ae1bc Merge branch 'master' into crazy ae4e756 Link HTML pages to stylesheet 98cd46d Add CSS stylesheet *33e25c9 Rename crazy.html to rainbow.html *677e0e0 Add a rainbow to crazy.html 506bb9b Revert "Add a crazzzy experiment" *514fbe7 Add a crazzzy experiment 1c310d2 Add navigation links 54650a3 Create blue and orange pages b650e4b Create index page
Publish the Crazy Experiment
We’re finally ready to merge our crazy branch back into master. git checkout master git merge crazy
You should get a message that reads: Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
This is our first merge conflict. Conflicts occur when we try to merge branches that have edited the same content. Git doesn’t know how to combine the two changes, so it stops asking us what to do. We can see exactly what went wrong with the familiar git status command: # On branch master # Changes to be committed: # # new file: rainbow.html # # Unmerged paths: # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: index.html #
We’re looking at the staged snapshot of a merge commit. We never saw this with the first 3-way merge because we didn’t have any conflicts to resolve. But now, Git stopped to let us modify files and resolve the conflict before committing the snapshot. The “Unmerged paths” section contains files that have a conflict.
Open up index.html and find the section that looks like <<<<<<< HEAD
Blue Is The New Hue (news-1.html)
=======
Our New Rainbow (rainbow.html)
>>>>>>> crazy
Git went ahead and modified the conflicted file to show us exactly which lines are afflicted. The format of the above text shows us the difference between the two versions of the file. The section labeled <<<<<<< HEAD shows us the version in the current branch, while the part after the ======= shows the version in the crazy branch.
Resolve the Merge Conflicts
We can change the affected lines to whatever we want in order to resolve the conflict. Edit the news section of index.html to keep changes from both versions:
News
Blue Is The New Hue (news-1.html)
Our New Rainbow (rainbow.html)
The <<<<<<<, =======, and >>>>>>> markers are only used to show us the conflict and should be deleted. Next, we need to tell Git that we’re done resolving the conflict: git add index.html git status
That’s right, all you have to do is add index.html to the staged snapshot to mark it as resolved. Finally, complete the 3-way merge: git commit
We didn’t use the -m flag to specify a message because Git already gives us a default message for merge commits. It also gives us a “Conflicts” list, which can be particularly handy when trying to figure out where something went wrong in a project. Save and close the file to create the merge commit.
The final stage of our project looks like the following.
Cleanup the Feature Branches
Since our crazy experiment has been successfully merged, we can get rid of our feature branches. git branch -d crazy git branch -d crazy-alt
As noted in the last module, the git branch -d command won’t let you delete a branch that contains unmerged changes. But, we really do want to scrap the alternative experiment, so we’ll follow the error message’s instructions for overriding this behavior: git branch -D crazy-alt
Because we never merged crazy-alt into master, it is lost forever. However, the crazy branch is still accessible through its commits, which are now reachable via the master branch. That is to say, it is still part of the structure of the repository’s history, even though we deleted our reference to it.
Fast-forward merges are not reflected in the project history. This is the tangible distinction between fast-forward merges and 3-way merges. The next module will discuss the appropriate usage of both and the potential complications of non-linear history.
GIT Interview Questions And Answers
1) What is GIT and What are its advantages?
A) Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
2) What is the relationship between GIT and SCM tools?
A) SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
3) Can you explain Branching and Merging in GIT?
A) The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.
Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.
4) How do you rate GIT in terms of speed?
A) Git is fast. Speed and performance have been a primary design goal of Git from the start. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.
Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages.
5) What is a pull in git?
A) git-pull - Fetch from and integrate with another repository or a local branch
SYNOPSIS: git pull [options] [ […?]]
In its default mode, git pull is shorthand for git fetches followed by git merge FETCH_HEAD. More precisely, git pull runs git fetch with the given parameters and call git merge to merge the retrieved branch heads into the current branch. should be the name of a remote repository as passed to git-fetch
6) What does git commit a?
A) Basically, git commit "records changes to the repository" while git push "updates remote refs along with associated objects". So the first one is used in connection with your local repository, while the latter one is used to interact with a remote repository.
7) Why do you use GIT?
A) Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development but it can be used to keep track of changes in any set of files.
Interview Questions on GIT
Blue Is The New Hue
European designers have just announced that Blue will be this year's hot color.
Return to the home page (index.html)
We can’t use git commit -a to automatically stage news-1.html because it’s an untracked file (as shown in git status). So, let’s use an explicit git add: git add index.html news-1.html git status git commit -m "Add 1st news item"
Test these additions in a browser to make sure that the links work, it’s typo-free, etc. If everything looks good, we can “publish” the changes by merging them into the stable master branch. Isolating this in a separate branch isn’t really necessary for our trivial example, but in the real world, this would give you the opportunity to run build tests without touching your stable project.
Publish the News Hotfix
Remember that to merge into the master branch, we first need to check it out. git checkout master git merge news-hotfix
Since master now contains the news update, we can delete the hotfix branch: git branch -d news-hotfix git branch
The following diagram reflects our repository’s history before and after the merge. Can you figure out why was this a fast-forward merge instead of a 3-way merge?
Also notice that we have another fork in our history (the commit before master branches in two directions), which means we should expect to see another merge commit in the near future.
Complete the Crazy Experiment
Ok, let’s finish up our crazy experiment with one more commit. git checkout crazy
Note that the news article is nowhere to be found, as should be expected (this branch is a completely isolated development environment).
We’ll finish up our crazy experiment by adding a news item for it on the home page. Change the news list in index.html.
News
Our New Rainbow (rainbow.html)
Astute readers have probably observed that this directly conflicts with what we changed in the news-hotfix branch. We should not manually add in the other news item because it has no relationship with the current branch. In addition, there would be no way to make sure the link works because news-1.html doesn’t exist in this branch. This may seem trivial, but imagine the errors that could be introduced had news-hotfix made dozens of different changes.
We’ll simply stage and commit the snapshot as if there were no conflicts: git commit -a -m "Add news item for the rainbow" git log --oneline
Look at all those experimental commits (marked with asterisks below)! *42fa173 Add news item for rainbow *7147cc5 Link index.html to rainbow.html *6aa4b3b Add CSS stylesheet to rainbow.html b9ae1bc Merge branch 'master' into crazy ae4e756 Link HTML pages to stylesheet 98cd46d Add CSS stylesheet *33e25c9 Rename crazy.html to rainbow.html *677e0e0 Add a rainbow to crazy.html 506bb9b Revert "Add a crazzzy experiment" *514fbe7 Add a crazzzy experiment 1c310d2 Add navigation links 54650a3 Create blue and orange pages b650e4b Create index page
Publish the Crazy Experiment
We’re finally ready to merge our crazy branch back into master. git checkout master git merge crazy
You should get a message that reads: Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
This is our first merge conflict. Conflicts occur when we try to merge branches that have edited the same content. Git doesn’t know how to combine the two changes, so it stops asking us what to do. We can see exactly what went wrong with the familiar git status command: # On branch master # Changes to be committed: # # new file: rainbow.html # # Unmerged paths: # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: index.html #
We’re looking at the staged snapshot of a merge commit. We never saw this with the first 3-way merge because we didn’t have any conflicts to resolve. But now, Git stopped to let us modify files and resolve the conflict before committing the snapshot. The “Unmerged paths” section contains files that have a conflict.
Open up index.html and find the section that looks like <<<<<<< HEAD
Blue Is The New Hue (news-1.html)
=======
Our New Rainbow (rainbow.html)
>>>>>>> crazy
Git went ahead and modified the conflicted file to show us exactly which lines are afflicted. The format of the above text shows us the difference between the two versions of the file. The section labeled <<<<<<< HEAD shows us the version in the current branch, while the part after the ======= shows the version in the crazy branch.
Resolve the Merge Conflicts
We can change the affected lines to whatever we want in order to resolve the conflict. Edit the news section of index.html to keep changes from both versions:
News
Blue Is The New Hue (news-1.html)
Our New Rainbow (rainbow.html)
The <<<<<<<, =======, and >>>>>>> markers are only used to show us the conflict and should be deleted. Next, we need to tell Git that we’re done resolving the conflict: git add index.html git status
That’s right, all you have to do is add index.html to the staged snapshot to mark it as resolved. Finally, complete the 3-way merge: git commit
We didn’t use the -m flag to specify a message because Git already gives us a default message for merge commits. It also gives us a “Conflicts” list, which can be particularly handy when trying to figure out where something went wrong in a project. Save and close the file to create the merge commit.
The final stage of our project looks like the following.
Cleanup the Feature Branches
Since our crazy experiment has been successfully merged, we can get rid of our feature branches. git branch -d crazy git branch -d crazy-alt
As noted in the last module, the git branch -d command won’t let you delete a branch that contains unmerged changes. But, we really do want to scrap the alternative experiment, so we’ll follow the error message’s instructions for overriding this behavior: git branch -D crazy-alt
Because we never merged crazy-alt into master, it is lost forever. However, the crazy branch is still accessible through its commits, which are now reachable via the master branch. That is to say, it is still part of the structure of the repository’s history, even though we deleted our reference to it.
Fast-forward merges are not reflected in the project history. This is the tangible distinction between fast-forward merges and 3-way merges. The next module will discuss the appropriate usage of both and the potential complications of non-linear history.
GIT Interview Questions And Answers
1) What is GIT and What are its advantages?
A) Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
2) What is the relationship between GIT and SCM tools?
A) SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
3) Can you explain Branching and Merging in GIT?
A) The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.
Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.
4) How do you rate GIT in terms of speed?
A) Git is fast. Speed and performance have been a primary design goal of Git from the start. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.
Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages.
5) What is a pull in git?
A) git-pull - Fetch from and integrate with another repository or a local branch
SYNOPSIS: git pull [options] [ […?]]
In its default mode, git pull is shorthand for git fetches followed by git merge FETCH_HEAD. More precisely, git pull runs git fetch with the given parameters and call git merge to merge the retrieved branch heads into the current branch. should be the name of a remote repository as passed to git-fetch
6) What does git commit a?
A) Basically, git commit "records changes to the repository" while git push "updates remote refs along with associated objects". So the first one is used in connection with your local repository, while the latter one is used to interact with a remote repository.
7) Why do you use GIT?
A) Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development but it can be used to keep track of changes in any set of files.
Interview Questions on GIT
8) What is the purpose of Git?
A) The purpose of Git is to manage a project, or a set of files, as they change over time. Git stores this information in a data structure called a repository.
9) What do you mean by git add?
A) git add. adds all modified and new (untracked) files in the current directory and all subdirectories to the staging area (a.k.a. the index), thus preparing them to be included in the next git commit. Any files matching the patterns in the .gitignore file will be ignored by the git add.
10) What is the difference between Git and Github?
A) Git is a revision control system, a tool to manage your source code history.
GitHub is a hosting service for Git repositories.
GitHub is a website where you can upload a copy of your Git repository. It is a Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features.
11) What does a git pull rebase do?
A) git pull --rebase allows you to later squash your commits to a few (or one) commits. If you have merged in your (unpushed) history, it is not so easy to do a git rebase later.
12) What does git pull origin master do?
A) git pull origin master pulls the master branch from the remote called origin into your current branch. It only affects your current branch, not your local master branch.
13) What is the difference between SVN and Git?
A) In short, svn is a Centralized Revision Control System, and git is a Distributed Revision Control System (DVCS).
14) What is a stash in git?
A) Stashing takes the dirty state of your working directory, that is, your modified tracked files and staged changes, and saves it on a stack of unfinished changes that you can reapply at any time.
15) What is git pull origin?
A) pull is a fetch and a merge. * `git pull origin master` fetches commits from the master branch of the origin remote (into the local origin/master branch), and then it merges origin/master into the branch you currently have checked out.
A) The purpose of Git is to manage a project, or a set of files, as they change over time. Git stores this information in a data structure called a repository.
9) What do you mean by git add?
A) git add. adds all modified and new (untracked) files in the current directory and all subdirectories to the staging area (a.k.a. the index), thus preparing them to be included in the next git commit. Any files matching the patterns in the .gitignore file will be ignored by the git add.
10) What is the difference between Git and Github?
A) Git is a revision control system, a tool to manage your source code history.
GitHub is a hosting service for Git repositories.
GitHub is a website where you can upload a copy of your Git repository. It is a Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features.
11) What does a git pull rebase do?
A) git pull --rebase allows you to later squash your commits to a few (or one) commits. If you have merged in your (unpushed) history, it is not so easy to do a git rebase later.
12) What does git pull origin master do?
A) git pull origin master pulls the master branch from the remote called origin into your current branch. It only affects your current branch, not your local master branch.
13) What is the difference between SVN and Git?
A) In short, svn is a Centralized Revision Control System, and git is a Distributed Revision Control System (DVCS).
14) What is a stash in git?
A) Stashing takes the dirty state of your working directory, that is, your modified tracked files and staged changes, and saves it on a stack of unfinished changes that you can reapply at any time.
15) What is git pull origin?
A) pull is a fetch and a merge. * `git pull origin master` fetches commits from the master branch of the origin remote (into the local origin/master branch), and then it merges origin/master into the branch you currently have checked out.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.