4 ms·
From the article: > The biggest issue with [the article "A successful Git branching model"] is that it comes up as one of the first ones in many git branching
by vog 11y ago
From the article:
> The biggest issue with [the article "A successful Git branching model"] is that it comes up as one of the first ones in many git branching related searches when it should serve as a warning how not to use branches in software development.
This is so true! That one seems to be a classic example of over-engineering. Although that model may be useful for some types of developments, ultimately every project has to find out their own way of branching model, which I should be the simplest model that serves their need - no more, no less. Going crazy with branches is just another way to fail using them.
> I will explain next why merge commits are bad and what you will lose by using them.
To add to that, I think it is quite telling that the Linux kernel developers themselves prefer a simple, linear history in the end (using branches only as intermediate steps), especially since they were the ones who created Git in the first place.
- Bahamut 11y agoNot just Linux - most major open source projects I've come across on GitHub also practice similar processes, if not identical.
- vog 11y agoUnfortunately, GitHub pull requests encourage explicit merge commits for every pull request. This is not helpful and can be quite annoying - especially for pull requests that contain just a single commit. Those merge commits are introduced even if the Maybe there should be a GitHub feature that pull requests are automatically rebased (as long as possible safely and automatically). Or, that the GUI allows a pull reqeust to be "fast-forwarded" instead of "merged", if possible.
- karyon 11y agoonce more, gitlab does it right and offers a "rebase" button on merge requests along with a "fast-forward merges only" option for repositories. See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
- yxhuvud 11y agoIdeally it would be a setting on the repo to allow both kinds of processes.
- drothlis 11y ago> I think it is quite telling that the Linux kernel developers themselves prefer a simple, linear history in the end What do you mean? This is what the current git history of the linux kernel looks like: * 12b9fa6 Merge branch 'for-linus' of git://git.kernel.org/pu |\ | * 5129fa4 do_last(): ELOOP failure exit should be done after | * a7f7754 should_follow_link(): validate ->d_seq after having | * d456564 namei: ->d_inode of a pinned dentry is stable only | * c80567c do_last(): don't let a bogus return value from ->op | * 0fcbf99 fs: return -EOPNOTSUPP if clone is not supported | * b6853f7 hpfs: don't truncate the file when delete fails * | 340b3a5 Merge tag 'armsoc-fixes' of git://git.kernel.org/ |\ \ | * \ d877a21 Merge tag 'renesas-soc-fixes-for-v4.5' of git:/ | |\ \ | | * | 901c5ff ARM: shmobile: Remove shmobile_boot_arg | | * | 4e960f5 ARM: shmobile: Move shmobile_smp_{mpidr, fn, ar | | * | b1568d8 ARM: shmobile: r8a7779: Remove remainings of re | | * | d2613f5 ARM: shmobile: Move shmobile_scu_base from .tex | * | | 7931845 MAINTAINERS: Extend info, add wiki and ml for m | * | | 9fa6c2b Merge tag 'omap-for-v4.5/fixes-rc5' of git:// | |\ \ \ | | * | | 3f315c5 ARM: OMAP2+: Fix onenand initialization to av | | * | | e327b3f Revert "regulator: tps65217: remove tps65217. | * | | | a9e5547 MAINTAINERS: alpine: add a new maintainer and | * | | | 5e45a25 ARM: at91/dt: fix typo in sama5d2 pinmux desc | * | | | b223c9f Merge tag 'imx-fixes-4.5' of git://git.kern | |\ \ \ \ | | * | | | f5d0ca2 ARM: dts: imx6: remove bogus interrupt-pare | | | |/ / | | |/| | | * | | | e3acd74 Merge tag 'omap-for-v4.5/fixes-rc3-v2' of g | |\ \ \ \ | | | |/ / | | |/| | | | * | | cf26f11 ARM: OMAP2+: Fix omap_device for module reloa | | * | | 08c78e9 ARM: OMAP2+: Improve omap_device error for dr | | * | | bf26927 ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2 | | * | | a5b8751 ARM: dts: am335x/am57xx: replace gpio-key,wak | | * | | 5f35dc4 ARM: OMAP2+: Set system_rev from ATAGS for n9 | * | | | 74a46ec Merge tag 'mvebu-fixes-4.5-2' of git://git. | |\ \ \ \ | | * | | | 44361a2 ARM: dts: orion5x: fix the missing mtd flas | | * | | | 9d021c9 ARM: dts: kirkwood: use unique machine name * | | | | | 691429e Merge branch 'akpm' (patches from Andrew) |\ \ \ \ \ \ | * | | | | | 7f6d5b5 dax: move writeback calls into the filesy Merge commits galore.
- ajdlinux 11y agoIt's true that at the top level, most of Linus' commits are merge commits. However, on a per-subsystem level, we very much favour a nice linear history. In most parts of the kernel, it's rare to go beyond 2 levels of merging, which given that the kernel has something like 1500+ developers and well over 10k+ commits per release cycle, is fairly linear...