In the last days I tinkered a bit with things in Git that I haven’t tried yet. One was signed commits. Signed commits help other people to know that it’s actually you who committed changes. So when people trust you as a person, they can also trust your code because they can verify that it’s been actually done by you.
It’s pretty easy to set up and once configured, everything else will just happen automatically.
In this screencast we’re exploring the way Git saves files, directories commits and tags in it’s internal data structure, how we can inspect them and how they related to each other.
This video is meant to provide additional information for people that already use Git and want to know how it works under the hood.
Actually I like this approach to learn things and I think I’ll do another screencast on this topic, maybe providing additional information about how pack files and garbage collection works, how branches are stored and how integrity of data is ensured by their filenames.
When using Git extensively, you’ll likely have multiple branches which need to
be cleaned up from time to time. In some repositories I have hundreds of
release/ branches, which are already merged to the
master branch and deleting them manually would be a mess.
So here’s how to delete all branches from the server, that are already merged
master branch. In this case, branches need to start with either
release/ but you can simply adjust this to match your needs.
In this guide I’ll show you, how to prevent permission changes
within a Git repository to be recognized as a file change.
At least after changing file permissions using the
your version controlled project, the output of
git status will be a mess making
it nearly impossible to identify changes within your project’s source code.