-
-
Notifications
You must be signed in to change notification settings - Fork 17
Workflow
- Fork the repo by clicking the Fork button on the repo's github page
- Clone the repo and set it up so that it pulls from the upstream (BloomBooks) repo but pushes to your forked repo:
Run the following commands:
git clone https://github.com/BloomBooks/BloomDesktop.git
cd BloomDesktop
git config remote.origin.pushurl [email protected]:<githubusername>/BloomDesktop.git
- Configure your local repo so that you get notified about whitespace problems when you try to commit:
Run the following command:
git config core.whitespace space-before-tab,indent-with-non-tab,blank-at-eol,tabwidth=4
Our preference is to use Visual Studio Code to edit everything in the BloomBrowserUI folder (the Browser-based parts of Bloom's UI, in various web languages). You should install the tslint extension using ctrl-P, then type "ext install tslint". This will give warnings when you fail to follow our typescript coding standard.
It's easiest if you work on a topic branch. To make it easier to find your topic branches in the list of existing branches you might want to add a common prefix like feature/ or topic/. When the change is ready you commit, push to your forked repo and create a pull request. Afterwards you pull from the upstream repo.
# create topic branch
git checkout -b feature/ImplementFoo
# hack away
# commit change
git add mynewfile
git commit -m "Implement new feature foo"
# upload to your forked repo
git push origin feature/ImplementFoo
Once you pushed your change to your forked repo on GitHub you can create a pull request on the github page of your forked repo: in the right column click on Pull Requests, then click the button New pull request.
The top line now shows on the left the target repo and branch (base fork and base) where the changes will end up, and to the right the source repo and branch (head fork and compare). Click the Edit button to change those. The base fork should be BloomBooks/BloomDesktop, base branch the branch where your changes should end up, e.g. linux. Head fork should be your forked repo and compare your topic branch.
GitHub should now show just the commits you made. Click Click to create a pull request for this comparison and then the Send pull request button.
The pull request is now visible on the upstream repo and can be reviewed there.
If you need to modify your change simply create a new commit and push that. It will automatically be included in your pull request.
NOTE: If you've used Gerrit before you might be tempted to amend a change that is up for code review. However, don't amend a change that is already part of an open pull request! This might cause review comments and the review history to disappear...
If you prefer a cleaner history you can also create a new topic branch based on your existing topic branch, make the changes and then amend the previous commit. After pushing to github you'll have to close the existing pull request and open a new one.
# Create new topic branch based on previous topic branch feature/myBranch
git checkout -b feature/myImprovedBranch feature/myBranch
# make fixes, amend commit changes and push topic branch
git add myfixedfile
git commit --amend
git push origin feature/myImprovedBranch
Once the code is reviewed and accepted the pull request can be merged into the upstream repo, either on the GitHub site or locally. The person doing the merge should delete the topic branch by clicking the Delete branch button on the pull request page on GitHub.
When there are merge conflicts you won't be able to do the merge on GitHub. Instead the person who opened the pull request should do the merge locally, push it to github, close the existing pull request and open a new one.
It might be good to delete the topic branch after the pull request got closed. You can do this by running these commands:
git checkout master
# delete local topic branch
git branch -D feature/ImplementFoo
# delete topic branch on forked repo
git push origin :feature/ImplementFoo
To update your forked repo you simply push to it. It's advisable to fetch first which gets new commits from the upstream repo (when the configuration proposed in this document is used).
git checkout master
git pull origin
git push origin master
Sometimes you want to continue working while a pull request is open.
You create a new topic branch based on master and do your changes there. These changes are independent of the changes in your previous (open) pull request. When your done with your changes you can push them and open a new pull request. See above.
In this case it's easiest if you continue to work in the same topic branch. You create new commits and push these them. They will appear as additional commits in the open pull request.
You could also create a separate topic branch based on your first topic branch. When you push your new changes and open a new pull request the older changes will also be included in the new pull request as well as in the old pull request.