Switching from SVN to Git - help needed

Question

I'm a software developer recently in charge of entire project (project manager). The project I'm working on (with 6 other persons) is a complex Java-based application that's being developed for over 5 years. The entire time we were using SVN, without branching. Now, I would like to switch to Git as I do believe Git will provide superior branching and ease some development.

Anyway, before I do switch, I have to tell you about the current workflow we're having with SVN, I have to hear opinion from people experienced with Git and to tell you what are the things I expect from Git. Please tell me if Git can provide the things I need the way I need them, because if I switch the entire project to Git and then it turns out I have to revert it to SVN (for any reason), I would be dead :) .

The principle we're following with SVN is:

• Each team member is working on a single feature. When such feature is done, a local copy of dev's code is updated against SVN master and feature is deployed for testing. If testing by clients passed, the person developing the code pushes it to our main (and only) branch with a proper commit message that explains the feature, ticket number and so on.

• If, during "update before deploying for testing" the team member gets into conflicts, he's cherry-picking conflicting files line by line.

• When time comes that we deploy new features to production, I load the production code from a particular folder on the disk (like "physical branch"), I sync that code to the current state of the SVN, going class by class, reviewing committed changed and taking the code meant for that particular deploy. Usually, it happens that out of 230 classes we have in the repo (and not in production workspace) bewteen 30 and 50 classes are with conflicts because of the features we don't need on production yet. Sometimes, clients ask for the latest features before wanting some older features. If both feature they want and features they don't affect the same file, I have to manually skip some particular file from commit version number 3 to commit version number 6 without taking any changes from commits 4 or 5. Now, if another file is also affected, it happens that another file from version, say, 35, I have to update to version 40 without taking any changes done between 35 and 40. With SVN, it's easy, I sync a particular file and pick only the lines of codes ignoring all others. It takes time but I am in a position to tell clients "we'll postpone this for X days".

Also, if two developers are working on different features that largely affect the same subsystem or big number of the same files, in order to avoid nasty conflicts and collisions I usually tell clients "we can't develop both things in the same time, we'll postpone feature B till feature A is done and tested" and one of the devs get to work on something else.

Now, from Git the only thing I basically need is:

• Nice Windows GUI (for SVN we're using "Subclipse" plugin for Eclipse). I'm really not into investing a lot of time just learning or remembering how to push a branch or view the history or do something similar if it can be done with the click of a button. For me, the version control system should be just a tool - not something my devs should spend more than a day learning how to use because of CLI and advanced things we'll never use or require. With SVN we use only 4 commands: commit, update, synchronize (to see the differences) and "history". Ok, sometimes we do use "compare with version X from repo" but not so often.
• The ability to achieve nice code storage by using only a few basic commands (button clicks to be precise :D ): push / pull, fetch / commit, branch / merge, view history. Nothing fancy or advanced which would take a lot of time to learn or understand.
• The ability to partially take commits. For example: commit consists of 10 files. I take all changes from 8 files, but for two files I do cherry-pick in a manner that from current production version 5 I take two lines of code from file commit version 7 and few lines from file commit version 9 (effectively keeping those two files in "undefined version" so that I can supply my clients with the newest changes without all code changes preceding that newest feature I want). To achieve this point, for me it's not a problem to allocate an entire day digging through history and commits regardless if it's SVN or Git. That's my "preparing deploy" day anyway :)
• Having numerical commit versions, not HASH-based ones!

Is it possible with Git? I really have limited experience with Git, only on some small projects and I can't afford to move the entire code base from one system to another :( Please give me some advice.

Answer 1

IMHO you are approaching this from the wrong side. You probably need first and foremost a better workflow, utilizing branches, and not necessarily another tool. Why not start using feature branches with SVN? If you are going to develop two major features in parallel, just create individual branches for the features and assign them as a temporary "work space" for the part of the team which is going to implement the features.

That is a fairly simple and easy to grasp branching model, SVN supports this well, and as long as the centralized repo model of SVN is not a problem for your team, it might be all you need. You "newbie" developer will still just use "commit, update, synchronize, history" on the branch you assigned to him (and a daily "merge from trunk into my feature branch"), only the person who will integrate the features back into the trunk some day will have to know some more SVN commands. This integration step will become much easier than you current "cherry picking" approach, since you do not have to sort out which code change belongs to a certain feature afterwards in the cumbersome and error-prone manner you described.

When you go this route and reach the point where you and your team want to do more complex branches, and you notice SVN is not be sufficient any more, for example, when you need a tool for doing distributed, local branches, then it is time to switch to Git. But currently, it seems you are not there yet.

Answer 2

It seems to me from your post that you are not making the best use of source control.

Additionally you say you don't have much experience of using git.

I think its fairly well accepted that git has become the dominant source control software. Possibly you could argue that the git flow branching strategy is the most popular and a robust strategy for beginners to adopt.

However, it doesn't seem likely that you will be able to achieve a productivity increase if you try to switch to git without help.

It seems to me that it will be quite an organisational and culture change to switch to a better use of source control and it should only be attempted by an experienced person with a lot of buy in from the other developers

Answer 3

•Nice Windows GUI (for SVN we're using "Subclipse" plugin for Eclipse). •The ability to achieve nice code storage by using only a few basic commands (button clicks to be precise :D ): push / pull, fetch / commit, branch / merge, view history.

There is a Git integration plugin for Eclipse available from the official Eclipse repository which allows all these operations (under "Collaboration" on the "Install new software..." screen). This plugin is already included in many of the official Eclipse packages, so you might already have it.

The official Git for Windows also comes with a stand-alone GUI. It doesn't expose the full feature-set of Git, but allows the most common operations.

•The ability to partially take commits. For example: commit consists of 10 files. I take all changes from 8 files, but for two files I do cherry-pick in a manner that from current production version 5 I take two lines of code from file commit version 7 and few lines from file commit version 9 (effectively keeping those two files in "undefined version" so that I can supply my clients with the newest changes without all code changes preceding that newest feature I want). To achieve this point, for me it's not a problem to allocate an entire day digging through history and commits regardless if it's SVN or Git. That's my "preparing deploy" day anyway :)

In general, Git encourages you to use lots of branches (usually one branch per feature) and commit often on each branch. Commits should never contain two unrelated changes. This should allow you to cherry-pick the features you want by cherry-picking commits. It also allows you to create a release with only the features your customers request by merging the feature-branches which correspond to these features.

So if you have this requirement, you are using Git wrong.

However, if you are ever in the situation where you need to merge only parts of a commit, you should create a new commit on the feature-branch which reverts the changes you don't want and then merge the branch. If you still want to keep working on the features you don't want to merge into mainline, you would create that commit on a new branch which you merge and keep developing on the old branch.

•Having numerical commit versions, not HASH-based ones!

Sorry, but Git doesn't do that. Git encourages decentralized, parallel development on multiple branches with multiple commits per branch, so incrementing commit numbers just don't fit into the Git philosophy. However, you can use tags in Git to manually assign numbers (or other descriptors) to commits. You can do that on your master-branch after merging from the feature-branches.