Shulou(Shulou.com)06/02 Report--

What are the Git submission specifications? for this question, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

1. Commit message specification

Canonical format:

:

* * type * *

Feature: new feature (feature)

Fix: patching bug, style, etc.

Refactor: refactoring (that is, neither new features nor code changes to modify bug)

Test: add test chore: changes to the build process or aids

Subject

A short description of the purpose of the submission, describing what has been done or changed, and if there is a team management tool (issue, JIRA) or product requirements, an internally named requirement code must be used as part of the description information to facilitate access to logs, mergers, and cherry-pick.

For example:

Feature: develop and complete # code XXX.XXX requirements

Fix: modify # code XXXX query problem

two。 Submit specification and GIT development process

* * Git Branch * *

Master (production environment) deploys a uat function to be merged into master when quasi-production, and only uat branches are allowed to merge / cherry-pick.

Uat (Test Environment) deploys a feature branch to merge into uat when testing, and only feature branches are allowed to merge.

Feature/xxxx (feature branch) merges / submits to feature when developing a function or modifying bug

Dev/xx (locally developed version)

Before development, you need to cut a requirement, BUG, refactoring on the master branch. Name the feature branch, such as the feature/ project number (code for BUG)

2.1 No local project, clone the code and switch to the development branch

Clone and create a local feature development branch on the dev branch that needs to be developed, which can be named after dev/ 's own identity.

Git clone-b dev/xx feature/ project number 2.2 there is a local project, switch the development branch

To avoid inconsistency between the local branch and the remote, you need to switch to the feature/ project number branch and update it.

Git checkout feature/ project number git pull

Then cut out your own development branch on the feature/ project number.

Git checkout dev/xx2.3 submission Code

Note: suffixes or files that do not need to be submitted must be added to .gitignore files in the same directory as .git.

Add modified files to the staging area (staging area)

Git add.

Submit the modified file to the local version library

Git commit-m'fix: modified XXXXX'

It can also be synthesized in two steps and one step operation.

Git commit-am 'fix: modified XXXXX'

To submit the code, I personally suggest that it is best to use idea or other git graphical interface to check the files to be added, or to operate.

The meaning of the icon after git

The first is the git pull code operation button

The second is the git submit action button

The third is the git log operation button.

The fourth is the git revert operation button.

First click the git submit button

If the file does not need to be modified, or if you are not careful with spaces, use revert to restore it directly.

If the file is generated at the start of the project, such as the excel or log log exported by the project, delete it directly using delete

Tips: during the development process, you can enter the submission interface of the above figure at any time to see which files have been changed and manage your modified content more conveniently and efficiently, as well as other desktop graphics, such as TortoiseGit,Source Tree, and git comes with two gitk and git-gui (enter commands in the git directory).

2.4 push to remote branch

When pushing the local branch dev to the remote dev, you need to switch to the feature/ project number branch, the merge remote branch code.

Git checkout feature/ project number git pull

Then switch to your own development branch dev/xxx

Git checkout dev/xxx

Rebase feature/ project number to their own dev/xxx, the main purpose is to check if there is a conflict.

Git rebase feature/ project number

No conflict, push dev/xxx directly to remote dev/xxx

Git push origin dev/xxx

If there is a conflict, you can use the git status command at any time after the merge conflict to view the files that are in the unmerged state because they contain the merge conflict

Git status

All files that have conflicts in the merge that need to be resolved are identified as unmerged. Git adds standard conflict resolution tags to files that contain conflicts, so you can open those files that contain conflicts and resolve them manually.

> dev/xx:index.html

The contents of the above file indicate that the version that head points to (that is, the branch of rebase) conflicts with the version pointed to by dev/xx below.

= is the split line, the top half is the version of the branch pointed to by head, and the bottom half is the version of the code pointed to by the dev/xx branch

The above conflict resolution retains only the changes to one of the branches, and > these lines need to be deleted completely.

Action is required after the modification is completed.

Git add.

Use the git add command to mark it as a conflict resolved. Once these previously conflicting files are temporarily saved, Git will mark them as conflict resolved

Then continue with the rebase operation:

Git rebase-continue

Loop rebase-- continue until rebase succeeds

And then push

Git push origin dev/xxx

Finally, log in to the web management of gitlab or coding, submit the merge request, merge the remote branch dev/xxx and the remote branch feature/ project number branch, and then merge to show that your submission is complete. After all the people in the feature branch have completed the development and passed the test, merge the feature into uat for online testing.

Now let's take a look at resolving conflicts with our artifact idea.

When operating merge,rebase,cherry-pick, conflicts will pop up when there is a conflict.

After the solution is completed, after apply, you can directly push it.

Summary:

For git, only push and pull operations will deal with remote, and other commands are done locally, that is, only when pull,push or directly initiates a remote branch and remote branch merge request on the git platform can you really know whether there is a conflict. Even if the local rebase feature, there is still no way to guarantee that there is no conflict between dev and feature, because when you rebase, the code of your current local feature branch is not exactly the same as that of the feature branch when you initiate a merge request, so rebase feature just reduces the conflict when merging feature in advance.

For the process of git operation, we have some different habits, in fact, no matter how the operation is wrong, if the company, the team has recognized the specification, or in accordance with the specification.

* * Common submission methods * *:

1. Developed directly in the feature branch, everyone pull (git fetch + git merge) the new feature code before commit, and then add after an one-time conflict resolution. Commit push .

two。 Directly in the feature branch development, everyone first commit to the local branch, then pull-- rebase (git fetch + git rebase) the current new feature code, and then there is conflict resolution after add. Push .

3. As I wrote above, everyone has a local development branch named by himself, resolves the conflict with the local branch merge or rebase that will be merged, and then merges through the request of the web platform.

4. Welcome to provide more awesome ways.

The first is the simplest and most common way of operation, which is easy to lose your modified code when resolving conflicts, resulting in irreparable results. (you can also use the local history rollback of idea.)

Second, submit first, and then pull the code rebase to ensure that your code is submitted to the local branch, no matter how blindly you change the code afterwards, you will not lose the submitted commit.

Third, the operation is a bit complicated, although it takes a detour, but compared with the second one, the main difference is whether the feature branch allows direct submission. If allowed, then the permission control of the feature merge is placed in this part of the merge into uat.

Simple understanding: the operation of GIT is nothing more than pulling code, pushing code, merging code, and conflicts occur only when dealing with remote branches at each step. But there are many ways to resolve conflicts ahead of time or in what way.

No matter what graphical tool you use, we need to first understand the basic commands of git and the commands behind the git operation of each step of the graphical tool operation.

Warning: do not delete the .git directory without push code, you know.

The consequences of not resolving the conflict and then forcing push, , I laughed.

* * colored eggs; * *

After the knowledge submitted above is over, let's expand our knowledge.

How do I use 1.reset?

Usage:

Git reset-- mixed/--hard/--soft c27894c06a2cc23e4097a93013cf640cc4fd527dgit reset-mixed HEAD~1 rollback a version, and will restore all the contents of the temporary storage area and the local submitted content to the non-temporary state, and will not affect the original local files (those that have not been submitted will not be affected), that is, before restoring to add, git reset-soft HEAD~1 rollback a version, does not empty the temporary storage area, and restores the submitted content to the temporary storage area. Does not affect the original local files (those that are not submitted will not be affected), that is, before restoring to commit, git reset-hard HEAD~1 rollback a version, empty the temporary storage area, restore the version of the submitted content locally, and the local files will also be replaced by the fallback version. That is, it was restored to before it was developed.

First of all, it is emphasized that the online project reset is not recommended and prohibited. Why do you say so?

Git itself stores all the history of the code, whether you submit an error or the submitted code has BUG, you should commit a modified submission on the basis of the error, rather than undo the code you have submitted to the remote branch.

If you accidentally submit a small movie to GIT, or if you want to "delete the code and run", or if your changes become thousands of BUG, reset, you need to force the push to the remote branch, the record of the submission of the remote branch after the upload point will disappear forever.

two。 I want to merge the code before a commit from the uat branch

Git checkout-b uat20190711 c27894c06a2cc23e4097a93013cf640cc4fd527d

You can push to remote and then merge with other branches or switch other branches rebase direct push

Is that how 3.cherry-pick uses it?

Git cherry-pick-x-n 017822ece3049d3f46c72cabf32dee9f44dd15cc

Change a commit directly on the current branch, and then submit it, so the submitted commit needs to write down your intention to submit.

-x retain the original author-n does not submit automatically

Graphical tool screenshots, their own groping, all the same, to find a record of a commit can be directly operated.

The answers to the questions about the Git submission specification are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.