5 ms·
IMO, there's one big feature missing from git (and other SCMs in my limited knowledge of the field) that results in posts like this every so often. There reall
by bicknergseng 11y ago
IMO, there's one big feature missing from git (and other SCMs in my limited knowledge of the field) that results in posts like this every so often.
There really needs to be some concept of a commit group, one or more commits (probably the diff in commits from one branch to another) that are packaged together so that they can be addressed as one object instead of trying to keep track of a whole bunch of commit hashes. Merging a commit group is revertible and trivially cherry picked across branches. This addresses one of the weirdest behaviors in git: the rebase squash. We want commits to be understandable and usable, but that probably assumes the committer either held off committing or rewrote history to make it seem like things were written correctly the first time. It seems to me like the whole purpose of an scm is to keep track of history, whether it's the neatified, readable feature/branch merges or an individual git user's frantic, probably unorganized development progress.
- prodigal_erik 11y agoMaybe we need "git commit --signoff" for some kind of QA or review process to bless a branch as ready to deploy and give a high-level summary of it, and a mode of "git log" that only shows the graph of commits having a particular Signed-Off-By value.
- foxylion 11y agoWe use ticket references in our commit messages. So you'll be able to find all relevant commits of a specific feature or bug fix. Cherry-picking them is then also no big problem. git cherry-pick $(git log release/3 --grep ISSUE-123 --pretty=%h) The commit message contains the technical details about the changes. The ticket reference is a linking to the feature details itself, so you can quickly find out what the commit tries to achieve on a higher, non technical, level.
- azth 11y agoDo you put `ISSUE-123` in the title, or the body of the commit message?