Chapter 10 Github
by Stephanie Djajadi and Nolan Pokpongkiat
10.2 Github Desktop
While knowing how to use Git on the command line will always be useful since the full power of Git and its customizations and flexibilty is designed for use with the command line, Github also provides Github Desktop as an graphical interface to do basic git commands; you can do all of the basic functions of Git using this desktop app. Feel free to use this as an alternative to Git on the command line if you prefer.
10.3 Git Branching
Branches allow you to keep track of multiple versions of your work simultaneously, and you can easily switch between versions and merge branches together once you’ve finished working on a section and want it to join the rest of your code. Here are some cases when it may be a good idea to branch:
- You may want to make a dramatic change to your existing code (called refactoring) but it will break other parts of your project. But you want to be able to simultaneously work on other parts or you are collaborating with others, and you don’t want to break the code for them.
- You want to start working on a new part of the project, but you aren’t sure yet if your changes will work and make it to the final product.
- You are working with others and don’t want to mix up your current work with theirs, even if you want to bring your work together later in the future.
A detailed tutorial on Git Branching can be found here. You can also find instructions on how to handle merge conflicts when joining branches together.
10.4 Example Workflow
A standard workflow when starting on a new project and contributing code looks like this:
|SETUP: FIRST TIME ONLY:
||Clone the repo. This copies of all the project files in its current state on Github to your local computer.|
||update the state of your files to match the most current version on GitHub|
||create new branch that you’ll be working on and go to it|
|3. Make some file changes||work on your feature/implementation|
||add changes to stage for commit, going through changes line by line|
||commit files with a message|
||push branch to remote and set to track (-u only needed if this is first push)|
|7. Repeat step 4-5.||work and commit often|
||push work to remote branch for others to view|
|9. Follow the link given from the
||PR merges in work from your branch into master|
|(10.) Your changes and PR get approved, your reviewer deletes your remote branch upon merging|
||clean up your local git by untracking deleted remote branches|
Other helpful commands are listed below.
10.5 Commonly Used Git Commands
||clone a repository, only needs to be done the first time|
||check what branch you are on|
||check what branch you are on + all remote branches|
||create new branch and go to it (only necessary when you create a new branch)|
||switch to branch|
||add file to stage for commit|
||adds changes to commit, showing you changes one by one|
||commit file with a message|
||push branch to remote and set to track (-u only works if this is first push)|
||set upstream to
||push work to branch|
||switch to branch and merge changes from
||switch to branch and merge changes from
||pulls a remote branch and creates a local branch to track it (use when trying to pull someone else’s branch onto your local computer)|
||delete remote branch|
||deletes local branch, -D to force|
||untrack deleted remote branches|
10.6 How often should I commit?
It is good practice to commit every 15 minutes, or every time you make a significant change. It is better to commit more rather than less.
10.7 What should be pushed to Github?
Never push .Rout files! If someone else runs an R script and creates an .Rout file at the same time and both of you try to push to github, it is incredibly difficult to reconcile these two logs. If you run logs, keep them on your own system or (preferably) set up a shared directory where all logs are name and date timestamped.
There is a standardized
R which you can download and add to your project. This ensures you’re not committing log files or things that would otherwise best be left ignored to GitHub. This is a great discussion of project-oriented workflows, extolling the virtues of a self-contained, portable projects, for your reference.