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?

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.

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.

¿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:

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

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

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.

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.

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.

Creo que un Sistema de control de versiones distribuido funcionará bien. Las opciones comúnmente sugeridas son Git y Mercurial (Hg). Las herramientas gráficas pueden ser útiles, para Mercurial recomiendo TortoiseHg .