![]() > recently came across a merge that wiped out some of my > don't tell you how that was resolved in that merge. > when you've have a big merge conflict, many git tools > with merge commits: they are effectively black boxes, and > Though I will say that git has one big glaring problem Your commit history is as important as your code! Don't squash it away! I wish github never introduced that feature and instead developers were taught how to create a meaningful history of commits. This merge commit will make it very clear that the code branched off and was later merged back into master, yet, it will keep the history linear. This will rebase your branch on top of master, but, when merging, the `-no-ff` option will tell git to create a merge commit. If you want a very linear history, enforce a: Instead, if you hadn't squashed, you simply use `git bisect` and find in no time that the bug was introduced by the 12th commit of that branch, which itself was a small commit of 1 little change:ĭiff -git a/statistics.php b/statistics.php Have fun finding where in those 1500 changes that little nasty bug was introduced! Squashing that history of 25 commits, will create one giant commit of 1500 changes. The "super-feature" will in the end be the result of all of those commits together. If your developer cared at all about making "atomic" meaningful commits, each one of those commit will be introducing a small very well defined subset of the entire "super-feature". That feature was probably made of many small commits (say, 25 commits total), on a feature branch called "super-feature". Imagine said bug was introduced by a feature that took about 1 full month to code, introducing 1000 lines and removing 500. Your commit history is what you will use later down the line (think 6 months, a year, 2 years later) to find a very nasty yet incredibly subtle bug in your application. I disagree with squashing commits when merging to master, here's why: > I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. ![]() So the effort involved in merging bug fixes from release branches back to develop is typically both relatively small and well justified, and if you do need any manual conflict resolution, that implies divergence since the point when the release branch was started and then it probably is a good idea for someone to take a more careful look and make sure the bug is properly fixed on develop as well. If it's not important, you probably ship that release with the known bug, and the fix gets made on the "develop" branch via the usual process for incorporation in future releases. If it's not simple, you probably need to abort that release and go back to your main development line to do whatever more substantial work is required before continuing, then make a new release. The only time I've seen non-FF merges in a Git Flow style project is for bug fixes on release branches, but those tend to be characterised by two key properties: they are relatively simple and relatively important. Even if you're using a Git Flow style of workflow, why wouldn't you regularly rebase any feature branches back onto develop if they're lasting more than a short time, so you are keeping up-to-date, and why wouldn't you squash the finished feature down to a single commit that can be fast forwarded onto develop when it's ready, to maintain a linear history with one commit for one significant feature or fix? I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. Isn't that what the develop branch in Git Flow is for? Your project might need some additional steps as part of its release process, and those can take place using the corresponding release branch, but the idea is that you can start a new release off develop whenever you want. Master should always be in a deployable state. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |