All commands Flashcards
Learn all commands that exist. (27 cards)
git clone
Clones a local repository.
git clone
Clones a remote repository.
Explain git flow.
- 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.
Explain how to make a new feature with git flow in mind
- 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.
Explain how to make a release branch with git flow in mind.
- 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.
Explain how to make a hotfix with git flow in mind.
- 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.
How do you set up the git workflow with git commands?
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
What is the Forking Workflow?
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.
What is the main adventage of the Forking Workflow?
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.
What is the difference between forking and cloning?
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.
What is VCS?
Version Control System
What is DVCS?
Distributed Version Control System
How does a centralized version control system work?
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.
What does this git command line do: git merge branch1 branch2?
It merges both branches into the current branch.
Is merging a destructive operation?
No.
What does the rebase command do?
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.
What is the benefit of rebasing?
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.
What is interactive rebasing?
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.
What does the golden rule of rebasing say?
Never use rebasing on public branches.
What would happen if you would rebase the master onto a feature branch?
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.
What is the only time you should be force pushing?
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.
How to rebase only the last 5 commits?
git rebase -i HEAD~5
How to clean up a local branch from the start up?
Use git merge-rebase branchToCleanUp parentBranch to get the id of the commit. The use git rebase -i commitHas
Can you clen up a public branch?
No, because you breake the golden rule of rebase.
