There are many different Git workflows and it is very likely that the one you are using relies heavily on Git’s outstanding branch management.
If you have many branches, some of which may be release branches, you surely don’t want anyone to merge a feature branch branched off of develop into it (which already probably is dozens of commits ahead).
This is extremely important in teams formed by many developers – if one of them makes the mistake, and the others start branching off of the release branch, all of them will have the “corrupted” version of the branch, and then it takes a lot of effort to undo all of the damage.
Git doesn’t provide a way to deal with this problem out of the box – a pre hook is required, or some third-party software.
If you are using GitBlit, however, writing a pre hook which guards a branch from being flooded with commits from a branch which should never be merged into it, is quite easy.
Below simple groovy script achieves just that: Continue reading
I’ve been recently writing a pre hook for Git to check if any of the committed files violate any policies. I’m using GitBlit and it’s using JGit (an implementation of Git written in Java). You can’t use normal Git pre hooks with GitBlit, but you can write them in Groovy.
GitBlit’s author created an API to ease the use of JGit in pre hooks. I needed to detect if a file was renamed, and have access to its old path, as well as the new one.
Unfortunately, the documentation of
PathChangeModel (which corresponds to a file in a commit) doesn’t state how to obtain the old path – the renamed file object’s
path property contains the new path.
Luckily, it’s open source! I’ve had a look into the source code of the mentioned class and it turned out that, in case of a
rename, the old path is stored in the
name property. Take a look at the following example. Continue reading
Git is an extremely powerful Distributed Version Control System. And by saying that, I’m getting straight to business.
The “Distributed” part means that there is no central repository on which all developers are working. On the contrary – every developer has a clone of some publicly available (whether on the internet, or at work) repository. The “central” becomes just a place to share your work and pull others’ changes.
This is one of the features that make working with Git very handy. It is also one that people often don’t realize. Continue reading