All commands

Question 1

git clone

Answer 1

Clones a local repository.

Question 2

git clone

Answer 2

Clones a remote repository.

Question 3

Explain git flow.

Answer 3

1. Central repository. 2. Developers work locally and push their branches. 3. Two branches are used to recored project history: master and develop. 4. Develop serves as an integration branch for features. 5. Master brach stores the official release history.

Question 4

Explain how to make a new feature with git flow in mind

Answer 4

1. Pull the latest copy of the develop branch. 2. Make a new feature branch out of the develop branch. 3. Commit your work on your feature branch. 4. When the feature is complete and tested merge back into the develop branch.

Question 5

Explain how to make a release branch with git flow in mind.

Answer 5

1. A (senior) developer makes a release branch out of the develop branch. 2. The release branch has to contain pre-determined amount of features which are ready to be tested. 3. The release branch should be deployed to a Stagin server for the QA testing. 4. Any bugs that are found need to be fixed on the release branch. 5. At the end the release branch in merged back to the develop and also to master. 6. The merge to master should be tagged with the version number. 7. You should never add new features from develop to the relase branch once it was launched. All features that were in develop after the release branch was opened can only be in the next release branch.

Question 6

Explain how to make a hotfix with git flow in mind.

Answer 6

1. Hotfixes are defined as minor fixes to the project which don’t need an entire team to test. 2. Create a hotfix branch out of the master branch. 3. Commit the fix to the hotfix branch. 4. When the hotfix branch is tested in must be merged back in to the master and develop. 5. The master branched shuold be tagged again and then deployed. 6. Hotfix branched should be closed fast and shouldn’t be laying aroud for long.

Question 7

How do you set up the git workflow with git commands?

Answer 7

Initialization

git init

git branch develop

git push -u origin develop

Starting on a new feature

git checkout develop

git checkout -b feature/newFeature

Finishing the new feature

git checkout develop

git merge feature/newFeature

Starting a new release

git checkout develop

git branch -b release/v.1.0

Finishing the release

git checkout master

git merge release/v.1.0

git checkout develop

git merge release/v.1.0

Starting a hotfix branch

git checkout master

git checkout -b hotfix/newFix

Finishing the hotfix

git checkout master

git merge hotfix/newFix

git checkout develop

git merge hotfix/newFix

git branch -D hotfix/newFix

Question 8

What is the Forking Workflow?

Answer 8

The Forking Workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. The Forking Workflow is most often seen in public open source projects.

Question 9

What is the main adventage of the Forking Workflow?

Answer 9

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

Question 10

What is the difference between forking and cloning?

Answer 10

It’s important to note that “forked” repositories and “forking” are not special operations. Forked repositories are created using the standard git clone command. Forked repositories are generally “server-side clones” and usually managed and hosted by a 3rd party Git service like Bitbucket. There is no unique Git command to create forked repositories. A clone operation is essentially a copy of a repository and its history.

Question 11

What is VCS?

Answer 11

Version Control System

Question 12

What is DVCS?

Answer 12

Distributed Version Control System

Question 13

How does a centralized version control system work?

Answer 13

A centralized version control system works on a client-server model. There is a single, (centralized) master copy of the code base, and pieces of the code that are being worked on are typically locked, (or “checked out”) so that only one developer is allowed to work on that part of the code at any one time. Access to the code base and the locking is controlled by the server. When the developer checks their code back in, the lock is released so it’s available for others to check out. Of course, an important part of any VCS is the ability to keep track of changes that are made to the code elements, and so when an element is checked in, a new version of that piece is created and logged. When everyone has finished working on their different pieces and it’s time to make a new release, a new version of the application is created, which usually just means logging the version numbers of all the individual parts that go together to make that version of the application.

Question 14

What does this git command line do: git merge branch1 branch2?

Answer 14

It merges both branches into the current branch.

Question 15

Is merging a destructive operation?

Answer 15

No.

Question 16

What does the rebase command do?

Answer 16

It moves the entire branch, to begin on the tip of the other branch, effectively incorporating all of the new commits in the other branch. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

Question 17

What is the benefit of rebasing?

Answer 17

The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks. This makes it easier to navigate your project with commands like git log, git bisect, and gitk.

Question 18

What is interactive rebasing?

Answer 18

Interactive rebasing gives you the opportunity to alter commits as they are moved to the new branch. This is even more powerful than an automated rebase, since it offers complete control over the branch’s commit history. Typically, this is used to clean up a messy history before merging a feature branch into master.

Question 19

What does the golden rule of rebasing say?

Answer 19

Never use rebasing on public branches.

Question 20

What would happen if you would rebase the master onto a feature branch?

Answer 20

The rebase moves all of the commits in master onto the tip of feature. The problem is that this only happened in your repository. All of the other developers are still working with the original master. Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.

Question 21

What is the only time you should be force pushing?

Answer 21

One of the only times you should be force-pushing is when you’ve performed a local cleanup after you’ve pushed a private feature branch to a remote repository (e.g., for backup purposes). This is like saying, “Oops, I didn’t really want to push that original version of the feature branch. Take the current one instead.” Again, it’s important that nobody is working off of the commits from the original version of the feature branch.

Question 22

How to rebase only the last 5 commits?

Answer 22

git rebase -i HEAD~5

Question 23

How to clean up a local branch from the start up?

Answer 23

Use git merge-rebase branchToCleanUp parentBranch to get the id of the commit. The use git rebase -i commitHas

Question 24

Can you clen up a public branch?

Answer 24

No, because you breake the golden rule of rebase.

Question 25

Is it legal to rebase onto a remote branch instead of master?

Answer 25

Yes, because this rebase doesn’t violate the Golden Rule of Rebasing because only your local feature commits are being moved—everything before that is untouched. This is like saying, “add my changes to what John has already done.” In most circumstances, this is more intuitive than synchronizing with the remote branch via a merge commit. By default, the git pull command performs a merge, but you can force it to integrate the remote branch with a rebase by passing it the –rebase option.

Question 26

Is it legal to rewrite the history if you use pull requests as part of your code review process?

Answer 26

No, because as soon as you make the pull request, other developers will be looking at your commits, which means that it’s a public branch. Re-writing its history will make it impossible for Git and your teammates to track any follow-up commits added to the feature.

Question 27

What can you do to prevent any mess up you could do with git rebase?

Answer 27

If you’re not entirely comfortable with git rebase, you can always perform the rebase in a temporary branch. That way, if you accidentally mess up your feature’s history, you can check out the original branch and try again. For example: git checkout feature git checkout -b temporary-branch git rebase -i master # [Clean up the history] git checkout master git merge temporary-branch