background
I am beginner front contact git, at that time as long as will add/commit something good, online tutorials mostly stay in the beginning to the end about the git command, about various usage, especially the actual processing multiple branch cross back and forth conflict, there are very few in this area is introduced, after many times of practice (trample ray 👻), Want to share a little experience, for the students who just entered the front end of the transition, but after all, 1000 people have 1000 ways to use Git, so it is not guaranteed to be useful for everyone 👀
At present, I am developing and maintaining a large project in the company, including various NPM packages, framework codes, various business common codes and business implementation codes implemented by the company, with a total number of 500,000 or 600,000 lines. Frequent git submission often leads to code turning over. I have experienced several car accidents on site, and I have gained some experience 😂. The front-end code base of our company mainly has dev/test/release environment branch (corresponding to three back-end environments respectively), several large project/feature branches and small hundreds of business branches. The main rule is that the feature branches developed by ourselves are merged into dev (and back-end joint debugging) => merged into test (submit test, students test). Bug correction) => Merge release (test students simulate online environment test, prepare to release online), I feel very clear and simple when I say it, there will be various problems in actual operation, such as natural disasters (temporary modification requirements, background field modification) and man-made disasters (non-standard code submission).
External visualization tools
If you are not familiar with Git, you should choose a git visualization tool first. SourceTree is recommended. Before using GitHub Desktop, the lightweight Git tool can not meet the complex requirements. With the update of the version, it is more and more useful. You can write an article about the use of SourceTree, but if you have a deeper understanding of Git, it’s very easy to get started, saving your brain capacity to memorize commands, and the node diagrams are very intuitive. Those of you who are new to using it are advised to explore. Many operations such as conflict resolution and reset are faster than the command line, and most commands can be replaced with simple operations. If the git repository branch is many and the relationship is complex, pure writing command line git old driver is also easy to crash 😅
Local and remote Origin
Please think twice before submitting code, if using SourceTree, please don’t click on submit and push to remote (very important)
reset
push -f
Extract a single submission cherry-pick
The cherry-pick command is very powerful and is the only git command I use on the SourceTree command-line (as well as revert merge). It extracts a particular commit from one branch and applies it to another branch without affecting the rest of the code. If there is an urgent bug that is about to be released and I change it directly in release, then I must synchronize to my own feature branch and other environment branches such as test. In this case, I do not want to merge, so I need to use cherry-pick. Git cherry-pick XXXXX, git cherry-pick XXXXX
Rollback revert and rollback of a merge
Merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2, merge xxx1 into xxx2 For example, one of my new business branch development tests is getting pretty close, so I’m going to merge it into Release. It’s easy to understand, but after some time, I’m told that it’s not appropriate to add it to release. There are other things that the product has in mind 😳. It only affects the code that was submitted at that time, but the drawback is that a new node can be added to revert merge. Git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m 1 git revert XXXXX -m Since revert is a relatively new node, you have to revert the REVERT COMMIT again (the revert COMMIT is different from the first COMMIT), Merge (merge + revert) : merge (merge + revert) 😎
Branch pollution
Branch pollution is mainly aimed at the parallel development of multiple tasks, such as the coupon function next week, the price comparison function next week, then the two branches must not merge with each other, or indirectly merge, the reason is very simple, but the task is easy to chaos, and, Multiple feature task branches can merge release at any time (preferably often to keep in sync) because it is the final release, but not anything other than release, especially the test/dev branch, which has a lot of random/half-dead projects. This must not go out to another branch, otherwise the other branch will go to Release and bring this garbage online. In summary, the situation is different from company to company, but the general structure is similar, and it is good to have a one-way code flow.
A complex scenario
Actual situation can be complex, because our company to save the user level of various configurations with json, TSX do check for some major components inside the field type, these are automatically generated, sometimes changed only a little configuration, generates a lot of changes, such people repeatedly in different branches after modification, the merge conflicts don’t even know it mama of, This is still the pain point of the current project, it is possible that each merge will take a person half a day of work, such a merge can only be manually modified, with the help of internal tools of the editor, if the later time may change the NODE layer JSON configuration to mongoDB, but there is no good way to configure the local JSON, welcome to the comment area proposal.
Editor internal git tools (gitlens and webstorm of vscode)
Gitlens, a required plug-in in VSCode, has been updated recently, and the functions of merging are almost catching up with WebStorm. The three-column layout of merging is suitable for modifying some complex conflicts. The left and right sides are the current and incoming code, and the middle is your own modification, which is very scientific. Quick comparison with a file in a branch and so on solves many pain points in complex projects.
Submit hooks and bypass
Git /hooks/, which can be modified by yourself, must carry the JIRA task number for JIRA statistics or commit the merge information. But if you want to skip it (rules are made to be broken, 😓), you can set up a hook bypass commit in the SourceTree commit
The problem of the tag
Actual use git in a collaboration project, basic didn’t type the tag, the tag question is that if and branch name, switch/merge branches easy to tag, and hit the wrong wrong tag, must remove the tag with all local, or as long as there is the tag, there was a man of local a push again by remote, It is difficult to remove. Generally, it is easy to roll back when Jenkins is deployed with operation and maintenance by marking the tag of the launch date (but if Jenkins is deployed with non-standard tag and the same name, it will also cause various problems of front-end code base submission).
conclusion
Git is a very simple thing to say, and it is difficult to say. But in my opinion, the most important thing is to develop a good habit of submitting. Think twice before submitting locally, and think again before submitting remotely, so as to avoid tipping over and causing disaster to the team code and affecting the work of others. Pure hand knock out so many words, if feel some help, then I am very satisfied, if there is a problem although mention, common progress!