101–110 of 210 posts
Yup, as the other comment stated, this is par for the course in modern quality software development. Its actually rather shocking to me to see my comment get downvoted. The quality of the HN audience is declining dramatically. Feels like all we have is a bunch of web agency lifers at this point.
Yup, as the other comment stated, this is par for the course in modern quality software development. Its actually rather shocking to me to see my comment get downvoted. The quality of the HN audience is declining dramatically. Feels like all we have is a bunch of web agency lifers at this point.
Your account is 30 days old. On what basis are you making this remark?
Earlier quoted context omitted.
git-flow is anything but simple.
It's simple but it requires effort and habits. Many developers work using the opposite mindset, they prefer to trade short-term easiness for long-term complexity (which is kinda valid), instead of battling complexity upfront.
That seem to go against the definition of simple: easily understood or done; presenting no difficulty.
That's not to say there aren't any benefits to it or that developing those habits are a waste, but it's not simple. Changing existing or developing new habits is not without difficulty, it takes time, patience and perseverance.
Earlier quoted context omitted.
> If you learn how to break features down into small chunks If that's possible. What if there are some features for which it isn't?
You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge…
I understand that testing tells you you broke the trunk, so you didn't break up the feature into small enough merge-able pieces. My question is what happens if you can't break it up any smaller--do you just throw up your hands and say you can't implement the feature because there's no way to break it up into small enough pieces?
If you are delivering web app code to production every day, it doesn't make sense to cut versioned releases, with for example semantic versioning, instead you just release the code that has passed tests. It also doesn't make sense to have hotfix branches, because there is only one version in production[5], and you release every day, so there is no need to backport a fix to older versions, or do anything special to get a fix out quickly.
Trunk Based Development has branches. If you are working with a team you pretty much never want to commit straight to master. The difference is that in TBD the branches are short-lived and only exist for code review purposes.
This is what TBD would look like with GitHub and GitHub "forks".
git remote -a
origin git@github.com:/.git (fetch)
origin git@github.com:/.git (push)
git@github.com:/.git (fetch)
git@github.com:/.git (push)
git checkout master
git pull # make sure you are starting with the latest master
git checkout -b my-cool-feature # create a branch for you change
vim
git add
git status # check that all expected code is staged
git diff HEAD # review your changes
git commit # write a meaningful commit message
git fetch # get the latest changes from origin
git rebase origin/master # put your changes on top of the latest changes from master
git push my-cool-feature:my-cool-feature # push to a branch on your "fork"
# Open a PR to merge from /my-cool-feature to origin/master
# Once the PR is approved, use the GitHub UI to merge the PR into master
git checkout master
git pull # pull down your code that just merged to master
git branch -d my-cool-feature # delete your feature branch
[2] http://nvie.com/posts/a-successful-git-branching-model/
[3] https://guides.github.com/introduction/flow/
[4] I'm defining CD to mean delivering to production at least once a day.
[5] Unlike on-premises software, with a SaaS product you only have two versions: (1) what is in production, and (2) what is going out to production (in staging, canary, etc.).
Earlier quoted context omitted.
I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).
How do you support a 3 year LTS branch for enterprise customers without long lived branches?
In our case it was a valid concern (our team had a pretty awful track record).
One of the authors here. Ask questions :)
[0] http://paulhammant.com/2013/12/04/what_is_your_branching_mod...
I think some people are getting confused about terminology between Trunk Based Development[1], Git Flow[2], and GitHub Flow[3]. TBD and GitHub Flow are nearly identical, basically if you use TBD on GitHub you use GitHub Flow. Git Flow (not GitHub Flow) is a model that is all about cutting releases, and supporting bug fixes to releases. Git Flow is nonsensical when doing Continuous Delivery[4] of a web application. If…
Like I said in my other downvoted post... too many TBD zealots look at big companies that use it sans branches, and assume that it is the one true way, instead of understanding the larger picture (branches outside of git suck, these companies don't use git for various reasons)
Earlier quoted context omitted.
In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.
Amazon (today) maintains a git repo per package, though in theory there's no reason why it has to stay git (or even be homogenous). Each application is a set of versioned artifacts that can be updated, forked, or merged together so long as the whole set builds together.
I've never understood the mono repo argument. With something like Brazil (or even sonatype nexus), you end up in a much stronger place for guaranteeing consistency and immutability in your builds.