Now is a good time to commit and push the new project to GitBucket.

1. Right click the project in the projects pane.

   Select <

   Commit">>.

   You will see a dialog appear showing you what files are going to be added to the repository. At this point it will just be the Gradle files, and the Main class.

   You will also see a text area in which you can add a Commit Message. You should always provide a useful message that describes what you have done since you last committed.

   A Git commit message is a bit like an email message. The first line represents the subject and should very briefly name the feature/bug you were working on and what action you were performing on that feature/bug (adding, fixing, refactoring, completing, ...). There should be a blank line after the first line. The rest of the message can include a more detailed description of why the commit was added. Note the use of the word 'why' rather than 'what' in the previous sentence. We can easily see what changed --- Git has many features that can show us what changed so we don't need to repeat this in the commit message. The commit message is about describing why those changes were made.

   In this case, we have just created the project, so your commit message should reflect that.

   Click <

   >.

2. You should see the Git log in the output pane. You will see a message at the end stating that the commit has finished. Since you are committing to the local repository in your home folder the commit should happen nearly instantly.

3. Open the repository browser using <

   Repository > Repository Browser">>.

   This is a handy browser that we can use to perform operations on the entire repository rather than just the NetBeans project. If you only have one project in the repository then there is little difference. However, we can have many projects inside a single repository.

   Some actions require you to use the repository browser. An example would be if you move a file from one project into another. Ideally you would commit that action in a single commit, so you would have to perform the commit on the repository rather than the projects.

   This is a handy pane to keep open. We will use the repository browser to interact with GitBucket in the next step.

4. At this point you have only added the files to your local repository. Now we need to push the local repository into the repository on GitBucket.

   Right click your repository in the repository browser and select <

   Push to Upstream">>.

   You will be asked if you want to create a new remote master branch since the repository on GitBucket is currently empty. Click <

   >.

   You will also be asked if you want the local master to track the remote master. Doing this makes it easy to compare the local version of the project against the remote version which allows you to see what you have changed since you last pushed. Again click <

   >.

5. Check the output pane. You should see a message stating that the push is finished.

6. In the repository browser, expand the <

   > and <> folders under <>.

   You will see that currently there is only one branch in the local repository --- master. This is the primary branch for most Git repositories --- most work will be added to this branch.

   You will also see that there is a remote branch named origin/master. This is a branch that is used to store a copy of the master that comes from GitBucket. When you pull, the master on GitBucket is copied into this branch. This allows you to compare between the local master and the remote master to see what has changed since your last push/merge.

   Since we told Git to make the local master track the remote master, you can see that the local master is automatically checking itself against the origin/master. At the moment both branches are in sync with each other, meaning they are both identical --- you can also see that both branches have the same commit ID for their most recent commits.

7. Go back to the web browser and refresh the GitBucket repository page. You should now see that your repository has the NetBeans project in it. You will also see the commit message beside the files.

8. Explore the project by clicking the info202_project folder. Click the <> folder. You should see your Main class.

The general rules for committing and pushing are:

• Commit after you have completed some kind of logical work unit. Examples could be:

  • You added a new feature, or at least completed some logical milestone on your way towards completing the feature.

  • You fixed a bug.

  • You added a section to a documentation file.

  • You completed some other milestone, such as finishing an important class, or completing an issue.

  One good way to think about logical work units is to think about the commit message that you would add when you complete the commit. If you can't think of anything to add that another developer working on the same project would find useful, then you might not be at a logical place to commit yet.If on the other hand you can think of many things to add to the message then you probably should have committed a long time ago. Git does allow you to control exactly what code gets committed in these situations, but the closest that we can do in NetBeans is to commit individual files (right click the file) which is usually close enough.Think of the commit messages as a development log for other developers (or yourself in a few weeks time after you have forgotten how/where you implemented some features). You or another developer should be able to use the commit messages to easily find the commits that added a particular feature, or fixed a particular bug. If this is not the case then you are doing it wrong and your Git history is useless.If in doubt, committing more is better than committing less. Git has features that can be used to squash smaller commits into a larger commit. If you have 5 commits relating to a single feature, you can later squash these commits into a single larger commit that contains the entire feature. This is often done prior to 'publishing' your work to team mates or to a public repository via a push.

• Note that committing and pushing are different operations. Committing modifies your local repository (the version in your home folder). Pushing will push the changes in your local repository to the remote repository (GitBucket).

  Put another way, committing will update the local branch. Pushing will synchronise the local branch with the remote branch on the server.

  You don't have to push after every commit, but it is a good idea to push regularly so that you have a recent backup of your repository in case something horrible happens.

• Before you log out and leave also make sure that you push so that you have the latest version of your code in GitBucket in case you want to continue working on it from home.