GIT Introduction

Two Git groups: David and Nazario

Git for beginners with Nazario

Assuming some use of Git and starting at the bottom level.

Resources

• Video "Git for 4-year-olds"
• Article "Understanding Git conceptually"
• Practice: Git is source control; off-line; keeping track of changes;

Locally On Your Computer

Git as software tool installed on your computer.

• There are graphical tools as well as command line.
• Starting with cmd line...
  • Creating folder and file in folder -- then turn into a repository using "git init"
  • Start locally. Type "git status"
  • On branch master
  • see untracked file, To add to repository, "git add -A"
    • "add" is not the same as "commit" it is an intermediate step (like adding to shopping cart but not yet committing to buying)
    • "-A" means all additions, changes and deletions.
    • git commit -m with "message for the commit"
  • git show
  • git diff -- filename.txt
    • will show the difference between the earlier committed file and the modified (saved) file (labeled a and b).
  • Committed files reside in a "secret" folder (.git)
    • Must Add before Commit (must be in shopping cart before purchase!)
    • Commit is a cohesive collection of Adds that all relate to each other.
  • binaries (pdf, png, etc.)
  • Empty folders are ignored, git only cares about files.
  • If you want a folder to be in hte Commit create an empty file called .gitkeep (by convention)
  • Use touch command to create empty file with leading dot
  • git log
  • shows log of all changes; every Commit has a unique number
  • HEAD
    • Copy the Commit number and type
    • git checkout number
    • "you are in detached HEAD"
    • HEAD is your time machine; checkout a commit will take you back in time, and git log will show you only changes made up to this point in time.
    • To get back to the present time type
    • git checkout master (master is the name of the branch you are in)

Advanced Git with David

Best practices for test, stage, production environments and git.

• Use branches
  • specific branches for main line for particular environment
    • main testing
    • main staging that goes into production
    • maintain those branches for different enviornments
  • local branches are cheap and easy to add and destroy
  • create a new branch to do a merge on, if merge works do a fast forward merge
  • make a local branch

What is benefiting you to make a branch and then destroy the branch? Instead of rolling back to last commit on single local branch?

• If some interrupt comes up you can leave that branch and come back where I started and that’s there to go back to when the interrupt ends
• Dif easily by name
• Even if working in a tree that doesn’t have remotes
• Compare two different branches
• Stage commit messages
• Commit early, commit often—on a local branch you can do that and then occasionally do a squash merge

Squash merges

Want master to be relatively clean, so make a branch for something like a feature or bug fix. Messages are meaningful to individual when working on feature/bug, but might not be meaningful later or in the master.

Squash takes all of the commits on a branch make them only one single commit on master. You can keep the branch around or not depending on what you are trying to accomplish.

You might do a squash commit from dev to QA

Squash commit does not show parent.

Aliases

What is an alias? git config is a command that can be used to configure git in various ways either global or in a particular repo
one of the things you can do with a git config is make aliases, it is kind of like customized shorthand

Aliases David likes to use:

• tree log - - graph - - online - - all - - decorate
• git config color.status.changed yellow (gives a nice visual indicator to untracked files and changed files otherwise they both default to red)

Workflow best practices

This does kind of depend on what environment you’re working in. Some ideas that can help inform this is to get familiar with multiple remotes and using remotes so that for example three collabs have a main repo and each contributor has a remote and hosted version you can give each collabs remote meaningful names

If looking at a git tree can see collabs work

Get used to having those multiple remotes and name them something that’s easy to reference.

Three different remote origins instead of one origin. These might be forks if you use github or gitlab.

Multiple remotes feature branch can track a different remote, master branch can track origin. Make forks instead of branches because they are different repositories. You could be working on different masters.

Now if you want to go to staging server. At that point, create/do a push to origin repo called staging. Can push to production server that has origin with a branch for prod change is merged into prod. Staging gets master branch that’s about to go into prod. Point person only has access to pushing to production.

Steps

• Local work
• Individual repos for collar
• Ready to QA push it to the QA branch
• When QA gives okay for beta testing
• Someone merges from QA branch to master branch on staging server
• Get latest master branch and put onto the QA, when ready merge it up to production

Merge conflicts?

Have to chat with collabs

• Create a new git repo to explore how things work, make a new directory, cdn to it, git status, git init in new directory