Usar git correctamente en un equipo pequeño

14

¿Cuál sería la forma más fácil de usar git correctamente en un pequeño equipo de aproximadamente 5 desarrolladores, con un servidor que ejecuta la aplicación en vivo?

version-control git ONOZ
fuente
55
Me gustaría cuestionar el uso de git en este caso. No hay ninguna ventaja para usar el control de fuente descentralizado, cuando tienes a todas las personas en una habitación con un servidor dedicado. Y todavía hay gastos generales de tirar / empujar encima de los commits.
Eufórico
10
@Euphoric depende de sus herramientas y flujo de trabajo.
3
@ONOZ describa su forma actual de trabajar con más detalle.
22
@Euphoric - Qué actitud de mente increíblemente estrecha. Para facilitar la ramificación y la fusión solo gito hgsupera la mayoría de los VCS centralizados. Puedo entender que las personas se molesten con las personas que constantemente insisten en lo buenos que son los DVCS, pero enterrar la cabeza en la arena y negarse a reconocer que puede desarrollar flujos de trabajo diferentes y posiblemente más eficientes con DVCS que sin uno es igual de malo.
Mark Booth
8
@Euphoric, usar Git no significa que tu control de fuente esté "descentralizado". Trabajo en un equipo pequeño, usamos Git y todavía tenemos un repositorio central. Eso es lo que empujas. El uso de un DVCS generalmente no significa que todas las personas se separen de las demás sin un punto central.
Kyralessa

Respuestas:

11

Te sugiero que crees alguna rama:

  • producción
  • Maestro
  • local

La rama de producción es la rama "en vivo". ¿La aplicación está en uso en este momento?

Cuando se necesita una actualización, un desarrollador puede extraer la rama maestra en la rama local. Que, puede comenzar a codificar. Al final, simplemente tire y empuje de la sucursal local del desarrollador al maestro. Un gerente de proyecto puede echar un vistazo en la rama maestra. Pruébalo. Y cuando esté listo, puede fusionar la producción con el maestro. Y ahora tendrás un nuevo software.

sensorario
fuente
Si se encuentra en una situación de consultoría o empresa, es posible que también desee tener una sucursal para UAT.
John MacIntyre
De acuerdo, estoy usando este flujo de trabajo.
Cheung
¿Podría explicar por qué la diferencia entre una sucursal local y una principal? Puedo ver por qué querrías tener una versión de producción que funcione, pero cuando sacas / empujas los cambios, se fusionará automáticamente incluso sin una sucursal local, ¿verdad?
Luc
1
Debido a que la rama local se puede nombrar como XXX-feature-name, por lo tanto, tiene una rama maestra como la combinación de todas las ramas de características que desea en producción. Sí: porque algunas características pueden no estar incluidas.
sensorario
7

Comience de manera simple y desarrolle un flujo de trabajo más complejo cuando lo necesite.

Hagas lo que hagas, no dejes que un modelo de ramificación Git exitoso sea ​​lo primero que vea la gente, solo los confundirá y abrumará. Mira esto más tarde cuando tengas más experiencia.

Sugeriría que comience con un gitrepositorio central y tenga a todos, incluyendo su producción y clones de compilaciones de prueba a partir de eso.

Dentro de su repositorio git, cree una productionrama y una testrama.

Los desarrolladores deben trabajar en sus propias ramas de funciones locales o remotas hasta que se completen y se fusionen master. Desde aquí se pueden fusionar en la testrama para su implementación en el entorno de prueba y cuando pasan las pruebas se pueden fusionar en la productionrama.

De esa manera, siempre puede ver qué hay de nuevo y no probado, qué se prueba pero aún no se ha implementado en producción y qué está realmente en producción.

Mark Booth
fuente
Interesante opinión, consideraría que el modelo de ramificación git es un factor decisivo para git, por otro lado, podría no ser tan obvio para los usuarios que no son git.
wirrbel
@wirrbel No existe el modelo de ramificación git, puede implementar cualquier modelo de ramificación que desee gitpara adaptarse a su flujo de trabajo. El que sugiero aquí es simple y es probable que sea mejor para gitusuarios inexpertos que un modelo de ramificación Git exitoso, pero es probable que AsGbm sea mejor para gitusuarios más experimentados , pero no es tan adecuado para algunos equipos (personas que desean mantener la versión múltiple ramas por ejemplo). Sin embargo, como dije, el problema con AsGbm es que puede parecer demasiado complicado.
Mark Booth
Te entiendo. Solo para mí, comencé con AsGbm (o más bien lo adapté a mis necesidades). Fue perfecto ya que pude ver cómo git podría usarse de manera diferente que svn
wirrbel
7

Tenemos una situación similar, excepto que tenemos docenas de aplicaciones web, no una. Hemos estado utilizando con éxito un modelo de ramificación Git exitoso durante el último año más o menos sin quejas significativas.

Wyatt Barnett
fuente
También he usado esto para crear modelos de ramificación en los últimos años. Es un modelo fantástico.
John MacIntyre
Pulgares arriba para el enlace
Rahul Gautam
0

Debe tener un repositorio maestro en el servidor de integración y cada desarrollador debe clonarlo. Después simplemente tira y empuja. Desarrolle nuevas características grandes en rama separada. No hay ciencia espacial aquí. En el servidor en vivo: también debe clonar el repositorio principal. Y es una buena práctica tener una rama como "en vivo" para ello.

Nikolay Fominyh
fuente
2
git archive es otra opción para implementar en el servidor en vivo asumiendo que en realidad no desea editar directamente cosas en el servidor en vivo
jk.