...
To avoid having to enter your password each time you interact with your fork on BitBucket, set up ssh for git. See: Set up SSH for Git.
Add "upstream" - an alias to the team repository
Use git to add the team repository as a new " remote " repository to your local clone. By convention, the team repository (which you forked) should be named "upstream".
...
Make a branch
Before you start making changes to your local clonework on a new feature, bug fix, or other improvement, create a new branch for the changes you intend to make. This new branch is called a "feature topic branch" and should only contain modifications that implement a address one specific, discrete feature or bug fix. This is critical! Doing this will allow you to issue focused, low risk pull requests that are easy to merge with other developers' work.
To make a new feature topic branch:
| Code Block | ||
|---|---|---|
| ||
git checkout -b <BRANCH> |
where BRANCH is the name of the new branch. Branch names always should refer to issues in the JIRA issue-tracking system - for example: IGBF-203. Branches should always derive from the master branch, the main line of development for IGB. To ensure this happens, make sure you are "on" the master branch before creating a new branch.
Note: Topic branches are sometimes also called "feature branches." However, this is may not be the best name because often branches deal with bug fixes or improvements to existing features. The IGB project prefers the term "topic branch" because it is more general.
Edit code, commit to your clone, push to your fork
...
If the main development branch changes, merge you must obtain those changes into your fork early and often. To bring your remote fork up-to-date, fetch and merge changes from the team repository's master branch using pull commands. Note, and test them with your branch.
First step is to update your copies of the master branch. Note that this assumes you have already added the team repository as a remote repository named "upstream."
...
Recall that "origin" is aliased to your fork on bitbucket.
Now the master branch is up-to-date on your clone and fork.
Rebase your branch
After updating your clone and fork with the latest changes to the master branch, you'll need to merge test how those new commits interact with your feature topic branch. The IGB team recommends you use "rebase" commands to do this. This makes the commit history for the IGB project much cleaner as it will simply move the "base" of your feature topic branch to the latest commit on the master branch.See: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
To rebase your branch on the latest master, update the master branch (see above), check out your feature branch, and rebase:
| Code Block |
|---|
git checkout <BRANCH> git rebase master |
Next, re-push your Push your newly rebased branch to "origin" (your fork) to update it:
| Code Block |
|---|
git push origin <BRANCH> |
...
- Select your branch (see above) as the pull request source (left side).
- Select the master branch as the pull request target (right side).
- Fill in the Title and Description fields
- Click Create pull request
...
Note that the team repository already has dozens of branches, most of them leftover from older workflows. DON'T push your branch as an all-new branch to the team repository as this just adds to the clutter!. And DON'T merge your branch with master.
Other info
GenoViz Software Development Kit
...