Answers.Body: <p>This seems mostly like a People Problem: if your client's team want to be able to make changes, then they should do so in the same way that you make changes - i.e., they need to get themselves set up locally and then push changes into the repository. If they want to &quot;go commando&quot; working directly in the staging site's files, they can't expect any good to come of it! I'd disallow access to the server files, and set Craft's allowAdminChanges to false, and allow access to the repository instead.</p>
  <p>If that's not feasible for some reason, you could set up a cron job that automatically commits and pushes to the repo from the staging site every couple of minutes. I had to do this once on an ExpressionEngine site we inherited where the site admins all had full super-admin access and were accustomed to altering the templates via EE's control panel (which in turn updates the template files). Eek! Just Say No.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-20T21:51:34.480Z
Answers.Text: I appreciate your viewpoint, but that doesn't answer the question. Whether the workflow should be like this or not is a separate discussion. The question is whether it's possible to work with Git on a remote server using a GUI on your local machine.
Answers.UserDisplayName: Tyssen
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-21T08:02:00.633Z
Answers.Text: Sorry you're right it doesn't answer that question directly, my answer should have been a comment instead. But given the back story/reasoning for wanting to do what you want to do, in my opinion you're trying to solve the wrong problem. If you solve the root problem then your core question becomes irrelevant as you can just use your regular GUI to examine the remote repository in the normal way.
Answers.UserDisplayName: James Smith
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-21T22:51:01.300Z
Answers.Text: I see what you're saying but I'd essentially be asking them to do more work to make up for the trouble that I'm having. Ideally, I want to solve my problem without having to ask them to do that.
Answers.UserDisplayName: Tyssen
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-22T08:27:09.963Z
Answers.Text: If they're professional software developers and they're making changes directly to the remote files, I'd see that as their problem, not yours. They should be familiar with software development lifecycle and the need to maintain version control and the integrity of deployments.
Answers.UserDisplayName: James Smith
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-20T14:07:28.280Z
Answers.LastActivityDate: 2022-09-20T14:07:28.280Z
Answers.UserDisplayName: James Smith
Body: <p>I work on a site that is set up with the staging site being the main site where changes are made and then the database and all files are copied over to the production site when those changes are ready to be made live. The staging and production sites are both on the same server.</p>
  <p>The staging site has a Git repo too. When I'm pushing changes from my local repo, I push them to this remote repo and they then get deployed to the staging server.</p>
  <p>During initial development, all changes were being made locally and then pushed to staging which was fine.</p>
  <p>Now the site is live, the site's owners (who are software developers) sometimes make their own admin changes on staging.</p>
  <p>If new features are to be added, before I can begin working on them locally, I need to get the changes from the remote server first. Ideally, they would be committed to the Git repo on the server and then I could pull those changes down to my local.</p>
  <p>And this is the point of my question. I've tried using the CLI for seeing, staging, and committing changes on the remote server. But I find it difficult to use and have made some mistakes which have resulted in some of the contents of the git folder being removed.</p>
  <p>So I'd like to know if there's a way of setting up a Git GUI tool on Mac to manage the changes to files on the remote server. Just in the same way that I would if the files were on my local machine.</p>
  <p>Has anyone done anything like this before?</p>
  
Tags: <git>
Title: Git GUI for interacting with changes to files on remote server
ThreadText: # Git GUI for interacting with changes to files on remote server
  
  (Asked by: username_0 on 2022-09-20)
  
  I work on a site that is set up with the staging site being the main site where changes are made and then the database and all files are copied over to the production site when those changes are ready to be made live. The staging and production sites are both on the same server.
  
  The staging site has a Git repo too. When I'm pushing changes from my local repo, I push them to this remote repo and they then get deployed to the staging server.
  
  During initial development, all changes were being made locally and then pushed to staging which was fine.
  
  Now the site is live, the site's owners (who are software developers) sometimes make their own admin changes on staging.
  
  If new features are to be added, before I can begin working on them locally, I need to get the changes from the remote server first. Ideally, they would be committed to the Git repo on the server and then I could pull those changes down to my local.
  
  And this is the point of my question. I've tried using the CLI for seeing, staging, and committing changes on the remote server. But I find it difficult to use and have made some mistakes which have resulted in some of the contents of the git folder being removed.
  
  So I'd like to know if there's a way of setting up a Git GUI tool on Mac to manage the changes to files on the remote server. Just in the same way that I would if the files were on my local machine.
  
  Has anyone done anything like this before?
  
  **Tags:** git
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-09-20. Score: 1
  
  This seems mostly like a People Problem: if your client's team want to be able to make changes, then they should do so in the same way that you make changes - i.e., they need to get themselves set up locally and then push changes into the repository. If they want to "go commando" working directly in the staging site's files, they can't expect any good to come of it! I'd disallow access to the server files, and set Craft's allowAdminChanges to false, and allow access to the repository instead.
  
  If that's not feasible for some reason, you could set up a cron job that automatically commits and pushes to the repo from the staging site every couple of minutes. I had to do this once on an ExpressionEngine site we inherited where the site admins all had full super-admin access and were accustomed to altering the templates via EE's control panel (which in turn updates the template files). Eek! Just Say No.
  
  > **Comments:**
  > **username_0**: I appreciate your viewpoint, but that doesn't answer the question. Whether the workflow should be like this or not is a separate discussion. The question is whether it's possible to work with Git on a remote server using a GUI on your local machine.  
  > **username_1**: Sorry you're right it doesn't answer that question directly, my answer should have been a comment instead. But given the back story/reasoning for wanting to do what you want to do, in my opinion you're trying to solve the wrong problem. If you solve the root problem then your core question becomes irrelevant as you can just use your regular GUI to examine the remote repository in the normal way.  
  > **username_0**: I see what you're saying but I'd essentially be asking them to do more work to make up for the trouble that I'm having. Ideally, I want to solve my problem without having to ask them to do that.  
  > **username_1**: If they're professional software developers and they're making changes directly to the remote files, I'd see that as their problem, not yours. They should be familiar with software development lifecycle and the need to maintain version control and the integrity of deployments.  
  
  ---
  
  