Before GIT, our workflow was as follows: we used WinSCP SFTP support, to connect to the server, and modified the codes directly on the server. This was good for us, as we could quickly test the code we wrote.
At the moment, we are trying to switch to git for version controling, but we would like to simmulate the old work process. Our development and production codes are all on external CentOS servers, and we managed to create the connection between the dev server and the production server, and everything works flawlesly, when we are using the cli of git on the development server. We can commit, branch and push to the production server, and the production server updates itself immediatly (deploys the pushed code if it comes to the master branch).
But everything would be so much easier, if we could have a GUI, to not recognize all the cli commands of git, and to have an easier view on the progress of our branches.
So what we would like to achieve is the following: have a git gui that works on a local windows machine preferably, which watches for code changes on our development server, and can be used to commit the changes, or revert the commits, or push to the production server, while we edit the files the old way, using WinSCP. Is this possible somehow?
The only solution that came close to what we want was ungit, but it seems to us, that it is rather unstable. We installed it on the development server, started the web process, accessed it from our local browser, but when we tried to change branches or anything, it plain and simply froze:(
Other things we tried, is to mount the project folder in our local windows machine, using win-sshFS, and added the mounted directory as a local repository to the GUI which we are using right now (GitKraken), this also worked, but it was EXTREMELY slow.
As of now, a working solution, and I think the intended way to use git, would be to set up a XAMPP on our local machine, write and test the code locally, and push to the development/production server, when the code should be deployed, but this comes with the overhead to setting everything up as it is on the dev/production server, and errors may occur that we only find out when pushing.
