The process of integrating my changes to the main codebase, and seeing it go live.
Luckily at school, I did have to use GitHub for a couple of collaborative projects, otherwise this would've been infinitely more daunting.
But at school it was pretty much, commit your code and push it to GitHub. Have other teammates sync and we're good. And when it's time to turn it in to teacher, download it as a zip and upload that to the school website.
At my first job, it was really hard to grasp that we had two separate major branches in Git, one that represents our "Live" code, and one that is what we're working on. But then also some other co-workers have separate branches for projects they're working on.
Not sure how common the exact processes are, but at my old job it went something like: make a pull request, have someone review it, then merge it. Some days, a systems engineer would do a build for our test server. So you'd go check things out on the test server, making sure they work. Hopefully they do. Then a few days before the end of our two-week Sprint, the syseng would do a build for our pre-production environment (PPE). Again, go make sure things work fine. Then a few days later, there was a final build, that went on the Production server. And we'd all stay late that night testing everything we could.
The massive span between finishing some tweak, and seeing it go live, was so surprising to me. And all of the very strict rules to not be broken - making sure you don't merge to the wrong branch; making sure your merge doesn't conflict with others, etc.
I was always second-guessing myself, even though my instinct was right, because of how much my coworkers made a point about Not Doing The Bad Thing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The process of integrating my changes to the main codebase, and seeing it go live.
Luckily at school, I did have to use GitHub for a couple of collaborative projects, otherwise this would've been infinitely more daunting.
But at school it was pretty much, commit your code and push it to GitHub. Have other teammates sync and we're good. And when it's time to turn it in to teacher, download it as a zip and upload that to the school website.
At my first job, it was really hard to grasp that we had two separate major branches in Git, one that represents our "Live" code, and one that is what we're working on. But then also some other co-workers have separate branches for projects they're working on.
Not sure how common the exact processes are, but at my old job it went something like: make a pull request, have someone review it, then merge it. Some days, a systems engineer would do a build for our test server. So you'd go check things out on the test server, making sure they work. Hopefully they do. Then a few days before the end of our two-week Sprint, the syseng would do a build for our pre-production environment (PPE). Again, go make sure things work fine. Then a few days later, there was a final build, that went on the Production server. And we'd all stay late that night testing everything we could.
The massive span between finishing some tweak, and seeing it go live, was so surprising to me. And all of the very strict rules to not be broken - making sure you don't merge to the wrong branch; making sure your merge doesn't conflict with others, etc.
I was always second-guessing myself, even though my instinct was right, because of how much my coworkers made a point about Not Doing The Bad Thing.