-
Notifications
You must be signed in to change notification settings - Fork 10
Java Development Steps
After setting up your Java development environment, follow these steps for each task. For example, if the task is to add some small feature to a robot project as described by an issue, then follow this procedure for this task. When completed, you can then follow the same procedure for your next task.
Before starting the task, be sure that there is an issue for your task.
Before you make any changes, the first step is to make sure that your local master
branch is completely up-to-date with what has been put into the official FRC 4931 "2014" repository.
$ git checkout master
$ git pull upstream master
$ git checkout -b {new_branch_name}
At this point, your working directory (where all the Java source files are) will be on the branch named {new_branch_name}
, and all changes will be made there.
In the Eclipse IDE, make the changes required to satisfy the task/issue. Save and test as required. Periodically stage your changes, which basically makes Git remember the state of your changes so you can get them back. First, see what you've changed:
$ git status
This will show you which files have been modified, and which files have been staged. It also will tell you what to do next for the files. For example, to stage the changes:
$ git add .
You can continue to change the local files, and can either stage them as you progress or you can revert your local files back to the staged versions.
When you think you've reached a point where all the code compiles and has been tested, and where the changes represent a logical set of changes (e.g., they fix a bug, they add a component, etc.), then you can commit these changes using Git:
$ git commit -m "This is a description of my changes" .
This commit is added to the history on your branch.
It is important that the code in a commit can be compiled successfully and run on the robot. If your code is not at this point, then do not commit.
If you need to make more changes, then repeat steps 2 and 3 until you have completed the work involved in the issue.
So far, your changes are only on your local machine in your branch. The next step is to make them available to others by pushing your branch to your fork on GitHub, and then create a pull-request to have your work merged into the official "upstream" repository on GitHub. The steps to do this are:
$ git push origin {new_branch_name}
This will simply move all of your changes to the {new_branch_name}
branch on your GitHub.com fork of the FRC 4931 "2014" repository. If you followed the procedure to set up your environment, then "origin" is the name that your local Git repository uses for the remote Git repository on your fork.
Then, use your browser to go to your fork on GitHub.com. There, you will likely see a "Create pull-request" button; simply press it, add a meaningful description of your changes, and then create the pull-request.
One of the mentors will then be notified and will review your proposed changes, and will merge them into the master
branch of the FRC 4931 "2014" repository
All developers need to periodically pull all changes that have been merged into the official FRC 4931 "2014" repository, and this is the same as step 1:
$ git checkout master
$ git pull upstream master
Once your topic branches are no longer needed, you can remove them. First, remove the local branch:
$ git branch -d new_branch_name
Then, remove the branch from your fork:
$ git push origin :new_branch_name
(This command seems strange, but it actually of the form git push origin {local-branch}:{remote-branch}
, where you are pushing nothing onto the remote branch. That results in Git removing the remote branch.)
This involves removing them {new_branch_name}
After the changes have been merged, all developers need to