Software Developer Blog |

Summary of The State of AI-assisted Software Development Report

2026-02-26T04:00:00+00:00

This year’s edition, of the DORA research, entitled State of AI-assisted Software Development, focused on the impact of AI assistance on software development.

What is DORA

DORA is the largest and longest-running research program, analyzing IT organizations of various sizes and in many different industries around the world each year.

The researchers used a rigorous statistical evaluation methodology to identify the common characteristics of successful companies. The analysis covered practices and factors affecting the effectiveness of teams involved in software development.

Full report available at dora.dev/research/2025/dora-report.

AI Is Already the Standard, but It Doesn’t Replace Thinking

AI in software development is no longer an experiment: 90% of surveyed developers use AI at work, and more than 80% report increased productivity.

At the same time, as many as 30% of respondents have low trust in AI-generated code, which demonstrates a mature approach to verifying the results of AI “work.”

AI genuinely accelerates development, but it requires critical thinking and solid engineering practices.

AI Amplifies What’s Good — and What’s Bad

The key takeaway from the report: AI does not fix systemic problems — it amplifies them.

Organizations with strong architecture, clear processes, and a healthy work culture gain the greatest benefits. Where chaos, technical debt, or poor collaboration prevail, AI leads only to local improvements that get lost in later stages of delivery.

With AI, Productivity Increases — but Stability Still Suffers

In 2025, for the first time in DORA research, AI genuinely increases throughput (the speed of delivering changes).

At the same time, an increase in delivery instability is still being observed (more rollbacks, hotfixes, and unplanned work).

This signals that teams have learned to write code faster with AI, but quality control and feedback systems are not keeping pace with this pace.

Platform Engineering Is the Foundation of AI Success

As many as 90% of organizations have adopted platform engineering, following the concept introduced in the book Team Topologies.

The report clearly shows that the quality of the internal developer platform is crucial for realizing tangible benefits from AI.

Additionally, Value Stream Management (VSM) acts as a “force multiplier” — it enables organizations to convert local time savings (e.g., faster code writing) into real business outcomes, rather than generating more downstream chaos.

AI Adoption Is an Organizational Transformation

The greatest return from AI comes from investing in the system — not merely in models or licenses.

The new DORA AI Capabilities Model identifies seven key capabilities that determine success:

A clear and well-communicated AI position
Working in small batches
Healthy data ecosystems
User focus
Internal data accessible to AI
High-quality internal platforms
Strong version control practices

Summary

AI is now a standard part of software development, but it does not solve organizational problems. It acts as an amplifier: the best teams become even better, while weak systems become even more chaotic.

Real value from AI is achieved only by organizations with solid technical, process, and cultural foundations.

Replacing Planning Poker with Team Estimation Game

2025-12-20T04:00:00+00:00

Planning Poker has been with us for years, and it works to a certain extent. But it has its drawbacks as well…

What is the Team Estimation Game

The Team Estimation Game is a collaborative, fast-paced estimation technique focused on relative comparison rather than individual voting. Instead of estimating one item at a time, the team works with many backlog items simultaneously.

On the internet, you can find many complex variants of it, yet I’m a big fan of its simplest form.

Keep the Big Picture during estimation

In the Team Estimation Game, the team works on the whole sprint scope and looks at all stories/tasks at the same time, reasoning about them all at once. In Planning Poker, you focus on one story at a time, estimate it, and then forget about it. That’s a meaningful difference.

Preparation

You can play remotely using any online board you like (like Miro/Lucid), or locally with classic sticky notes and a whiteboard or even just on the table.

Draw columns according to your scale

Not to end up with estimation more granular than your current scale, prepare columns upfront. For example, assuming you estimate in story points: 0, 1, 2, 3, 5, 8, 13, 21, draw 8 columns.

List players

You’ll play in turns, so to avoid messing up the move order, prepare a list of players in some accessible place.

Bring stories/tasks

Prepare sticky notes (literally or virtually) with stories/tasks - those will be moved back and forth during the game.

The Game

As a facilitator call players by name, start by calling first person on the list instructing them to move one card. Keep up the pace by calling the next player shortly after the previous person finishes, especially during online collaboration, prone to distraction.

Move one card or pass

Each player moves one card either from the stack to the board or from one board column to another. It’s allowed to move a card in between, moving existing cards to the column on the right or left. When everything already looks good to you, you can pass your turn. Everyone is allowed to do any move they want, explaining the reasoning behind. Others can ask questions, but cannot ‘block’ someone’s move. Obviously at some point when some players disagree, deeper discussion and some compromise is inevitable.

The Results

At the end, when everyone is satisfied with the current state of the board, the game is finished and you have nice estimations focused on references to each other :)

The Matrix

Instead of columns you can prepare two-dimensional matrix, for example with value/effort or risk/effort, to gain deeper understanding of the tasks and maybe give up some less valuable stories or those with bigger risk.

Summary

That’s it — a very simple exercise that brings more precise estimations and deeper understanding (through the discussions that took place) than classic Planning Poker. Obviously, quick Poker sessions still have their place, but when planning a whole sprint, the Team Estimation Game is my go-to approach now.

Introduction to Git Bisect with CodeceptJS automation example

2020-01-10T06:00:00+00:00

Many developers have heard about Git Bisect, but only few gave it a try. It’s a pity, because it can… find a bug without your attention!

Git Bisect is a tool which comes pre-installed with Git, which is meant to find particular commit. But unlike Git log it’s not meant to find commit by its details, for example commit message or introduced changes, but by behaviour which it introduces to system.

How Git Bisect works

Git Bisect uses binary search algorithm to check commit. You need to set commits range and then Git Bisect checks commit in the middle of the range. If behaviour which we are looking for exist in this commit, then Git knows that it was introduced in first part of the range, otherwise in the second part. This way range gets smaller by half and then algorithm repeats up to the point, when Git is sure which commit has introduced given behaviour. If you create small commits and each of commit has one, consistent change into the system, then you not only see which commit introduced given behaviour, but also which changes in code are guilty.

How Git Bisect knows that particular commit has given behaviour

When Git Bisect has selected the commit, there are two modes to check if system at this point of time had given behaviour.
You can do it manually - simply run the system and tell Git the answer or…
You can do it automatically. Just pass to Git Bisect script or program which tests system and returns 0 exit code if system works good or exit with a code between 1 and 127 (inclusive, except 125), if currently there is bad behaviour.

Can Git Bisect be used to other purpose than finding a bug

Usually we talk about bad behaviour - a bug, that’s why by default we operate with terms good and bad, but you can use Git Bisect to find other type of introduced behaviour, for example improved performance, so you can use alternate terms. By default, you have two alternate terms given: old and new, but you can set up your, to make bisecting easier to understand. If you want to know how to achieve it, it’s described nice in documentation, I don’t want to lose focus on general usage here, so let’s move forward.

Git Bisect manual demo

Let’s imagine, that we have noticed, that our system at the newest version has regression bug, which for sure did not exist in last release, tagged as v1.2. To start bisecting we need to write git bisect start. Then we need to set end of commits range, by writing git bisect bad *COMMIT_ID*. As we know that the newest version has it, we can skip *COMMIT_ID*, to have HEAD taken. Then we need to set beginning of commits range, by writing git bisect good *COMMIT_ID*, which in our case it’s git bisect good v1.2.

When commits range is set, Git chooses first commit. Output may look like this:

Bisecting: 10 revisions left to test after this (roughly 4 steps)
[3007a714657da73173b7236d3821bbea0555bd2b] Adjust fonts

Now we need to check system: recompile, run, and test manually if bug exist. If so, then write: git bisect bad. If bug doesn’t exist, then write: git bisect good.

This process repeats until commit which introduced the bug is found, which is indicated by commit details printed out. At this moment we are still in bisecting mode. To finish it, we need to write git bisect reset, which returns us to the commit that was checked out before git bisect start (unless you don’t specify other commit id as parameter to reset command).

There are other commands to use during bisecting, but they are additional. If you are curios which are those, they are described clearly in documentation. I don’t want to distract us, so will skip them here, with exception to one convenient command: git bisect visualize, which shows us current commits range and currently selected commit. If you have gitk installed it will show you there, otherwise in terminal.

Git Bisect automated demo with CodeceptJS

Of course, checking if bug exist is a boring process which usually can be easily automated. As our system is website, we will use CodeceptJS. Initializing it, and creating test scenarios is out of scope of this article, so if you’re new to it, just follow theirs official manuals. We need to describe behaviour in test scenario, which need to be initialized in directory outside of our repo, or in untracked file in our repo, to have it unchanged when Git Bisect changes commits. Of course after finding bug, we will commit those new scenarios to rest of our system test scenarios, to not have this regression any more in the future.

Let’s assume, that in our case we run webserver once, and it refreshes itself when files change, during commits switching (like for example Jekyll does).

Then we need to start bisecting and set commits range like before. Next, instead of telling Git whether given commit is good or bad we run automated testing: git bisect run node codeceptjs run --steps. The first argument after run keyword is the script/program to run, next are arguments which will be passed along. In our case it’s CodeceptJS with its arguments. If you don’t have CodeceptJS globally installed you can pass path for example from node_modules directory: git bisect run node node_modules/.bin/codeceptjs run --steps.

That’s it, Git Bisect will check every chosen commit with this script to the point, when it knows which commit introduced given behaviour, in our case - a bug. Like in manual process you need to reset bisecting mode at the end - git bisect reset.

What if you need to compile system during every check, or do some other preparations? It’s not a problem, you simply need to put those tasks in script/program which got executed by bisect.

Video demo

In my view Git bisect with automated tests look spectacular, so I have created a video Demo, if you prefer to watch before trying yourself :)

Summary

To summarize, Git Bisect is a simple tool, which can be really helpful. When? In situations, when you have a bug (or other behaviour), which is hard to debug, so it’s easier to find which commit introduced it, especially when you create small, consistent commits. I have seen developers who do binary search manually, counting and switching commits.

It’s giant help especially, when you have good automated tests, so you can just add new test scenario, then Git Bisect will take care of rest of the job.

Do you use Git Bisect or have some thoughts about it? Please share it through comments. And send this article or video demo to colleagues who hasn’t heard of it :)

Error 459 - permission denied while trying to run git bisect with script

2019-11-16T06:00:00+00:00

How to fix error occurring during git bisect run - 459: /usr/lib/git-core/git-bisect: script.sh: Permission denied.

Full logs of git-bisect with 459 error

As you see, problem with running script doesn’t stop git-bisect so it finishes job. I hope in the future Git team will improve this, to stop when something goes wrong - such result is not reliable, there is no point to continue process.

~/Projects/app ((no branch, bisect started on fix_bug)) $ git bisect run /usr/lib/git-core/scripts/check-app.sh
running /usr/lib/git-core/scripts/check-app.sh
/usr/lib/git-core/git-bisect: 459: /usr/lib/git-core/git-bisect: /usr/lib/git-core/scripts/check-app.sh: Permission denied
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[0e804f177d84772564ef74cb3905c4c1147d2f78] commit title
running /usr/lib/git-core/scripts/check-app.sh
/usr/lib/git-core/git-bisect: 459: /usr/lib/git-core/git-bisect: /usr/lib/git-core/scripts/check-app.sh: Permission denied
Bisecting: 1 revision left to test after this (roughly 1 step)
[e02f6d38ed24ee37caddd494e04742dcfa2eef84] another commit title
running /usr/lib/git-core/scripts/check-app.sh
/usr/lib/git-core/git-bisect: 459: /usr/lib/git-core/git-bisect: /usr/lib/git-core/scripts/check-app.sh: Permission denied
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[4abe5155e0b4781b3247b289ebea23c081889150] yet another commit title
running /usr/lib/git-core/scripts/check-app.sh
/usr/lib/git-core/git-bisect: 459: /usr/lib/git-core/git-bisect: /usr/lib/git-core/scripts/check-app.sh: Permission denied
4abe5155e0b4781b3247b289ebea23c081889150 is the first bad commit
commit 4abe5155e0b4781b3247b289ebea23c081889150
(COMMIT DETAILS)
:040000 040000 92dfff033a3f883db1311fe9a8a3b50a5c901cbd a60d2bf636421197930d7194fbd56b954880e50e
bisect run success

Quick solution

Quick solution is to allow everyone to access directory with script.
To do so you just need to use chmod command like this:

# Make directory available for all 
chmod -R 777 PATH_TO_DIRECTORY

In my case it was fine, I have even moved whole script to /usr/lib/git-core/scripts directory, so it’s globally available now, so I didn’t investigate what exactly has gone wrong.

Summary

To summarize: 459 access problem can be fixed without investigation, but only if giving permission for every user is acceptable in your case. If this quick solution is not enough for you or doesn’t work in your case, please share your own with others in comments :)

Store Git SSH key pair in Linux with Libsecret to skip asking for credentials

2019-11-04T10:00:00+00:00

If you have to connect to Git via SSH, your usual credential manager may be not enough. Read how to avoid entering password every time on your Linux device.

I have already introduced Libsecret Git credential manager, which works fine if you connect to remote repo via http(s), which is what we usually do. But sometimes we are forced to use SSH protocol, and once again we need to write password every time we interact with remote repo. Luckily it can be solved in secure way quite easily, but unfortunately descriptions which I found on the internet are not clear, moreover usually skip securing private keys. My goal is to explain it in this article in simple words, so you can apply it and understand what you do.

How automate SSH connection works

Mechanism which is used in SSH to automate connections is really simple. You generate public-private keys pair (those keys are not related to credentials nor any other data), hide private key with you and share public key with server. Then when you try to connect to server, your clients uses private key as prove that you’re allowed to connect - that’s it.

It sounds quite magically, but it’s really simple. Those keys are just text files, stored somewhere on your device, usually in ~/.ssh directory. They are not related to any data, it’s just a pair which suits each other, in mathematical meaning, you generate it with OpenSSH tool. Look at this example (with default file names id_rsa and id_rsa.pub):

Private key file: ~/.ssh/id_rsa

Public key file: ~/.ssh/id_rsa.pub

You store both files in your device and save public one in server which you want to connect, at proper path - that’s it. If you want to read more about key pair mechanism, article on ssh.com explains it nice.

How to configure automatic SSH connection

Once you know the theory, it’s time to try automated connection in practice. First I will show you the process with Seahorse tool which I find convenient for this task, but of course you can achieve the same with command line, which I will show later.

In Ubuntu and Linux Mint Seahorse comes pre installed with OS and you can find it as Seahorse or Passwords and Keys. I’m pretty sure it’s not difficult to install it in other distros, so if you don’t have it already, just search how to install it in your case. It uses libsecret abstraction which was created to unify access to sensitive data, so it should work on all popular Linux distributions.

If you don’t see secrets categories on the left side of Seahorse, set View » By Keyring.

Create SSH keys

Choose OpenSSH Keys category and press + button

Select Secure Shell Key

Now give your keys some description, to remember what is this for. This name will be seen on server, so you can write here your email address, to simplify server administration (so maintainer could know who uses this and if it’s still required).

Choose encryption type - at the time of writing the only available options in Seahorse are RSA and DSA - it’s a bit subjective, but I suggest choosing RSA as explained on security.stackexchange.com. There is a way to choose Ed25519 algorithm which is more secure and gives better performance, but currently only from command line.

RSA key strength can be left 2048 bits as is by default. You can increase it, but be aware that some devices may not support it and that it takes a bit more of resources to work with bigger number. But if you insist, 4096bits should be fine. Here is nice article which explains RSA key size topic with details.

From this point you can choose two options:

Just Create Key
Create and Set Up

With second option you will populate newly created key to server right from this wizard, so that’s what we will do. If you don’t have access to server at this moment, you can just create key and populate it later from command line.

Encrypt SSH keys with password

Next you will be asked to write passphrase for new secure shell key. It may be a bit confusing - you may wonder if this password must match SSH user password - it doesn’t need to, moreover - it shouldn’t - it is different password so it should be different (you won’t need to remember it). If you leave it blank your private key will be saved on disk unencrypted, which causes security risks. Despite some people advice to leave it this way I don’t see any reason not to encrypt it, that way or another you won’t need to remember it - we will use keyring for that (but it this moment save it somewhere, preferably in some password manager). Enter strong passphrase, I recommend using some tool which will generate it (I use KeepassXC), then enter it again as confirmation.

Check created keys files

Now you should have new files in ~/.ssh directory, as described earlier - id_rsa with private key and id_rsa.pub with public key. If you skipped encrypting private key you will see it in plain text, otherwise it will be encrypted and will contain header which indicates encryption, for example: Proc-Type: 4,ENCRYPTED.

Send public key to server

If you decided to create key and set it up, you will now see new Window - Set Up Computer for SSH Connection. Write your server address and a port in format server:port then your login name and press Set Up button. You will be asked for given user password.

Connect and store encryption password in keyring

If setting up succeeds, then in user directory on server will be copy of your public key in ~/.ssh directory in authorized_keys file - connect to server and check if it is there. It may look like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxGhrhgMsQqOvXf+M1z04toa65/8vY6b+lzjAas7YJqut65o0ONWItpz2UHXSl0mFlbN49UR6VDR9jesUKW+vfuIRUaPs+8/bNEP5tIzPq3lSvw1msYNBT2kbQWO5+Qqiy7EXf/RJ7z4BGiBDEZ4rRhjxIrPAuaxeOpWU6KEDlsxCczxZWgl2xcldhk5oJwzItNd2piQlr7r2CYibHU36XtELvAhlTI1/p11rfSf/BwGtCxb25dApg8k/yRw2zpdV/JD0nfNQiESnCSmLxDr66WK5dScpXQ8zRMRSM3ekoo2ElkDEl9gQ9PhrqdKDLiPqgbobhi22ro4GKsHHAy2VF GitGitRsa

Do it as usual, just: ssh user@server.com -p 22 To see file you can for example write: cat ~/.ssh/authorized_keys

When you try to connect for the first time, you should be asked for password to Unlock private key. Set Automatically unlock this key whenever I’m logged in checkbox and since now it will be unlocked along with your login keyring, when you log in. You will no longer see this window and your private key will be encrypted - like I told, there is no reason not to encrypt it, it’s secure and convenient at the same time.

In my view if Seahorse works in your case, it’s convenient to use it’s wizard, but there is one exception: when you want to use Ed25519 algorithm which, like I told earlier in this article, is more secure and gives better performance, you must use command line, as at the time of writing it’s not supported in Seahorse wizard.

Bellow steps are exact equivalent of previous from Seahorse tool, just written from command line 😺

First generate a new Ed25519 SSH key pair (if you haven’t done it already):

ssh-keygen -t ed25519 -C "description or your email"

If server which you want to reach doesn’t support Ed25519 or if you have old version of OpenSSH on your PC (Ed25519 was introduced to OpenSSH in version 6.5), use RSA instead:

ssh-keygen -t rsa -b 2048 -C "description or your email"

Description or email is optional, but it’s good to put some convenient information here, because as I described earlier, this name will be seen on server, so it should identify you, so administrator will know who uses it.
If you wonder how many bits should have RSA key size (in above example 2048 bits), it’s the same case which I described during key creation with Seahorse tool. The bigger number you choose, the better security you have, but it comes with a bit bigger resources usage, and with risk, that it will not work - some devices don’t support length bigger than 2048. I recommend good article about RSA key size length, for those who want to understand choice better.

First you will be asked about path where to save keys - use default option by hitting Enter. If you’re warned that key already exist, you must choose custom path and later set up ~/.ssh/config file.

Next you will be asked for encryption password. This is not your SSH user password, so create strong password, different than user’s one, the best option is to generate it with some tool. You won’t need to remember it, but before you configure everything, save it somewhere - the best option is to use passwords manager - I recommend KeepassXC. I described why to do that in earlier part of this article.

Now you can check created keys files to ensure everything worked as expected.

If you had to enter custom path for keys, now you should configure it:

# Only if created keys at custom path 
eval $(ssh-agent -s)
ssh-add ~/.ssh/YOUR_NEW_PRIVATE_KEY

And save ~/.ssh/config file as in below example:

# Only if created keys at custom path 
Host gitlab.com
  Preferredauthentications publickey
  IdentityFile ~/.ssh/GITLAB_COM_KEY

Host github.com
  Preferredauthentications publickey
  IdentityFile ~/.ssh/GITHUB_COM_KEY

Next you need to copy your public key to server, this can be done with one command:

ssh-copy-id user@server

or if ssh-copy-id utility is not available on your device, you can use plain ssh solution
(change PUBLIC_KEY.pub to what you have generated, for example id_rsa.pub):

cat ~/.ssh/PUBLIC_KEY.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"'

Next check if public key is copied as expected and store encryption password in keyring.

Troubleshooting SSH key pairing

If automate connection doesn’t work and you don’t know what has failed, and you have only one remote SSH server, you may want to try everything from scratch - maybe you made some mistake? That is what helped me, but use it only if you’re sure you don’t have any other keys already and just in case copy files as backup.

Remove all files from local ~/.ssh directory.
Remove all files from remote (server) ~/.ssh directory.
Try setting up everything again. I suggest reading short description how key pair automation works, to know what is happening during process.

If you see that keys are generated correctly, but copying to server failed, try to copy it manually (it may require sudo access):

Copy public key to server, for example with scp - scp ~/.ssh/PUBLIC_KEY.pub user@server:/home/user/PUBLIC_KEY.pub
Login to server as usual, for example: ssh user@server.com -p 22
Create .ssh directory, for example with command: mkdir ~/.ssh
Append the public key content to authorized_keys file: cat ~/PUBLIC_KEY.pub >> ~/.ssh/authorized_keys

If your key is copied to ~/.ssh/authorized_keys file on server but automate connection doesn’t work, try changing remote user permissions to 711 (some people advice to do it as well for user home directory) - you may need sudo access:

Login to server as usual, for example: ssh user@server.com -p 22
cd ~
chmod 711 .
chmod 711 .ssh/
chmod 711 .ssh/authorized_keys
chown -R USERANAME .ssh/

Summary

If you have any questions feel free to ask them in comments, or just to tell if this article has helped you. If you know someone who also uses SSH protocol to manage remote Git repo, don’t hesitate to send him or her link, it may help yet another person and I will be glad too :)

Libsecret - remember Git credentials in Linux Mint and Ubuntu securely

2019-03-06T06:00:00+00:00

Typing username and password every push is burdensome and irritating… libsecret git credential storage to the rescue.

When you want to use external git repository hosting service, like Gitlab or GitHub you need to authorise yourself. Git has built in credential helper mechanism, which allows choosing the way you have credentials persisted. It gives you two options out of the box, but you’re not limited to them - you can install third party solution.

Cache credential helper (out of the box)

Cache is quite secure because keeps data only in memory. It’s fine for security, but every time you open new session, you need to type credentials again. Memory is purged after 900 seconds (15 min) by default, but it can be changed with optional timeout parameter.

If for some reason you don’t want to install anything, at least use cache :)

git config --global credential.helper 'cache --timeout=300'

Official description - git-scm.com/docs/git-credential-cache

Store credential helper (out of the box)

Store keeps your username and password in… plain text file! It’s totally insecure and use it only if you don’t care about your account (for example during some kind of workshops).

git config --global credential.helper store

Official description - git-scm.com/docs/git-credential-store

Git Credential Manager for Mac and Linux (by Microsoft)

Windows users are familiar with convenient Git Credential Manager for Windows which is integrated with OS way of storing credentials. It can be installed with official wizard or during git installation on Windows (there is checkbox to select). And recently Microsoft announced release of… Git Credential Manager for Mac and Linux. I was positively surprised, till I tried to use it on my Linux Mint 19 Tara. Installation was successful (but not without complications) and attempt to use it ended up with error:

Fatal: java.lang.RuntimeException encountered. Details: 
Secure credential storage is not available on this operating system. You may opt-in to store credentials in an unencrypted file under your user home directory by running 'git config --global credential.canFallBackToInsecureStore true'.
fatal: credential helper '!/usr/lib/jvm/java-11-openjdk-amd64/bin/java -Ddebug=false -Djava.net.useSystemProxies=true -jar /home/linuxbrew/.linuxbrew/Cellar/git-credential-manager/2.0.4/libexec/git-credential-manager-2.0.4.jar' told us to quit

I have opened the issue and till now I haven’t received any response (more than 2 months) and recently I have seen the same issue created for Ubuntu 18.04. So currently it doesn’t work on Linux Mint and Ubuntu.

Official description - github.com/Microsoft/Git-Credential-Manager-for-Mac-and-Linux

Libsecret git credential storage (by GNOME)

The best way to store Git credentials on Linux used to be GNOME Keyring (libgnome-keyring), but as it is specific to GNOME, it is deprecated since January 2014. For Git versions 2.11+ you should use credential helper based on libsecret. Installation and configuration takes only 4 bash commands :)

sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

That’s all, next time when you’ll be asked for your username and password will be the last time on this device :)

Official description - wiki.gnome.org/Projects/Libsecret

How to secure SSH credentials

Above credential managers work only if you use http(s), which is usual case. If you have to use SSH protocol, I have described how to skip asking for credentials with SSH key-pair in safe manner, in another article.

Summary

As you see it’s not difficult to protect your credentials and not have to type them all the time. If it doesn’t work for you or you have some question or unusual case, feel free to ask me in comments, I will do my best to help you.
If you know someone who uses unsafe credential manager or doesn’t use manager at all, send him this article, I will appreciate it :)

Software Developer Blog |

Summary of The State of AI-assisted Software Development Report

What is DORA

AI Is Already the Standard, but It Doesn’t Replace Thinking

AI Amplifies What’s Good — and What’s Bad

With AI, Productivity Increases — but Stability Still Suffers

Platform Engineering Is the Foundation of AI Success

AI Adoption Is an Organizational Transformation

Summary

Replacing Planning Poker with Team Estimation Game

What is the Team Estimation Game

Keep the Big Picture during estimation

Preparation

Draw columns according to your scale

List players

Bring stories/tasks

The Game

Move one card or pass

The Results

The Matrix

Summary

Introduction to Git Bisect with CodeceptJS automation example

How Git Bisect works

How Git Bisect knows that particular commit has given behaviour

Can Git Bisect be used to other purpose than finding a bug

Git Bisect manual demo

Git Bisect automated demo with CodeceptJS

Video demo

Summary

Error 459 - permission denied while trying to run git bisect with script

Full logs of git-bisect with 459 error

Quick solution

Summary

Store Git SSH key pair in Linux with Libsecret to skip asking for credentials

How automate SSH connection works

How to configure automatic SSH connection

Create SSH keys

Encrypt SSH keys with password

Check created keys files

Send public key to server

Connect and store encryption password in keyring

Automate SSH login using command line

Troubleshooting SSH key pairing

Summary

Libsecret - remember Git credentials in Linux Mint and Ubuntu securely

Cache credential helper (out of the box)

Store credential helper (out of the box)

Git Credential Manager for Mac and Linux (by Microsoft)

Libsecret git credential storage (by GNOME)

How to secure SSH credentials

Summary