使用 git 和 GitHub 似乎需要很多额外的工作,我是否看错了?

发布于 2024-11-17 17:35:01 字数 613 浏览 1 评论 0原文

我是一名单一开发人员,总是通过 FTP 开发到开发服务器,然后在准备好后将文件转移到生产环境中。我对使用 git 和 GitHub 感兴趣已经有一段时间了,现在我终于有了一个很好的借口来开始一个新项目。然而,这似乎很乏味:

git add file1.php
git add file2.php
git commit -m 'updated file1 & 2'
git push origin master

然后在 GitHub 上的存储库中,通过 SSH 进入我的服务器,转到正确的目录,然后执行:

git pull

每次对代码进行任何更改时。这与在 Coda 之类的工具中进行编辑然后只需单击 command+S 是相反的。

有没有更好的(也许更自动化的)方法来做到这一点?我知道有一个适用于 Mac 的 GitHub 应用程序,它非常好,可以帮助完成第一部分,但我仍然需要登录 SSH 来更新任何内容,在一个下午进行几十次更新后,这可能会变得乏味。

我还看到我可以添加一个后挂钩,这样我就可以调用 PHP 脚本来在每次提交时执行 git pull,但我觉得这可能会存在一些安全问题,更不用说问题了该脚本失败,因为它无法输入密码。

I'm a single developer that has always just developed over FTP to a development server and then moved the files into production when ready. I've been interested in using git and GitHub for quite a while now, and I've finally got a good excuse now with a new project I'm starting. However, it seems tedious to have to do:

git add file1.php
git add file2.php
git commit -m 'updated file1 & 2'
git push origin master

Then after that is in the repo on GitHub, SSH into my server, go to the correct directory, and do:

git pull

each time I make any change to the code. This is apposed to editing in something like Coda and then just clicking command+S.

Is there a better (maybe more automated) way of doing this? I know there is a GitHub for Mac app which is quite nice and helps with the first part, but I still have to login to SSH to update anything, which can get tedious after a few dozen updates in an afternoon.

I've also seen that I can add a post-hook, so I could call a PHP script to execute the git pull on each commit, but I feel like there could be some security issues with that, and not to mention the issue with that script failing since it can't enter the passphrase.

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

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

发布评论

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

评论(5

于我来说 2024-11-24 17:35:01

我强烈建议您阅读 ProGit 书 http://progit.org/

不,有更快的方法可以做到这一点。

添加文件后,您可以简单地 git commit -a -m "Change descriptions"

为了添加文件,您可以 git add . 这将递归地添加所有不可忽略的文件。

如果您与分支机构建立了跟踪关系,您只需说git push即可。只有当其他人进行更改时,您才需要 git pull

当然有许多 IDE 可以帮助管理 git 以及各种 git gui。
https://git.wiki.kernel.org/index.php/Interfaces ,_frontends,_and_tools

但实际上,您只需要了解少数命令即可从命令行执行此操作。

  • 日常命令

这些命令您每天都会使用

git pull --rebase    # Getting changes other people made.  Using rebase is my personal preference
git commit -a -m msg # Committing your work
git push             # Sharing changes with others
git status           # Finding out what you have not committed/pushed
git diff             # Finding out what changed
  • 偶尔命令

这些命令您仅在安装时或很少使用

git init                 # Set up a new git repo
git clone URL            # Set up a git repo from the master source
git add <file/directory> # Mark a change specifically for commit

我想重申一下,git 不是一个 Web 部署系统。但是,如果您尝试做类似的事情,有些人已经通过 http://toroid 取得了成功.org/ams/git-website-howto

I strongly suggest you read the ProGit book http://progit.org/

No, there are much faster ways of doing this.

Once you have the files added, you can simple git commit -a -m "Change descriptions"

In order to add the files, you can git add . which will recursively add all non-ignored files.

If you have a tracking relationship set up with your branches, all you need to say is git push. Only if someone else makes a change do you need to git pull

There are of course many IDEs which will help manage git, and git guis of various breeds.
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools

But really there are only a handful of commands you need to know to do it from the command line.

  • Everyday commands

These commands you will be using every single day

git pull --rebase    # Getting changes other people made.  Using rebase is my personal preference
git commit -a -m msg # Committing your work
git push             # Sharing changes with others
git status           # Finding out what you have not committed/pushed
git diff             # Finding out what changed
  • Occasional commands

These commands you will use only on setup or rarely

git init                 # Set up a new git repo
git clone URL            # Set up a git repo from the master source
git add <file/directory> # Mark a change specifically for commit

I would like to reiterate that git is not a web deployment system. However, if you are trying to do something like that, some people have had success with http://toroid.org/ams/git-website-howto

他是夢罘是命 2024-11-24 17:35:01

每次提交后,您不必在有本地分支的任何地方都进行 git pull,git pull 将很乐意拉取多个更改。您还可以使用 git add . 或 git commit -a 来添加/提交所有更改,而无需转到 git add file{1,2}.php dir/otherfile .txt 或同等文件。只需确保之前使用 git status ,这样您就不会错误地添加和提交您不想要的内容。

使用 git 的目的是进行版本控制。它是一个非常强大的源代码管理工具,但它并不意味着仅仅用作文件传输机制。如果您想要/需要的只是 FTP,请使用 (S)FTP。

You don't have to git pull everywhere you have a local branch after every single commit, git pull will gladly pull multiple changes. Also you can use git add . or git commit -a to add/commit all changes without going git add file{1,2}.php dir/otherfile.txt or equivalent. Just make sure to use git status before so you don't mistakenly add and commit something you don't want.

The point of using git is to have revision control. It's an extremely robust tool for source code management, but it's not meant to be used just as a file transfer mechanism. If all you want/need is FTP, use (S)FTP.

遥远的绿洲 2024-11-24 17:35:01

如果您对服务器有足够的控制权,则可以在服务器上托管自己的中央存储库。 (如果没有,您仍然可以执行以下操作。)

从那里,您可以设置接收后挂钩以自动拉取或安全复制 (scp) 到您的实时部分/服务器中。 Gitolite 可以帮助解决安全问题,SSH 也可以密钥认证。

另外,正如 DyInuge 提到的,您不必在每次更改后都推动。您可以毫无问题地进行多次提交的单次推送。

最后,除了 Seth 的建议之外,我还将 Git Immersion 添加到您的阅读列表中。这是一个分步教程,旨在帮助您了解 Git 的工作原理以及可以在其中执行哪些操作。

If you have enough control over your server, you can host your own central repository on your server. (If not, you might still be able to do the following.)

From there, you can set up post-receive hooks to do a pull, or secure copy (scp) into your live section/server automatically. Gitolite can help with the security concerns, as can SSH key authentication.

Also, as DyInuge mentioned, you don't have to push after every change. You can do a single push of multiple commits with no problem.

Finally, in addition to Seth's recommendations, I also add Git Immersion to your reading list. It's a step-by-step tutorial aimed at helping you understand how Git works and what you can do in it.

遇到 2024-11-24 17:35:01

使用 git 和 GitHub 似乎需要很多额外的工作,我的看法是否错误?

我会说“是的,你看错了”,我认为@Mat 的评论有正确的想法。 Git 是一个版本控制系统。事实上,当它已经成为您工作流程的一部分时,您还可以将它用作部署工具,这可能是一个不错的好处。

我认为您应该使用 git 或某种其他形式的版本控制,因为您正在生成代码(或任何其他形式的数字工作)并尝试在没有更改历史记录和管理并发分支的能力的情况下这样做是疯狂。然而,如果我需要向您推销在工作流程中包含版本控制的价值,那么就没有必要担心 git 作为部署机制的工作效果如何。

Using git and GitHub seems like a lot of extra work, am I looking at this wrong?

I'll argue "yes, you are looking at this wrong" and I think @Mat's comment has the right idea. Git is a version control system. The fact that you can also use it as a deployment tool can be a nice bonus when it is already a part of your workflow.

I think you should be using git, or some other form of version control, because you are producing code (or any other form of digital work) and to attempt to do so without both a history of your changes and the ability to manage concurrent branches is madness. However if I need to sell you on the value of including version control in your workflow then there's no point in worrying about how well git works as a deployment mechanism.

在巴黎塔顶看东京樱花 2024-11-24 17:35:01

其他答案已经涵盖了命令行的效率 - 像你一样来自 Coda,需要一段时间才能习惯,但是一旦你熟悉了它,你就会喜欢它(特别是当你必须这样做时)重置)。

以下是我最近在(基本上)完成了您的工作后推出 DVCS 部署的方式。唯一的区别是出于安全原因我使用 gitolite 而不是 GitHub。

中央 git 服务器有一个存储库 - 在 master 分支上,如果它是开源项目,我将签入普通安装,或者我拥有的最新工作/稳定代码。然后,我为每个阶段创建一个分支 - 因此在您的情况下,有一个用于实时/生产和本地开发环境的分支。

我在 dev 分支上完成工作,制作功能分支或修补程序并将它们合并回来。一旦一切稳定,我将与 prod 分支合并。然后,我使用基于 SSH 的挂钩连接到远程服务器并启动拉取,这是 PHP 脚本的替代方案,并且更加安全。

即使您无法在服务器上安装 git,您仍然可以使用钩子来自动化部署。我必须进行广泛的测试以确保这是安全的,所以我建议您也这样做。此外,需要设置 Apache 以将任何请求重定向到 .git 目录,以便该目录不可读。

无论哪种方式,如果您不习惯编写挂钩来使所有内容就位,那么 git 就不是理想的 Web 部署系统。如果您有任何保留,请继续通过 FTP 上传。至少你现在有了版本控制。

The other answers have covered efficiency with the command line - coming from Coda like yourself, it took a little while to get used to, but once you're fluid with it, you're going to love it (especially when you have to do a reset).

Here's how I rolled out my DVCS deployment recently, after doing (essentially) what you are. The only difference is that I use gitolite instead of GitHub for security reasons.

The central git server has a repository - on the master branch, I'll check in a vanilla install if it is an open source project, or the latest working/stable code that I have. Then, I create a branch for each stage - so in your case, there's a branch for Live/Production and your local dev environment.

I do my work off of the dev branch, making feature branches or hotfixes and merging them back up. Once everything is stable, I'll merge with the prod branch. I then use an SSH-based hook to connect to the remote server and initiate the pull, which is an alternative to your PHP script and is quite a bit more secure.

Even if you didn't have the ability to install git on the server, you can still use the hooks to automate your deployment. I had to test extensively to make sure this was secure, so I suggest you do the same. Also, Apache needs to be setup to redirect any requests to the .git directory so that directory isn't readable.

Either way, git isn't the ideal web deployment system if you're not comfortable writing the hooks to get everything in place. If you have any reservations, continue uploading via FTP. At least you have version control now.

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