GNU/Linux Desktop Survival Guide by Graham Williams
Desktop Survival Project Home Preface Advocacy History Distributions Installing GNU/Linux Basic Survival Wajig Applications AI, Machine Learning, Data Science Android - GNU/Linux Devices Audio Backup Booting CD Chinese ChRoot Clock Command Line Databases DIA Directories Disks EcoSysL Emacs Email Evolution Files File Systems Firewalls Floppy Disks FreedomBox Glade GNOME Graphics, Images, Photos Hardware Initialisations on Booting Installation Examples Internet IOT Java KDE Kernels Keyboard Konqueror KVM Switch LATEX Log System Login Magellan MATE Mathematics Memory Modems Mounting Devices MS/Windows Music MySQL Nautilus Networks Nextcloud Network File System NFS NT File System Oracle Packages Partitions Passwords PDF Power Management PPP Presentations Printing Python R Remote Desktops Rsync Samba Scanning Science Screens Security Spreadsheet SSH Swap Teradata Data Warehouse Themes TV Unity USB Version Control Video Virtualization Voice over IP WebCam WordPress Web Sites Word Processing and Printing X XML Troubleshooting Index

CLICK HERE TO VISIT THE UPDATED SURVIVAL GUIDE

Git Commit

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 option -m allows the message to be provided there:

$ git status
$ git commit -m "Add description of git commit." git_intro.tex

This might encourage descriptions to be short, but that is fine if a short description is all that is required.

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