I currently don't have a very good system for version control or sharing code with others and getting input. I wouldn't use it for work due to privacy regulations, but have a few personal projects I wouldn't mind having a backup of but am wary of sharing the code.
What are everyone's thoughts???
Get on it! I know it can be tempting to feel like someone's gonna swipe your code the moment you make it public, but IMO 99.9% of code is improved by being shared publicly. Unless you're putting up the code for a product that have a definite plan to sell, it's just going to sit there. Share it on GitHub and others can help you improve it—or maybe it'll inspire someone!
Also, starting to use GitHub for your own code is a real gateway to contributing to other people's code. My start with the latter wasn't for anything big—I was building a weather station, and I found someone's shell script for uploading photos to Flickr. My first PR was to change it to reflect a changing Flickr security policy (like two words! 
).
That's a really good point about getting to help other people with their projects and finding help for your own projects. I've never really been in an area where I've been able to share code and collaborate on in-depth projects so it is all foreign to me.
If I decide to go with GitHub, where would I even get started? Is @jennybryan's Happy Git and GitHub for the useR a good starting place?
Yes that gitbook is excellent and has been battle-tested with many people over several years on different OS. Can't recommend a better resource for an R user wanting to get started with git
I hate how my code is reproducible, and how I can roll back my bad decisions and test new features without jeopardising my code base. I miss the risk.
There is literally no better guide out there.
I started putting things up on GitHub simply for record-keeping. Where I found it to be absolutely indispensable was in building my first Shiny app - I would get one thing working, but want to test something else out without ruining what I knew already worked - which is unbelievably easy when using GitHub.
Has anybody got any experience with GitLab? Does it work the same way as GitHub?
The reason I ask is that my company has a GitLab server which appears to only have very limited use and has no support.
I have no experience with GitHub so would need to rely on resources like Happy Git and GitHub for the useR if the experiences were similar enough.
As far as I'm aware, GitHub and GitLab are very similar.
They both offer hosting of git repositories, either online/in the cloud or on premise (sounds like you have an on-premise GitLab server).
Either way, I'd say that using git (the technology) and GitHub/GitLab are excellent for a number of reasons, most of which @jennybryan and colleagues have able covered.
We use git regularly at work for helping us keep track of projects and how they evolve over time. It's especially useful for some of the projects we do in highly regulated areas (e.g. financial services) where it's critical that we can reproduce answers from a given point in the project - git makes it very easy for us to do that.
Something like GitHub is also really helpful personally for me to have a place to put my testing/playground code and collaborate with old colleagues & friends on some little pet projects.
Thanks @jim89. I'll have to check whether that works.
Almost all of my R work is solo, so the sharing thing doesn't come into it, but I would love to evolve my work into the quality I see from others on their public github repos.
What does everyone think about GUIs for GitHub such as GitKracken and other like that? Do they help learning git or is command line better to go?
GUIs (including RStudio's git pane) can lower the bar to entry a bit, and make it easier to make a quick commit and see the commit graph. When things get hairy, though, the CLI is usually simpler to figure out (and get solutions for). It has really well-assembled messages and errors, so it's less opaque than most command line programs.
The nice thing about git is that it doesn't care how you interact. Clone through the Github GUI, commit through RStudio, amend the commit through the CLI, and then push through RStudio again, and everything works fine. It's a little magic, if you think about it.
I really like the GitHub desktop app for branching and making commits especially for contributing to other people's open source projects. Having it be visually represented so well really helps me be confident I am not accidentally committing a file I shouldn't or overwriting some code unexpectedly.
It's lacking in capabilities for more complex git needs but as @alistaire mentioned, it's easy to switch back and forth to command line depending on what you need to get done!
If you want an interactive quick intro to git/github I really like: https://try.github.io/
You might also find this piece helpful:
Excuse me, do you have a moment to talk about version control?
Jennifer Bryan
It's an expanded version of the "Why Git? Why GitHub?" intro of http://happygitwithr.com.
http://happygitwithr.com is mostly about installation and early workflows. The article above is a general explainer and motivator. There is some pain involved in starting to use Git, so it's important to know why you're putting yourself through this.
I would never advocate adopting Git w/o also using GitHub or GitLab. The remote, web-by, potentially collaborative aspect is a huge part of the value proposition. Being able to click around your files, at various commits, is incredibly helpful and no local Git workflow approximates that very well IMO.
I'm also a big believer in a graphical Git client. I use SourceTree but I think GitKraken also looks very good. It didn't exist when I started this journey and I don't feel like switching. I also use RStudio a lot for basic stuff. Anecdotally, I think new Git users tend to make more mistakes when they only use command line Git. It's just harder to see the state of the world. I think graphical clients are really useful when you're still trying to digest the concepts of Git.
You should use git even if you don't host remotely on GitHub or Gitlab. On Unix based systems (Linux and macOS), a simple git init will turn any folder into a version controlled folder using git.
You mentioned privacy reasons for not using GitHub at work. Just for reference, many companies, including mine, host all their code on GitHub. Private organizations and repositories just cost money.
@jennybryan Thanks for that article, it is really interesting and a big help! Right now I'm leaning towards using GitKracken to learn through.
@raybuhr I know that there is privacy options for GitHub, my organization just won't pay for it so I was just making the distinction that I would be using it for personal projects, rather than learning it through work.
My lab mate recommended bitbucket because it has free "private repos", you can have a look.
By the way if you stay in academic GITHUB will hand out "private repo" plans.
FWIW, I just ran my first workshop, building a website with GitHub Pages. The idea was to give ppl some exposure to the basics of git without the extra cognitive load of also having to learn the command line (which some students hadn't used).
It went pretty well! We hit a few unexpected snags, but for our basic purposes (forking, cloning, committing and pushing) it was great. I would tell participants to go learn the command line (say, with Software Carpentry) if they wanted to start using git more, but I think it did what I wanted it to 
Also, I pinched a couple of figures (with appreciate citations, of course 
) from @jennybryan's excellent paper above.
EDIT: one thing I didn't anticipate beforehand was that some students were running Linux on their laptops. I sent them toward GitKraken, although frankly if you've installed Linux on a laptop your probably comfortable with the command line.
Okay, I signed up for a GitHub account. Time to figure out how it works now!
I found that piece really helpful and I wish I'd read it when I first started using GitHub instead of cobbling together my GitHub knowledge from several less helpful and less complete sources. Thank you!
Also, I think graphical Git clients are really helpful even if you are comfortable with the command line. The value isn't so much in the buttons that replace the various command line functions as it is in seeing the history of the project. I'd started with command line, but after trying GitKraken found that having that the visualization of what was actually happening was extremely helpful to actually understanding what was going on (as opposed to just sort of using git without destroying anything, which was what I was basically doing from the command line).
I really agree with @natekratzer re: value of graphical Git client. This seems like an area where people are easily convinced they need to use command line Git for nerd cred. But this is purely a workflow matter! No one else ever needs to know, unless you share here, how you work with Git. All that matters is that you accomplish your goals. I like to switch between SourceTree, RStudio, and command line, depending on the task at hand.