Below is a summary of my suggestions of using git to manage research source, based on numerous discussions I have had with my collaborators across multiple projects at multiple institutions.
Always revision control your code. There are multiple options, but at this moment of writing, git beats alternatives such as svn and perforce.
Use github for public repos and bitbucket for private repos.
Start with existing code if feasible. If the code is already under git, use submodule as a component or fork/branch as an extension. Otherwise, convert the code into git, and preserve revision history whenever possible (e.g. github/bitbucket can help you convert svn repos into git repos).
Use multiple branches for different versions of the code, such as stable branch for release or a personal branch for experiments.
Use multiple remotes across organizations and time-frames.
For example, during your internship with a company, use an internal corporate github repo, and sync it with an external bitbucket (private) repo at the end of your internship so that you can continue the project at your school. When you are ready to publish your code, mirror it to a public github repo.
Keep multiple remotes under the same repo for easy management.
For paper drafts, you can create an overleaf git branch for more WYSIWYG-style editing while retaining all the benefits of branching and revision control.
Keep one (or at most a few) sentence(s) at one line, to avoid false alarms from spell checkers (broken sentences) and excessive (line-based) diff by git.
Note that Latex treats line breaks as spaces.
Chongyang Ma (@ Snap Research) has recommendations for industry research code practice.
