WCCI Course Materials

Git Branching and Merging

Git Commits

  • Each time you make a change to your code, you should make a commit.
  • You can think of the revision history of your code as a straight line with many dots, where each dot represents a time in history when you commited changes to your code.
  • Commits give you a way to track the history of your code, or move backwards to a previous version of your code.

Git Branches

  • Branches allow us to collaborate and work with others on a team.
  • master is the default branch for any Git repository when it is created.
  • We have the ability to create other branches.

Creating Branches

  • Branches create a copy of your code and allow you to have a separate place to work on something.
  • They are called branches because they look like branches on a tree. The difference is that they can merge back into the master branch.
  • Branches exist on their own and provide a separate stream of development, and separate commits.

You might want to create a branch...

  • To test something that you're not sure you want to have as a part of your program.
  • To work on a specific feature separate from the rest of the project before integrating it back in.

Merging

Merging takes the changes and deviations you have been working on separate from the project and merges them back into another branch (usually master).

Advantages:

  • One of the advantages of branching is that the rest of your team doesn't have to stop the work they're doing.
  • We don't have to coordinate with anyone, we can make our separate branch, and do our separate commits. They can do what they're doing, and then when we're ready, we can merge our changes back in.

Merge Conflicts

What happens when two people on a team are working with the same section of code? Conflicts can arise. How do you resolve these conflicts?

  • Git is really smart when it comes to merging sets of code. It can track when changes were made. Git does its best to merge things together.
  • Eventually, Git will run into some problems. It holds the separate parts of the code in separate places, and asks the developer to choose which changes she or he wants to include and which ones to not include. This is called resolving a merge conflict.
  • Visual Studio includes mark-up and options in your program, and the developer then chooses which section(s) of code is correct.

Best Practice

  • Nobody should be doing all of their work in master.
  • master should be reserved for working, clean, and tested code while all of the members of the team are doing their work in their separate branches.
  • Instead of merging a branch directly into master, you should go to GitHub and create a Pull Request for your branch.
  • Communicate frequently with your team members!
  • Pull updates from master into your branch regularly.

Where Can Branches Be Created?

  • Branches can be created directly off the master branch. They can also be created from existing branches.

.gitignore

  • A .gitignore file goes a long way towards preventing merge conflicts!! ALWAYS include a .gitignore!

Remember...

  • Include your .gitignore file in your project before initializing your Git repository.

Ways to Create a Branch

Whenever you create a branch, it's taking the most recent code and making a copy for that branch. The branch starts from wherever you currently are when you create your branch.

This command creates the branch, but keeps you in your current branch:

  • git branch branchName, where 'branchName' is replaced by the name of your new branch.

This command creates the branch and then switches you over to the new branch you've created:

  • git checkout -b branchName, where "branchName" is replaced by whatever you are naming your branch.

Branch Naming

  • If it's used for testing, call it testBranch.
  • If it's used for building a feature, name the branch after that feature.
  • Give some intention to your branch names.

  • NO SPACES in your branch name.

    • When you have spaces in your branch name, some programs will not function correctly with the branch.

Knowing what branch you're in

  • Git Bash will include the name of your branch in blue and in parentheses.

Pushing your branch to GitHub

  • We've only ever previously done git push origin master
  • With branches, we'll do git push origin branchName where "branchName" is replaced by whatever your branch's name is.

To Switch Branches

  • git checkout is the code we use to switch from one branch to another. Example: git checkout master from testBranch
  • When you switch a branch, Visual Studio will try to revert back your code to wherever the code was when the branch was intitiated.

Command to use sparingly

  • git push origin --all will push all of your branches to Github. Use sparingly because you don't want to be pushing non-functional branches and you don't want all of the members of your team to have to delete the bad branches.

Merge

Merging is when we bring the changes back in to another branch (usually master)

  • Important: You want to be checked out in the branch where you want to bring the changes in.

    • For example, git checkout master and git merge testBranch merges the testBranch into master
    • WARNING - it is possible to do it backwards, so be mindful when doing merges.

Here are 2 examples of merge commands:

  • git merge -m "Merge Message" branchName where "Merge Message" is replaced by the message you want to include and branchName is the branch you are merging in
  • git merge branchName where branchName is the branch you are merging in

Rules for Using Branches on a Team Project

Feature Branches

We will be using feature branches to build out all of our content for future team projects and the final project. All feature branches will be verified and merged to master via Pull Requests (PR).

Working Rules

Do not code on master on your local machine, but if you find yourself in this position we can fix it:

  • git stash will take all of your changes on master and remember them
  • git checkout -b new-branch then git stash apply will take these changes you had on master and place them on your new branch

Do not add/commit/push to the master branch

The Process

Make a feature branch for every "feature" you plan on adding into your application Since we work in iterations, these should be todos from your trello cards for a particular sprint

Name your feature branch to match the feature you are building

  • For example git checkout -b account-and-bank-build may be a branch that a dev creates to test and build these entities out

You can add / commit / push to this branch as much as you would like

Pull Request

When ready, submit a Pull Request on GitHub

A teammate will verify the pull request (PR) and merge the changes into master on GitHub

Entire team can do a git pull to pull these changes into master

Navigating branches

Remember, git checkout master allows you to leave a feature branch and go back to master

bash will warn you to add and commit your changes before it will let you leave a branch!

git checkout branch-name allows you to move from master or one branch to another...again, bash will make sure all changes are stored before letting you out of a branch

Tips

Keep it very very simple. No more and no less than what has been described. There is no need to do any rebasing or to get crazy with the endless commands that googling bash issues could lead you to

COMMUNICATE! COMMUNICATE! COMMUNICATE!

  • Let team members know if you put in a PR (Pull Request)
  • Let team members know when you merged a PR and it is good to pull to master

Work on separate parts of the app...definitely ensure you are in different files to avoid major merge conflicts

Be sure to avoid any manual uploads to Git Hub, these most likely will unintentionally go to master

Git Branching and Merging Practice Exercise

For this exercise you will need at least two people, Person A and Person B. Changes should not be made in master directly, but rather, each person should make changes in a branch and merge them into master.

  1. Have Person A create a new project, create a Git repository, and add a .gitignore file. Next, they should perform an initial commit and push the code to a new GitHub repository.
  2. Person A should go into the Git repository's "Settings" and add Person B as a collaborator under "Collaborators & teams".
  3. Person B should accept the invite via email (or via the sharable link from Person A).
  4. Person B should copy the link under the green "Clone or download" button on the repository's main page. Person B should now run git clone [url copied from the repository]
  5. Be sure to run the git clone command wherever you would like the folder to be created on your computer. For example, if you run the git clone command in the ~/source/repos/Projects directory, the project folder would be created at ~/source/repos/Projects/[ProjectName]
  6. Ensure Person B navigates into the project directory by running the cd command. For example, if you ran your git clone command in the ~/source/repos/Projects and your project was called GitBranchTest, you would then need to run cd GitBranchTest to navigate to the project directory.
  7. You can verify you are in the project directory if you see the branch name at the end of the directory name in the console like the following: ~/source/repos/Projects/GitBranchTest (master)
  8. Person B now needs to create a branch by running git checkout -b [newBranchName] Person B should make a few small changes, and commit those changes locally.

  9. (Optional) If Person B wants to add their changes to GitHub, they can run git push -u origin [newBranchName].

    NOTE: By using the -u flag the first time you push a branch to GitHub, you create an upstream (tracking) reference that automatically links your local branch with your remote branch. Future pushes are "argument-less" and can therefore be accomplished with a simple git push.

  10. Once Person B is done with their changes, they need to merge them back into master. First, they should checkout master with git checkout master. Then, to merge their changes into master, they should run git merge -m "[merge message]" [newBranchName]
  11. Remember, when we perform a merge, we are merging the changes into the branch we currently have checked out. You can kinda think about us bringing those changes into our currently checked out branch.
  12. With their changes merged in, Person B now needs to update origin. Before running a push, you should run a git pull to make sure you have the most recent code. Then you can update origin by running git push
  13. Person A now needs the most recent changes in master. First, they need to have the master branch checked out by running git checkout master. To get the most recent changes, they can run git pull. If there are more than 2 people working on the project, everyone can run this step now to ensure all are up-to-date.

Additional:

You can repeat these steps, alternating who is creating a branch and adding changes until you feel comfortable with the process.

You can also reuse any of the already created branches. You should first checkout the branch, make your changes, commit, and follow the same steps from there.

You can use the "Network" graph under the "Insights" tab on the GitHub repository to help verify the state and relationship of the different branches.