4 ms·
I go one step further - All changes (even single commits) are in a feature branch. Feature branch is prefixed with issue number. eg. PROJ-1234-update-ui-to-do
by lysp 8y ago
I go one step further - All changes (even single commits) are in a feature branch.
Feature branch is prefixed with issue number. eg. PROJ-1234-update-ui-to-do-something. That ensures that every commit is logged against an issue.
If you list --first-parent and show the list of merge commits, you see a list of features which were implemented into the dev branch.
If you need to drill down into lower level changes of a feature, you can look at the individual commits that were made in that branch.
That way merge commits are atomic commits of features, and commits in a branch are logical commits/steps for an individual feature.
And in answer to the original post - I try to make all commits have a message of what was the type of change, what the change was, and where it was. eg. "Added a clear button to reset all form elements on the update address page". The general rule is, you should be able to read the commit message and know exactly what was changed and where. Compared to "Added clear button".
- scrollaway 8y agoThis is IMO a potentially good system but it requires a lot of rigor. In my experience, such systems break down unless they are rigidly enforced, and that's never fun for anybody.
- lysp 8y agoThe way I have set it up is to do 2 things: 1) Create a post-commit hook script that only allows commits into feature branches. This prevents accidentally committing into the dev/master branches (it still allows merges). 2) Create a script file that all developers use to start / end features which handles all the branch creation, pushing and pulling. That way the process is standardised and you cant make a mistake. eg. * script startfeature abc123-this-is-new-feature * script endfeature (this automatically picks up local open features) The only time there is ever an issue is when the end-feature causes a conflict. This is solved by rebasing your local branch, fixing up any issues in your commmits and then ending it again.
- maelkum 8y agoI am using this method to a great success at my current job. It leads to always having a clear, well-defined place where you look for changes related to issue XYZ. Support from tooling also helps a lot, e.g. "checkout branch of issue XYZ".