在iPhone项目中,哪些文件需要保持在版本控制之下?

时间:2023-01-13 23:16:08

I found this previous question about Cocoa projects, but I wanted to know if it's the same for iPhone projects.

我发现了之前关于Cocoa项目的问题,但是我想知道对于iPhone项目是否也是这样。

5 个解决方案

#1


2  

As far as I know, the same responses there apply to iPhone development as well. In my projects, the only files I keep under SVN's control are the source files, any resources (images, .XIBs, audio, etc.), and the .xcodeproj file.

据我所知,同样的反应也适用于iPhone的开发。在我的项目中,SVN控制下的文件只有源文件、任何资源(图像、. xibs、音频等)和.xcodeproj文件。

#2


1  

It may be a good idea to version control provisioning profiles. Especially for an ad-hoc beta test profile, you'll need to update it every time you add a new beta tester, and having a history of that seems like a good idea.

版本控制配置文件可能是一个好主意。特别是对于一个特别的beta测试配置文件,您需要在每次添加一个新的beta测试人员时都对它进行更新,并且有这样的历史经验似乎是一个好主意。

#3


1  

Actually there is something I would say you should version control that you would normally not - the final application bundle and dsym file, both under build. However, you only need to archive these when you release either an ad-hoc or distribution build for the store - so I'd leave build in the ignore file, but have somewhere you can copy these files to check them in for a distribution and tag them along with the source.

实际上,我想说的是,您应该对版本控制进行一些通常不会进行的控制——最终的应用程序包和dsym文件,都在构建中。但是,您只需要将这些文件归档,当您发布一个临时的或分发的存储构建时——因此,我将在忽略文件中构建,但是在某个地方,您可以复制这些文件以检查它们的分布,并将它们与源代码一起标记。

You'll probably want to compress the app bundle before placing it in this save directory

在将应用程序包放入这个save目录之前,您可能想要压缩它

You need these two files in order to be able to symbolicate crash logs sent to you by either beta testers, or users of the app from the app store. A meaningful stack trace of a crash is priceless!

您需要这两个文件,以便能够象征测试人员或应用程序商店用户发送给您的崩溃日志。一个有意义的崩溃堆栈跟踪是无价的!

#4


1  

If you're planning on updating the app over time in addition to project sources and media you may also want to put the following under version control:

如果您打算在项目源和媒体之外的时间内更新应用程序,您可能还希望将以下版本控制在版本控制之下:

  • Signing certificates for app (and/or mobileprovision files).
  • 为应用程序(和/或移动供应文件)签名证书。
  • The final version of the binary app (zipped) submitted to Appstore.
  • 提交给Appstore的二进制应用程序的最终版本。
  • Binary.dSYM file for each revision (for post-release crash symbolicating).
  • 二进制文件。每个修订的dSYM文件(用于发布后的崩溃符号)。
  • Screenshots/icons/text file of description for app as submitted to Appstore.
  • 提交给Appstore的app的截图/图标/描述文本文件。

Before beta releases you may also want to put mobileprovision files as well as a snapshot of the device list from the Developer portal for that version just so you can go back in time and figure out who got what release. If you're really hardcore you can also keep emails submitted by beta testers so you can keep it all in one place and go back and double-check against bug reports.

在beta版本发布之前,您可能还希望将mobileprovisioning文件以及该版本的开发门户中的设备列表的快照,以便您能够及时返回并确定谁获得了哪个版本。如果你是真正的核心,你也可以保留测试人员提交的电子邮件,这样你就可以把所有的邮件放在一个地方,然后回去检查错误报告。

#5


0  

Yes. I use the exact same .gitignore file for iPhone OS projects as I do for Mac OS projects.

是的。我在iPhone OS项目中使用的.gitignore文件与在Mac OS项目中使用的文件完全相同。

#1


2  

As far as I know, the same responses there apply to iPhone development as well. In my projects, the only files I keep under SVN's control are the source files, any resources (images, .XIBs, audio, etc.), and the .xcodeproj file.

据我所知,同样的反应也适用于iPhone的开发。在我的项目中,SVN控制下的文件只有源文件、任何资源(图像、. xibs、音频等)和.xcodeproj文件。

#2


1  

It may be a good idea to version control provisioning profiles. Especially for an ad-hoc beta test profile, you'll need to update it every time you add a new beta tester, and having a history of that seems like a good idea.

版本控制配置文件可能是一个好主意。特别是对于一个特别的beta测试配置文件,您需要在每次添加一个新的beta测试人员时都对它进行更新,并且有这样的历史经验似乎是一个好主意。

#3


1  

Actually there is something I would say you should version control that you would normally not - the final application bundle and dsym file, both under build. However, you only need to archive these when you release either an ad-hoc or distribution build for the store - so I'd leave build in the ignore file, but have somewhere you can copy these files to check them in for a distribution and tag them along with the source.

实际上,我想说的是,您应该对版本控制进行一些通常不会进行的控制——最终的应用程序包和dsym文件,都在构建中。但是,您只需要将这些文件归档,当您发布一个临时的或分发的存储构建时——因此,我将在忽略文件中构建,但是在某个地方,您可以复制这些文件以检查它们的分布,并将它们与源代码一起标记。

You'll probably want to compress the app bundle before placing it in this save directory

在将应用程序包放入这个save目录之前,您可能想要压缩它

You need these two files in order to be able to symbolicate crash logs sent to you by either beta testers, or users of the app from the app store. A meaningful stack trace of a crash is priceless!

您需要这两个文件,以便能够象征测试人员或应用程序商店用户发送给您的崩溃日志。一个有意义的崩溃堆栈跟踪是无价的!

#4


1  

If you're planning on updating the app over time in addition to project sources and media you may also want to put the following under version control:

如果您打算在项目源和媒体之外的时间内更新应用程序,您可能还希望将以下版本控制在版本控制之下:

  • Signing certificates for app (and/or mobileprovision files).
  • 为应用程序(和/或移动供应文件)签名证书。
  • The final version of the binary app (zipped) submitted to Appstore.
  • 提交给Appstore的二进制应用程序的最终版本。
  • Binary.dSYM file for each revision (for post-release crash symbolicating).
  • 二进制文件。每个修订的dSYM文件(用于发布后的崩溃符号)。
  • Screenshots/icons/text file of description for app as submitted to Appstore.
  • 提交给Appstore的app的截图/图标/描述文本文件。

Before beta releases you may also want to put mobileprovision files as well as a snapshot of the device list from the Developer portal for that version just so you can go back in time and figure out who got what release. If you're really hardcore you can also keep emails submitted by beta testers so you can keep it all in one place and go back and double-check against bug reports.

在beta版本发布之前,您可能还希望将mobileprovisioning文件以及该版本的开发门户中的设备列表的快照,以便您能够及时返回并确定谁获得了哪个版本。如果你是真正的核心,你也可以保留测试人员提交的电子邮件,这样你就可以把所有的邮件放在一个地方,然后回去检查错误报告。

#5


0  

Yes. I use the exact same .gitignore file for iPhone OS projects as I do for Mac OS projects.

是的。我在iPhone OS项目中使用的.gitignore文件与在Mac OS项目中使用的文件完全相同。