1. Introduction

1.1. What is Git

• Git is a Version Control System (a.k.a. Source Control Manager)
• It is a Free and Open Source Software (FOSS)
• It is distributed i.e. does not need a central server
• It allows managing changes in source code, over time and over multiple concurrent users.

1.2. How does it work?

• Git keeps track of the files you want it to handle within the project.
  • It stores the changes made at specific points.
  • You only need to store one file (no more report_draft_v3_final.txt)
• Git also allows you to keep parallel/alternate versions.

1.3. Interface

• We will see the git cli (Command Line Interface)
• In practice, you use a git client.
  1. Git for Windows
  2. VSCode Git Extension
  3. Eclipse Git Integration (egit)
  4. Emacs Git Integration (magit)
  5. GitKraken

1.4. Help

When in doubt, use --help

git --help
git <subcommand> --help

• Always provides the complete information.

2. Concepts

2.1. Repository

• The .git folder that keeps all the git related files used only for version control.
• Never edit this manually.

• Inside the project you want to manage, enter the command to create a repository

    git init .
  

  • This creates a new repository at . (current location)

2.2. Working Tree

• All the files and subdirectories of the directory where the repo exists.
• The folder in which .git exists and its subfolders is the working tree.

2.3. Index

• Git does not track all files by default.
• Index is the list of files that the git repository is tracking.
  • This is also called staging

• You can add a file to index with

    git add <filename>
  

• You could also add the entire current folder by using

    git add .
  

2.4. Commit

• A commit is an index that is preserved.

• All the staged files are added to the commit with a user defined message.

    git commit
  

• Git allows you to go back to any commit using its hash which is a unique label.

2.4.1. Commit Messages

• Always use a informative and precise commit message.
  • One line brief title (56 characters ending with a .)
  • An empty line
  • And a more detailed message (if required)
• Always try to ensure each commit contains one task so that it is easy to find.

2.5. Log

A list of all your commits in the current history.

2.6. Branch

• Branches are parallel version of commits.
• You can use a branch to work on multiple independent features in parallel.
• Branches have various uses
  • But for courses except INF113 using just a main branch may suffice.

• You can

  1. List Branches

     git branch
     

  2. Create branches

     git branch <branch-name>
     

Practice Learn Git Branching

2.7. Merge commits

• Adding together two separated lists of commits requires a merge.
• Git will try to add the changes from both the branches.
  • If both modify the same lines and git cannot automatically resolve
  • It will create a merge conflict

2.8. Conflict

• Conflicts are notified by git, along with the files.

• Visible in git status

• Opening the file in a text editor will show the following

• You can modify the file to keep either of the changes, or keep both.
  • Also remove the surrounding characters.

• Finally, you can commit this change.

2.9. Rebase

• Rebase is an alternate merge behaviour
  • Instead of merge commit, reapply the commits to the top of the destination.

• This is cleaner, and often considered more appropriate when doing a pull to avoid too many merges.

    git pull --rebase
  

3. Collaboration

3.1. Remote

• Collaborate by sending your changes to a remote repository.
• Publicly available repository

• You can add extra remotes using

    git remote add <custom-name> <url>
  

3.2. Clone

• Clones a pre-existing remote repository.

    git clone <url> [<directory>]
  

3.3. Pull

• Recieve commits from the remote repository
• Git treats this as a merge

• Keep your local repo up-to-date by using

    git pull [<remote> <branch>]
  

3.4. Stash

• Sometimes you need to put away your work to pull.

git stash

• And you can re-apply it by

git stash apply

3.5. Push

• Send all your commits to remote repository.
• Push will fail if the local repository is behind the remote.
• Always ensure to pull before push.

4. Other features

4.1. Git Ignore

• Generally, certain files don’t need to be version controlled.
• .o, .so, .dll, .exe, .class, log.txt, token.txt etc.
• These are outputs/secrets that should not be available in git.
• Manual staging will avoid these, but that is a lot of work.
  • And they will still show in the git status
• Solution is to use the .gitignore file.

4.2. .. Git Ignore

• Create a file called .gitignore in the same directory as .git/
• You can write a filename, a directory or a regex (*.exe) that it ignores.

• For Example: for VSCode

    .vscode/
    .code-workspace
  

• You can find samples on Github

4.3. Other helpful commands

• Reset

  • Removes things from index. Reverse of git add

        git reset <filename>
    

• Revert
  • Applies the opposite diff of the commit
• Bisect
  • Identify which commit caused a bug.
  • Use binary search until you find the commit.

5. General Workflow

• When changes are “ready”

  git add <files>
  git commit
  git pull --rebase
  git push
  

6. Best Practices

6.1. Index

• Always check the staged files before commit.
• Always keep an up-to-date .gitignore

6.2. Commits

• Always write a descriptive commit message.
• Always focus a commit on one task.
  1. A subsection of an assignment
  2. A bug-fix
  3. A feature

6.3. Pull/Push

• Always pull before pushing
• Do not force push unless you are certain.
• Never force push on main

6.4. Best Practices

• Ideally, develop code on branches and open pull requests to main per-feature.