如何在 Mac 上设置 (GUI) 本地版本控制系统?

发布于 2024-11-26 13:29:08 字数 549 浏览 3 评论 0原文

我是一名网络开发人员。我的公司有一个开发服务器,我们所有人都直接在上面工作。我们只有 3 个人,都从事不同的项目,所以人们覆盖彼此的工作是没有问题的。因为我们太小了,所以没有人建立任何类型的版本控制,我也无法为我们所有人坚持这样做。然而,我最近破坏了我自己的一些代码并且无法让它再次工作,这让我想设置某种版本控制。

我希望它的工作方式如下:

  1. 制作开发服务器上存在的项目的本地副本。
  2. 在开发服务器上进行更改。
  3. 每次重大更改后,提交到我的本地副本。
  4. 如果新的更改破坏了开发服务器上的代码,则能够从本地副本获取以前的版本。

因为我经常同时处理 6 个或更多文件,所以在进行任何更改之前手动创建每个文件的备份对我来说是不可行的。

我查看了 GitBox 和 Versions,但无法判断它们是否允许我制作不使用某种版本控制的远程项目的本地副本。

有谁对 Mac 的良好 GUI 版本控制系统有建议,可以让我完成上面概述的任务吗? (主要问题是步骤#1 - 制作尚未使用版本控制系统的项目的本地副本,并能够通过单个操作更新本地副本。)

I'm a web developer. My company has a dev server that all of us work directly on. There's only 3 of us, all working on different projects, so there's no issue with people overwriting each other's work. Because we're so small, no one has set up any kind of version control, and I'm not in a position to insist on it for all of us. However, I recently broke some of my own code and can't get it working again, and this makes me want to set up some kind of version control.

Here's how I'd like this to work:

  1. Make a local copy of my project that exists on the dev server.
  2. Make changes on the dev server.
  3. After every major change, commit to my local copy.
  4. If the new change broke the code on the dev server, be able to grab the previous version from the local copy.

Because I'm frequently working in 6 or more files at a time, it's not feasible for me to just manually create backups of each file before making any changes.

I've looked at GitBox and Versions, but am unable to tell if either of them will allow me to make a local copy of a remote project that isn't using some kind of version control.

Does anyone have suggestions for a good GUI version control system for Macs that will let me accomplish what I've outlined above? (The main issue is step #1 - making a local copy of a project that isn't already using a version control system and being able to update the local copy with a single action.)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

赏烟花じ飞满天 2024-12-03 13:29:08

通过(传输)[http://www.panic.com/transmit/] 提供的映射,您可以轻松地完成您想要的操作。

为您提供 GUI 界面的一个选项是每次手动复制文件,然后每次您想要存储一组更改时使用 GitBox 创建一个新的提交。这会起作用,但很快就会变得乏味。乏味的事情会被忽视,所以不是最好的选择。

更好的解决方案是设置一个小脚本来为您进行复制和提交。查看以下示例:

#!/bin/bash

### SETUP:

### Set the path to the remote mapped directory
SOURCE="/Volumes/your/mapped/folder/path"

### Set the path to your local folder (this must already exist)
REPOS="/Users/your-username/your-storage-folder"


### MAIN:

### Move into the respository directory
cd $REPOS

### Initialize the repository if it doesn't exist
if [ ! -d "${REPOS}/.git" ]; 
    then 
    git init
fi

### Now copy down the files
rsync -a --delete --exclude '.git' $SOURCE/ $REPOS/

### Add all the changes to git staging
git add .

TIMESTAMP=`date`

### Now commit the changes
git commit -am "Committed: $TIMESTAMP"

假设您的 mac 上安装了 git,如果您执行以下操作,则应该可以使用:

  • 创建一个带有“.command”扩展名的新文本文件(例如“archive-site.command”)并将该代码粘贴到它。
  • 将“SOURCE”和“REPOS”路径的值更改为计算机上的实际路径。
  • 使用 chmod u+x archive-site.command 使其可执行。

从那里,您所要做的就是在 Finder 中双击该文件,它会将您的本地文件夹与服务器目录的内容同步,然后在存储库中进行新的提交。它是基本的,有点非正统,但它会给你一定程度的版本控制保护,而不会有太多麻烦。

With the mapping available via (Transmit)[http://www.panic.com/transmit/] you can pretty easily do what you are looking for.

One option that would give you the GUI interface is just to copy the files manually each time and then use GitBox to create a new commit each time you wanted to store a set of changes. That would work, but it would get tedious quickly. Tedious stuff gets neglected so not the best option.

A better solution would be to setup a little script that would do the copy and commit for you. Check out the following as an example:

#!/bin/bash

### SETUP:

### Set the path to the remote mapped directory
SOURCE="/Volumes/your/mapped/folder/path"

### Set the path to your local folder (this must already exist)
REPOS="/Users/your-username/your-storage-folder"


### MAIN:

### Move into the respository directory
cd $REPOS

### Initialize the repository if it doesn't exist
if [ ! -d "${REPOS}/.git" ]; 
    then 
    git init
fi

### Now copy down the files
rsync -a --delete --exclude '.git' $SOURCE/ $REPOS/

### Add all the changes to git staging
git add .

TIMESTAMP=`date`

### Now commit the changes
git commit -am "Committed: $TIMESTAMP"

Assuming you have git installed on your mac, that should work if you:

  • Create a new text file with a ".command" extension (e.g. "archive-site.command") and paste that code into it.
  • Change the "SOURCE" and "REPOS" paths to the values to actual paths on your machine.
  • Use chmod u+x archive-site.command to allow it to be executable.

From there, all you would have to do is double click on that file in the Finder and it'll sync your local folder with the contents of the server's directory and then make a new commit in the repository. It's basic and a bit unorthodox, but it will give you a some level of version control protection without too much hassle.

往昔成烟 2024-12-03 13:29:08

恕我直言:只要 2 个人就足以证明该小组的源代码控制是合理的。如果其他人不愿意,那么下一个最好的办法就是掩盖你的背后......

在你喜欢的任何系统中设置一个本地存储库。然后从远程服务器复制应用程序并将其添加到版本控制。由于其他人可能会在您不知情的情况下进行更改,因此您应该通过将本地副本与开发副本进行比较来开始每次编辑会话。

您可能需要研究 rcp 来根据开发副本维护本地副本。

保留两个本地副本可能会有所帮助,一个用于您处理,另一个用于合并开发副本中的更改。只需用用于开发的文件覆盖本地开发副本中的文件即可。然后根据需要签入或合并它们。这将允许您对开发中的更改与您的存储库进行完整的比较,而无需杀死您自己的工作副本。

IMHO: Just 2 people is enough to justify a source code control for the group. If the others are unwilling then the next best thing is to cover your behind...

Set up a local repository in whatever system you prefer. Then copy the app off the remote server and ADD it to version control. Since other people may make changes without your knowledge, you should start each edit session by comparing your local copy to the development one.

You may want to look into rcp for maintaining your local copy against the development one.

It may be helpful to keep TWO local copies, one you work on and one that you use to merge in changes from the development copy. Just overwrite the files in the local dev copy with the ones for development. Then check them in or merge as necessary. This will allow you to do a complete compare of changes in dev against your repo without killing your own working copy.

各自安好 2024-12-03 13:29:08

如果我处于您的情况(并且无法在服务器上设置版本控制系统),我会将您提出的方法更改为更像这样的方法:

注意:我意识到您正在询问 GUI,但我我也将在此处输入您可以在终端中使用的命令。这实际上很容易做到。只需几分钟的练习和一些备忘单,您可能会发现这样做更容易/更快。我还假设您的开发 Web 服务器是 linux/unix 类型,并且您可以以类似的方式将 Mac 设置为服务器网页。通过内置的网络共享功能或使用诸如 MAMP 之类的东西。

  1. < p>在我的 Mac 上创建一个空的本地工作目录,用于执行开发工作。

  2. 从本地工作目录中的终端应用程序初始化 git 存储库:

    <前><代码>git init

  3. 将所有代码从开发服务器拉到本地工作目录。我将使用终端中的 rsync 命令来执行此操作。如果您将开发服务器安装为 Mac 上的驱动器,则命令将类似于:

    rsync -a /Volumes/{DriveName}/{path}/{to}/{project-folder} /Users/{yourUserName}/projects/{project-folder}
    

    如果驱动器未安装,您可能仍然可以使用 rsync。只是需要不同的设置。如果您需要,还有其他资源可以帮助您解决此问题。当然,您也可以使用您计划在工作流程中传输文件的任何其他内容。

    作为更直接的问题,我不知道 git 或其他版本控制软件能够从不是另一个存储库的远程位置提取文件。我认为你必须用其他东西来完成这一步。

  4. 将所有文件添加到 git,以便它知道跟踪它们,然后使用以下命令将它们提交到存储库中:

    <前><代码>git add .
    git commit -m“在此处放置提交消息”

  5. 使用以下命令对 Mac 上的文件而不是开发服务器上的文件进行所需的任何更改可以使用内置的 Mac Web 共享或 MAMP 之类的工具来查看更改。

  6. 添加所有更改并使用相同的两个命令再次提交:

    <前><代码>git add .
    git commit -m“关于更改内容的新消息”

  7. 重复步骤 5 和 6,直到您想要将某些内容发送回开发服务器以进行更深入的测试。

  8. 将您的代码推送到开发服务器。然后返回第 5 步并继续进行更改和提交,直到您准备好再次推送回开发为止。

这种方法的优点:

  • 在本地处理版本控制比尝试每次复制文件然后版本要容易得多。这样做需要额外的步骤,这意味着更有可能发生错误,或者您不会做应做的事情。

  • 它应该比在开发服务器本身上工作更快。

  • 即使未连接到开发服务器,您也可以工作。 (如果您的计算机是某种类型的 MacBook,则您可以在任何地方工作。)

  • 您不太可能让开发服务器处于代码无法运行的状态。

  • 除非您已准备好让他们看到您的代码,否则没有人会看到您的代码。

此工作流程提供基本版本控制,让您可以轻松回滚到以前的版本。您还可以使用分支、标记等做更多事情……但是我列出的内容将帮助您从基础知识开始,并在您提交时涵盖您。在 GUI 方面,您提到了 GitBox。我以前用过它并且喜欢它,但我发现在命令行上使用命令对我来说更容易、更快捷。

If I were in your situation (and couldn't get a version control system setup on the server) I would change the methodology you propose to something more like this:

Note: I realize you are asking about a GUI, but I'm going to put in the commands you could use in the terminal here too. It is actually pretty easy to do. With just a few minutes practice and a little cheat sheet, you'll probably find it easier/faster to do it that way. I'm also assuming that your dev web server is a linux/unix type and that you can setup your mac to server web pages in a similar way. Either via the built in web sharing feature or with something like MAMP.

  1. Create an empty local working directory on my Mac that will be used to do the development work.

  2. Initialize a git repository from the Terminal app in the local working directory with:

    git init
    
  3. Pull down all the code from the dev server to the local working directory. I would do this with the rsync command from the terminal. If you have the dev server mounted as a drive on your mac, the command would be something like:

    rsync -a /Volumes/{DriveName}/{path}/{to}/{project-folder} /Users/{yourUserName}/projects/{project-folder}
    

    If the drive isn't mounted, you can probably still use rsync. It'll just take a different setup. There's other resources available for helping with that if you need them. Of course, you can also use whatever else you were planning to transfer the files with in your workflow.

    As a more direct point to your question, I'm not aware of git or other version control software being able to pull files from a remote location that's not another repository. I think you are going to have to do this step with something else.

  4. Add all the files to git so it knows to track them and then commit them into the repository with:

    git add .
    git commit -m "Put a commit message here"
    
  5. Make whatever changes you need to the files on the Mac instead of on the dev server using either the built in Mac Web Sharing or something like MAMP to view the changes.

  6. Add all the changes and commit again with the same two commands:

    git add . 
    git commit -m "A new message about what changed"
    
  7. Repeat steps 5 and 6 until you have something you want to ship back up to the dev server for more in depth testing.

  8. Push your code up to the dev server. Then go back to step 5 and continue to make changes and commits until you are ready to push back up to dev again.

Benefits of this approach:

  • It'll be a lot easier to deal with the version control locally than trying to copy files down each time and then version. Doing it that way would require extra steps that means it's more likely that a mistake will occur or you won't do it as much as you should.

  • It should be faster than working on the dev server itself.

  • You can work even when you aren't connected to the dev server. (If your machine is some type of macbook, you can work from anywhere.)

  • You are much less likely to ever have the dev server in a state where your code isn't working.

  • No one will see your code unless it's in a state that you are ready for them to see.

This workflow provides basic versioning that lets you simply roll back to prior versions. There's more you can do with branches, tagging, etc... but what I laid out will get you started with the basics and cover you as often as you make commits. In terms of the GUI, you mentioned GitBox. I've used that before and like it, but I've found that it's a lot easier and quicker for me to use the commands on the command line.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文