small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

Git is a fundamental tool that every developer must have in their arsenal. In a modern and agile world of software development, where codebases are managed by huge teams, having a tool that helps to streamline the process of adding features, changes, or fixes is, without a doubt, a necessity.

Like many tools, git is, with no exception, easy to learn and hard to master. In just one day, an inexperienced developer can learn how to connect to a remote repository, create a branch, push commits, create pull requests, and merge the code. This blog post aims to help developers become more mindful about what and when is being committed to keeping the history well organized, informative and clean.

Keeping the commits history clean helps understand what changes were made to the codebase to backtrack easier if something is not working properly. Not having descriptive commit messages or having too many changes in a single commit are common issues of larger codebases.

![blog-DecodingReactUI_blog_01.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_Decoding_React_UI_blog_01_8c93667a61.png)

#### The easy parts

Every developer knows these commands by heart:

These commands are the foundation of working with Git. However, some of these commands can be slightly modified to create better commits.

##### git add

When working on a new feature, it is often hard to stop in the middle of the process just to create a commit. After some time, the feature is fully implemented. X number of files have been altered, and Y files were added. The time to commit code has come. Instead of creating one big commit, it is often better to have multiple smaller ones, e.g., creating a UI component, creating a test case, updating the types, etc. But the work is already done, so how can one split it now?

Simply by adding `-p` (patch) flag to `git add` command will open an interactive window that will go change by change (it **will not** go through newly created files). Developer will be able to decide whether or not to add given change, skip it or break it down even more. Now all changes regarding the tests, creating new ui components or updating the types can be separated into a different commits. Same file can be committed multiple times containing different changes that are part of a given commit, thus bringing it one step closer to create a clean commit history.

##### git commit

Now that the bigger changes can be grouped into smaller chunks adding a descriptive commit message is next in order.

Adding one `-m` flag will create a header for the commit message that will be shown in the history. However, sometimes one liner is not enough to fully describe the changes because more context is required. Adding another `-m` flag will create a commit's description:

When running the `git log` to display the commit history, it will be displayed as so:

_To quit the git log command, click 'q' on the keyboard._

Descriptions can be improved by adding `$` before the description to introduce better text formatting.


_Adding \n creates a new line_

This will be visible as:


Not every commit requires a description. It is always up to a developer to consider if changes that are being committed require more context or not.

_At Bitnoise, we follow the guidelines laid out by the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure that our commit messages are well structured. This ensures that commits in the history have a similar structure, making them easier to read._

There can be cases where the commit was made, but there was a typo in the code, or some small improvement was still missing. Instead of creating a new "fix typo" or "remove console.log" commit ```--amend``` flag can be used.


It will add all new changes to the last existing commit, so it's super useful for small updates on the last commit (how to update commits that are higher in the history will also be covered later in the blog post).

_Amending will change the commit hash, so if the commit has been pushed to the remote branch, it will be required to force push; thus, amending on shared branches must be avoided!_

#### Bringing it all together

Moving changes from one branch to another is a crucial part of working with git. It serves three purposes:

- shared branch can be merged to a local branch to have it up-to-date with the latest changes made by the rest of the team,
Local branches can be merged into a shared branch to make the new feature or bug fix accessible to other developers in the team (usually via pull request).
- local branch can be merged to another local branch to have them up-to-date

These cases may seem the same at first - making one branch up-to-date with the changes of the other. However, there is an important difference between the shared branch that is being used by the whole team and the local branch that's being used by one developer. The difference is that on a shared branch, the commit hashes should never change (pushing with force should never be required). On local branches, commit hashes can change (until the changes are not merged to the shared branch), and it will not impact the team's work.

In those scenarios, the developer has access to two different strategies: **merging** and **rebasing**.



**When is it safe to rebase?**

- when updating the private branch with the shared / main branch to preserve linear history.
- When making changes to the commits made on the private branch that are not a part of the shared branch, e.g., editing commits, rewording commit messages, squashing commits, or deleting them.

**When is it not safe to rebase?**

- when working on a shared branch like development or main, it's always better to use merge over rebase to ensure that commit hashes will not change and no forcing push will be required. If merge commits are not needed, `git merge branch-name --ff-only` can be utilized to merge changes without adding the merge commit.

  
##### Interactive rebasing

Where rebase surely shines is the interactive version, which can be used to alter the commit history in many ways.

_ n - number of commits in the history to take into the rebasing from latest to oldest f.g if two latest commits should be rebased, then n = 2_

Interactive rebasing allows you to edit committed files, reword commit messages and even squash or delete commits.

When running the command, it will show a window that can look like this:


For example, above following actions can be utilized to organize the commits better:

_When editing a commit, after editing was finalized, `git rebase --continue` should be executed to move to the next commit_

Rebase will go through each listed commit, execute the desired action, and after completion, replace a commit, thus **changing commit hash**, and move to the next one.

_If the commits were already pushed to the remote branch push with force will be required._

When a need arises to edit a commit message or whole commit that is not the latest one (the latest one can be updated by amending with `git commit—-amend`), interactive rebasing truly becomes handy.

#### More is not always better

On the other hand, having 30 commits for a single feature or bug fix might be an overkill and reduce the history's readability rather than improve it. Sometimes, it makes more sense to join or squash some commits into one bigger commit with more substance.

For example:


The commits above are very granular, and it does not make sense to have them separated like that. One can leverage interactive rebasing to squash these commits easily.

The end result may look something like this:

Now, instead of having multiple remove console.logs, typo fix commits can be organized into one big, easy-to-understand commit.

#### Conclusion

Many developers stop learning git after understanding the basics, which can negatively influence the team's work. Clean history is a part of code documentation and improves not only tracking what was done and when but also reviewing the code in pull requests. Tracking where something could've gone wrong when bug fixing is also less painful if commits are well organized.

This blog post shows that small changes to well-known commands can drastically improve the quality of the commits being created. Adding interactive rebasing into the mix will also make any developer an even better team player.

#### Useful tips and tricks

##### Git game

If you're a beginner and those topics still appear too advanced, you may want to check out this [game](https://learngitbranching.js.org) to familiarize yourself with the git basics.

###### Editing name of the branch

Sometimes, a typo can sneak into a branch when creating it. So here is a flow that will allow me to edit branches to fix the typo. 


##### Removing all local branches

When working on a big project, sometimes a lot of old branches can be deleted. Instead of going branch by branch, this command can be used to delete all local branches:

large_blog-DecodingReactUI_cover_high.png

medium_blog-DecodingReactUI_cover_high.png

small_blog-DecodingReactUI_cover_high.png

thumbnail_blog-DecodingReactUI_cover_high.png

blog-DecodingReactUI_cover_high.png

Git Gut: Take care of your commits history like a pro

Frontend engineering

UX/UI Design

Research & Discovery

Services

Case Studies

Career

About us

Blog

Second Bitnoise_meet was focused on the technical debt problem on the front end, both from programmers' and business' points of view.

At Rojber Pub, Bitnoise's experts: Piotr Baranek, Adrian Kępa, Arkadiusz Michowski, Adam Misiorny and Łukasz Roth were talking, among other things, about:

What is technological debt, and why do we want to focus on the front end?
Indisputable features of clean code?
What generates technological debt?
Why is it sometimes(!) worth intentionally running into debt?
(Not)perfect programmer?
Real-life situations - specific problems and specific solutions.
Tips from Bitnoise.
Q&A and discussion.
All disputes were settled during the axe-throwing tournament! ;)  

Bitnoise_meet is a space we create to exchange experiences and learn from each other. We believe that sharing knowledge brings only benefits, and development is very important to us.



small_Blog_artykul_BitnoiseMeet02P_cover_high.png

thumbnail_Blog_artykul_BitnoiseMeet02P_cover_high.png

Blog_artykul_BitnoiseMeet02P_cover_high.png

Bitnoise_meet #2 Poznań

On September 9, we met in Wrocław during Bitnoise_Meet #2 Wrocław edition.
Wrocław was wonderful, as well as the audience. We were in awe of the warm welcome in the capital of Lower Silesia.

Our experts: Piotr Baranek, Adrian Kępa, Adam Misiorny and Krzysztof Proszkiewicz, were discussing such issues as:

- Is technological debt generated by hasty team decisions, pressure from the business side of the project, overengineering, the programmer's ego or something else?

- How does it affect the project, when UX ends up being the least important part of it?

- How important is keeping the balance?

- Can soft skills be a solution to very technical problems?


Bitnoise_meet is a space we create to exchange experiences and learn from each other. We believe that sharing knowledge brings only benefits, and development is very important to us.




small_Blog_artykul_BitnoiseMeet02W_cover_high.png

thumbnail_Blog_artykul_BitnoiseMeet02W_cover_high.png

Blog_artykul_BitnoiseMeet02W_cover_high.png

Bitnoise_meet #2 Wrocław

The existence of the technical debt in all IT projects is often an open secret that nobody involved wants to admit. The scale of the debt and the speed at which it grows depends on many variables. I’m gonna walk you through a few most important aspects of technical debt (in my opinion of course). With that knowledge, your daily developer work will be easier in the long run. Fewer bugs and the easier introduction of new features will surely be rewarding for the team and make the project itself better.

### 1. Keep up with SOLID
The first issue on our list is the fast pace of new features introduction. It often goes in combination with skipping some important design and architecture bits. The new feature is just glued into the project **without SOLID principles preserved**. If it works, it works, I guess it’s good enough, but this is only partially true. If you make these mistakes, they can get back at you in the future and interfere with the development of the project.

### 
2. Skipping Unit testing
The second problem on my list is **skipping Unit testing** of newly introduced features. If SOLID wise features can be placed between trash and garbage, we need at least add Unit Tests. Those can be reused when the feature will be rewritten or refactored. It is important to ensure that the functionality is redone in 100% and don’t introduce any regression bugs.


### 3. Omitted documentation
The third mistake is **forgetting about documentation**. Developers' brains don’t store unneeded information. We forget about feature-specific solutions and hacks implemented after a couple of weeks of the project lifespan. Sooner than later the project-specific elements will be overwritten by new features. And when you get back to the feature that you need to refactor it won't be there. And believe me, that time will finally come. You will spend many hours trying to figure out what the author had in mind. That’s embarrassing, especially when you were… the author.

### 4. Lack of the proper code review
The fourth well-known sin committed by development teams is the lack of **proper code review**. We accept the code that’s good enough. But in many cases good enough isn’t so good in the last place. Later on, we can’t focus and lose the bigger picture. For example, we concentrate on typos in comments instead of critical code failures and risky code structures.

The code review process is the most important point of your software production. With good code review you will:

- mentor junior developers how to code better,

- give feedback to experienced developers,

- show a better approach (if it is possible) and plan future refactoring if the deadline is tight.


Increase in the quality of software 

![ ](\uploads\eight_useful_advices_on_how_to_deal_with_technological_debt_372btLkvd3nXpq8jGV0TW2.jpg)
### 5. Procrastination
The fifth issue is the sight of surprise on the developer's face when he finds a technical debt that wasn't addressed before. All the time, each developer **should be on a technical debt hunt!** When you open a class after a while, and you see the mistakes, don’t procrastinate, address the problem, create a ticket and plan it. Refactor! Fulfill your duty to the project.

### 6. Losing the debt awareness
The sixth problem: losing track of your debt, each commit, each version you and your team released.  All the team members knew that some shortcuts were made. But they didn’t know how far the debt was forced into the project.  **There is a point of no return and believing it's still far away is irresponsible.**  Your team needs to act now!   Audit the project with a static analysis tool. Establish the desired level of debt in your project. Make a plan to refactor most debt-heavy classes. Introduce in your Continuous Integration a step that will run the static analysis tool, and bring you a detailed report for each commit. That will give the team situational awareness about the debt introduced or the debt reduced with this change. Furthermore, it can make the code review easier, because it can integrate nicely with GitHub or GitLab merge requests.

### 7. Skipping Unit testing… again
The Seventh Sin - Unit tests. Yes, we are all **guilty of skipping the unit tests!** It’s hard to write them when the time is crucial. Skipping these tests is risky in all situations. But when you plan a refactor and the features aren’t covered with tests, it can be a suicidal mission for the team, managers, and the dagger for the project.   You need to have the source of truth that will determine if the feature you just refactored is working as intended. Before refactoring, do yourself a favor and test the feature you're gonna work with. 

### 8. Refactoring the trouble-making solutions
The Eighth, final, and most important problem - in my op

inion - is **building a team awareness** that with any chosen approach we will always introduce some amount of technical debt into our project, simply because of a need of meeting business needs and given deadlines. But, having this in mind, we also need to be aware of the fact that in the next iteration we're gonna deal with that debt by refactoring the trouble-making solutions.

### Summary
That awareness is a key to keeping the debt at bay. When you can address the problems you created, prioritize and plan tickets to refactor parts of code that have the heaviest impact on debt and project.

**Tips and tricks to avoid the technical debt**

Don’t deny the existence of the technical debt in your project. Raise awareness about it among your management. Define weak spots and prioritize tasks. Plan the refactor in your development cycle (time-box the refactor tasks). Write the tests to ensure that refactoring won’t damage anything fragile. Do the refactor itself. Track the progress of the refactor with a static analysis tool. And keep your team sane and they won’t be afraid to work with your well-maintained project.



Git Gut: Take care of your commits history like a pro

Michał

How to keep your team sane while dealing with technical debt?

Max

Bitnoise_meet #2 Poznań

Magdalena

Bitnoise_meet #2 Wrocław

Magdalena

GET IN TOUCH