Few days ago I've found absolutely tremendous post about practical Git usage - written by GitHubber & ex-Microsoftie: Phil Haack. The post itself is all about aliases Phil uses in his every-day scenarios. Even if I use Git & GitHub on daily basis, I have to admit I've learned something new again. But the best thing about this post is not nifty syntax - Git is that flexible & "capacious" that you could imagine literally dozens of Git usage patterns: it's always good to hear about someone else's good practices & use cases.
As you may may already know (or just suspect) there are many materials like that on the web already - starting with famous (& free) Pro Git e-book & finishing with ultra-popular GitFlow. But, as it appears, something that works well in OSS and / or independent CotS products, may not be fit well in Enterprise scenarios...
From my observations - many companies:
- by design do the development on two (or even more!) parallel, interleaved branches -> because they find it the best way to release the software more frequently
- synchronize (& merge) the release cycle of several interdepent projects
- postpone merging of feature branches until the very last moment
- change feature branch 'functions' because long-living workstreams change their assumed release moment => that effectively prevents them from having a clear distinction: which branch should be 'parent' & which should be 'child' (it's important, because it determines branching order & direction)
But ... what for?
Usually they don't do such things without a good reason - it's an old, honest necessity that forces them to do so. But even if the reasoning may make sense at the first glance ....
... that the longer I think about it & the longer I work with Git, the more I'm convinced that these Enterprise would get much better if they had cut this practices out completely. The benefit they bring is 100% delusive - all the practices mentioned above are an excuse:
hey, were doing anything we can to deliver as frequently as we can ...
... without making a meaningful move towards more Agile development. The price is huge: painful, risky, bare transparent & erroneous merges of huge pile of code - that destabilize the development, reduce the overall confidence & in the end - cause re-work.
The problem is that whether we like it or not ...
Git is forged for agile practices
Yes.
- Git works awesome IF you publish & release very often.
- Git works awesome regardless of branch numbers, IF you merge frequently.
- Smooth (and fully controlled) merging is enforced by idea of pull requests (and communication that accompanies them).
- Git branching models (like GitFlow) work well IF you're able to test your products / projects independently & in isolation -> not only as an integrated element of huge gossamer of nightmares ...
The further you are from being Agile (especially if you pretend you're closer), the more you will struggle with Git & its branching models.
