Ask HN: I'm a researcher and I have to mantain code. Where do I start?

> Is Git the only way to go to mantain the code?

Pretty much. You could try leaving it in Dropbox, but the nature of codebases is such that a solution like this could result in unnecessary bandwidth/storage use, lost/corrupted data, catastrophe when you need to roll-back a version, or worse. Suffice to say, you'd quickly learn why we use VCS over bog-standard syncing.

Yes, git looks scary. But you don't need a whole lot to get started. Learn the basics: start with cloning, then learning to commit, then learn how to push, pull, and you should be set with the basics. There are other relatively important things you'll need to learn (like rebase and diff), but you can cross that bridge when you come to it. If you ever want to learn more about a function of git, many of the commands have manpages. On any Unix machine, you can type 'man git $COMMAND` and it will give you a detailed explanation of how that particular function works.

Git isn't the only solution but it's very likely the best.

> 1. It is not easy to learn.

Learning the basics really isn't that hard, especially if you're the only one writing code. It's true that branching and merging require a bit more intellectual investment but depending on exactly what you're doing you can go quite far without that.

> I have no problem in learning it, but older academics are not willing to put the effort...

Why would they even need to if all the development is done by you ? If they need to make code changes you could have them send you their code and then merge their changes into the repository yourself.

> 2. Sync between my two machines is not always easy, fur sure not as easy as Dropbox.

That's what git servers like github and gitlab are for. You should really be using one, whether it's on an internal server (which would require quite a bit of effort to set up) or a provider such as github. Have you considered creating a private github account for this ?

You mention that the code is constantly updated and must be shared with colleagues.

Are you the only person modifying the code? Or do your colleagues modify it, too?

If the latter, distributed version control is why git was created.

Git isn’t the only way — certainly distributed projects existed before it. But you’re going to need to use version control and I don’t think you’re going to have an easier time convincing or teaching hesitant colleagues mercurial or svn instead.

For reference, I am also a (non-software) engineer working with code. We have an internal GitLab instance. There were definitely growing pains getting folks to use it. But it’s certainly been better than asking Joe for his version of this code and Bill for his version of that code and getting them to play nicely together. It helps to have your leadership on board. So a department chair in your case, perhaps?

If it’s just you developing, you could use whatever version control system you’re comfortable with and when you commit files have them automatically saved to an internal website that your colleagues know the location of.

If you don’t already know a version control system I would just bite the bullet and learn git. Nowadays it seems to be the most popular so odds are people you collaborate with in the future will use it.