独立开发者的Git工作流程（总git newbie） [英] Git workflow for lone developer (total git newbie)

问题描述

我已经决定，现在是我开始在一个PHP项目上开始使用Git的时候了，这个项目我十多年来一直在随意开发。 （请从版本控制警察处获得讲座！）由于我的VPS需要进行复杂的设置才能满足项目的所有需求（特别是单一代码库 - 多客户端结构以及日语安装的TeX来创建特殊PDF文件），我无法在本地Windows机器上设置开发环境。但是我可以在服务器上有一个测试区域，所以这是我的开发区域。目前我使用Filezilla来访问服务器并直接将文件打开到Notepad ++中，当我准备好看到我的编辑动作时，我只需保存并让Filezilla上传。当测试平台上的所有内容都看起来不错时，我将这些文件复制到生产代码库区域。是的，除了我自己的评论之外，这并没有给我带来任何变化的历史记录，我必须小心，不要将错误修复与半新功能混合在一起。我可以看到Git分支机构在进行不同升级时的价值。

昨天，我的脚趾湿了。首先，我创建了一个Github帐户，然后（根据教程的建议）安装了Git For Windows（带有自己的Bash和小巧的GUI）和Kdiff3，并遵循了一些关于配置Git Bash的说明。尽管如此，我最终还是需要安装其他的东西才能与我的Github帐户（适当地命名为Github for Windows）进行交互，这似乎是其他两个程序应该为我做的所有事情。无论如何，我做了一件简单的工作，因为我第一次进入Github世界 - 我为其他人的jQuery插件添加了功能，并希望与开发人员分享它，所以我分叉他的回购，克隆到我的机器，覆盖我之前编辑和测试的文件，同步到我的Github帐户，并发送拉取请求。最后一句话中的所有术语对我来说都是全新的，所以我为自己感到非常自豪，我得到了很多。 ;）但我想我只需要Github软件，而不是Git软件 - 很难知道要相信哪些教程。

无论如何，现在我想弄清楚我自己的工作流程，这是我真正的问题给你们。据我所知，在任何地方都有主回购商，但公共Github需要花钱，而且我不在乎别人是否看到我的代码（我不希望其他人能够使用由意大利面条代码制作的古怪项目，但如果他们想，这很棒）。好的，但那又怎么样？也许是这些场景中的一种，或者其他的东西：

1. 将repo的分支克隆到我的PC上，对本地文件进行编辑，并将它们上传到Filezilla进行测试（比我当前的工作流程多点击一次，因为Filezilla不会自动查看本地文件和远程文件之间的关系，但不是什么大问题）。然后，当我对代码感到满意时，在本地提交，同步到Github，然后将文件（从某处 - 不确定这一点）复制到生产区域。




2. 在我的VPS上安装Git的Linux风格，以便本地Git文件位置是测试平台，并通过PuTTY使用Git执行本地提交。简单的文件结构（根本不需要在我的电脑上复制），但使用Git更麻烦：
   
   

   
   
   • 我不在PuTTY非常频繁，出于某种原因，连接经常死亡，我必须重新启动。
   
   
   • 尽管Linux命令行是Git的本地栖息地，但我可能更习惯于GUI （因为我很快就忘记了命令语法 - 我认为是老大脑）。
     
     
     

     另外，因为我从未使用过Git程序I安装在这里，我不确定它是否是我将在服务器上使用的Git或Github。

   其他情况下，因为＃1或＃2使用Git / Github来管理生产文件区域，这可能是一个好主意，这样我就不会忘记复制我需要的所有东西。
   
   

我试图研究基于PHP的图形用户界面（GUI）与概念＃2一起使用的可能性（因此我不必在日常操作中使用PuTTY），但这似乎是这些工具的讨论都假设你正在尝试创建自己的Github服务，或者本地克隆的repo在物理上位于本地PC上（xAMP在任何操作系统上运行）。但是，也许我使用的Github软件足以完成所有这些 - 很难说。我还不明白Github上的主公共回购，某些地方的分支（在Github上？），我的Web服务器（测试平台和生产区域）上至少有两组文件，Github软件，Git软件，以及我所坐的电脑的键盘/屏幕。

因此，请原谅我的新手ramblings，但如果有人有类似的发展情况，您的工作流程是什么？或者你会为我建议什么？

解决方案

这是解决问题的一种方法：

您需要三个存储库：

• 编辑代码的本地存储库。 [1]


• 服务器上的裸露远程存储库。这将位于不公开查看的位置，但您可以使用ssh进入。 [2]


• 生产环境。 [b]
  
  
  

  下面是实现：
  
  

    workstation $ cd localWorkingDirectory / 
  工作站$ git init 
  工作站$ git add。 
   workstation $ git commit -m'initial commit'
   workstation $ ssh login @ myserver 
   myserver $ mkdir myrepo.git 
   myserver $ cd myrepo.git 
   myserver $ git init --bare 
   myserver $ exit 
   workstation $ cd localWorkingDirectory / 
   workstation $ git remote add origin login @ myserver：myrepo.git 
   workstation $ git push origin master 
    

  每次您在任何分支上进行提交时，请将其备份：

    workstation $ git push origin BRANCH 
    

  当您准备将分支版本2 移入生产时：执行此操作

    workstation $ git push origin version2 
   workstation $ ssh login @ myserver 
   myserver $ git clone path / to / myrepo.git productionDirectory 
   myserver $ cd productionDirectory 
   myserver $ git checkout version2 
    

  哦不！它并没有工作！更好地切换回版本1！
  
  

   工作站$ ssh登录@ myserver 
   myserver $ cd productionDirectory 
   myserver $ git checkout version1 
    

  
  

  I have decided that it's time for me to start using Git on a PHP project that I have been developing casually for over a decade. (Please, no lectures from the version control police!) Due to the complex setup required on my VPS to do everything the project needs (esp. single-codebase-multiple-client structure and a Japanese-capable installation of TeX to create specialty PDFs), it is not possible to set up a development environment on my local Windows box. But I do have a testbed area on the server that I can play in, so it's my development area. Currently I use Filezilla to access the server and open files directly into Notepad++, and when I'm ready to see my edit in action, I just save and let Filezilla upload. When everything looks good on the testbed, I copy the files to the production codebase area. Yeah, that gives me no history of my changes other than my own comments, and I have to be careful not to mix bug fixes with half-finished new features. I can see the value of Git's branches for different upgrades in progress.

  Yesterday I got my toes wet. First I created a Github account, and then (at the recommendation of a tutorial) installed Git For Windows (with its own Bash and tiny-looking GUI) and Kdiff3, and followed some instructions for configuring Git Bash. After all that, though, I ended up having to install something else in order to interface with my Github account (appropriately named Github for Windows), which seem to do all the stuff the other two programs were supposed to do for me. Anyway, then I did a simple task as my first foray into the Github world - I had added functionality to someone else's jQuery plugin and wanted to share it with the developer, so I forked his repo, cloned it to my machine, overwrote the file I had previously edited and tested, synced to my Github account, and sent a pull request. All the terminology in that last sentence was brand new to me, so I was pretty proud of myself that I got that far. ;) But I guess I only needed the Github software, not the Git software - it's hard to know what tutorials to believe.

  Anyway, now I want to figure out a workflow for my own stuff, which is my actual question for you guys. From what I can tell, having the master repo anywhere but the public Github costs money, and I don't care if others see my code (I don't expect anyone else to work on my oddball project made of spaghetti code, but if they want to, that's great). Okay, but then what? Perhaps one of these scenarios, or something else:

  1. Clone branches of the repo to my PC, do edits on the local files, and upload them in Filezilla for testing (a couple more clicks than my current workflow because Filezilla doesn't automatically see the relationship between the local file and the remote file, but not a big deal). Then when I'm happy with the code, commit locally, sync to Github, and copy the files (from somewhere - not sure on this point) to the production area.

  2. Install the Linux flavor of Git on my VPS so that the "local" Git file location is the testbed, and use Git through PuTTY to do the local commits. Simpler for file structure (no need for a copy on my PC at all) but more cumbersome to use Git:

     • I'm not on PuTTY very frequently, and for some reason the connection often dies on me and I have to restart.
     • Even though the Linux command line is Git's native habitat, I am probably more comfortable with a GUI (because I forget command syntax quickly - old brain, I guess).

     Also, since I never ended up using the Git program I installed here, I'm not sure whether it would be Git or Github I would be using on the server.

  3. Some other scenario, since neither #1 or #2 uses Git/Github to manage the production file area at all, which would probably be a good idea so that I don't forget to copy everything I need.

  I tried to research the possibility of a PHP-based GUI to go with idea #2 (so I don't have to use PuTTY for day-to-day operations), but it seems that the discussions of such tools all assume either that you are trying to create your own Github service, or that the "local" cloned repo is physically on your local PC (with xAMP running on whatever OS it is). But maybe the Github software I used is enough to do all that - it's hard to tell. I don't yet understand the interplay between a master public repo on Github, branches somewhere (on Github also?), at least two sets of files on my web server (the testbed and the production area), Github software, Git software, and the keyboard/screen of the computer I'm sitting at.

  So pardon my newbie ramblings, but if someone out there has a similar development situation, What's your workflow? Or what would you suggest for me?

  解决方案

  Here's one way to aproach the issue:

  You will need three repositories:

  • a local repo to edit code. [1]
  • a bare remote repository on your server. This will be in a location that in not publicly viewable, but you can ssh in to. [2]
  • The production environment. [3]

  Here's the implementation:

  workstation$ cd localWorkingDirectory/
  workstation$ git init
  workstation$ git add .
  workstation$ git commit -m 'initial commit'
  workstation$ ssh login@myserver
  myserver$ mkdir myrepo.git
  myserver$ cd myrepo.git
  myserver$ git init --bare
  myserver$ exit
  workstation$ cd localWorkingDirectory/
  workstation$ git remote add origin login@myserver:myrepo.git
  workstation$ git push origin master
  

  every time you make a commit on any branch, back it up with:

  workstation$ git push origin BRANCH
  

  When you are ready to move branch version2 into production: do this

  workstation$ git push origin version2
  workstation$ ssh login@myserver
  myserver$ git clone path/to/myrepo.git productionDirectory
  myserver$ cd productionDirectory
  myserver$ git checkout version2
  

  Oh no! It dsoesn't work! better switch back to version1!

  workstation$ ssh login@myserver
  myserver$ cd productionDirectory
  myserver$ git checkout version1
  

  这篇关于独立开发者的Git工作流程（总git newbie）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！