CHERRY PICK COMMITS TO MERGE SMARTGIT HOW TO

Performs refactoring, builds it and passes to the testers. The developer starts the fix branch, prepares a fix and then starts a refactoring branch from the fix branch. As we have limited testing capabilities, more efficient is to test fix and refactoring at the same time. But this has a serious drawback: even though refactoring doesn’t change functionality, some bugs can be introduced. The simplest would be to do a fix, merge to main, start a new branch with refactoring. Additional refactoring – solutionįortunately, we’ve found the solution to this problem.

What if we examine the commit log and see the fix-commit that contains 5000 lines? What was the actual fix and what just refactoring? This situation breaks the very important rule of single responsibility ( SOLID applies not only to the code). But this is not a very big problem, because the author can be asked about it.

CHERRY PICK COMMITS TO MERGE SMARTGIT HOW TO

How to do a code review? The reviewer would not know what is the fix, and what is refactoring. The refactoring affects almost 5000 lines. Now, imagine that you fix a bug in the class with 5000 lines. This means that each time bugfix is done, refactoring of the adjacent code should also occur. As we have thousands of classes, each with hundreds or thousands of lines of code, the amount of work even for such simple refactoring is huge and all team members should do this as often as possible. This is simple, but we need it to do more radical changes. The first step is the simplest and contains everything that ReSharper offers out of the box – names could be changed, unused code removed, comments limited or deleted, things like that. Refactoring such complicated code is not easy and very limited in most cases. Additional refactoring – problemĪs I mentioned, the system is of type „legacy” and requires to be refactored.

Additional refactoring with file splitting.

This works like a charm in all standard cases. And merging policy states that it should be done by squash merging. Then teammates could do a code review, testers can test the fixed application and if everything is ok, PR can be completed.Ĭompletion means that the bug branch is merged back to the main release branch.

When the bug is fixed on the bug branch, PR is created. Most important for this post is the Pull Request (PR) feature. We also use Azure DevOps with all its goodies. This limits the number of irrelevant noise in history and it works well in general. To avoid all commits from feature branches being presented in the history, squash merging has been introduced – probably from the beginning of the Git repository. Bugs have to be fixed in different versions, and I guess that even 30 feature branches are merged to corresponding release branches daily. We have 6 or 7 main release branches (including the master containing the recent version). Without history, work would be even harder. Usually before correcting it, one has to read this description. The reason why the line of code was added is described in a related ticket/bug. Which means that code history is extremely important. This leads to another problem – average knowledge about the system and domain is low. Its size is not important – it’s big and old. It consists of probably a few millions of lines of code.

The system is developed by many programmers. But how to do refactoring from Git’s point of view? To make the history clear and neat? I will try to tell you how we do this. It’s complex, released in many different versions, and definitely needs to be refactored.

Cherry pick commits to merge smartgit