define git hooks for better git branch names

[mrtrkmn]

There should some name conventions in order to get out from a situation where everything is messed up. This issue could be closed by creating customised git hooks which might run on server and client side.

• New branches should be created from master branch
• If there is no issue which points your dev intention, first create issue and define your intention
• There should not be branch-to-branch (other than master) pull requests at least for time being.
• The name of branches should match with the issues that the project has.
• Branch names should contain issue number at the end otherwise that should NOT be accepted
• A proper length of branch name should be between 18 and 25.
• Example :
  • For issue #4, the ideal branch name could be add-more-sources-#4

[mrtrkmn]

Please pull following pre-commit hook and change with your local hooks. (under project root)

 $ cd .git/hooks/
 $ wget https://gist.githubusercontent.com/mrturkmen06/b44c09df3a86286d017cdd3a01e4f87c/raw/bfbf98cae8936cc964e596489d846093d8757f70/pre-commit.sh 
 $ mv pre-commit.sh pre-commit
 $ chmod +x pre-commit

[kidmose]

I can confirm that it blocks branchnames test and testtesttesttesttesttesttest (len=28).

It seems that it would be beneficial to add a check on whether the name matches your regex on pre-commit.sh:6, because the two names above are simply not caught on by that, thus it reports a length of 0 and prints some misleading messages.

Are we testing or is this the intended mean of deploying the hook? :) (I was hoping that the hooks would just live in the repo, but we then of course have the problems of mixed dev platforms..)

[kidmose]

I had a look at e.g. https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/ and learned some about the challenges of centrally manages git hooks. I suggest we take the git config core.hooksPath .githooks-based approach described there, combined with a GH Actions step that runs the same hook. That way enabling the hooks in our local dev repos is optional and setup is done once, with updates trickling down automatically, but adherence to the rules of the hook is enforced centrally before merge.

[mrtrkmn]

https://stackoverflow.com/questions/22100581/github-server-side-git-hooks-i-e-pre-commit-and-post-commit

:(

[kidmose]

With Travis you have $TRAVIS_PULL_REQUEST_BRANCH available. Suppose you have you hooks as shell scripts in e.g. .githooks/test_branch_name.sh. Then on travis I believe you can test with this command:

./.githooks/test_branch_name.sh --name=$TRAVIS_PULL_REQUEST_BRANCH

Or not?

https://graysonkoonce.com/getting-the-current-branch-name-during-a-pull-request-in-travis-ci/