In this series of posts and videos, we will explore creating and deploying a SOA composite using Oracle Developer Cloud Service.
One important step to take early on is to create a ".gitignore" file. This will tell Git to not add generated files to source control. The final artifact and all its temporary files such as generated sources, class files, build logs, and such should not be checked in. Not only do they hog a bunch of space, but they also lead to spurious merge conflicts since everyone is constantly generating new ones. I created a simple .gitignore file in the video, but it will likely evolve over time (in a later chapter, I will make a complete project available).
The first step to putting your composite into source control is to make Git aware of the files. Git can always tell you what the current state of the world is with the following command:
With this command, Git will tell you what files it thinks are new, what files it thinks have changed, and what files it thinks have been removed. More importantly, Git will tell you what commands to execute to record the changes. This is different from some source control systems which require you to tell them upfront when you add, remove, or modify a file. Git instead lets you use normal file system commands to alter files, but it still requires you to eventually tell it what files you really want added, removed, and modified.
To add all the files under a specific directory, run the "add" command:
git add --all
If you run the status command again, Git will now tell you what files were added and helpfully tell you how to unadd them.
Finally, you must commit these changes before they can become part of your repository.
git commit --all -m "my comment"
An important thing to keep in mind is that all these adds, removes, and commits happen only on your local repository. No one else will be affected by adds, removes, and commits you make to your local repository, until you "push" the changes to the remote repository. If you are familiar with SVN, consider your local repository to be a branch/fork. Until you merge your branch back, everyone else is completely isolated from your changes.
Once you are ready to make your changes public, run the "push" command. Note that if the branch was newly created in your local repository, you will need to specify the name of the remote server and remote branch name in order to link them. For whatever reason, Git will not simply default to origin and use the name of the local branch. Once the push succeeds, subsequent pushes will remember to use those values until you change them:
Congrats! Your changes should now be visible in the DevCS console as well as to your fellow developers!While Linux is used in the video series, all mvn and git commands are applicable to Windows. Any variations will be called out in the accompanying blog.