Git SCM Git Workflows

• When used properly Git allows us to modify our source code WITHOUT looking at it!
• Spend less time managing the code

DO NOT WORK ON MASTER EVER!!!!!!!!!

1. Branch from a source of truth (typically master, but sometimes dev - in the case of IBM)
2. Create a new branch (either on your terminal and then push - see below - or using the github interface - see below)
3. Open a PR after your first commit and push (add relavent labels, and project information)
4. Do work...commit very often (preferablly more often) and push to the corresponding branch
5. When you're done request a reviewer in the PR.
6. After the PR is approved merge using (squash and merge)

We're the team "NAME-IT!" and our job as namers are to record names of people.

1. Create a new branch and PR. Name the branch create-<your-first-name For example:

git checkout -b create-noah
git push origin -u create-noah # I'll use the printed link to create a new PR

1. If you're in the terminal:

cd practice

1. Create a new file with your first name in lowercase (and no file extension). For example:

   touch noah # remember we're in the practice/ directory
   

2. Print your favorite food and current city in the file in the format:

   { "favoriteFood": "pizza",
     "city": "Atlanta"
   }
   

1. Refer to here their official docs (make sure to select the dev or `master branch!)

2. On your local machine:

   git fetch origin
   git checkout -t origin/<new-branch-name>
   

Follow the steps below (assuming you're on a clean working directory)

git checkout master
git pull origin master
git checkout -b <new-branch-name>
git push origin -u <new-branch-name>

Github sends a link in the push message to a new PR. Use that to open a new pull request.

These changes are...

• New feature
• New bug fix
• Testing / playing around
• Changes that might be needed across multiple braches

1. Use git rebase instead of git merge when pulling in changes from master.

A <- B <- C <- D <- H (master)
            \- E <- F <- G (new-feature)

            ||
            ||  (git rebase master; ...)
            ||
            \/

              (master)
A <- B <- C <- D <- H <- E' <- F' <- G' <- I (new-feature)

            ||
            ||  (git checkout master; git merge new-feature)
            ||
            \/

                                             (master) 
A <- B <- C <- D <- H <- E' <- F' <- G' <- I (new-feature)

Is easier to manage than

A <- B <- C <- D <- H (master)
            \- E <- F <- G (new-feature)

            ||
            || (git merge master; ... git checkout master; git merge new-feature)
            ||
            \/

A <- B <- C <- D <- H --------- J (master)
          \            \       /
            \- E <- F <- G <- I (new-feature)

• Use them to communicate to the team.

• Use them as a place to keep notes and write down your thoughts.

• My favorite:

  git log --graph --oneline --all --decorate
  

A remote is simple: another repository ...ANYWHERE...

From Git SCM on remotes

It is entirely possible that you can be working with a “remote” repository
that is, in fact, on the same host you are. The word “remote” does not
necessarily imply that the repository is somewhere else on the network or
Internet, only that it is elsewhere. Working with such a remote repository
would still involve all the standard pushing, pulling and fetching operations
as with any other remote.

Remotes allow you copy a git tree from one repository to another.

A remote branch is completely independent of your local branches. Use git branch -a to list all available branches.

1. git fetch
2. git merge origin/<branch>