Basic Concepts
What is Git?
Git is a distributed version control system that, compared to a centralized version control system like SVN, centralized version control systems can work collaboratively with multiple team members, but sometimes if a central server goes down, no one can commit updates and co-development during downtime. Even sometimes, a central server disk fails, and it happens that no backup or backup is in time, and there may be a risk of data loss.
But Git is a distributed version control system, and the client is not just extracting the latest version of the snapshot, but also copying the entire code warehouse image. If any server that works together fails, you can use any one of the code warehouses to recover. And while the collaboration server is down, you can also submit the code to the local repository, and when the collaboration server is working, you synchronize the local warehouse to the remote repository.
Why to use Git
- Ability to file version control and multi-person collaboration development
- Powerful branching features, so flexibility to collaborate with different workflows
- Distributed version control system, even if the collaboration server down, can continue to submit code or files to the local warehouse, when the collaboration server resumes normal operation, and then synchronize the local warehouse to the remote warehouse.
- When a member of a team completes a feature, the pull request action informs other team members that other team members can review code and then merge them.
What are the features of git?
- Three states of file (modified, staged, committed)
- Direct recording of snapshots, rather than differential comparisons
- Most operations only add actions
- Nearly all operations are performed locally
- Maintain data integrity at all times
git basic Workflows
- Modify a file in a git version-controlled directory
- Save
git add
The modified file snapshot to the staging area using the command
- Commit
git commit
updates using a command to permanently dump a snapshot of a file saved in the staging area to the Git directory
Basic git Tips
- Auto-complete
- Git command Aliases
git version control
Create a warehouse
git init
git clone
git config
Save changes
View Warehouse
git status
git log --oneline
Undo Changes
View Previous Commit
git checkout <commit> <file>
git checkout <commit>
git checkout <branch>
Undo Public modifications
Undo Local Modifications
Rewrite git history
git commit --amend
git rebase
git reflog
git Collaborative development
Branch
git branch
git checkout
git merge
Warehouse Synchronization
git remote
git fetch
git pull
git push
git workflow
Because Git has a powerful branching feature, its workflow is flexible and lacks constraints, so refer to the comparing Workflows section of Atlassian git tutorial for four git workflows:
- Centralized Workflow
- Feature Branch Workflow
- Gitflow Workflow
- Forking Workflow
The workflow above is only a reference guide, not a specific rule. Depending on your situation, you can choose your own workflow or fine-tuning to suit your needs.
Centralized Workflow
Transitioning to a distributed version control system looks like a daunting task, but if you make the most of git, you don't have to change your existing workflows, and your team can develop projects in the same way that you used SVN before.
How it works
Centralized Workflow
- Cloning a project from a remote repository (central repository) to a local warehouse (locally repository)---
git clone
- Edit files in the local warehouse and submit updates---
git add
andgit commit
- Fetch remote Repository updated commit to the local repository and rebase to the top of the updated commit---
git fetch
and gitrebase
orgit pull --rebase
- Push the local Master branch (master Branch) to the remote repository---
git push
Managing conflicts
File Conflicts
- When a conflict occurs: Before developers release their functionality, they need to fetch the updated commit of the remote repository to the local repository and rebase to the updated commit. Sometimes a conflict occurs between a local commit and a remote commit, and git pauses the rebase process to let you resolve the conflict manually.
- How to resolve conflicts: You can use
git status
and git add
to manually resolve merge conflicts.
Feature Branch Workflow
The main idea of Feature Branch workflow is to create a separate branch when developing each function rather than just using the main branch. Since each branch is independent and unrelated, this means that the main branch does not contain broken code, which is helpful for a continuous integration environment.
How it works
Feature Branch Workflow
- Still using remote repositories (central repository) and Main branch (master branch) still records the history of official projects
- Developers create a new branch each time they develop new features---
git checkout -b
- Feature branches should be pushed to the remote repository (central repository)---
git push
- Send pull request to request that an administrator can merge into the main branch (master branch)
- Publish new features to the remote repository (central repository)
Pull Request
Pull request is a mechanism for sending notifications to other team members when a developer completes a new feature. It uses the following procedures:
Developers can send pull request via GitHub or BitBucket
Pull request on Github
- Other team members review, discuss, and modify the code
- Project Maintainer merge new feature branch to Main branch (Master Branch), then close pull request
Gitflow Workflow
Feature Branch Workflow is a very flexible way to develop. For some larger teams, it is best to assign different roles to specific branches. In addition to the feature branch (feature Branch), Gitflow Workflow also uses separate branches to prepare for release (preparing), maintenance (maintaining), and record versions (recording releases). I'll describe each of these branches individually: historical Branches, Feature Branches, Release Branches, and maintenance Branches.
Historical Branches
Historical Branches
- Master Branch holds official release history
- Develop branches derive from each feature branch
Feature Branches
Feature Branches
- The feature branch uses the develop branch as their parent branch
- When one of the feature branches is completed, it merges the develop branch
- The feature branch should never interact directly with the master branch
Release Branches
Release Branches
- The release branch is primarily used to clean up, test, and update documents
- Once the develop branch gets enough functionality to publish, you can derive a release branch from the develop
- Once the shelves are ready, release merges into the master branch and marks a version number
- Also, you need to merge back into the develop branch
Maintenance Branches
Maintenance Branches.png
- Maintenance branch is used to quickly fix bugs or fine-tune features for released products
- It derives directly from the master branch.
- Once the fix bug is complete, it should be merged back to the master branch and develop branch
- Master should be tagged with a new version number
tags tags
Use two commands to mark the master branch with a version number:
git tag -a 0.1 -m "Initial public release" master
git push origin master --tags
forking Workflow
Forking workflow is very different from the workflow discussed above, and one important difference is that it is not just multiple development sharing a remote repository (central repository), but each developer has a separate service-side repository. This means that each contributor has two warehouses: a local private warehouse and a remote shared warehouse.
Forking Workflow
Forking workflow The main benefit of this workflow is that each developer has its own remote repository that can push the submitted commits to its own remote repository, but only the project maintainer has permission to push the submitted commits to the official warehouse, Other developers are not allowed to push without authorization. Many of GitHub's open source projects are based on forking workflow workflows.
How it works
1. There is an official public warehouse on the server
2. The developer fork the official repository to create a copy of it and then store it on the server
Fork official Repository.png
1. When developers are ready to publish local commits, they push commit to their own public warehouse
2. Send a pull request to the official warehouse in your own public warehouse
3, the maintainer pull contributor's commit to his own local warehouse
4. Review the code to make sure it doesn't break the project, merge it into the master branch of the local repository
5, the push master branch to the official warehouse on the server
6, other developers should synchronize the official warehouse.
Git version control and workflow