Committing Code

Adding files

Before you can commit your work to local or remote repositories you need to make sure git is tracking the file you have changed, otherwise those changes won't sync. To add a specific file to the git repository run the command:

# Change <filename> for the file you want to add
git add <filename>

Now when you do a commit this file will be tracked and if you make changes to it in the future that will be tracked also. You only need to add the file once.

Now here's a short cut for you, if you want to add all the files in a directory you can run the following to save you a lot of time.

# Add all files in the git repo
git add .

It is possible to have files in your working directory that are not tracked and pushed to the local and remote repositories.

Excluding files

There are times when you want to exclude certain files from your git repository. These could be credential files or something more harmless like _DS_Store folders that get created when you look at images. A .gitignore file specifies intentionally untracked files that Git should ignore, and thus keeps those files from being committed even when you run git add .. To create this file:

Make sure you are in the root of your git repository
create a new file called .gitignore
add the rules for the files to ignore

# OSx image cache
.DS_Store

# Some Java files you might want to ignore

# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
replay_pid*

Now make sure to add the .gitignore file to git itself:

git add .gitignore
git commit -a

If you want to ignore files that you've already added to the repo you need to run the following command:

git rm --cached <filename>

Commits

When working with commits it's good practice to add a commit message that describes the changes you've made. This is also why it's good to make frequent commits and split your work into smaller units of work, meaning the commit message is simpler to create and more accurate. There are a couple of ways you can add the commit message from the command line, the first is the way I tend to use because you get to see a nice easy to read list of things that have changed and maybe files you've forgot to include. It opens up your default text editor for you to write the commit message in, yet again in my case this is vim. If you are wondering how to exit vim it's ESC then :wq. This commit in this way do the following:

git commit -a
# Now enter you commit message at the top of the file and save and exit

However, some people prefer to add their commit message on the command line for speed and convenience. You can do this by adding the -m flag:

# Add a message on the command line
git commit -m "meaningful message"

If you've followed the advanced guide and set up GPG signing of your code you will be prompted for your GPG password at this point

If you realise you've made a mistake and want to change the last commit, you don't have to create a new commit, you can use the -—amend flag to amend the most recent commit

# make your changes
git add .
git commit --amend

When you push changes you may need to use the -force flag but this can be dangerous so use cautiously.

As a rule of thumb it’s good practice to commit frequently, thus avoiding loss of progress or accidentally resetting the unstaged changes.

Sync Commits to the Remote Repository

Right so you're committed this is good. If you remember back to our diagram about the stages of a git repository you've now moved the files into the local repository. It's now time to sync them back up to the remote repository. Now this is pretty simple just run the following command:

git push

If you have no merge conflicts all will be good and the code will now appear in the remote repository on the branch you are working on.

If you do have a merge conflict we'll deal with this in the merging file.

If you want to visualise this on your git diagram what you've done is effectively this:

gitGraph
    commit id: "first commit"
    commit id: "updates"

Tagging

Now you have a release lets look at how you tag that commit as a particular version. Here we turn your current version into a v1.0 tag.

git tag -a v1.0 -m "my version 1.0"

This is effectively what happens in your git branch.

gitGraph
    commit id: "first commit"
    commit id: "updates" tag: "v1.0"

To list your tags you can run:

# list all tags
git tag

# To filter tags to a certain string
git tag -l "v1.*"

5 KiB Raw Blame History Unescape Escape