TL;DR version, what you're doing works, but leaves opportunities for robustness, debugging, and reproducibility. You asked about how to make it easier to do it your way, but this sub slants towards a different way.
A git strategy does imply running the full source code locally (ie: PHP code). You would probably have other repo(s) for managing your server infrastructure as code, using containers. You could push the branch(es) to the centralized host when you're done working on one machine, and pull them when you move to another machine to continue working.
The idea would be to have a limited/mocked functionality running locally with the same requirements (PHP version, nginx/apache conf, etc) and slightly different configs (endpoints, etc). Test your changes locally to the best of your ability (on a branch), then merge it back into master. Ideally you'd use a continuous integration/deployment job to build consistent/reproducible code to push to the server(s).
Your dev VPS, with configs very similar to production, could test the new functionality in an integration type setup with "real" dependencies/endpoints. It would also be something that could be wiped/deployed to new hardware since everything is tracked/managed via code.
I dunno... but I feel that maybe its just that you are not interested in learning git? I can tell you, I haven't memorized any commands, neither have my employees. I fact, all I did was open git-scm a few years back and read it, and drew how the internal architecture and git layout works and from there on it was dumb easy for me to understand its commands and workflow. And later on teaching git to my employees wasn't hard at all. Took like a 2 day 12 hour dedicated session and we had Git up and running(with hooks) for our projects. :)
I dunno why you find it THAT hard? But I do agree with your sentiment that a decent amount of developers do just memorize the git commands. But you can't really blame them for that, as IMO, there isn't much need for getting into the nitty-gritty of git for like 90% of developers. Mainly becasue knowledge of simple add, commit, merge, checkout push, pull commands is sufficient enough for their requirements.
As for Git GUI, there is GitKraken, SmartGit etc. which have decent-ish GUI offerings over gitk/gitg(whatever is the inbuilt one). Although, I personally prefer command line for logs and checking branches etc.
With all that said, if you still want to give git a shot, this is a good website which explains git internals quite nicely -- https://backlog.com/git-tutorial/
Cheers! :)
Guter Link, nur der Ausführung zum Punkt zu Bug Database würde ich vehement widersprechen. Excel/Google Sheets/Lotus 1-2-3/whatever sind einfach keine guten Bugtracker, Punkt.
Screenshots/Videos/Network captures einfügen ist ne Katastrophe, und Kommentieren geht wenn überhaupt nur mit viel Kopfschmerzen. Von ner status history (wer hat wann an dem Ticket gearbeitet und es auf welchen Status gesetzt) will ich gar nicht erst anfangen.
Es gibt genügend freie oder zumindest billige Tools mit denen man sich nicht gleich den ganzen Atlassianklotz ans Bein bindet (Mantis, Backlog, Unfuddle, ...), die für diese Aufgabe einfach deutlich besser geeignet sind.
If you search for "git caret vs tilde" the first few results all give pretty good explanations:
I particularly like the mnemonic in the first answer on that Stack Overflow question. I always used to have trouble remembering which was which.
Hi there,
>depending on the number of bugs your studio is handling, Google Sheets can become quite large and a lot of sorting would be the result of many different pages.
>
>After many years in QA I tried to find a professional bugtracker at a reasonable price. If you have only one project and up to 10 users, I can highly recommend backlog (https://backlog.com/).
>
>It offers the most important features for free. Maybe you want to check it out!
I've looked into Backlog too. We have three projects running concurrently with about 10 team members. One criteria fits but unfortunately we have a bit too many projects to run the free version of Backlog.
> By the way, you can also set up a bot as a receiver of issues. Anyone can send a mail to the bot with his/her issue and then the bot will be the standard assignee for new issues. From there you can go through all new issues and assign them to the corresponding people.
I'm planning to come up with a bot that integrates directly into the game itself but that requires the attention and effort of the programmers. With the amount of workload, we cannot spare anyone to do anything else at the moment. But thanks for the input! :D
Hi there,
depending on the number of bugs your studio is handling, Google Sheets can become quite large and a lot of sorting would be the result of many different pages.
After many years in QA I tried to find a professional bugtracker at a reasonable price. If you have only one project and up to 10 users, I can highly recommend backlog (https://backlog.com/).
It offers the most important features for free. Maybe you want to check it out!
By the way, you can also set up a bot as a receiver of issues. Anyone can send a mail to the bot with his/her issue and then the bot will be the standard assignee for new issues. From there you can go through all new issues and assign them to the corresponding people.