Estoy exactamente en esta situación, pero opté por un flujo de trabajo un poco más complejo, aunque no necesariamente más complicado, con Git.
El objetivo al principio era aprender la manera git, así que hice un poco de exploración. luego volvió al flujo de trabajo que describió.
Después de un tiempo, esto se volvió difícil de trabajar ya que surgieron algunas situaciones y también me dio malos hábitos que serían difíciles de romper una vez que me uniera a un equipo.
así que me decidí por lo siguiente:
- Depósito local para trabajar.
- Rama maestra como troncal estable para la aplicación
- Una rama para cada función / refactor, básicamente una rama para cada cambio considerable que se realizará.
- Vuelva a fusionar al tronco cuando la rama esté estable y pasen todas las pruebas.
También configuré una cuenta git hub donde sincronizo el enlace troncal. Esto me permitió comenzar a trabajar fácilmente en diferentes computadoras. Fue por necesidad, pero me permitió encontrar errores que estaban relacionados con el entorno en el que estaba y que no estaba disponible en las otras computadoras. Así que ahora tengo la costumbre de probar un proyecto en un sistema "virgen" diferente al menos una vez. Me ahorra muchos dolores de cabeza cuando llega el momento de implementarlo en el cliente.
- Etiqueto todas las versiones que lo convierten en github como una versión liberable.
- Si se lo lanzo al cliente, saldré de esta versión para crear un segundo tronco estable para las correcciones de errores declaradas por el cliente.
Las múltiples ramas al principio parecían excesivas pero REALMENTE ayudó mucho. Podría comenzar una idea en una rama, trabajar en ella por un tiempo y cuando empiezo a correr círculos me di por vencida y comencé otra rama para trabajar en otra cosa. Más tarde surgió una idea en la que volvería a la rama a medio hornear y exploraría esta idea. En general, esto me hizo MUCHO más productivo, ya que podía actuar rápidamente e ideas y ver si funcionaba. El costo de cambiar de sucursal con GIT es extremadamente bajo, lo que me hace muy ágil con mi código base. Dicho esto, todavía tengo que dominar el concepto de rebase para limpiar mi historia, pero dado que estoy solo, dudo que realmente necesite hacerlo. Empujó como "agradable de aprender".
Cuando toda la ramificación se volvió complicada, exploré la opción de registro para dibujar un árbol de cambios y ver en qué rama estaban.
En pocas palabras, git no es como SVN, CVS o (brrr) TFS. La ramificación es muy barata y cometer errores que acabarán con el trabajo es bastante difícil. Solo una vez perdí algo de trabajo y fue porque hice mis compromisos demasiado grandes (ver malos hábitos arriba). Si te comprometes a menudo, por pequeños pedazos, git definitivamente será tu mejor aliado.
Para mí, git abrió mi mente sobre de qué se trata realmente el control de fuente. Cualquier otra cosa antes era solo intentos de obtenerlo, git es el primero, que en mi mente lo entendió. Dicho esto, no probé otros DVCS, posiblemente esta declaración podría ampliarse a toda la familia.
Un último consejo, la línea de comando es tu amigo. No quiere decir que las herramientas gráficas no sean buenas, sino todo lo contrario, pero realmente me sentí mal cuando bajé a la línea de comando y lo probé. En realidad, está muy bien hecho, es fácil de seguir con un sistema de ayuda muy completo. Mi mayor problema fue estar atado a la consola fea de Windows hasta que encontré alternativas.
Ahora uso ambas, la integración de Eclipse con Git para ver lo que está sucediendo en tiempo real y hacer algunas operaciones como diffs, explorar el historial de un archivo, etc. Y la línea de comandos para bifurcar, fusionar, empujar, obtener y los árboles de registro más complejos . algunas secuencias de comandos básicas y nunca he sido tan productivo con respecto al control de fuente y nunca tuve tanto control sobre mi fuente.
Buena suerte, espero que esto ayude.