This article is my summary after using Git for a period of time and reading some materials, as well as my personal opinion. I deeply feel that the standard use of Git is very important, and non-standard use will bring a lot of trouble.

Comparison of similar tools

SVN and Git

On the principle of

  1. Git directly records file snapshots, and SVN records which files are updated and which lines are updated each time
  2. Git has a local repository and a remote repository. SVN has no local repository
  3. While most Git operations are performed locally, SVN operations are almost always connected to the network

On the operation

  1. After Git is submitted, it is saved in the local repository, which needs to be pushed to the remote repository. The SVN submits the data to the remote repository
  2. Git has a variety of “go back” commands, SVN has almost none
  3. Git has a real branch, and a branch on SVN is actually a copy of the workspace

Git usage status

  • Submit information with unknown meaning

  • Bad version tree

Existing problems

  • Merging conflict resolution is error-prone
  • It is difficult to find the rollback version number by submitting information during rollback
  • Files affected by this merge may not be visible at the merge point

Git workflow

Gitflow workflow

Gitflow assigns a clear role to the different branches and defines how and when the branches interact with each other. There are history branches, function branches, release branches and maintenance branches.

Branch of history

Use two branches to record the history of the project. The Master branch records the history of the official release, while the Develop branch acts as the integration branch for the functionality. Therefore, each commit of the Master branch should be assigned a version number.

Function branch

A feature branch is a new branch that comes out of Develop checkout, one for each feature.

1. Assume to develop function A:

git checkout -b feature-a develop
Copy the code

2. When the new functionality is complete, merge back into the Develop branch.

git checkout develop
git merge --no-ff feature-a
git push
git branch -d feature-a
Copy the code

Release branch

1. When the Develop branch is ready to publish, pull a publish branch from the Develop branch and name it release-* or Release /*.

Git checkout -b release-0.1 developCopy the code

2. This branch is used for the release cycle and only does release-oriented tasks such as bug fixing and document generation. No new functionality is added to this branch. 3. Once publishing is complete, merge the publishing branch into the master branch.

Git checkout master git merge --no-ff release -- 0.1 git pushCopy the code

4. Tag the release number to track each release.

git tag -a0.1 - mRelease 0.1 "publish" master
git push --tags
Copy the code

5. Merge the changes made since the new release branch into the Develop branch.

Git checkout develop git merge --no-ff release -- 0.1 git pushCopy the code

6. Delete the publish branch

git branch -dRelease 0.1Copy the code

Maintenance branch/hot fix

When bugs occur in the online version, the maintenance branch is used to quickly patch the production release.

1. Pull a maintenance branch from the Master branch (this is the only branch pulled from the Master branch).

git checkout -b hotfix master
Copy the code

2. As soon as the fix is complete, merge back to Master and Develop.

git checkout master
git merge --no-ff hotfix
git push
git checkout develop
git merge --no-ff hotfix
git push 
git branch -d hotfix
Copy the code

3. Tag the master version with the new version number.

git tag -a0.2 - mRelease 0.2 "publish" master
git push --tags
Copy the code

The illustration

Image from Internet

advantages

  • A single function is developed independently, and parallel development does not interfere with each other
  • masteranddevelopBranches record the history of release and feature development, respectively
  • Due to the release branch, the development of other features that are not yet released is not affected by the release and can continue to be committed
  • The maintenance branch can patch quickly without affecting the functionality under development

disadvantages

  • Complex, many branches
  • Git GUI does not support, pure command line
  • High requirements for developers (understanding workflow, familiarity with Git commands)
  • All functional branches are based on instabilitydevelop
  • Two long-term branches need to be maintainedmasteranddevelop

GitHub Flow

Workflow used by GitHub

  1. All inmasterEverything is releasable (published or about to be published).
  2. When developing new features frommasterPull a new branch with a clear name
  3. Commit it locally to the branch at the same timepushTo remote warehouse
  4. When you need feedback or help, or the branch is readymergeWhen, open onepull request
  5. After the branch is reviewed and agreed to merge, merge intomaster
  6. pushtomasterAfter that, it should be published immediately

advantages

  • The operation is simple
  • The trunk code is quality-assured

disadvantages

  • There is no distinction between the test line and the release of the formal environment

Git-Develop

Develop as a fixed continuous integration and publishing branch

  1. Every function is frommasterPull a functional branch.
  2. Develop on this branch of functionality. When the functionality is completed and released, submit code review and automatically merge into it after passingdevelop.
  3. Wait until all planned change branch code is merged intodevelopLater,rebase mastertodevelopTo complete the release.
  4. Hit one when your app launches successfullytag.
  5. developThe release version of the branch is merged backmaster.

advantages

  • Relatively simple to operate
  • With a few changes to the process, the test line can be distinguished from the formal environment
  • Each development is based on the latest code in the official release (master) and have no dependencies on other branches of current development
  • masterIt is always published

disadvantages

Not at the moment…

Pull Requests

Pull Requests is not a workflow, but rather a feature that makes it easier for developers to collaborate and discuss proposed changes before they are incorporated into a formal project. This approach has some limitations on branch merging, such as only the project maintainer has the authority to merge branches into the repository. How it works:

  1. The developer creates a new feature branch in the local repository.
  2. After the feature is complete, the developerpushBranch changes to the remote repository.
  3. Developer initiatedPull requests.
  4. Team members are notified for code review, discussion and modification.
  5. The project maintainer merges functionality into the repository and shuts it downPull Requests.

Git Use Tips

git commit –amend

Git commit — The most common use of amend is to recommit to overwrite the last commit if something was written wrong, or if the commit is too many or missing.

In fact, it is also used to merge commits. For example, you can use this command to merge the last commit and the last commit after making some changes that were not complete.

git reset

Git reset can be used when you need to roll back one or more commits. Because this command is dangerous, it is recommended for local branches that have pushed the latest commit to a remote repository.

  • git reset HEAD [filename]

To cancel a file in the temporary area and restore it to the modified and unstored state.

  • git reset HEAD~[n]

Git reset can be followed by HEAD~[n](n >= 1). Indicates a rollback to before n commits. It can also be used to merge commits. The result is the same as git commit –amend.

git reset HEAD~1
git commit
Copy the code

The following rule is to merge multiple submissions

git reset HEAD~2
git commit
Copy the code
  • git reset [version]

Git reset can also be followed by the version number to go back to the specified version.

  • Git reset

    1. Using parameter--hard, such asgit reset --hard [version]The following operations are performed:
      1. Replace the pointing of the reference. The reference points to the new commit ID.
      2. Replace the staging area. After replacement, the contents of the staging area are the same as the directory tree to which the reference points.
      3. Replace the workspace. After the replacement, the contents of the workspace become the same as the staging area and the contents of the directory tree pointed to by HEAD.
    2. Using parameter--soft, such asgit reset --soft [version]Will perform the above operation a. That is, only the reference pointing is changed and the staging and workspace are not changed.
    3. Using parameter--mixedOr no arguments (default is--mixed), such asgit reset [version]Operations A and B are performed. That is, change the reference pointing and reset the staging area, but do not change the workspace.

git merge –no-ff

–no-ff stands for no fast merge

Git Merge differs from Git Merge

Git merge results

The branches of the merge and the current branch are graphically aligned, and the commit points of the merge are merged into the current branch one by one.

Git merge –no-ff

The branch being merged is not on the same line as the current branch, the commit point is still on the original branch, and a merge point is generated on the current branch.

git rebase

Git rebase git rebase git rebase git rebase

Git Merge differs from Git Merge

Git rebase merge git rebase merge git rebase merge git rebase merge git rebase merge git rebase

For example, if dev commits once and master commits once after that, the status of the two branches is as follows:

  • Order of submission points

After git merge, the commit point sequence is the same as the commit time sequence, whether or not –no-ff parameter is added, that is, master commit after dev.

After git rebase, all commits on the rebase branch (master) are first, and all commits on the rebase branch (dev) are after the rebase branch. The commits on the same branch are still in chronological order, as shown in the figure:

  • rebase

As you can see from the diagram above, dev is rebase master, and the branch changes. Originally there were two branches, and the result of rebase looks like: Dev is the master-based branch, and some new commits are generated.

In general, rebase dev and remote origin/dev will be separated, and the command line interface will prompt:

Your branch and 'origin/dev' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
Copy the code

Git push -f is used to override the remote branch. If you use git pull as prompted, the result will be merge and a merge commit point will be generated.

Note: carefulgit push -f!

git pull –rebase

Git pull –rebase — git pull –rebase

Differences with Git pull

In general, there is no difference between adding and not adding –rebase. If you use Git pull, you will merge your local branch with your remote branch. If you use Git pull, you will merge your local branch with your remote branch. Git pull –rebase is the correct way to pull the latest branch.

So it is recommended that you pull a remote branch at any time, preferably with the –rebase parameter.

git reflog

Git reflog is used to view local commit records. Git reflog is used to view local commit, merge, rebase, etc.

6fe46ab HEAD@{0}: rebase finished: returning to refs/heads/dev
6fe46ab HEAD@{1}: rebase: dev modify a
2c92bcb HEAD@{2}: rebase: checkout master
9b26f5d HEAD@{3}: reset: moving to 9b26f5db1e8597b884c45114fbbff36c440da274
5531fc0 HEAD@{4}: merge master: Merge made by the 'recursive' strategy.
9b26f5d HEAD@{5}: checkout: moving from master to dev
Copy the code

Git Tool Recommendations

  • SourceTree
  • GUI Clients

The resources

Pro Git, Git reference: http://iissnan.com/progit/html/zh/ch1_5.html

Git workflow guide, introduces several mainstream workflow: https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md

Theory of Gitflow harmful: http://insights.thoughtworkers.org/gitflow-consider-harmful/

Making Flow: http://scottchacon.com/2011/08/31/github-flow.html

Google’s “main development” (trunk – -based development) : http://www.ruanyifeng.com/blog/2016/07/google-monolithic-source-repository.html