Hello, I’m Houhou.

It has been a long time since I last saw you in 2022, and the epidemic has not dissipated yet…

But our lives have long since returned to normal

The New Year, the Flag or to establish, in case are completed?

Come on together!

Recently in the project, I found that some friends are not so normative when using Git, so I took some time to sort out a wave, hoping to help you.

The article mainly includes: branch specification, submit merge specification, branch use process and so on.

Do you still use merge? Rebase takes a look.

First, branch specification

In the development process, there are generally the following branches:

The main branch (master)

The master branch, which is also used to deploy the production environment, is generally combined by the Dev and Fixbug branches and cannot directly modify the code at any time.

Dev branch

Develop is a branch of development that keeps code up to date and bug-fixed. In general, when developing new features, the feature branch is created under the dev branch.

Feature -[feature name/version info]

Feature is the requirement branch, and a feature branch is created based on the Dev branch. Each developer creates his own development branch based on the feature branch.

Fixbug – [bug code]

Create a fixbug branch based on the master branch and merge the fix to the Master branch and dev branch.

Commit specification

2.1 Format of submitted logs

Each Git commit log is in the following format: Type: Description

  • type

    Only the following seven identifiers are allowed to describe the commit category.

    • Feat: New function
    • Fix: Fixes bugs
    • Docs: Modify the document
    • Style: Format the code structure, no logical code changes
    • Refactor: Refactoring, i.e. code changes that are not new features or bug fixes, such as renaming variables
    • Test: Add test code, unit test type, without production code changes
    • Chore: Changes to the build process or helper (without affecting code execution)

  • describe

This is the description of the commit, stating exactly what the commit is doing

Such as:

Git commit -m "feat: add user details page "git commit -m "fix: add user details page" git commit -m"Copy the code

2.2 Submission Frequency

  1. The submission granularity is based on function points. Remember not to submit all the time, accumulate a lot of code and then submit;
  2. Compress temporary or meaningless commits before pushing;

Remember to compress multiple commits. Only compress your own commits. Do not manipulate others’ commits, or you may be attacked by your colleagues

  • Command-line mode
# find the commit that needs to be merged For example, what if you want to merge the last four commits? $git rebase -i HEAD~4 Is the fifth time submit to merge commitId $git log $git rebase -i ecc2741a2337d6b50f2c35ba877aa040eea3531 # 6 will enter next vi operation, automatically list need to merge to submit, # pick f77f9da list branch Update two # pick ff65dd9 feat: List branch update three and four Squash: Preserves the commit, but adds the commit to the previous commit. Fixup: squash, but log message is discarded. (:wq) Git log: < commit > < commit >Copy the code

Pick: keep the commit (abbreviated: p)

Reword: Reserve the commit and modify the comment for the commit (abbreviated: r)

Edit: Retain the commit, rebase pauses, allowing you to modify the commit (abbreviated: e)

Squash: Merges the current COMMIT with the previous commit (abbreviated: S)

Fixup: same as squash, but does not save commit comment information for the current commit (abbreviation: f)

Exec: Execute other shell commands (abbreviated: x)

Drop: drops the commit (abbreviation: d)

  • IntelliJ IDEA development tool built-in mode

2.3 Update and merge specifications

Principle:

① The downstream branch updates the upstream branch code with Rebase;

② Merge upstream branch code into downstream branch code;

③ Update the branch code with –rebase (if there are more than one people in the branch development time);

This eliminates unnecessary merge records that are generated automatically, making it easier to view development records later.

When the downstream branch updates the upstream branch code, merge results in a useless merge record, which affects the view history. Rebase does not.

The following describes how to operate in different scenarios. Currently, there is a requirement of XX, and two students, A and B, are responsible for the development branch explanation (the establishment of personal development branch is for the convenience of code review) :

  • master: main branch
  • dev: Test branch
  • feature-xx: Order details Demand branch
  • feature-xx-a: Order details A Development branch
  • feature-xx-b: Order details b Development branch
Scene 1:feature-xxThere’s been an update to the branch code, localfeature-xxUpdate the code.

C and D jointly developed on feature-XX branch. One of them pushed the code and the other updated it.

  • Command-line mode
# The current code is in the feature-xx branch. $git pull origin feature-xx --rebaseCopy the code
  • IntelliJ IDEA development tool built-in mode

Scene 2:feature-xxThe branch code is updated with the new code, and A wants to merge the code.

Let’s comb through the ideas:

① feature-xx-a updates the remote branch code.

(2) Merge origin/feature-xx branch code, there is conflict resolution conflict, there is no conflict to push the code to the server;

③ Initiate merger.

  • Command-line mode
# assuming that all code has been committed, there is no need to commit or hold code; $git rebase origin/feature-xx # $git rebase --continue # $git rebase --continue # $git rebase --continue # If a code review is required, make a merge request; $git checkout feature-xx $git pull --rebase $git merge feature-xx-a $git pushCopy the code
  • IntelliJ IDEA development tool built-in mode

Step 1 Refer to scenario 1. This section only shows how to perform step 2.

2.4 Branch use and release process

Responsible person arranges the release plan and executes the release control, paying attention to the front/back end coordination. The test release can disassemble production release tasks and organize phase tests according to the development plan.

Test smoke through the pull branch to continue the development, the version of the bug fixes after closing to the submitted version to re-issue. The specific process is as follows:

Finally, welcome to pay attention to me oh, have a problem private letter I study together, grow up together! Finally, if it helps you a little bit, can you give a thumbs up? Thank you very much