Configuración de Git para no desarrolladores

Question

Estoy tratando de presentar a git en el trabajo, y para hacerlo quiero maximizar la aceptación del equipo.

Esto no es un problema para los programadores (generalmente estamos encantados de aprender nuevas cosas como esta) pero es un problema para los diseñadores y gestores de contenidos que cometen contenido estático como HTML, CSS, etc. apenas pueden use Subversion a través de TortoiseSVN, así que necesito simplificar git tanto como sea posible. Esto significa que algunos conceptos tienen que estar ocultos de alguna manera, como index, stash, merges, rebase, branches.

Las copias de trabajo sucio deben manipularse automáticamente con stashes.

Además, no hay forma de que usen la línea de comandos. Tampoco leerán ninguna guía o tutorial.

Quizás te preguntes por qué no me limito a git-svn: es porque los diseñadores tienen que ajustar el html/css que creo antes de que se fusione en el maletero.

Entonces las preguntas son: ¿Alguien ha usado git con no desarrolladores? ¿cómo lo manejas? ¿cuál es tu flujo de trabajo? podría git-cvsserver ser útil para esto? ¿Hay alguna GUI que haga almacenamiento automático?

Todo lo que se pueda usar para simplificar git será muy apreciado.

Answer 1

que habías dicho que no va a leer tutoriales, pero tal vez usted puede leer éste un explicarlo a ellos ..

http://hoth.entp.com/output/git_for_designers.html

En cuanto a las interfaces gráficas de usuario echar un vistazo a estos mensajes:

https://stackoverflow.com/questions/157476/what-guis-exist-for-git-on-windows

https://stackoverflow.com/questions/83789/what-is-the-best-git-gui-on-osx

Answer 2

Básicamente, es necesario hacer Git:

• transparente para los usuarios no técnicos
• administrados por uno Git-comprensión "superusuario" técnica

Eso significa:

• un repo central de Git, donde cada diseñador/contenido el administrador presionará para (incluso si no lo saben)
• guiones que se ejecutan todos los días (generalmente temprano en la noche) para:
  • supervisando un "archivo de instrucciones" central (que puede indicar a dicho script en cada estación de committer que cambie de rama, o actualice un archivo .gitignore, o ...)
  • git add -A, git commit
  • git push
  • git pull (que tienen que ser conscientes de revisar cada mañana su espacio de trabajo con el fin de tener en cuenta los nuevos trabajos extraídos de la repo central)
  • escribir el resultado de todos los comandos en los archivos dedicados (fecha y el nombre de la confirmador, en el centro de un directorio compartido)

Cada mañana, el superusuario wo Verifique si todos los empujes son exitosos y resuelva cualquier conflicto. Él/ella también fusionaría el trabajo aprobado en las sucursales locales del repositorio central (incluido el que se retira todas las noches).
También recomendaría hacer esos repositorios Git (en estaciones de trabajo committer) en un directorio compartido, para que el superusuario pueda acceder a ellos y manipularlos directamente si es necesario.

Answer 3

Acabo de ver this question emergente. Se menciona flashbake, que parece ser un conjunto de scripts de Python (que se pueden instalar para los diseñadores como iconos para hacer doble clic, como se sugiere) que se ocupan de una gran cantidad de acciones git comunes. No lo he usado, pero parece que probablemente sea mucho mejor que empezar de cero, y si realizas algunas mejoras, ¡ayudará a otros en tu lugar! Desde la página del proyecto:

El objetivo principal de los scripts es generar un mensaje de confirmación rico pero automatizado para git. En segundo lugar, automatiza la administración de un proyecto de git, por lo que una única e invariable llamada a flashbake se ocupa del flujo de trabajo git más común, agregando y confirmando archivos.

Definitivamente también creo que la sugerencia de VonC anterior sobre el flujo de trabajo, incluida la supervisión de un superusuario, es otra gran parte de la respuesta aquí.

Answer 4

¿Por qué no dejar que continúen utilizando SVN y dejar que los expertos en tecnología usen Git?

Git puede trabajar con repositorios SVN. Así que mantenga un repositorio SVN para los diseñadores, y un repo de git para los desarrolladores. Haga que sus usuarios expertos manejen empujando y tirando entre los dos si es necesario.

TortoiseSVN es muy simple, y parece que es todo lo que sus usuarios no expertos en tecnología realmente necesitan. ¿Qué beneficio verán si se mudan a Git?

(Sólo una nota - Realmente no entiendo por qué no se puede utilizar git-svn)

Answer 5

Tenemos algunos diseñadores que trabajan con git utilizando GitExtensions. No tienen ningún problema porque GitExtensions hace todo de forma automática, como esconder, presionar y advertir al usuario cuando hay algún tipo de problema/conflicto. La configuración se verifica automáticamente al inicio y no hay mucho que se pueda hacer mal. Es mucho más fácil que tortugas una vez que te acostumbras a los términos push/pull/commit.