Tools: git

installing and running git

Note git is NOT Github

This covers the installation of git to run on commandline, e.g.

git <command>

Installing git

• To install git latest source release 2.27.0 [Release Notes (2020-06-01)] click here: https://git-scm.com/downloads
• Click on the name of your OS and the download of git starts automatically. If the download hasn't started automatically, a page will be opened to download manually with respect to your OS.
• After downloading, select the .exe folder to install. A tab will be opened, read and click next after selecting the required options you need and finally select install.

( NOTE : For Windows , when installing git, if you are not going to use any of your projects under Unix, don't agree with the default first option. Choose the third one.)

• After installing, another tab opens. Select the Launch Git Bash, which provides a git bash shortcut in your desktop and click next to finish the setup.

running git

• Run the command git --version in command prompt to check git installation, in case of Windows.

common git commands

• When you give the command git in your command prompt, the following are shown:

usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=path]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone             Clone a repository into a new directory
   init              Create an empty Git repository or reinitialize an existing one

work on the current change (see also: git help everyday)
   add               Add file contents to the index
   mv                Move or rename a file, a directory, or a symlink
   restore           Restore working tree files
   rm                Remove files from the working tree and from the index
   sparse-checkout   Initialize and modify the sparse-checkout

examine the history and state (see also: git help revisions)
   bisect            Use binary search to find the commit that introduced a bug
   diff              Show changes between commits, commit and working tree, etc
   grep              Print lines matching a pattern
   log               Show commit logs
   show              Show various types of objects
   status            Show the working tree status

grow, mark and tweak your common history
   branch            List, create, or delete branches
   commit            Record changes to the repository
   merge             Join two or more development histories together
   rebase            Reapply commits on top of another base tip
   reset             Reset current HEAD to the specified state
   switch            Switch branches
   tag               Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)
   fetch             Download objects and refs from another repository
   pull              Fetch from and integrate with another repository or a local branch
   push              Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.

Using Git

Git is first and foremost a collaboration tool. If many people work on a complex software project, they must do so without disrupting the work of others. Collaborators need to be able to work independently, at their own pace, and commit their work frequently and in a way that doesn't interfere with others. Git makes this possible. It also keeps a complete history of all work done, so mistakes can be easily recovered from.

Git's working model is distributed. _Everyone _keeps a complete copy of a 'repo' (repository) that hold all the project's work. As users make changes, they commit them to the repo locally. Then they synchronize their changes with that of a central repo using pull and push.

The process for getting started with a remote Git repo is simple:

• Clone the repo
• Make your changes
• Commit your changes locally
• Push them to the remote repo
• Pull down changes that you don't yet have.

Cloning the repo

You should only need to clone once. This creates a copy of the repo on your machine. The repo is simply a collection of folders and files, with some extra information to tell Git how to work with it.

git clone https://github.com/petermr/openVirus.git

will create a repo in the folder openVirus (the folder name defaults to that of the repo). You can then add, edit or delete files in its folders as you otherwise would.

Committing

When you have finished making changes, you can commit them:

git commit

Git then opens a file using your text editor, listing the changes to the files, and asking you to supply a commit message describing the work you've done. (A blank message will abandon the commit).

Synchronizing

It's always best to refresh your local repo first before publishing your changes.

git pull

will pull down any remote changes to your repo. If these include any files you've worked, Git will try to reconcile those changes with your own.

git push

then pushes your changes up to the remote repo.

Commit and synchronize frequently. This avoids Git getting into the situation where it cannot reconcile changes. It also helps to pull down changes before starting on any new work.

Independent Working

Branches

Whenever you work with Git, you are working with a branch. Branches are simply independent streams of development. They can be created and deleted at will. Think of them like parallel railway lines where work can go on unimpeded. Changes made in one branch are not reflected in other branches until you do a merge operation. You can pull into, push from and commit within a branch without affecting any other branch. This shows how branches work:

          A---B---C topic
         /
    D---E---F---G master

The **topic** branch has been created from **master** after commit **E**. Two more commits have happened on **master** since the branch was created.

There is always at least one branch in a Git repo, and this is generally called master. It is OK to work directly on the master branch, but it's much better to create and manage your own branches. Then when you have finished, merge your changes back into master before pushing. You will be working with master by default.

Creating a branch

This is a good idea when you are starting any discrete task. It is near essential if it's a major piece of work that could stretch over several days. Create a branch called, say task-101 with the command

git branch task101

from the current master. Then switch to the new branch with

git checkout task101

Make your changes and commit as usual.

Merging

Switch back to the master branch with

git checkout master

Then merge in the changes from your work branch:

git merge task101

Good practice

Avoid Staircase Branching

You can probably work out what this means. A staircase branch structure is when you create branches from branches from branches. This can cause great difficulties when merging. Keep to one branch at a time from master and merge that back in when you've finished your work.

Name branches meaningfully

If you have a task or bug code , then name the branch after it, e.g: task-567 or bug-323

Keep branches short if you can

Long lived branches can cause problems as they can easily get irretrievably out of sync. Make sure that you pull changes frequently down to your repo, and clean up old branches with git branch -d.