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 el modo git, así que exploré un poco. luego volvió al flujo de trabajo que describió.
Después de un tiempo, fue difícil trabajar con él, ya que surgieron algunas situaciones que también me dieron malos hábitos que serían difíciles de romper una vez que me uniera a un equipo.
así que me conformé con lo siguiente:
- Repositorio local para trabajar.
- Rama maestra como un tronco estable para la aplicación
- Una rama para cada función / refactor, básicamente una rama para cada cambio importante que se realizará.
- Combinar de nuevo al tronco cuando la rama es estable y todas las pruebas pasan.
También configuro una cuenta de git hub donde sincronizo el 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 me acostumbro a 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 entrega al cliente, me desviaré de esta versión para crear un segundo enlace 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 comienzo a hacer círculos, me di por vencido y comencé a trabajar en otra rama. 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 con destellos e ideas muy rápidamente 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 como estoy solo, dudo que realmente lo necesite. Lo empujó como "agradable de aprender".
Cuando toda la ramificación se complicó, exploré la opción de registro para dibujar un árbol de cambios y ver qué rama está donde.
En pocas palabras, git no es como SVN, CVS o (brrr) TFS. La ramificación es muy barata y cometer errores que eliminarán el trabajo es bastante difícil. Solo una vez perdí algo de trabajo y fue porque hice mis compromisos demasiado grandes (ver los malos hábitos arriba). Si te comprometes a menudo, git pequeños serán definitivamente tu mejor aliado.
Para mí, git me abrió la mente de lo que realmente se trata el control de fuente. Cualquier otra cosa antes era solo intentos de conseguirlo, git es el primero, en mi opinión, lo tengo. Dicho esto, no probé otro DVCS, posiblemente esta declaración podría ampliarse a toda la familia.
Un último consejo, la línea de comando es tu amigo. No quiero decir que las herramientas gráficas no sean buenas, sino todo lo contrario, pero realmente me molesté cuando caí a la línea de comandos y lo probé yo mismo. 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 pero fea consola 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. árboles de troncos complejos. algunas secuencias de comandos básicas y nunca he sido tan productivo con respecto al control de origen y nunca tuve tanto control sobre mi origen.
Buena suerte, espero que esto haya ayudado.