Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "gitflow"
-
Started using longer passphrases for logins, colleague starts to tell people I'm doing bad things because"no one needs a password that long"
I get reprimanded by my boss
How the hell does this even happen smh13 -
TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.
I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.
FF to today:
- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"
And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.11 -
10 years experience in DoD C4I enterprise hardware and software.
Looks at civilian job (requires A+)
Gets A+
Looks at civilian job (requires Network+)
Gets Network+
Looks at civilian job market (requires Security+)
Gets security+
Looks at civilian job market (requires CCNA)
Getting CCNA
Looks again at job market (requires CCNP)
Fuck...
Job interview "we don't think you have a strong enough background"
Looks back at my 5 million dollar military flying robotic server FML4 -
I'm sick to death of hiring people from other companies and explaining GitFlow and why its useful (what are you people doing?).
Then watching them doing it wrong, pointing out its easier to use something like sourcetree. Which leads to "... well see, the terminal is just more efficient, tools like sourcetree are bloated".
Ok fair enough, well heres the deal i'll make with you, while using your "efficient tool", stop breaking our workflow and i'm fine for you to keep using it. Otherwise, stop being a dick and be a team player.18 -
What the fuck gitflow
I feel like I must be doing this wrong
Everybody pushes to their own branch and then the team lead approves merge requests into the master
But everybody else sucks and nobody pushes to their branch even regularly let alone into master
So basically everyone’s working on their own version of the site it’s just a big fucking mess and I’m frustrated7 -
Installing OS onto server
3 hours
Configurations and Updates
4 hours
Won't boot up and keyboards not functioning till after grub...
Priceless
"A start job is running for Wait for Plymouth Boot Screen to Quit" can go fuck itself.4 -
Long time ago i ranted here, but i have to write this off my chest.
I'm , as some of you know, a "DevOps" guy, but mainly system infrastructure. I'm responsible for deploying a shitload of applications in regular intervals (2 weeks) manually through the pipeline. No CI/CD yet for the vast majority of applications (only 2 applications actually have CI/CD directly into production)
Today, was such a deployment day. We must ensure things like dns and load balancer configurations and tomcat setups and many many things that have to be "standard". And that last word (standard) is where it goes horribly wrong
Every webapp "should" have a decent health , info and status page according to an agreed format.. NOPE, some dev's just do their thing. When bringing the issue up to said dev the (surprisingly standard) answer is "it's always been like that, i'm not going to change". This is a problem for YEARS and nobody, especially "managers" don't take action whatsoever. This makes verification really troublesome.
But that is not the worst part, no no no.
the worst is THIS:
"git push -a origin master"
Oh yes, this is EVERYWHERE, up to the point that, when i said "enough" and protected the master branch of hieradata (puppet CfgMgmt, is a ENC) people lots their shits... Proper gitflow however is apparently something otherworldly.
After reading this back myself there is in fact a LOT more to tell but i already had enough. I'm gonna close down this rant and see what next week comes in.
There is a positive thing though. After next week, the new quarter starts, and i have the authority to change certain aspects... And then, heads WILL roll on the floor.1 -
When you come up with a perfect working model for branching and merging, and everyone agrees apart from the one guy who insists you use gitflow because he likes shiny new things2
-
I teach military students how to operate a UAS control station and these things are as complicated as computers get. ATCA's and the most crazy stupid network setups I've ever seen. I have one month to teach a guy that's never even had a laptop... Basically giant server room that can fall out the sky from the push of a button.2
-
Typical Git work flow on a feature branch:
Commit#1 : The silly feature itself that took 10 minutes to code
Commit#2 : Added unsaved files
Commit#3 : Fix unit tests
Commit#4 : Fix
Commit#5 : Fix
Commit#6 : Fix
Commit#7 : Various Fix
Commit#8 : Added unsaved files
Commit#9 : Merge
Commit#10 : Fixed unit tests
Commit#11 : Code Review tasks
Commit#12 : Revert- Code Review tasks
Commit#13: Refactor part 1
Commit#14: Refactor part 2
Commit#15: Deleted unit tests
Commit#16: Added checking for null
Commit#17: Completely different feature's bugfix
Commit#18: Code review spacing corrections
*Approved*
Trying to merge, then merge conflicts.....2 -
Today we had an hour long meeting on gitflow. The senior developer who felt compelled to arrange this meeting, during his demo couldn't figure out how to merge a hot-fix. "But you guys know what I'm talking about, right?" *Forehead=>Brick-wall*
If I wanted to lose brain cells I'd just start doing drugs, at least it would be more fun.1 -
Ok, im hired here as a frontender. Formally the designer did a bit of it. The site is shit. I want to fix everything about it basically. But, the thing is that we are working according to gitflow so someone has to check my code. But backend is like: thats frontend. And the designer is too busy and just wants to see the pixels. So who is check my PR’s now? Guess i’ll do it eventually... it’s going to test first anyway3
-
Ok, im hired here as a frontender. Formally the designer did a bit of it. The site is shit. I want to fix everything about it basically. But, the thing is that we are working according to gitflow so someone has to check my code. But backend is like: thats frontend. And the designer is too busy and just wants to see the pixels. So who is checking my PR’s now? Guess i’ll do it eventually... it’s going to test first anyway2
-
finally we started adopting gitflow concept and it worked pretty well for most of the projects and devops guy came in saying Gitflow needs to die in a fire because we devops is the best, all the tech companies are using it.
But...
1. gitflow can be tweaked to suit the project's need
2. gitflow can work with devops model
3. our projects are still release based
noooooooooo! gitflow needs to die in a fire! everyone needs to commit directly to master branch now and we CI directly to production!
and some dude started doing so because some random dude said it. wtf?
whats wrong with people?8 -
Just installed Cent OS 7 on my HP 380 g6 server, can someone please explain why hp withholds bios updates unless you pay extra... Where do I even get a support licence for this old thing. DoD normally handle's these things.
Also what do you do with a server at home. I found some AI assistant software to run and of course VM's but what else.5 -
On my free time I was looking for software where I could visualize the shape of the git graph to sort of reflect Git Flow. What I found was a bunch of git GUI's that list features that normal git already has:
- "undo local changes!"
- "squash commits!"
- "undo branch deletions!"
Da heck people actually pay for this?3 -
TFW you know you're going to be seen as a sort of code anarch or unenlightened (foo)barbarian for even suggesting that there are other git workflows more suitable than GitFlow, but you do it anyway.
Saying that I keep my master unprotected feels like telling Grandma I worship Satan.
I work with a very small team that's always physically nearby, we all get along well, trust each other and communicate to know what everyone is up to, which I guess is hard to believe in and of itself, but is it so fucking hard to believe that we'd be okay without redundant eternal branches or a vomitload of unbisectable history-warping merge commits? -
Update:
I've been trying to leave DoD for a couple of months now. Translating my 10 year's experience with complex Intelligence enterprise level systems to something relatable to the civilian IT world. Grabbed a few certs to help out A+, network+ and security+ with Linux+ as my next target. Photos of me working on unclassified systems, radios, cell towers and servers. I'm a teacher for military UAS so this shouldn't be to hard to get even a basic job in IT right.
No one will hire...
Linux admin: Nope
Network admin: Nope
Assistant Network admin: Nope
IT call service: Nope
Pool cleaner fucking nope
Many interviews and nothing
I'm broke and sold all of my personal valuables. I can't hold out much longer and really looking at becoming homeless. But I'm kinda ok with it, one last payment on my apartment and car is all I can do now. My parents think I'm in Afghanistan working a six figure job lol
DoD: we see you're trying to leave we'll pay you alot to teach A+, Network+ and Security+ traveling all across the country and staying at hotels with all expenses paid.
FU FU FU I want out please tell me someone has a job, I'll be a janitor of a server room Idc I just want out. Fuck the pay
I start Tuesday...4 -
Our Gitflow:
- kill bug
- pushes hotfix branch.
- deploy hotfix branch
- see if that solves the issue
- go back to the top if it doesn't
- merge hotfix into main and then deploy main -
How to set the up a stagging environment for a github branch in heroku.
Lets say i have a master branch and a dev branch. All the changes and updates first pushed to dev branch and after successful review and test in goes to master branch.
But the issue is as i'm following the gitflow of keeping the master branch always deployable.since my heroku app is linked to the master branch, when i try to test the dev branch in production environment of heroku,sometimes it breaks for some error.and at that time the sites goes down untill i redeploy the master branch as it's the stable version .So how do i test a branch in heroku production environment while also keeping the the site active with master branch. it that makes any sense 🤡 plz help3 -
Has anyone had success with GitFlow hotfixes and GitHub branch protection rules? Finishing a hotfix requires pushing directly to develop, but GitHub prevents it if PR policies are set up :/8
-
So trunk-based is the new approach everyone is using, because it is so cool.
I used gitflow for the last projects with azure devops, set up the pipelines like tipically in 1 week if I had other things to do with the help of the portal clicking through things. PR-s triggered pipelines, everything worked cool.
But then trunk-based got momentum, so I worked with this client where 2 developers worked for !!!3 months!!! to setup trunk-based pipeline. It was not my money, so I did not say a thing. They were using infrastructure as code.
I am all in for automation, but seriously? Then again, another project where a DevOps team took 1 dev-month to setup the pipeline + meetings. And what do you get in the end? So that the same image goes on all environments? Like how many releases do you have for prod in a year. Lets say 24. 24 x 5 minutes of manual work for the release, that is 2 hours. So my question is why would you spend 2 hours of manual work while you can automate it merely in a month? Everyone loves to code, but using the ui on the DevOps portal saves you so much time. I don't get this. Maybe I am getting old :D4 -
I was asked to make release branches which will change my gitflow. Am I understanding it correctly now? Fix me if I'm wrong
So I do my fixes in develop, once Im done I squash merge them into 1 commit. Then I make a release branch from develop, if everything is fine I release it. After release I merge back release branch to master and thats it?3