¿Tiene sentido usar Git para pequeños equipos internos?

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 por un equipo más pequeño (<10) y proyectos internos (dentro de la organización). Entiendo que hay un claro beneficio de performance al tener una copy local del repository (aunque eso no es tan importante cuando su repository dentro de su organización …).

¿Todavía recomendarías Git (y la complejidad que conlleva) y por qué?

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é la gente dice que es complejo, pero todo eso está sobrevalorado. Para hacer todo lo que necesita hacer, tal vez tenga que trabajar con 10 commands como máximo. Y no necesita comprender todas las opciones de esos 10 … solo unas pocas "recetas" estilo libro de cocina.

Lo que necesitas entender es un poco acerca de cómo Git difiere bajo el capó . Pero eso no es porque git sea complejo, es porque Git es diferente. Puedes dedicar un time 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 files 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 a Git. Hazlo. Usted será tan feliz de haberlo hecho. Buena suerte.

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. Uso git todos los días, y casi nunca publico nada más que:

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, solo hay un puñado de commands que debe recordar a diario. Para algo más complicado que eso, siempre puedes searchlo en la documentation.

Una de las cosas que realmente me encanta de git y por la que recomiendo encarecidamente utilizarlo es que puede mantener su trabajo bajo control y la versión controlada, incluso cuando todavía no está listo para comprometerse con el repository. 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 repository principal.

Uso Git para un proyecto que corro solo (tamaño de equipo = 1) y para otro proyecto con 5 miembros .

Las razones por las que personalmente me encantan:

  • ramificación y fusión sin dolor;
  • configurar varios repositorys que acumulan diferentes types de cambios (útiles para proyectos web);
  • funciona a través de HTTP, SSH, lo que sea ( nunca tener que pensar cómo conectarse );
  • una vez que te acostumbras al flujo de trabajo commit-until-good-then-push , no puedes volver atrás.

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

  • uno puede trabajar en una sucursal durante semanas sin preocuparse de tener que arreglar 100 conflictos más tarde;
  • El flujo de trabajo distribuido tiene aún más sentido y también integra la revisión de código en su process.

Sin embargo, si su equipo es tonto (lo cual puede ser cierto algunas veces) o parcial en contra de Git, recomiendo encarecidamente que no lo haga porque requiere cierto esfuerzo y curiosidad por aprender , y no todos en el mundo quieren ramificarse, fusionarse, usar flujo de trabajo distribuido o cualquier otra cosa que Git tenga para ofrecer, en absoluto.

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

Ni mas ni less.

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

Prefiero git over 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.

Yo diría que sí.

Incluso por mi count tiendo a usar git, debido a todas sus características útiles. No tener que golpear la networking (incluso en interno) para todas las operaciones excepto dos (empujar y tirar) es un gran ahorro de time en el largo ploop. Cosas como consultar diferentes twigs solo sucede localmente, al igual que leer el logging.

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

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

Vea para una estrategia de ramificación exitosa git flow

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

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

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