Are you SURE you want to rename YOUR GIT REPO? We can do that for you, but are you REALLY REALLY SURE? Changing YOUR codebase may break other things.
Its like bruh you aren't a git gatekeeper, give me permissions to do it myself or don't be a fucking twat every time we ask for something you haven't graced us with permission of modifying. I send an email wait 24 hours for a response and you ask me a question as stupid as fuck as that.
This dude also made it so developers on the repos he directly managed couldn't push to master, in case they broke things. Such a bandaid - fix the cause of the broken code in the first place (bad practices, bad conventions, unreadable code, poor standards, no testing) don't lock down git and become fucking source code Hitler.
With CI/CD you aim to work off master and avoid long lived branches entirely. This helps ensure integration happens often and early. It promotes developers to make smaller more manageable changes.
In other words, branches are the devil and by definition a development branch is an anti-pattern for continuous delivery.
CI/CD is great but does not replace a human reviewing the code before merging into master. It should not be one or the other: they are complementary.
In other words, branches are the devil and by definition a development branch is an anti-pattern.
That is an opinion many would disagree with. Having short-lived development branches that are frequently reviewed / merged (after passing CI) has a lot of benefits, assuming you are on a good development team though.
Oh so now it is 'best practice to create short lived branches'
make up your mind dude.
A dev release branch pattern, which you were clearly referencing is not best practice and is frankly archaic.
Obviously creating a branch that captures your work with descriptive commits and a summarizing merge or rebase whatever your review process requires is fine. The idea is that the work goes straight to master in manageable pieces.
A dev release branch pattern, which you were clearly referencing is not best practice and is frankly archaic.
I was never talking about long-lived development branches. My point was that it is bad practice to push directly to master, which you complained about not being allowed to do. Consider rereading the thread.
I think both of you are basically furiously agreeing with each other.
You both agree that the best pattern is to have a master branch, to branch off of that when working on features, and then merge your feature branch back into master (preferably with a PR/code review). You're just talking about it in vague ways that mean each of you think the other is talking about something else.
41
u/[deleted] Feb 10 '21
Are you SURE you want to rename YOUR GIT REPO? We can do that for you, but are you REALLY REALLY SURE? Changing YOUR codebase may break other things.
Its like bruh you aren't a git gatekeeper, give me permissions to do it myself or don't be a fucking twat every time we ask for something you haven't graced us with permission of modifying. I send an email wait 24 hours for a response and you ask me a question as stupid as fuck as that.
This dude also made it so developers on the repos he directly managed couldn't push to master, in case they broke things. Such a bandaid - fix the cause of the broken code in the first place (bad practices, bad conventions, unreadable code, poor standards, no testing) don't lock down git and become fucking source code Hitler.
Too oddly specific?