1 ramble about

Recently, I have been busy with my work and some trifles in my personal life, so I suddenly feel that it is too difficult to write an article. However, I still insist on it gradually, even though the update frequency becomes slower. The latest theme is the same as the original intention, to write down some thoughts on my daily development work.

2 preface Git

In the daily development work, it is inevitable to use Git for code management, skilled use of Git will enable us to have more time to focus on code writing, accelerate the overall development efficiency. For me, however, Git is just a tool, and a few routine operations are enough for me to delve into it when I have time and interest. It doesn’t matter if you are not familiar with Git, just learn it. If you are quick, just read a few commands and then practice them yourself, you can deal with daily development.

3 Common Git commands

In my daily development, I use IDEA to operate Git. Of course, in some scenarios, I will manually type commands in the Terminal panel of IDEA. When you are familiar with it, you will fly comfortably and feel that the codes in each branch seem to be chaotic and managed in an orderly way under your operation of several commands.

3.1 Git Clone Project

Git Clone: VCS->Checkout from Version Control->Git


Of course, also can git clone https://gitee.com/xxx/Test.git to the local before, in the project to import the idea

3.2 Checking Branches Git Branch

See what branches the current project has

3.3 Checking out code git Checkout

Pull the remote branch code

Git checkout -b dev origin/dev

Git checkout -b

Git checkout -b dev(branch name)

It is equivalent to two commands

git branch dev

git checkout dev

Make sure you create a new branch on top of the latest master branch

Git pull/git commit/git push

These operations are really the most basic, I believe that in all commands, people familiar with this account for a large majority, here I usually use IDEA to operate.


If multiple people are working on the same branch, pull the latest code before push, but who wants to make sure that even after you pull, at the moment of push, there is no one to submit the code?

  1. If you have submitted code, IDEA will prompt you to merge when you push. If there are no conflicts, git will merge automatically, and git will record this line in the log

    Merge remote-tracking branch ‘origin/dev’ into dev

    Git logging is no longer a straight line. If any conflict exists, manually resolve it.

  2. If you pull first, it is better if there is no conflict. If there is conflict, you will pull and fail, indicating that local changes will be overwritten.

    • This is where you can temporarily store your changes with git Stash.

    • Git pull pulls the code after successful staging.

    • Git unstash updates the temporary code to the current branch.





Local code on the left, remote code on the right, and code in the middle after a successful merge


3.6 Canceling Operations

  1. If you want to abandon your changes before committing, just right-click the file to Revert.

  2. Commit not push, want to undo commint operation.

    Git reset –hard HEAD~ –hard

    Git reset --soft HEAD~ --soft

    Git reset –mixed HEAD~ –mixed

    GIt->Repository->Reset HEAD…

HEAD~ previous version

Git reset –hard HEAD commit_id git reset –hard HEAD commit_id

  1. After push, I want to go back.

    The above operation can still be used, but after the next push, the previous version will be retrieved and merged with the current change, so there is a conflict to be resolved.

Git merge

Here I tend to do things graphically, merging remote code into my current branch.

Merge dev(branch name) into current

4 multiplayer development co-op mode

The development collaboration model is simply git branch management.

Each company has its own management standards due to the different volume of services and number of servers.

The simpler ones might be the trunk master and the development branch dev.

There are even test branches and pre-release branches.

Of course, the names for these different scenarios are your own, but no matter how simple your project is, it’s best not to simplify it to just the Master and Dev branches.

I once worked for a company where there were only master and Dev projects, and I said to the developers at the time, “Won’t you have any problems doing this?” I didn’t think it was right, so I standardized the branch management.

What's the problem with that?

  • Master is a stable code branch on the line, generally can not be directly modified on the above, then the product comes to two or more requirements, due to the different schedule can not be launched at the same time, then you share the same dev, that is not to others have not tested the code on the. You may say that our company does not have much demand, and only after launching a function can we develop the next function. Then you privately want to write some demo test optimization, and you should change it on dev.

  • I want to test and launch the two functional requirements together, so I am in dev development? It’s best to split up and build your own branch development so that other colleagues don’t kill your code because they’re not familiar with Git while trying to resolve conflicts. After want to go online together and then merge together.

Master + multiple feature branches, that’s all:

  1. Demand down, inLet's create a functional branch on the master, name f+ time + function name, for example: f_20200521_coupon(define A for now).
  2. Local development, server testingDirectly deploy the code for the functional branch.
  3. When the test passes and is about to go live,Checkout is the local master, and Git pull pulls the latest code.
  4. againSwitch back to its own functional branch A and merge matser into CurrentManually resolve conflicts.
  5. If you want to go live with someone else’s branch (definition B for now),It's best to ask your partner to merge the master code firstCheckout B, merge A, merge B
  6. inMerge A into matserThere is absolutely no conflict.
  7. After merging into masterDelete your own functional branches.
  8. The master is deployed on the server.

Why is there a third step? For steps 4 and 6, make sure your local matser is up to date, go to step 6 after step 4, because the master is up to date and has resolved conflicts in step 4, there will be absolutely no conflicts in step 6.

Why not merge A into current (master) directly after step 3? For security purposes, the master is generally a protected branch that cannot operate directly locally.

Why merge A into matser in step 6 after step 4? Are you kidding me? Merge A into Matser cannot be performed locally, but only on gitLab (git private server). However, you cannot manually resolve conflicts on GitLab. So we need to merge the matser into A locally and resolve the conflict manually before going to step 6 to merge perfectly.

Is not dizzy by me…… ?????

In addition, if you encounter an online bug that needs to be fixed urgently, you can also set up a functional branch and follow the above method.

If you just want to change the online minimal functions (copywriting, simple judgment and so on) and want to quickly online, and you have the permission to operate matser, then you don’t need to follow the above way, directly master after the submission of changes on the line, how cool is it?

Five Suggestions

[Tip 1] Make sure you create a branch on the latest master, otherwise it will launch with someone else’s untested code.

[Suggestion 2] Submit the code after completing a function point to avoid code loss caused by unexpected events. When working with others on the same branch, commit early to avoid resolving conflicts and leave it to others hahaha.

[Tip 3] If you are not sure whether it will be handled improperly when resolving a conflict, it is best to bring along the colleague who wrote the code before you.

[Suggestion 4] It is better to inform the development group after the online merge to master, and let other development colleagues pull the latest master code to merge into their branch as soon as possible.

[Recommendation 5] Associated with Recommendation 4, the development cycle is long, so you should merge the latest online master to the branch under development in time to avoid a lot of conflicts before the final online, and avoid new exceptions caused by the modification of the upstream business you depend on as soon as possible.

[Recommendation 6] Irregular code review.

[Recommendation 7] Do not submit local files or some files with personal configuration, such as files in the.idea folder. The IP address in the configuration file should be 127.0.0.1, so that everyone can use it locally and the account password of various middleware can be unified. If you must use your own configuration file, then you should not submit these files to Git, otherwise there will be conflicts with others. (strongly supplement, suffer from)

6 summarizes

This article introduces my usual git commands and some general operations, branch management mode, project on-line specification, daily development suggestions and so on. It is more basic and too difficult to write. It just records my usual work and some ideas.

As a newcomer to Git, it’s no big deal if you don’t even know what git is.

However, if you are the leader of a development team and don’t have a good git management practice, you may need to take it seriously.

For a more complete git tutorial, please refer to Liao Xuefeng’s git tutorial

Git command gifs are also recommended

See you next time ！！！！