Git version control and workflow

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

1. Modify a file in a git version-controlled directory
2. Save git add The modified file snapshot to the staging area using the command
3. 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

• git add
• git commit

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

• git revert <commit>

Undo Local Modifications

• git reset
• git clean

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

1. Cloning a project from a remote repository (central repository) to a local warehouse (locally repository)---git clone
2. Edit files in the local warehouse and submit updates--- git add andgit commit
3. 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
4. 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

1. Still using remote repositories (central repository) and Main branch (master branch) still records the history of official projects
2. Developers create a new branch each time they develop new features---git checkout -b
3. Feature branches should be pushed to the remote repository (central repository)---git push
4. Send pull request to request that an administrator can merge into the main branch (master branch)
5. 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