GitHub, GitLab, Git operation of some specifications

Irregular commit messages result in arbitrary content, uneven quality, low readability, and difficult to maintain.

Branch specification

  • The master branch is the master branch (the protection branch). Code changes and commits cannot be made directly on the master
  • The Develop branch is the test branch, and all developed functions that need to be submitted for tests are merged into this branch
  • The Production branch is the production branch, and all functions that need to be submitted to production after testing are merged into this branch
  • The feature branch is a development branch. You can create separate feature branches based on your needs and then merge them into the Develop branch
  • The fix branch is a bug repair branch. You need to fix the vulnerabilities of the released version based on the actual situation

Commit format specification

Submission format: Type (scope) : Subject

Type: Specifies the type of commit. The following types are specified:

  • Feat: New function;

  • Fix: Fix a bug;

  • Docs: Modify a document;

  • Refactor: Code refactoring without adding any features or fixing any bugs

  • Build: changes to the build process, including new dependencies, tools, etc. (e.g. webPack changes)

  • Style: changes only Spaces, indents, etc., without changing the code logic;

  • Perf: Modifications that improve performance and performance;

  • Chore: Non-SRC and test modifications;

  • Test: Modification of test cases;

  • Ci: Automated process configuration modification;

  • Revert: Roll back to previous version;

    The sample





Ignore the rules

  • Ignoring blank lines in the file or lines that start with a pound sign (#) are ignored.

  • Linux wildcards can be used. For example, the asterisk (*) represents any number of characters, and the question mark (?) Represents a single character, square brackets ([ABC]) represents a range of optional characters, curly braces ({string1,string2… }) represents an optional string, etc.

  • If the name is preceded by an exclamation point (!) Is an exception rule that is not ignored.

  • If the name is preceded by a path separator (/), the file to be ignored is in this directory, while files in subdirectories are not ignored.

  • If the name is followed by a path separator (/), it means that subdirectories of the name in the directory are to be ignored, not files (the default is to ignore either files or directories).

Stash and Pop

Relevant command

Git Stash List gets the list of hidden workspaces. Git Stash Pop gets the top hidden workspaces and deletes Git Stash Apply to get the top hidden workspaces. Git Stash Apply Stash @{0} Gets the hidden workspace code at the specified locationCopy the code

Common Problems

1. How do I restore a deleted branch?

If you remember the commit number, you can use the Git reset-hard ID method to point to the deleted branch. There is also a way to restore the deleted branch if the commit number is not remembered. First, git reflog is used to obtain every recent command, and then search for the most recent commit to delete the branch, find the commit number, and then the branch content can be retrieved smoothly.

2. We are currently developing dev code, but suddenly we need to fix bug1.0, but the dev code is not submitted, what should we do at this time?

Start by hiding the current workspace code on the stack with git Stash to save the temporary state. Cut out another fixBug branch to solve the problem, and when the problem is solved, use git Stash Pop to retrieve the workspace code hidden in the stack and continue dev development. When you retrieve the workspace code using the Git Stash pop command, you also remove the code that was pushed into the stack. The Git Stash List looks at all the temporary workspace code. You can also use git Stash Apply stash@{0} to restore exactly the code in the stack.

3. How do I resolve a conflict when I submit a command

You can only use the third-party software Compare software to compare the differences between the two files.

Use the interface to submit conflict issues

  • Adopt current change: keep current and discard remote
  • Adopt incoming changes: discard the current and keep the remote
  • Both parties are reserved: both parties are reserved in the corresponding locations
  • Compare changes: Compare files and make changes

conclusion

Code specification, process specification in the software development process is very important, it can make us in the development process to take a lot of detours. The Same is true of the Git Commit specification, which is certainly necessary and requires little extra effort and time, but is very efficient in finding problems later. As programmers, we should focus more on standardizing our code and processes, never on quality.