Git灾难后团队工作流SenchaTouch和科尔多瓦 - Git Post Catastrophe Team Workflow with Sencha Touch and Cordova

- 此内容更新于:2016-02-03
主题:

我们的团队与git斗争快速版本问题。很遗憾我最能了解Git和我们一直保持战斗使用它。我们开发iOS应用SenchaTouch和科尔多瓦。有很多的生成的文件。一些生成我们需要修改。3的4人需要能够创建构建iOS设备。一个人是一个质量保证的人,需要能够测试分支的变化。QA人学习修改代码和需要合并。目标合并让它更干净。减少生成的内容把冲突。理想情况下就好了如果有一种方法有一个命令合并完成后运行。例子:我可以让脚本但不确定如何确保它最终在其他文件夹中。我认为这将覆盖大部分的问题如果生成的文件将被忽略。不确定这是一个明智的想法,但有一个分支是专门为科尔多瓦建筑。我认为这将解决的问题必须编辑生成的文件。一旦构建功能我们可以标记点的版本我试图找出一种方法来实现这个尽可能简单。如果太复杂我担心有些人会不使用它。稍长一些的版本有一些其他的问题我有合并。我不是专家在Git中。我试图找到最安全的方法来合并两个分支并获得期望的结果,但当我感到自信,它失败了。我们所做的工作在相同的文件在同一时间。我试图鼓励短分支的生活减少问题,但事实上,这并不总是实用。只有理论Git工作流与吨谷歌上找到简单的合并冲突的例子。不如何解决数以百计的他们。我很感兴趣如果有人不得不处理,以及他们如何管理它。为了解决这些问题我一直试图让团队遵循一个工作流。在下面的评论中有点相反的顺序。我是开放给其他建议如果有人不同意这个工作流。好忽略策略吗?由于最近一期在IDE设置在某种程度上包含在合并,这真的有些事情搞砸的。这个不会有大的问题,除了人端端不知道发生了什么事情,让事情变得更糟。这是一场噩梦来解决。这启发了我为我们每个人做一个标准gitignore文件使用。它基本上是我的但我添加了一些说明。我想知道有一个更有效的方法忽略文件适用于所有分支已经存在吗?这解决了这个问题的例子,但每个现有分支需要经历这个过程。我错了吗?新文件内容的项目结构参考SenchaTouch项目结构1级文件/文件夹只有科尔多瓦目录结构我试图离开我认为没有必要的文件从用户名我改变。有谁知道如果这些应该被忽略?我觉得他们应该。这关系回到了不止一个的问题我们能够创建一个构建出奇怪的问题。对不起,这是这么长时间。我希望这是有意义的。如果有人到最后感谢你的阅读。任何反馈都是感激。

原文:

Quick Version

The Problem

  • Our team struggles with git. Unfortunatly I am the most knowlegable in Git and have been fight a battle to keep us using it.

  • We develope iOS apps with Sencha Touch and Cordova.

  • There's a lot of generated files.

  • Some are generated then we need to modify.

  • 3 out of 4 of us need to be able to create builds for the iOS device.

  • One of us is a QA person that needs to be able to test changes in branches.

  • The QA person is learning to make changes to code and will need to merge as well.

The Goal

  • Make merging cleaner. Less generated content throwing conflicts. Ideally it would be nice if there was a way have a command run after a merge is complete. example: sencha app refresh && sencha app build I could make a script to do this but not sure how to make sure it ends up in the other persons .git/hooks folder. I think this would cover the majority of issues if generated files are ignored.

  • Not sure if this is a wise idea but having a branch meant specifically building for Cordova. I think this would solve the issues with some generated files need to be edited. Once a build is functional we can tag that spot with the version

  • I'm trying to figure out a way to implement this as simply as possible. If it's too complicated I fear some will not keep using it.

Slightly Longer Version

There's a few other concerns I have about merging. I'm no expert in Git. I've attempted to find the safest way to merge two branches and get the desired outcome but just when I feel confident in that it fails me. We do work in the same files at the same time quite a bit. I've tried to encourage shorter branch lives to reduce issues but in reality this is not always practical.

Theoretical Git Workflow

With tons of Googling only find examples of simple merge conflicts. Not how to resolve hundreds of them. I am really interested if anyone has had to deal with that and how they manage it.

In an attempt to resolve these problems I've been trying to make a workflow for the team to follow. It's kind of reverse order in the comments below.

master                      # maybe master will contain deploy tags from completed builds
└── build                   # once qa is ready changes will be added to cordova build
    └── qa                  # dev work will merge into qa when ready
        └── development     # dev work done off of this branch
            ├── feature-01  # normal work
            └── feature-02  # normal work

I'm open to other suggestions if anyone disagrees with this workflow.

Good Ignore Stragegy?

Due to a recent issue where IDE settings were somehow included in a merge, this really screwed some things up. This wouldn't have been as big of an issue except the person on the recieving end had no idea what was going on and made things worse in the process. It was a bit of a nightmare to fix. So that inspired me to make a standard gitignore file for each of us to use. It was basically mine but I added some instructions to the top.

I do wonder if there is a more efficient way to apply an ignore file to all branches that already exist? This solves the problem in this one case but each existing branch will need to go through this process. Am I wrong?

New .gitignore file contents

#### ------------------------------------------------------------
#### UPDATING YOUR GITIGNORE
#### ------------------------------------------------------------
#
#   cd path/to/project
#   open -a TextEdit .gitignore
#
#### ------------------------------------------------------------
#### paste the contents of this file into your .gitignore file. 
#### if you do not have one save this file as .gitignore to the
#### root of your project. Now quite your IDE.
#### ------------------------------------------------------------
#
#   git rm -r --cached .
#
#### ------------------------------------------------------------
#### delete any files or folders you do not want
#### ------------------------------------------------------------
#
#   git add .
#   git commit -m 'updated tracking to allow gitignore updates to work'
#
#### ------------------------------------------------------------

# GIT

.git
*.orig

# IDE GENERATED

nbproject/
.idea/
.idea_modules/
*.iml
*.ipr
*.iws

# SENCHA

.sencha_backup/
archive/
build/
resources/sass/.sass-cache/
resources/css/app.css

The Project Structure for Reference

Sencha Touch Project structure

1st level files/folders only

APPNAME
├── .git
├── .gitignore
├── .sencha/                # I am on the fence about whether to ignore or not.
├── app/
├── app.js          
├── app.json                # a lot like a package.json file in node
├── bootstrap.js            # best I know is it contains a classname map to pre built src before compiling
├── bootstrap.json          # contains refs for index.html to external files like css and js
├── build/                  # contains testing, production builds for web, but production build is copied to cordova
├── build.xml
├── cordova/                # has all things related to xcode and native app. there are some
|                           # custom changes in here so we try to avoid rebuilding from zero.
├── index.html      
├── resources/              # images, fonts, sass, css etc
└── touch/                  # sencha framework

Cordova directory structure

I tried to leave out anything I thought wasn't necessary

The files starting with USERNAME I changed. Does anyone know if these should be ignored? I feel like they should. This ties back to the issue with more than one of us able to create a build with out weird issues.

cordova
├── config.xml
├── hooks/
├── platforms
│   └── ios
│       ├── CordovaLib
│       │   ├── Classes
│       │   └── CordovaLib.xcodeproj
│       │       └── xcuserdata
│       │           └── USERNAME.xcuserdatad    # ignore?
│       │               └── xcschemes
│       ├── cordova
│       │   └── lib
│       ├── APPNAME
│       │   ├── Classes
│       │   ├── Images.xcassets
│       │   │   ├── AppIcon.appiconset
│       │   │   └── LaunchImage.launchimage
│       │   ├── Plugins
│       │   └── Resources
│       ├── APPNAME.xcodeproj
│       │   ├── project.xcworkspace
│       │   │   ├── xcshareddata
│       │   │   └── xcuserdata
│       │   │       └── USERNAME.xcuserdatad    # ignore?
│       │   └── xcuserdata
│       │       └── USERNAME.xcuserdatad        # ignore?
│       │           └── xcschemes
│       ├── platform_www
│       └── www
├── plugins/
└── www
    ├── app.js
    ├── index.html
    ├── css
    ├── img
    ├── js
    └── resources

I'm sorry this is so long. I hope this makes sense. If anyone made it to the end thanks for reading. Any feedback is appreciated.

网友:我的建议:现在退出和/或找到一个有信誉的顾问。多个误解造成了许多问题,包括不必要的细节和你的请求,并省略一些必要的——例如,忽略每一个具体细节合并问题,除了“我失败了”,至少有一些你所描述的解决方案就加剧了麻烦。单独的问题我可以看到至少可以简单,足够我可能容易错过了的东西——它是星期天我毕竟——但他们都需要学习。我想说你把它在生产。太快。

(原文:My advice: back out now and/or find a reputable consultant. Multiple misunderstandings have caused many problems, and your requests include unnecessary details and omit necessary ones -- for instance, omitting every concrete detail about a merge problem except "it fails me" -- and at least some of the solutions you describe look to have compounded the trouble. Individually the problems I can see at least could be simple, and I might easily enough have missed something -- it's Sunday AM after all -- but they all involve learning. I'd say you put it in production too soon. Much too soon.)

楼主:哦好吧我明白你的意思。我能够解决这个问题,但我希望在未来避免它们。在我提到..我失败了……我可能说得更好。我一直试图给团队一个解释,“如果你这样做将会更少的痛苦”

(原文:Oh ok I see what you mean. I was able to solve the issues but I'm hoping to avoid them in the future. Where I mention ..it fails me.. I could have said that better. I have been trying to give the team an explanation of "if you do it this way it will be less painful")

楼主:Tho在写这今天早上我设法收集我的思想的方式简化了问题。再次运行思想这个问题从一开始就没有长周很晚我认为它能够工作。我更新了忽略,重新创建缓存,发现与git日志文件丢失,并检查这些电流恢复它们。那是一个微风。当然我有一些新知识在我的皮带,没有在我耳边开发人员的恐慌。当我花时间仔细看看一切没有汗水:)

(原文:Tho as of writing this this morning I managed to gather my thoughts in a way that simplified the issue. Running thought the issue again from the beginning without a long week of late nights I was able to work thought it. I updated the ignore, recreated the track cache, found what files were missing with the git log and and checked those out to current head to restore them. It was a breeze. Of course I had some new knowledge under my belt and didn't have the panic of the developer in my ear. When I took the time to carefully look at everything it was no sweat :))

网友:很高兴听到这个,欢呼声拉出来,谢谢你的更新。祝你好运。

(原文:Glad to hear this, cheers for pulling it out, thanks for updating. Good luck to you.)

楼主:谢谢!哦,就像一面堆栈溢出的问题。我应该更新这些想法的主要职位?

(原文:Thanks! Oh just as a side stack overflow question. Should I update those thoughts into the main post?)