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.