GNU/Linux Desktop Survival Guide
by Graham Williams
20190415 A commit should be done when you are finished with your changes or updates. A good motto is to commit early and commit often. This finer granularity then keeps track of changes as we go. Others argue to complete some significant changes and then commit in a block. I prefer the step-by-step approach and through this I can often even see the progress of my ideas as they develop. We may do so though in a branch other than the main branch, as we will discuss below.
Each commit must have a description. When committing from the command
line git will pop up an editor into which you are encouraged to enter
a good description of what is being committed. It can be any length,
but we often prefer clear and concise messages. The command line
-m allows the message to be provided there:
$ git status $ git commit -m "Add description of git commit." git_intro.tex
An option to avoid is
-a which will apply the commit and
message to all files that need to be committed (i.e., all changes). At
times this can be useful but you should do so with care. Accidents can
happen where by some half finished or even unwanted changes get
committed. This, do the following with care:
$ git add * $ git status $ git commint -am "Add all files into the repository."
Notice the practice of always reviewing the status of git every time we do a commit. This is a good practice!
So, before getting started with any activity on git we may like to ensure our main branch is up-to-date. This is not required but is a good idea to regularly check. First we check the current status of the main branch.
$ git status
There are changes not yet staged so lets commit them, noting that you may like to choose better messaging.
$ git commit -am "Commit the main branch before branching to a dev branch." $ git push