GIT Workflow
This document is written to give an overview on how to work with your BitBucket on RebelMouse integration.
Using GIT
Since you are using your own GIT repository on Bitbucket which is totally separated from RebelMouse repository , you can maintain your repository as you wish. This allows for a lot of creative freedom in using the environment the way you'd like.
While you can use your own workflows, we still highly recommend our suggested workflow described in next steps.
I am new to GIT
Start by reading this GIT reference first http://gitref.org/. You can skip the part about "Getting and Creating Projects", everything else is quite useful.
Comparing GIT workflows
You can find a really good tutorial about different GIT workflows at https://www.atlassian.com/git/tutorials/comparing-workflows, which we highly recommend reading. especially Feature Branch Workflow. The most vital and necessary commands are listed in this tutorial as well.
Daily workflow example
As mentioned before Feature Branch Workflow is approach which we highly recommend to stick with. It means that for every new feature (or any bug you will fixing) you will create a new branch. All changes for that feature then should be in this branch. This way your master will be always clean and ready for syncing with our master.
This tutorial contains also other commands. Before start please read topics about VIM and Nano and Custom Roar Commands.
Switch to master branch, be sure that you are on it with git status. You can also check if there are any changes with git diff command.
git checkout master
Rebase the master. This will take down all changes (which other developers in your team have pushed to origin) from BitBucket repository to your local repo.
git pull --rebase
Fetch new changes. This will take down all changes (which other developers in our team have pushed to origin) from GitHub repository to your local repo.
roar-fetch
Check if there are any changes.
git status
If there are any changes you need to commit them.
git commit -am "updates from RM repo"
Push new changes from local master branch to your origin master branch.
git push origin master
Let's say you would like to start working on a new feature. Create a new feature branch. Please respect the TICKET_NO-lower_case_with_underscore naming.
git checkout -b 12345-new_branch_name
Open and edit file which you need to update. I will work on article.css with VIM terminal editor for this example.
vim static/css/roar/article.css
Every time you want to check your changes in browser you need to run roar-reload.
roar-reload
All templates are cached. This command reloads your environment and applies your recent changes; without running it you won't see any updates in the browser after refresh. You don't need to run this command when you've edited static files.
Check your beta in browser now. If you are satisfied with your changes and new feature looks okay, you should push this changes to your repo first.
Verify your changes one more time.
git diff
Commit your changes with meaningful commit message. Don't forget to include #TICKET_NO at the end.
git commit -am "updated colors on article page #12345"
Push changes to your repo.
git push origin 12345-new_branch_name
After this you are ready for pushing to stage server. Please note that you can push to stage server from any branch. Branch which you are currently on will be deployed to stage.
roar-push-stage stage_name
URL of stage server will be outputted in this step.
If everything looks okay, you can proceed with pushing to production. Pushing to production is possible only from master branch. Before that you need to fetch latest code from BitBucket and GitHub repo. This way you will be sure that your changes looks well even with latest code. It could happen that in meantime someone else has made changes in the same file you were working on. It is necessary that code is synced. You need to repeat the steps which we made in the beginning.
git checkout mastergit pull --rebaseroar-fetchgit statusgit commit -am "updates from RM repo"git push origin master
Then merge your feature branch into master.
git merge --no-ff 12345-new_branch_name
In most cases everything will be okay after this. But from time to time you will get merge conflicts. You will be notified about them in terminal and you need to solve them manually. This happens because someone else were working in the same time, on the same lines in the same file as you do.
Just before pushing changes live, please verify that everything still looks okay on your beta.
roar-reload
Check your beta in browser. If everything is okay, you're clear to push your updates live.
roar-push-prod "A meaningful message explaining new updates."
Deployment could be blocked by other developers at any given time and deploying itself could take up to 20 min. In this process your feature branch will be also pushed to BitBucket.
When deploying will be done, you are able to check your changes in browser on live site.
You're not required to stick with this workflow, but it is helpful. If you are good with GIT, you can use it on your own way. Then all you need to know are our 4 roar-[...] custom commands.
From 
From 
From Google
