version control - usados - ¿Cómo usar un sistema de control de fuente?

svn version control (18)

No edite su código en producción.
Cree un entorno de desarrollo con los servicios apropiados (apache w / mod_php).
El directorio de la aplicación dentro de su entorno de desarrollo es donde hace su trabajo.
Pon tu aplicación de producción actual allí.
Confirme este directorio con la herramienta de control de origen. (ahora tiene un control de fuente poblado con su aplicación)
Realice cambios en su nuevo entorno de desarrollo, presionando F5 cuando desee ver / probar lo que ha cambiado.
Fusionar / Confirmar sus cambios al control de origen.

Entiendo que la mayoría de ustedes me fruncen el ceño por no usar ningún control de fuente. Quiero hacerlo, realmente lo hago, ahora que he pasado un tiempo leyendo las preguntas / respuestas aquí. Soy un programador aficionado y realmente no hago mucho más que jugar, pero he sido mordido un par de veces sin tener a mano la ''máquina del tiempo'' ...

Todavía tengo que decidir con qué producto iré, pero eso no es relevante para esta pregunta.

Realmente estoy luchando con el flujo de archivos bajo el control de la fuente, tanto que ni siquiera estoy seguro de cómo plantear la pregunta con sensatez.

Actualmente tengo una jerarquía de directorio donde todos mis archivos PHP viven en un entorno Linux. Los edito allí y puedo presionar Actualizar en mi navegador para ver qué pasa.

Según lo entiendo, mis archivos ahora viven en un lugar diferente. Cuando quiero editar, lo reviso y edito. Pero, ¿cuál es mi sustituto para F5? ¿Cómo lo pruebo? ¿Tengo que volver a controlarlo y luego presionar F5? Admito un poco de prueba y error en mi trabajo. Sospecho que me voy a cansar de registrarme y salir muy rápido para los pequeños cambios frecuentes que tiendo a hacer. Me falta algo, ¿verdad?

¿Alguien puede guiarme a través de dónde vive todo y cómo lo pruebo en el camino, mientras me mantengo fiel al objetivo de tener a mano una ''máquina del tiempo''?

Aquí está el flujo de trabajo general que usaría con un sistema de control de fuente no centralizado como CVS o Subversion: Al principio importa su proyecto actual en el llamado repositorio, un almacenamiento versionado de todos sus archivos. Tenga cuidado únicamente de importar archivos generados manualmente (fuente, archivos de datos, archivos make, archivos de proyecto). Los archivos generados (archivos de objeto, ejecutables, documentación generada) no deben colocarse en el repositorio.

Luego debe verificar su copia de trabajo. Como su nombre lo indica, aquí es donde hará todas sus ediciones locales, donde compilará y hacia dónde dirigirá su servidor de prueba. Básicamente es el reemplazo al lugar donde trabajabas antes. Solo necesita hacer estos pasos una vez por proyecto (aunque puede verificar múltiples copias de trabajo, por supuesto).

Este es el ciclo de trabajo básico: al principio, verifica todos los cambios realizados en el repositorio en su copia de trabajo local. Cuando se trabaja en equipo, esto generará los cambios que otros miembros del equipo hayan realizado desde su último control de salida. Entonces haces tu trabajo. Cuando hayas terminado con un conjunto de tareas, deberías revisar la versión actual nuevamente y resolver posibles conflictos debido a cambios por parte de otros miembros del equipo. (En un equipo disciplinado, esto generalmente no es un problema.) Haga la prueba, y cuando todo funcione según lo esperado, comprométase (controle) sus cambios. Luego puede continuar trabajando, y una vez que haya terminado de nuevo, revise, resuelva conflictos y vuelva a registrarse. Tenga en cuenta que solo debe confirmar los cambios que fueron probados y funcionan. La frecuencia con la que se registra es una cuestión de gusto, pero una regla general dice que debe comprometer sus cambios al menos una vez al final de su día. Personalmente, hago mis cambios mucho más a menudo que eso, básicamente cada vez que hago un conjunto de cambios relacionados que pasan todas las pruebas.

Dependiendo del sistema de control de la fuente, ''checkout'' puede significar cosas diferentes. En el mundo de SVN, solo significa recuperar (podría ser una actualización, podría ser un archivo nuevo) la última copia del repositorio. En el mundo de fuente segura, eso generalmente significa actualizar el archivo existente y bloquearlo. El siguiente texto usa el significado SVN:

Usando PHP, lo que quiere hacer es revisar su proyecto / sitio completo en una carpeta de trabajo en un sitio de prueba de Apache. Debería configurar el repositorio para que esto pueda suceder con un único proceso de pago, incluidas las subcarpetas necesarias. Pagará su proyecto para configurarlo una vez .

Ahora puede hacer los cambios y presionar F5 para actualizar como siempre. Cuando esté satisfecho con un conjunto de cambios para admitir una solución o función en particular, puede comprometerse como una unidad (con los comentarios apropiados, por supuesto). Esto pone la última versión en el repositorio.

Revisar / comprometer un archivo a la vez sería una molestia.

En realidad, sus archivos, mientras están almacenados en un repositorio de origen (palabra grande para otro lugar en su disco duro o disco duro en otro lugar), también pueden existir en su máquina local, justo donde existen ahora.

Por lo tanto, todos los archivos que no están desprotegidos se marcarán como "de solo lectura" si usa VSS (no está seguro acerca de SVN, CVS, etc.). Por lo tanto, aún puede ejecutar su sitio web presionando "F5" y volverá a cargar los archivos donde se encuentran actualmente. Si marca uno y lo está editando, NO se convierte en solo lectura, y puede cambiarlo.

De todos modos, el servidor web que está ejecutando cargará archivos de solo lectura / escritura con el mismo efecto.

Eric Sink tiene una gran serie de publicaciones sobre conceptos básicos de control de fuente. Su compañía (Sourcegear) hace una herramienta de control de fuente llamada Vault, pero el modo de hacerlo es generalmente bastante agnóstico al sistema.

Esta es una pregunta abiertamente abierta porque cómo usa un SCM depende en gran medida de qué SCM elija. Un SCM distribuido como git funciona de manera muy diferente a uno centralizado como Subversion.

svn es mucho más fácil de digerir para el "nuevo usuario", pero git puede ser un poco más poderoso y mejorar su flujo de trabajo. Subversion también tiene excelentes documentos y soporte de herramientas (como trac), y un libro en línea que debe leer:

http://svnbook.red-bean.com/

Cubrirá los aspectos básicos de la administración de control de origen que le ayudará de alguna manera sin importar qué SCM elija en última instancia, por lo que recomiendo pasar los primeros capítulos.

edit: Permítanme señalar por qué la gente le está frunciendo el ceño, por cierto: SCM es más que simplemente una "copia de seguridad de su código". Tener "timemachine" no es nada como un SCM. Con un SCM puedes volver atrás en tu historial de cambios y ver qué cambiaste realmente y cuándo es algo que nunca obtendrás con blobs de código. Estoy seguro de que se preguntó en más de una ocasión: "¿cómo llegó este código aquí?" o "Pensé que arreglé ese error" - si lo hizo, es por eso que necesita SCM.

No "tiene" que cambiar su flujo de trabajo de manera drástica. Podrías, y en algunos casos deberías, pero eso no es algo que dicta el control de versiones.

Simplemente usa los archivos como lo harías normalmente. Solo bajo control de versión, una vez que alcanzas un cierto estado de "terminado" o al menos "funcionando" (resolvió un problema en tu rastreador de problemas, finalizó un método determinado, retocó algo, etc.), lo registras.

Si tiene más de un desarrollador trabajando en su base de código, asegúrese de actualizar regularmente, por lo que siempre está trabajando contra una versión reciente (fusionada) del código.

Parece que estás preguntando cómo usar el control de código fuente para administrar las versiones.

Aquí hay algunas pautas generales que no son específicas de los sitios web:

Use una copia local para desarrollar cambios
Compila (si corresponde) y prueba tus cambios antes de registrarte
Ejecute compilaciones y pruebas automatizadas tan a menudo como sea posible (al menos diariamente)
Actualice sus compilaciones diarias (tenga alguna forma de especificar los bits exactos de código correspondientes a una compilación y prueba en particular)
Si es posible, use ramas separadas para las versiones principales (o tenga una rama de desarrollo y una de lanzamiento)
Cuando sea necesario, estabilice su código base (defina un conjunto de pruebas tales que pasar todas esas pruebas significa que tiene la suficiente confianza en la calidad de su producto para liberarlo, luego conduzca hacia 0 fallas de prueba, es decir, prohibir cualquier checkins a la rama de publicación aparte de las soluciones para los problemas pendientes)
Cuando tenga una compilación que tenga las características que desea y haya pasado todas las pruebas necesarias, impleméntela.

Si tiene un equipo pequeño, un producto estable, una compilación rápida y pruebas eficientes y de alta calidad, todo este proceso podría estar 100% automatizado y podría llevarse a cabo en cuestión de minutos.

Puede hacer un "pago" en el mismo directorio donde trabaja actualmente para que no tenga que cambiar. Básicamente, su directorio de trabajo no necesita cambiar.

Si está utilizando Subversion, revisa sus archivos una vez . Luego, cada vez que haya hecho grandes cambios (o vaya a almorzar o lo que sea), los compromete con el servidor. De esta manera, puede mantener su flujo de trabajo anterior presionando F5, pero cada vez que se compromete , guarda una copia de todos los archivos en su estado actual en su repositorio SVN.

Solo quiero agregar que el sistema que creo que fue más fácil de configurar y trabajar fue Mercurial . Si trabajas solo y no en un equipo, solo debes inicializarlo en tu carpeta de trabajo normal y luego continuar desde allí. El flujo normal es editar cualquier archivo usando su editor favorito y luego a un checkin (commit). No he probado GIT pero supongo que es muy similar. Monotone fue un poco más difícil de empezar. Todos estos son sistemas de control de fuente distribuidos.

Todavía tienes todos los archivos en tu disco duro, ¡listos para F5!

La diferencia es que puedes "marcar" tus archivos en el repositorio. Tu vida diaria no tiene que cambiar en absoluto.

Todo esto es muy subjetivo dependiendo de la solución de control de fuente que decida usar. Uno que definitivamente querrá examinar es Subversion.

Mencionaste que estás haciendo PHP, pero ¿lo estás haciendo en un entorno Linux o en Windows? No es realmente importante, pero lo que normalmente hacía cuando trabajaba en un entorno PHP era tener una rama de producción y una rama de desarrollo. Esto me permitió configurar un trabajo cron (una tarea programada en Windows) para extraer automáticamente de la sucursal preparada para la producción para el servidor de producción, mientras me retiro de la rama de desarrollo para mi servidor de desarrollo.

Una vez que decida sobre una herramienta, realmente debería dedicarle un tiempo a aprender cómo funciona. Los conceptos de entrada y salida no se aplican a todas las soluciones de control de fuente, por ejemplo. De cualquier manera, le recomiendo que elija uno que permita la ramificación. Este artículo repasa un excelente (en mi opinión) modelo de control de origen para seguir en un entorno de producción.

Por supuesto, declaro que todo esto no ha "modificado" en años. He estado haciendo desarrollo profesional por un tiempo y mis técnicas pueden ser excesivas para alguien en su posición. No quiere decir que haya algo de malo en eso, sin embargo.

Un sistema de control de origen generalmente es un lugar de almacenamiento para sus archivos y su historial, y generalmente está separado de los archivos en los que está trabajando actualmente. Depende un poco del tipo de sistema de control de versiones, pero supongamos que está utilizando algo similar a CVS (como la subversión), y luego todos sus archivos vivirán en dos (o más) lugares. Tiene los archivos en su directorio local, la llamada "copia de trabajo" y otra en el repositorio, que puede ubicarse en otra carpeta local, o en otra máquina, a la que generalmente se accede a través de la red. Por lo general, después de la primera importación de sus archivos en el repositorio los revisa en una carpeta de trabajo donde continúa trabajando en ellos. Supongo que esa sería la carpeta donde ahora viven sus archivos PHP.

Ahora, ¿qué sucede cuando ha comprobado una copia y ha realizado algunos cambios no triviales que desea "guardar"? Simplemente debe enviar esos cambios en su copia de trabajo al sistema de control de versiones. Ahora tienes un historial de tus cambios. Si en algún momento desea volver a la versión en la que realizó dichos cambios, puede simplemente revertir su copia de trabajo a una revisión anterior (el nombre dado al conjunto de cambios que realiza de inmediato).

Tenga en cuenta que todo esto es muy específico de CVS / SVN, ya que GIT podría funcionar ligeramente diferente. Recomiendo comenzar con la subversión y leer los primeros capítulos del excelente Libro SVN para que comiences.

Depende del sistema de control de fuente que use. Por ejemplo, para subversión y cvs, sus archivos pueden residir en una ubicación remota, pero siempre verifica su propia copia localmente. Esta copia local (a menudo referida como la working copy ) son solo archivos regulares en el sistema de archivos con algunos metadatos para permitirle cargar sus cambios de vuelta al servidor.

Si está utilizando Subversion aquí hay un buen tutorial .

Gran pregunta Con el control de fuente, aún puede hacer su proceso de actualización "F5". Pero después de cada edición (o algunas ediciones menores) desea verificar su código para que tenga una copia de seguridad.

Dependiendo del sistema de control de fuente, no tiene que extraer explícitamente el archivo cada vez. Solo editando el archivo lo verificará. He escrito una guía visual para el control de la fuente que mucha gente ha encontrado útil al resumir lo básico.

Recomendaría un sistema de control de versiones distribuidas (mercurial, git, bazaar, darcs) en lugar de un sistema de control de versiones centralizado (cvs, svn). Son mucho más fáciles de configurar y trabajar.

Pruebe mercurial (que es el VCS que usé para entender cómo funciona el control de versiones) y luego, si lo desea, puede incluso cambiar a git.

Hay un buen tutorial introductorio en la página principal de Mercurial: Entendiendo a Mercurial . Eso le presentará los conceptos básicos sobre VCS y cómo funcionan las cosas. Es realmente genial. Después de eso, te sugiero que pases a los tutoriales de Mercurial: la página del tutorial de Mercurial , que te enseñará cómo usar Mercurial. Finalmente, tiene un ebook gratuito que es una gran referencia sobre cómo usar Mercurial: Control de Revisión Distribuida con Mercurial

Si te sientes más aventurero y quieres comenzar con Git de inmediato, entonces este ebook gratuito es un gran lugar para comenzar: Git Magic (lectura muy fácil)

Al final , sin importar qué herramienta de VCS elija, lo que terminará haciendo es lo siguiente:

Tenga un repositorio que no edite manualmente, solo para el VCS
Tenga un directorio de trabajo donde realice los cambios como siempre.
Cambia lo que quieras, presiona F5 tantas veces como desees. Cuando le gusta lo que ha hecho y piensa que le gustaría guardar el proyecto tal como está en ese mismo momento (al igual que lo haría cuando está escribiendo, por ejemplo, algo en Word), puede confirmar sus cambios. al repositorio.
Si alguna vez necesita regresar a cierto estado en su proyecto, ahora tiene el poder para hacerlo.

Y eso es más o menos.

Recomiendo Subversion . Configurar un repositorio y usarlo en realidad es bastante trivial, incluso desde la línea de comando. Así es como funcionaría:

si no ha configurado su repo (repositorio)

1) Asegúrate de que tienes Subversion instalado en tu servidor

$ which svn /usr/bin/svn

que es una herramienta que te dice el camino a otra herramienta. si no devuelve nada, esa herramienta no está instalada en su sistema

1b) Si no, obténgalo

$ apt-get install subversion

apt-get es una herramienta que instala otras herramientas en tu sistema

Si ese no es el nombre correcto para la subversión en apt, intente esto

$ apt-cache search subversion

o esto

$ apt-cache search svn

Encuentre el nombre correcto del paquete e instálelo usando apt-get install nombredelpaquete

2) Crea un nuevo repositorio en tu servidor

$ cd /path/to/directory/of/repositories $ svnadmin create my_repository

svnadmin create reponame crea un nuevo repositorio en el presente directorio de trabajo ( pwd ) con el nombre de reponame

Ya terminaste de crear tu repositorio

si tiene un repositorio existente, o ha terminado de configurarlo

1) Asegúrate de que tienes Subversion instalado en tu máquina local según las instrucciones anteriores

2) Mira el repositorio a tu máquina local

$ cd /repos/on/your/local/machine $ svn co svn+ssh://www.myserver.com/path/to/directory/of/repositories/my_repository

svn co es el comando que usas para consultar un repositorio

3) Crea tu estructura de directorio inicial (opcional)

$ cd /repos/on/your/local/machine $ cd my_repository $ svn mkdir branches $ svn mkdir tags $ svn mkdir trunk $ svn commit -m "Initial structure"

svn mkdir ejecuta un mkdir normal y crea un directorio en el directorio de trabajo actual con el nombre que proporcione después de escribir svn mkdir y luego lo agrega al repositorio.

svn commit -m "" envía sus cambios al repositorio y lo actualiza. Lo que sea que coloque en las citas después de -m es el comentario de esta confirmación (¡haga que cuente!).

La "copia de trabajo" de su código iría en el directorio troncal . ramas se usa para trabajar en proyectos individuales fuera del tronco; cada directorio en las ramas es una copia del tronco para un subproyecto diferente. tags se usa más lanzamientos. Sugiero centrarme en trunk por un tiempo y acostumbrarme a Subversion.

trabajando con su repositorio

1) Agregue código a su repositorio

$ cd /repos/on/your/local/machine $ svn add my_new_file.ext $ svn add some/new/directory $ svn add some/directory/* $ svn add some/directory/*.ext

La penúltima línea agrega todos los archivos en ese directorio. La última línea agrega todos los archivos con la extensión .ext.

2) Verifica el estado de tu repositorio

$ cd /repos/on/your/local/machine $ svn status

Eso le dirá si hay archivos nuevos y actualizados, y archivos con conflictos (diferencias entre su versión local y la versión en el servidor), etc.

3) Actualiza tu copia local de tu repositorio

$ cd /repos/on/your/local/machine $ svn up

La actualización extrae cualquier cambio nuevo del servidor que aún no tiene

A svn up le importa en qué directorio se encuentra. Si desea actualizar todo el repositorio, asegúrese de estar en el directorio raíz del repositorio (arriba del enlace)

Eso es todo lo que necesitas saber para comenzar. Para obtener más información, le recomiendo que consulte el Libro de Subversion .