¿El uso de Git tiene sentido para pequeños equipos internos?

Question

Me parece que Git fue diseñado para proyectos de código abierto a gran escala, con un gran número de desarrolladores y equipos.

Me pregunto si Git lo vale para un equipo más pequeño (< 10) y proyectos internos (dentro de la organización). Entiendo que hay un claro beneficio de rendimiento al tener una copia local del repositorio (aunque eso no es tan importante cuando su repositorio dentro de su organización ...).

¿Seguiría recomendando Git (y la complejidad que conlleva) y por qué?

Answer 1

Git no es realmente tan complejo. Y es fantásticamente poderoso y preciso. No usaría nada más, para un proyecto de una persona o un proyecto de 100,000 personas. Lo digo en serio.

Veo por qué las personas dicen que es complejo, pero que todo está sobrevalorado. Para hacer todo lo que necesita hacer, tal vez tenga que trabajar con 10 comandos como máximo. Y no necesita comprender todas las opciones de esos 10 ... solo unas pocas "recetas" estilo libro de cocina.

Lo que hace hay que entender es un poco sobre cómo difiere Git bajo el capó. Pero eso no es porque git sea complejo, es porque Git es diferente. Puedes dedicar un tiempo en el transcurso de uno o dos días a profundizar en esa información, y estarás listo para continuar.

Disculpe mi crudeza, pero Git hace que el sistema de archivos sea b * tch. Puede cambiar entre "realidades alternativas" de su proyecto de software a voluntad. Una vez que comprenda de dónde viene la herramienta, tendrá un control completo, casi divino sobre los bits y caracteres que componen su software. Hay pocas herramientas de tal poder disponibles para los desarrolladores de software, punto.

Sí, hombre, recomiendo Git. Hazlo. Usted será tan feliz de haberlo hecho. Buena suerte.

Answer 2

Es bastante simple: hace lo que se supone que debe hacer bastante bien: control de versiones.

No más, no menos.

Funciona con mi IDE, combina las ediciones de grupo perfectamente, y puedo extraer el código anterior en cualquier momento.

Answer 3

Sí, debido a cómo funciona el seguimiento de cambios en comparación con svn. (Simplemente hay menos conflictos en grandes fusiones de varios pasos).

Sí, porque puede hacer pequeñas comprobaciones locales mientras trabaja y luego realizar cambios de trabajo completos en el repositorio principal. Cuando haces el push, todos tus pequeños commits son empujados.

Sí, porque cuando haces una extracción desde el repositorio principal, no se fusiona inmediatamente sino que coloca las cosas tiradas en ramas. Perfecto para cuando realiza cambios más grandes y desea retrasar la actualización algunos días en algunas computadoras.

Answer 4

Prefiero git sobre svn para proyectos de una sola persona. Es más fácil usar las mismas herramientas en toda la línea, y mantener tanto las reposiciones git como svn me parece infructuoso.

Answer 5

Yo diría que sí.

Incluso en mi propio tiendo a usar git, debido a todas sus características útiles. No tener que golpear la red (incluso en interno) para todas las operaciones excepto dos (empujar y tirar) es un gran ahorro de tiempo en el largo plazo. Cosas como consultar diferentes ramas solo sucede localmente, al igual que leer el registro.

Tenga en cuenta que incluso cuando se distribuye git, aún puede tener repositorios centrales desde donde todos estén presionando y tirando de ellos. Pero es solo un repositorio central por convención.

Y la creación barata de sucursales también es una ventaja. Puede crear fácilmente una rama de tema donde implemente una característica pequeña, que posteriormente fusionará de nuevo en la rama de desarrollo.

Véase, por una estrategia exitosa de ramificación git flow

Answer 6

uso de Git para un proyecto que corro por mi (tamaño del equipo = 1) y para otro proyecto con 5 miembros.

Las razones por las que personalmente me encanta:

• indolora branching and merging;
• configurando several repositories que acumulan diferentes tipos de cambios (útiles para proyectos web);
• funciona a través de HTTP, SSH, lo que sea (nunca tiene que pensar cómo conectarse);
• una vez que se acostumbre a commit-until-good-then-push workflow, no se puede volver atrás.

Los beneficios para un equipo inteligente son aún más evidente:

• una lata trabajo en una rama durante semanas sin la preocupación de tener que fijar 100 conflictos más adelante;
• flujo de trabajo distribuido tiene aún más sentido y también integra revisión de código en su proceso.

Sin embargo si su equipo es tonto (que puede ser cierto a veces) o sesgada en contra de Git, recomiendo fuertemente contra porque toma cierto esfuerzo y curiosidad programador para aprender, y no todo el mundo en el mundo quiere ramificarse, fusionarse, usar flujo de trabajo distribuido o cualquier otra cosa que Git tenga para ofrecer, en absoluto.

Answer 7

Git tiene sentido para equipos grandes y pequeños. Sí, git es complejo, pero eso no significa que siempre tengas que lidiar con esa complejidad.Yo uso git todos los días, y rara vez expido otra cosa que no sea:

git branch # To remind myself what features I'm working on. 
git checkout <name_of_branch> # To switch to whatever I want to work on. 
git checkout -b <name_of_new_feature> # To start work on a new branch 
git add <name_of_file> # To add it to the list of tracked files. 
git commit -m <commit_message> # To checkpoint my work. 
git merge <name_of_branch> # To integrate changes back to trunk. 
git branch -d <name_of_branch> # To delete a branch after it has been merged. 

En realidad, hay sólo un puñado de comandos que necesita recordar sobre una base diaria. Para algo más complicado que eso, siempre puedes buscarlo en la documentación.

Una de las cosas que realmente me encanta de git y por la que recomiendo encarecidamente su uso es que puede mantener su trabajo bajo control y la versión controlada, incluso cuando todavía no está listo para ser enviado al repositorio. Por ejemplo, podría usar "git commit" muchas veces, localmente, antes de mostrarlo a otros desarrolladores. Esto ha aumentado enormemente mi confianza en hacer cambios al código; Puedo experimentar y no preocuparme de que mi trabajo actual se perderá; siempre puedo volver a una versión segura si algo sale mal. Esto no se puede decir de SVN, por ejemplo, donde se verán las confirmaciones en el repositorio principal.