Thread by @WeAreRLadies

Today's about version control and collaboration today and one of its powerful tools: #git ✨

💡What is Git?

Using Git can be a lifesaver (and it has often been one in the past for me 🙏). It’s basically like a mini time travel machine that you use - it allows you to have version control of your work progress.

But unlike Dropbox or other tools, it does not automatically save the status quo of your work but requires you to do it actively with commits and pushes. A typical workflow looks like this 👇

RStudio has a nice GUI that allows you to do everything without writing code - but if you need to remember some commands, it’s most likely git add, git commit, git push, git pull, and git status (to check if you have uncommitted files) 😊

Here's what the typical workflow can look like in action:

You start with your local repository on your own machine, work on your code and do some changes. Now the #git workflow starts 💫

✨ git add: Once you made some changes, this command lets you add them to the staging area (this is an essential step before committing them and tells git that these are the files you want to commit in your next commit) 😊

✨ git commit: Once you used "git add", this allows you to “commit” them and to “version control” them. It takes a snapshot of your current project status in git - but your changes are still only versioned on your local machine.

I talked to many people and I couldn’t find a best practice on how often you should send commits. I like to think of them as a status report or a (small) milestone to which you may want to return to. So I try to send a commit once a (thematic) step is reached.

✨ git push: If you hit this command, you will push one (or more) commits to the remote repository (for instance to GitHub). Now your changes are also versioned in the #cloud ☁️

✨ git pull: This command pulls changes from others and makes sure that you’re working on the most current version 😊

✨ git status: This command allows you to check if you have still some uncommitted changes in files 🕵🏼‍♀️

Whenever I close a project, I usually push my changes (or at least commit them) and whenever I open it, I usually pull first to get changes from others before starting my work.

But there are many more commands out there! When I get lost, I usually find myself here looking things up atlassian.com/git 👩🏼‍💻

You have probably also heard of branches and merges in Git — this is an excellent way to collaborate with others.

The GIF shows how you start working from the main branch (this is where all the changes should eventually end up and where your final product lives). Each dot shows a new commit that is pushed.

Once you want to make changes (like integrating a new function in your package) you start a new feature branch.

The feature branch eventually goes back to the main branch (this is what we call "merging"). The cool thing is that you can somewhat work independently from your colleagues or collaborators on individual tasks because they can start their own feature branch ✨

Merging back feature branches (in the best case) requires a code review - you can also do this on GitHub (github.com/features/code-…) and I'm a big fan of it because it makes you a better programmer step-by-step and allows sharing knowledge.

I learned it the hard way but it's best if feature branches don't get too long and complicated because it easily becomes hard to review them 🤓

If you want to visualize it yourself, here's a slide deck that explains workflows and more: bit.ly/how-git-works 👩🏼‍🏫

And, one thing that I should add: git is fantastic but it can be intimidating at first. It's a steady learning process (that can be steep at times). I remember when I received my first pull request on GitHub (for merging some changes into my repository) and how lost I felt 😊

The best advice I can give here is to ask (and I know it's hard to do it sometimes - I'm also working on it 😄) - but it's getting better and there are so many great people out there who were in the same situation and who are happy to help 🤗