Git from scratch in a nutshell

After downloading Git from https://git-scm.com/downloads and installing it on your machine, you should open the terminal and configure the username (the author) and the email within the global configuration:

Then, create a new project and convert it to a Git repository (versioned project) issuing git init command:

Or, by using Spring Tool Suite as shown below:

Now, let's create a new file within the project directory, then add it to staging area using git add <file> command. Afterwards, commit these changes to the repository's database using git commit -m <message> command:

Or, by using Spring Tool Suite as shown below:

In order to check your repo status, you might find the command git status -s very useful with the param s standing for short. On the other hand, you have the command git log --oneline with the param oneline for brevity's sake to check commit history.

One of the most brilliant features of Git is branching. Branching allows you to work on a different directory rather than working on the production's one, which is a bad practice. Now let's suppose you want to do some development and commit changes within a different branch named development. The following commands are useful for this purpose:

$ git branch development
$ git checkout development

or simply:

$ git checkout -b development

These equivalent commands above, create a new branch named development and switch to it.
After making and committing your changes, you might want to merge these changes to the production directory(master branch) and delete the development branch. In order to do so, you could issue the following commands:

$ git checkout master
$ git merge development

$ git branch -d development

Pushing into GitHub
using
git pull origin <branch>
git push origin <branch>
commands:

Or, by using Spring Tool Suite as shown below:

Setting Up The Central Repository, And Multiple Development Environments

GitHub via SSH
In order to communicate with GitHub via SSH protocol rather than HTTPS(default), you should generate encryption keys using ssh-keygen -t <type> -b <lenght> - C <comment> command.
Afterward, you should start the SSH agent on your machine using eval "$(ssh-agent -s)" command and then add the SSH public key into it using ssh-add ~/.ssh/id_rsa.pub command.
Now copy the content of you public key file(~/.ssh/id_rsa.pub), head to GitHub.com, create new SSH key and paste that content into it.
You might verify the SSH connection using ssh -T -p 443 git@github.com command.
Now, in order to switch the protocol to SSH for the remote connection you should use git remote set-url origin git@github.com:<USERNAME>/<REPOSITORY>.git command. Afterward, you might check the effect of the previous command using git remote -v :

Configuring Sessions in the Deployment Descriptor

In many cases, HTTP sessions are ready to go in Java EE and require no explicit configuration. However, configure them you can, and for security purposes, you should. You configure sessions in the deployment descriptor using the <session-config> tag. Within this tag, you can configure the method by which sessions are tracked, the age after which sessions timeout, and the details of the session ID cookie, if you use that. Many of these have default values that you never need to change. The following code demonstrates all the possible deployment descriptor settings for sessions.

<session-config>
     <session-timeout>30</session-timeout>
     <cookie-config>
          <name>JSESSIONID</name>
          <domain>example.org</domain>
          <path>/shop</path>
          <comment><![CDATA[Keeps you logged in. See our privacy policy for more information.]]></comment>
          <http-only>true</http-only>
          <secure>false</secure>
          <max-age>1800</max-age>
     </cookie-config>
     <tracking-mode>COOKIE</tracking-mode>
     <tracking-mode>URL</tracking-mode>
     <tracking-mode>SSL</tracking-mode>
</session-config>

All of the tags within <session-config> and <cookie-config> are optional, but they must appear in the order shown in this example (excluding omitted tags).
The <session-timeout> tag specifies how long sessions should remain inactive, in minutes, before being invalidated. If the value is 0 or less, the session never expires. If this tag is omitted, the container default applies. Tomcat’s default container is 30, which can be changed in the Tomcat configuration. If you want consistency, you should explicitly set the timeout using this tag. In this example the timeout is 30 minutes. Each time a user with a certain session ID makes a request to your application, the timer resets on his session’s inactivity. If he goes more than 30 minutes without making a request, his session is considered invalid and he is given a new session.
The <tracking-mode> tag, which was added in Servlet 3.0/Java EE 6, indicates which technique the container should use for tracking session IDs. The legal values are:

- URL : The container only embeds session IDs in URLs. It does not use cookies or SSL session IDs. This approach is not very secure.
- COOKIE : The container uses session cookies for tracking session IDs. This technique is very secure.
- SSL : The container uses SSL Session IDs as HTTP session IDs. This method is the most secure approach available but requires all requests to be HTTPS for it to work properly.

You may use <tracking-mode> more than once to tell the container it can use multiple strategies. For example, if you specify both COOKIE and URL, the container prefers cookies but uses URLs when cookies are not available. Specifying COOKIE as the only tracking mode tells the container to never embed sessions in URLs and always assume the user has cookies enabled. Likewise, specifying URL as the only tracking mode tells the container to never use cookies. If you enable the SSL tracking mode, you cannot also enable the COOKIE or URL modes. SSL Session IDs must be used on their own; the container cannot fall back to cookies or URLs in the absence of HTTPS.
The <cookie-config> tag applies only when COOKIE is specified as one of the (or the only) tracking modes. Tags within it customize the session cookies that the container returns to the browser:

- The <name> tag enables you to customize the name of the session cookie. The default is JSESSIONID, and you will probably never need to change that.
- The <domain> and <path> tags correspond to the Domain and Path attributes of the cookie. The web container appropriately defaults these for you so that you should usually not need to customize them. The Domain defaults to the domain name used to make the request during which the session was created. The Path defaults to the deployed application context name.
- The <comment> tag adds a Comment attribute to the session ID cookie, providing the opportunity to add arbitrary text. This is often used to explain the purpose of the cookie and point users to the site’s privacy policy. Whether you use this is entirely up to you. If you omit this tag, the Comment attribute is not added to the cookie.
- The <http-only> and <secure> tags correspond to the HttpOnly and Secure cookie attributes, and both default to false. For increased security, you should always customize <http-only> to true <secure> should be changed to true only if you have HTTPS enabled.
- The final tag, <max-age>, specifies the Max-Age cookie attribute that controls when the cookie expires. By default, the cookie has no expiration date, which means it expires when the browser closes. Setting this to -1 has the same effect. Expiring the cookie when the browser closes is almost always what you want. You customize this value in seconds (unlike <session-timeout>, which is in minutes), but doing so could cause the cookie to expire and session tracking to fail while the user is in the middle of actively using your application. It’s best to leave this one alone and not use this tag.

As of Servlet 3.0/Java EE 6, you can skip the deployment descriptor and configure most of these options programmatically using the ServletContext. Use the setSessionTrackingModes method to specify a Set of one or more javax.servlet.SessionTrackingMode enum constants. getSessionCookieConfig returns a javax.servlet.SessionCookieConfig use this object to configure any of the <cookie-config> settings. You can configure the tracking modes or cookie configuration only within a ServletContextListener’s contextInitialized method or a ServletContainerInitializer’s onStartup method. Currently, you cannot configure the session timeout programmatically this oversight should be corrected in Java EE 8.