Buck9195/Gladstone-Bioinformatics-Workshop
1
0
Fork 0
mirror of https://github.com/gladstone-institutes/Bioinformatics-Workshops.git synced 2025-11-30 09:45:43 -08:00
Code Issues Projects Releases Packages Wiki Activity Actions

Create workflows.md

Browse source 
Copied over unchanged from https://github.com/ariutta/git-primer/blob/master/workflows.md
This commit is contained in:
Anders Riutta 2020-03-24 11:09:55 -07:00 • committed by GitHub
parent db24cc62d9
commit 0a3fcab44e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

32
Using-git-and-github/workflows.md Normal file
View file

@ -0,0 +1,32 @@
# git workflows
Higher-level tips and strategies for more effective usage of git.
## Workflow Models
The appropriate workflow model depends on the size of your team and the type of your project. You have many options, e.g., [Atlassian](https://www.atlassian.com/blog/archives/simple-git-workflow-simple), [Driessen](http://nvie.com/posts/a-successful-git-branching-model/), [GitHub](https://guides.github.com/introduction/flow/) and [GitLab](https://docs.gitlab.com/ee/workflow/gitlab_flow.html), but they tend to be designed for projects like websites that are continuously running and supported by large teams, making them more complex than is needed for a one-off bioinformatics project created by a single individual or a small team. For these types of projects, the GitLab workflow is a good starting point, but you should feel free to customize it to suit your specific needs.
`tldr`
* Use feature branches, e.g., `add-cleaning-step` for changes
* When code in feature branch is solid, merge it into `master` branch
* Always keep your `master` branch in "last known good" state (working, production-ready, deployable)
## What to Commit
Don't commit everything: be deliberate. Never commit files with passwords or API keys. Avoid committing build artifacts, temporary and meta files like `*.swp`, `*.DS_Store`, `*.jar` and `*.pyc` files. Be judicious when deciding whether to commit source data. If you can reference the source and have your scripts download the data if it's not already present, you can reduce the size of your git repo.
To tell git to ignore certain types of files, you can add a `.gitignore_global` file to your home directory and a `.gitignore` file to your project directory. Reference [these templates](https://github.com/github/gitignore) for examples.
`tldr`
Be sure your home directory has a `.gitignore_global` file like one of these: [Linux](https://github.com/github/gitignore/blob/master/Global/Linux.gitignore), [macOS](https://github.com/github/gitignore/blob/master/Global/macOS.gitignore) or [Windows](https://github.com/github/gitignore/blob/master/Global/Windows.gitignore)
## [Tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging)
Whenever you deploy code or run a publishable job, tag your code using [semantic versioning](http://semver.org/).
## [Rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
To update a feature branch so the changes it contains are applied on top of the latest from `origin/master`:
```
git fetch
git checkout my-new-feat
git rebase origin/master
```
See [this post](https://blog.algolia.com/master-git-rebase/).