Switching from SVN to Git in a fast-paced environment

Question

The development team I am part of consists of five members in a fast-paced in-house development environment (we develop web-based solutions that is used by other departments, ie an ERP.) We currently use SVN for a single project which has a development environment and a live environment; the development environment allows us to ensure that features are working before pushed to the live environment. When the requirements are met, we commit the changes to the SVN repository from the development server and pull those specific changes onto the live server.

We do the testing on dev until the code reaches a stable point to commit.

We want to switch to Git, however (a lot of our other projects are housed on Git, and we want it to be consistent.) It has been a bit of a challenge. We want to have a workflow that is easy and quick to use and track. I suggested having two main branches for live (master) and dev, and having each feature / fix in their own branches. This makes things better to track but harder to put in place, as it takes a lot longer and some of the changes we make to the code need to be pushed live as quick as possible.

Another suggestion was to have only a dev and live branch. We would commit to the dev branch, ensure they work, then once we are satisfied with the result, merge those files into live. The only thing with this one is I am unable to find a decent way of implementing this behaviour. Is it possible to quickly merge specific files from one branch into another?

Are there any other git workflows that would be more suitable for our kind of environment?

Answer 1

Both of the two suggestions you list can work, but the two workflows can be improve with the below workflow:

• develop branch: all the developers work on this branch. When the changes are ready to deploy for live environment, the developer can push his changes to live ( master ) branch.
• Feature/hotfix branches: are the shorting living branch for developers on their local repo. Such as if a developer want to develop new functions or fix bugs, he can create local feature/hotfix branch from develop branch. After finishing the work, merge the feature/hotfix branch into develop branch.
• live / master branch: it works as the production/released versions. After codes are verified on develop branch, then the develop branch can merged into live / master branch.

The differences among the two suggestions you list:

1. It's also has two main branches ( develop and live / master ) as the first suggestion, but it only has feature/hotfix branches for develop branch since live / master branch work as production/release version.
2. This workflow is not make changes on develop branch directly. It works on feature/hotfix branches, and then merging the changes into develop branch.