![]() After that it’s time to launch GitKraken, my preferred GUI for giving me a visual overview of repo and the uncommitted changes. This is nothing but an alias for git reset HEAD~1 -mixed and resets my branch to the commit preceding the aforementioned SAVEPOINT while keeping the changes in the working directory. How I keep my history cleanĭepending on the situation, it often starts with the following commands. So let’s look at the development workflow I’m using myself. IMO, that either means somebody lacks the ability to structure their work (which is a problem by itself), or is not using the right tool for the right job. Quite often, you’ll hear excuses along the lines of “it’s too complicated” or “I don’t work/think like that”. That’s true, but IMO much more work compared to what I’m going to show you below. ![]() ![]() Others also say its better to move those unrelated changes into separate PRs. Some even go further with so-called Atomic Commits, but I’m not yet ready for that level of discipline. It either copies the title and description of the most important commit, or, if you decide to squash everything, should contain everything I just mentioned. The same applies to the PR title and description. Even if you only did it to stay up-to-date, I’d like to see that mentioned in the title or description. Quite often there’s something that triggered you to bump that library, so I want to understand why. So a simple Bumped Json.NET to 10.0 is not enough. ![]() And if all of this means that I sometimes have to start a new branch, copy those unrelated changes or reapply a refactoring, and then get that merged through a separate PR, so be it.Įach commit also has a title and description that explains what it tries to do and why. I even keep unrelated one-liners in separate commits. So anything else, like refactorings, moving of files and renames of code constructs go in separate commits. First of all, each commit should contain only closely related changes. Well, if you ask me, there’s a couple of things I do myself. And isn’t that the entire purpose of peer reviews? And don’t dismiss the fact that a nice focused commit makes cherry picking or porting some related changes between branches much easier. In fact, I’ve started to observe a direct correlation between the clarity and structure of a PR and the thoroughness of the review. You won’t believe how often I see a 100-file PR getting approved without a single comment. I also prefer to be able to do a code-review of a pull request (PR) commit by commit and not having to drill through hundreds of unrelated code changes at the same time. I regularly use Github’s excellent blame view and particularly like that little icon in the gutter to go back into history. To capture that past, I will make sure we capture design choices in Architecture Decision Records and try to deliver my code changes in well-structured commits. But after 23 years of software development experience, I’ve learned to value the past. Maybe they only write new code and never have to maintain anything they, or others, have written six months ago. I don’t have such skills, and don’t believe anybody else has. Or they have some special skill that allows them to deduce the purpose of a block of code just by looking at what the code does right now. They remove weird constructs because they somehow know why it was needed in the first place. For some reason, they are capable of rewriting code without the need to understand what that code was trying to do in the first place. I could not believe that is true, until I’ve met such folks in person. I’ve heard stories that there are people that believe that the code is the only documentation they need. How I keep my Git source control history clean
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |