Git & Version Control

Seshal Jain

Created: 2022-09-22 Thu 00:35

Version Control

the practice of tracking and managing changes to software code

Why use VC?

  • undo changes
  • simplify collaboration
  • look at previous versions

Bad version control

filename-based
bad-vc.png

unnecessary comments in code

for (int i = 1; i < Ntr; i++) {
  if (radius > turn_rad[i - 1] && radius <= turn_rad[i]) {
    // for(int j = 1; j < Nh; j++) {
    //     if (theta < heading[j-1]) {
    //         // cout << "I" << i << endl;
    //         // cout << "J" << j << endl;

    //         q11 = torque_in[i-1][j-1];
    //         q12 = torque_in[i][j-1];
    //         q21 = torque_in[i-1][j];
    //         q22 = torque_in[i][j];

    //         // torque_out = sqrt(q22 - q12) * q22/q11;
    //         torque_out = abs(sqrt(q22 - q12) * q22/q11);

    //         cout << "T_Out:" << t_out << endl;
    //     }
    // }
    q11 = torque_in[i - 1][0];
    q22 = torque_in[i][0];
    torque_out = q22 / q11;
  }
}

what is git?

git is a good version control tool

it is a command line utility
(but can be used via GUI clients)

installing git

download from https://git-scm.com/downloads

make sure to enable

  • Git on PATH (for Git Bash and CMD integration)
  • CRLF Normalization
  • MinTTY

चलिए शुरू करते हैं

बिना किसी…

configure Git

git associates your name and email with every change you make

inside a terminal:

$ git config --global user.name "Your Name"
$ git config --global user.email "youremail@domain.com"

make a new repo

git-innit.jpeg

step by step:

  1. mkdir [folder_name]
  2. cd [folder_name]
  3. git init

repository “repo”

a folder containing your code

every git repo contains a .git folder
it stores all of your changes, don’t mess with it (manually)

use an existing repo

$ git clone [path]

creates a new folder in your current directory

$ git clone [path] [destination]

clones the repo at destination

path is usually a git repo link:

  • a link to a remote repo

    $ git clone https://github.com/github/training-kit.git
    
  • it can also be a repository on your computer

    $ git clone ./path-to-existing-repo ./new-clone
    

git commands

terminal command syntax

git [subcommand] [options]

git status

tells you the status of your repository

*can tell you what to do next

a few important terms

  • untracked: new files, known to git but not tracked
  • staging: collect related changes, put them on a stage
  • commit: document these changes file-by-file, line-by-line

a commit stores

  • a descriptive comment
  • metadata
  • changed lines
  • commit id

create your first commit

inside the new repo you created with git init, create README.md

$ echo "Hello world!" > README.md
$ git status

will tell you about the changes to your file

on branch master

no commits yet

untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md

nothing added to commit but untracked files present (use "git add" to track)

git add

$ git add README.md

will “add” README.md to the staging area

on branch master

no commits yet

changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   README.md

git commit

$ git commit -m "Commit message"

will “commit” this change and store it permanently

[master (root-commit) 04e48d4] Initial Commit
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

running
git status
again will tell you the updated status of your repo

on branch master
nothing to commit, working tree clean

step by step:

  1. Create changes (add/edit/remove)
  2. $ git status
  3. $ git add [filename]
  4. $ git commit -m "Meaningful commit message"
  5. Repeat

*more parts coming soon!

when & what to commit

git is only as good as your commits

Write in present tense, imperative mood

Ex:

  • Add README with title and summary
  • Rewrite presentation section on commit messages

*commits should sound like commands

try to combine multiple related changes into one commit

making inefficient commits causes problems later

commits are checkpoints, you can revert them

good commit history:

Update Navbar component

fixes #42
- added border-radius
- fixed bug around mobile view

bad commit history (and commit messages):

- navbar
- sorry
- navbar styles
- typo

*bad commits clutter up your git history

what is Github?

Github is a cloud-based git repository hosting service

there are several others: Gitlab, BitBucket, self-hosted Git instances

sign up at https://github.com/join

why Github?

  • host your code online
  • extra collaboration tools
  • large developer community

a Github repo is simply a git repo on a server

we can:

  1. use git on a terminal
  2. interact through the site itself (via a browser)

github-repo.png

create your own repository

  1. Go to https://github.com/new
  2. Provide a name and description

*don’t initialize the repo with README (for now)

github-empty-repo.png

clone your new repo

  1. copy the git URL
    https://github.com/yourname/repo.git
  2. $ git clone [copied_url_path]
  3. $ cd [repo_name]

connect your local repo to the remote repo

inside your local repo

git remote add origin [copied_url_path]

OR

copy the contents of your local repo to the cloned repo

you will need to recreate your commits

the .git directory stores ALL info related to your project,
∴ different .git == no commit/history

*esp useful when things go wrong

git fetch

syncs your remotes

git push

$ git push -u [remote] [branch]

git push -u origin main
pushes changes from your local main branch to the remote repo (aka origin)

git push remembers your remote

git workflow (updated):

  1. $ git fetch
  2. Create changes (add/edit/remove)
  3. $ git status
  4. $ git add [filename]
  5. $ git commit -m "Meaningful commit message"
  6. Repeat
  7. $ git push

how to do X in Git?

https://stackoverflow.com/search?q=how+to+do+X+in+Git

Branching and Merging

branch.svg

Figure 1: branches allow you to work on multiple features/fixes simultaneously

  • main / master: git’s default branch


  • HEAD: alias to current branch

when to create branches

several approaches

  • testing, staging, prod etc
  • 1 feature/1 branch
  • 1 dev/1 branch
  • combination of the above

Demonstration

branching-1.png

create new branch

assuming working on some issue #53

$ git branch iss53
$ git checkout iss53

OR

$ git checkout -b iss53

branching-2.png

add some changes to feature “iss53”

add file, commit file branching-3.png

go back to continuing work on master

$ git checkout master

now there is some urgent issue, new fix required

create hotfix branch

$ git checkout -b hotfix

resolve bug, commit changes branching-4.png

bring master to hotfix

go back to master

$ git checkout master

merge master to hotfix

$ git merge hotfix

master is now on hotfix (HEAD = master == hotfix) branching-5.png

hotfix no longer required, can safely delete hotfix

$ git branch -d hotfix

continue working on iss53

$ git checkout iss53
# make changes, add commits

issue #53 completed, let’s merge it in master

$ git checkout master
$ git merge iss53

merging-1.png

merging-2.png

Merge Conflicts

such pain, much wow

if you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly

Git does not know which change to keep

ergo, MeRgE CoNFliCts - Git asks you which change to keep

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html