cómo usar el control de versiones

19

Estoy desarrollando un sitio web en php en localhost y cuando los módulos se completan, lo subo a la nube para que mis amigos puedan probarlo alfa.

A medida que sigo desarrollando, tengo muchos archivos y pierdo la noción de qué archivo he editado o cambiado, etc. He oído hablar de algo como "control de versiones" para administrarlos, pero no estoy seguro de cómo funciona.

Por lo tanto, mi pregunta es: ¿hay alguna manera fácil / servicio / aplicación disponible para hacer un seguimiento de todas las ediciones / cambios / nuevos archivos y administrar los archivos a medida que desarrollo el sitio web? Tan pronto como termine con un módulo, quiero subirlo a la nube (estoy usando Amazon Cloud Service). Si algo sucede con los archivos nuevos, es posible que desee volver al archivo anterior. Y tal vez, en un clic o dos, ¿puedo ver los archivos que he editado o cambiado desde el último que he subido?

ptamzz
fuente
55
Hay muchas sugerencias sobre qué sistema de control de versiones usar, y para ser honesto, todas son mejores que su forma actual "manual".
Johan

Respuestas:

28

La gestión de la configuración del software , de la que forma parte el Control de versiones , es un poco más compleja que realizar un seguimiento de los cambios en los archivos, aunque ciertamente puede comenzar con eso. Pero lea los artículos de Wikipedia vinculados anteriormente junto con el tutorial de Joel Spolky sobre Mercurial .

Para comenzar, elija uno de Mercurial, GIT o Bazar, en ese orden, e instálelo junto con las herramientas para su IDE y sistema operativo (prefiero Mercurial con HGE para Eclipse).

  1. Inicialice un repositorio desde su directorio de trabajo ( hg init con Mercurial).
  2. Decida qué archivos y directorios desea rastrear y cuáles no. La regla general no es rastrear archivos generados por compiladores y otras herramientas.
  3. Use el comando para agregar los archivos y directorios al repositorio ( hg add para Mercurial).
  4. Informe a la herramienta sobre los patrones de los archivos que no desea rastrear (edite .hgignore para Mercurial).
  5. Realice una confirmación para rastrear las versiones originales ( hg ci ).
  6. Realice una confirmación después de cada hito lógico, incluso si es pequeño.
  7. Agregue nuevos archivos a medida que los crea.
  8. Repite los dos últimos.
  9. Haga una copia de seguridad de su directorio de trabajo y el repositorio con la frecuencia que sea razonable.

Con sus archivos en el repositorio, puede conocer las diferencias entre dos versiones de un archivo o directorio, o el proyecto completo ( hg diff ), ver el historial de cambios ( hg hist ) y revertir los cambios ( hg up -r )

Es una buena idea etiquetar (etiqueta hg ) el repositorio antes de publicar su código para que haya una manera fácil de volver exactamente a lo que publicó para enmiendas o comparaciones.

Si desea experimentar con una línea de desarrollo diferente, hágalo en una rama simple clonando el repositorio principal ( clon hg ) y no retroceda hasta que el experimento sea concluyente. Es tan fácil como tener un directorio de trabajo diferente para el experimento.

Si el experimento es para una nueva versión actualizada, clone y luego bifurque ( hg branch ) para que pueda mantener actualizadas todas las copias de los repositorios sin que un experimento interfiera con el otro.

Linus Torvalds (que se ocupa de decenas de miles de archivos y millones de líneas de código en sus proyectos) dio una charla en Google sobre por qué la herramienta no puede ser CVS, SVN o cualquiera de los muchos gratuitos y comerciales que existen. ; Vale mucho la pena verlo.

Apalala
fuente
1
Prefiero Mercurial también. Me gusta el soporte en Netbeans porque, mientras está codificando, le muestra cada línea que ha cambiado desde su última confirmación. También codifica por color los archivos nuevos / modificados / no modificados en el árbol del producto. Que suena como que sería útil para la OP: I lose track of which file I've edited or changed. HGE puede hacer esto también, no lo he usado.
JD Isaacks
1
+1 para describir el proceso, así como parte de cómo usar las herramientas para hacerlo.
Donal Fellows
Como pregunta secundaria, ¿se consideraría que el .xcodeprojarchivo que Xcode usa para proyectos de iOS debe decirle a Mercurial que ignore, o es importante mantener el archivo sincronizado?
Kevin Yap
1
@Kevin No sé acerca de Xcode, pero los IDE y las herramientas más recientes tienen archivos de configuración separados para cosas generales del proyecto (idioma y versiones de la biblioteca, reglas de formato de código, dependencias, etc.) y preferencias del usuario (directorios donde coloco cosas, panel diseño, máscaras, tamaño de fuente, firma personal). El primero puede incluirse en el repositorio si el equipo está de acuerdo. Este último no debe incluirse, ya que una actualización del repositorio sobrescribiría sus preferencias con las de otra persona, y eso se vuelve rápidamente molesto y contraproducente.
Apalala
1
@ John: NetBeans hace eso por cada VCS que admite. En este punto, es solo una característica básica de los IDE.
Mike Baranczak
13

Recomiendo encarecidamente a Git. Obtenga más información aquí: https://lab.github.com/

Si no le gusta Git, hay otras soluciones de control de versiones. Puede consultar SVN.

Todd
fuente
1
Como usuario cotidiano de Git, me gustaría agregar que es extremadamente fácil e intuitivo recoger los comandos esenciales. Y el soporte es excelente, por lo que no se perderá cuando busque ayuda. He usado SVN pero no fue tan fácil para mí, pero podría estar bien para muchos usuarios.
Muhammad Usman,
1
+1 También considere: las personas eligen pasar de svn (un VCS) a git (un DVCS - d = distribuido) pero no de GIT a SVN (a través de la elección).
Michael Durrant
7

¿Eres solo tú ?, usa un DVCS

Por contradictorio que parezca, un sistema de control de versiones distribuido (mercurial, git, bazar) es mejor para comenzar que un sistema centralizado (svn, cvs). ¿Por qué ?, lo instalas en tu máquina y ejecutas tu repositorio localmente, y eso es todo. En un sistema centralizado como svn, necesita configurar su cliente y un servidor ... y luego, debe conectarse a un servidor para almacenar sus cambios.

Con un DVCS eres tú, el repositorio local, y si lo deseas, puedes usar un servicio como bitbucket.org o github.com.

En mi humilde opinión, mercurial es un DVCS más amigable e igualmente capaz para empezar.

¿Hay otros ?, ¡use un DVCS!

Existen numerosas ventajas al usar un DVCS para trabajar con un equipo, la más importante en contraste con un sistema centralizado es que no hay carreras de compromiso y esto se debe a que, técnicamente, el repositorio de cada individuo es una rama, y ​​cuando comparte su los cambios de esas ramas se fusionan para usted y ni siquiera se da cuenta, lo que significa que en lugar de tener un historial de versiones como este, donde hay personas que canalizan su trabajo en línea recta:

ingrese la descripción de la imagen aquí

Terminas teniendo algo como esto, donde todos solo se comprometen ad hoc:

ingrese la descripción de la imagen aquí

Cada uno solo se preocupa por su propio trabajo mientras realiza el versionado (es decir, no compite para comprometerse) y no se preocupa por una conexión a un servidor solo para comprometerse.

Buena suerte

dukeofgaming
fuente
1
+1 ¡Muy buenos ejemplos! Debe editar para enfatizar el dolor ausente en los árboles de fusión complejos con herramientas modernas.
Apalala
5

Para ser breves, hay muchas alternativas, entre las cuales Subversion (SVN) y Git parecen las más populares (por lo tanto, es más fácil encontrar soluciones en la web).

Ambos difieren. SVN es más simple, pero Git no requiere que tengas un servidor para comenzar: puedes controlar la versión localmente.

Suponiendo que tiene Linux y desea comenzar a usar Git:

  1. Instalar Git
  2. Vaya al directorio y ejecute el comando 'git init'
  3. Aprenda a agregar archivos, revisar cambios, confirmarlos ...
  4. ... y hacer cosas más avanzadas (revisar registros, revertir cambios, ignorar archivos, crear ramas, fusionarlos, crear y usar controles remotos, usar submódulos, usar soporte SVN, etc.).

Espero que esto te ayude a comenzar.

Tadeck
fuente
1
SVN no requiere un servidor, pero sí requiere que el repositorio esté en un directorio diferente del que funciona. SVN y CVS generalmente están en desuso en favor de herramientas como GIT y Mercurial que no requieren una conexión de red para el trabajo diario y no requieren un repositorio central para el desarrollo de software colaborativo y distribuido.
Apalala
¿No crees que esto es realmente idéntico a la creación del servidor de repositorio SVN en localhost? Lo que necesita es configurar el repositorio central y mantenerlo, y cuando mueva sus archivos debe asegurarse de que el repositorio SVN aún sea accesible (ni siquiera piense en copiar todo el repositorio central cada vez que mueva archivos a una máquina diferente). Además, no creo que Subversion esté en desuso (aunque no estoy hablando de CVS), solo está centralizado y en algunos casos sería una mejor idea aplicar la centralización.
Tadeck
Apalala, alguna pregunta: ¿cómo Mercurial maneja la información que el usuario creó el cambio específico? En Git puedes alterarlo y confirmar el cambio como otra persona, creando así un poco de desorden (hay alguna característica para distinguir al remitente del remitente, pero no es lo suficientemente obvio). ¿Mercurial ha resuelto este problema relacionado con el control de versiones distribuidas?
Tadeck
2
@Tadeck En mi opinión, esa no es la forma en que Mercurial y GIT funcionan. En estos, una sola persona está a cargo de lo que entra en un repositorio, ya sea por medio de commits, pulls o parches. En repositorios distribuidos, si alguien tiene privilegios de inserción, entonces ya confía en ellos con todo su corazón. Linus Torvalds lo explica bien en esta charla: youtube.com/watch?v=4XpnKHJAok8
Apalala
@Tadeck Con respecto a SVN, lo usé mucho y terminé pensando que no era una mejora con respecto a CVS (que al menos tiene repositorios ASCII simples y es lo suficientemente maduro como para nunca corromperlos). Una vez más, Torvalds lo explica bien en el video que vinculé antes. La imposibilidad de trabajar sin conexión y la imposibilidad de fusionar dejan en desuso las viejas herramientas SCM.
Apalala
2

Como sugiere Apalala, recomiendo pagar hginit . Como es nuevo en el control de versiones, puede omitir la primera página. Eso debería darle una buena introducción, luego puede publicar en SO si tiene preguntas específicas.

JD Isaacks
fuente
0

Voy a ir en contra de la opinión de la mayoría y recomendaré Subversion. Subversion es fácil de usar y hace todo lo que las personas y los equipos pequeños necesitan. Es un producto maduro, por lo que cada IDE tiene un buen soporte. Sí, no tiene todas las características de Git. (Nunca he usado Mercurial, así que no hablaré sobre eso). Pero la mayoría de los desarrolladores no necesitan esas características adicionales.

Múltiples repositorios? Estoy seguro de que hay algunos usos legítimos para esos, pero nunca me he encontrado con ellos.

¿Ser capaz de realizar confirmaciones locales sin acceso a la red? Es bueno tenerlo si está haciendo varios cambios discretos y no puede acceder al servidor de repositorio, pero honestamente, ¿con qué frecuencia sucede eso?

Git hace que sea más fácil lidiar con la ramificación y la fusión. Pero para un equipo de una sola persona, eso no es un gran problema.

Para algo en la escala del kernel de Linux, sí, use Git. Para el resto de nosotros, Subversion es lo suficientemente bueno.

Mike Baranczak
fuente
Votación a favor. Las características de Git que no están en SVN (como la ramificación ligera y la fusión fácil) son útiles, tal vez incluso esenciales, en proyectos pequeños tanto como en proyectos grandes.
Marnen Laibow-Koser
1
@ MarnenLaibow-Koser Sí, esa era mi opinión en ese momento, pero después de usar Git profesionalmente durante varios años, tendría que estar de acuerdo con usted.
Mike Baranczak
¡Excelente! Serás asimilado. : D
Marnen Laibow-Koser