- Explain what a branch is in git
- Create, merge and delete branches on local and remote repositories
- Describe how branching and merging allows for collaboration during development
- Describe Github Workflows using issues, branches, and pull-requests
- Resolve a merge conflict
Quickly review the basics of git:
1. What is the purpose of git? How does it differ from github?
``` Git is a version control system allowing us to easily track files, manage changes, and move between versions. Github is a web application that hosts remote repositories and allows developers to easily host and share code. ```2. What command is used to start tracking a directory? What commands record the changes that occurred in the tracked directory?
``` 1. $ git init - create empty Git repo 2. $ git add - stage file(s) for commit 3. $ git commit -m "commit message" - commit staged files ```
3. What's the difference between a fork and a clone?
A fork is a copy of a repository on github, a clone is a copy of a remote available locally.
4. What commands are used to share changes (commits) between local and remote repos?
``` 1. $ git remote add - add remote repo 2. $ git push origin master - sync remote repo with local 3. $ git pull origin master - sync local repo with remote ```
Say you are working on a paper. You’ve gotten a first draft out, submitted for review. You then get a new batch of data, and you’re in the process of integrating it into the paper. Halfway in, however, the review committee calls you up and tells you that you need to change some of your section headings to conform to format specifications. What do you do? 1
Take a minute to brainstorm some options for what could be done here, then share with your neighbor, and we'll share what we feel is important.
In Git, branches are a part of your everyday development process. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes. This makes sure that unstable code is never committed to the main code base, and it gives you the chance to clean up your feature’s history before merging it into the main branch 2.
Branches are incredibly lightweight "movable pointers" that help us as developers make experimental changes! A branch in git is just a label or pointer to a particular commit in a repository, along with all of it's history (parent commits).
What makes a branch special in git, is that we're always on a specific branch, and when we commit, the current branch HEAD moves forward to the new commit. Another way to say that is the HEAD always stays at the tip of the branch.
Terminology: HEAD is simply a reference to the current or most recent commit!
The diagram above visualizes a repository with multiple lines of development, one is the master branch, and the others are feature branches. By developing in branches, it’s not only possible to work on branches in parallel, but it also keeps the main master branch free from questionable code.
Q. Why is branching an important part of git?
Branches are useful for many reasons, but some of the most common ones:
- To allow experimentation. By switching to a new branch, we can experiment, and if the experiment fails, we can delete it and easily switch back to master (or another branch of our choice). If it succeeds, we can merge those changes into master.
- To allow work to proceed on multiple features (or by multiple people) without interfering. When a feature is complete, it can be merged back into master.
- To allow easy bug fixes on a stable version while features are being developed.
- "Branch Early, Branch Often": Branches are lightweight, there is no additional overhead associated with branches, so it can be a great way to organize our workflow
Now imagine that we have completed our awesome feature on its own branch and we want to bring those changes back into master, we now need a way to consolidate these two versions of our code base. The easiest way to do this is by merging the feature branch into the master branch.
Let's see what this process looks like visually:
Locally, all we need to do is check out the master branch and then run the git merge command to integrate our feature branch:
$ git merge <feature_branch_name>
Once merged, you can delete the branch:
$ git branch -d <feature_branch_name>
Remotely, we could easily merge our branch back into master through a PR and delete the branch on Github.
We are going to start with a brief tutorial. This is an introduction to branching.
- Do Levels 1-3. Stop at 4: "Rebase Introduction".
- Take your time:
- Read all the dialogs. They are part of the tutorial.
- Think about what you want to achieve
- Think about the results you expect before you press enter.
- Whenever you see/type
git commit, it may help to assume changes have been made and staged. Why else would you "commit"?
Please run this exercise using Chrome. It will not work propertly in Safari or Firefox.
git branch <new_branch_name>- create a new branch- ⭐
git checkout <branch_name>- switch to a specific branch (checks out tip commit and makes branch active) - ⭐
git checkout -b <new_branch_name>- create a new branch and check it out in one step git branch- list local branchesgit branch -rlist remote branchesgit branch -alist both remote & local branchesgit branch -d <branch_to_delete>- delete a branch- will not let you delete if branch isn't merged into another branch (i.e. would cause data loss)
git branch -D <branch_to_delete>- over-rides and deletes a non-merged branch - be careful!
- ⭐
git merge <branch_name>- merges<branch_name>into the current branch, creating a new merge commit in the process
From Github Guides
To Recap, in Software Development, Github is very useful in managing and tracking updates and changes to our code.
Discuss an idea for a new feature or any question about our project/application with our team and agree on what needs to be done.
An Issue is a note on a repo regarding some matter that needs attention. It could be a bug, a suggestion for a new feature, a question about the repo or code, etc! On GitHub you can also label, search and assign issues, which help with managing projects.
It can be useful to write the issue as short functional spec, documenting the requirements as user stories.
Issue for simple feature on Garnet
Create a feature branch off the master to work on this issue. Our branch name should have meaning to the issue we are working on.
$ git checkout -b [name of branch that solves issue]
Make changes/commits commits locally, then push your branch up to our remote repository
By making a PR, you’re requesting that someone pull in your changes and merge them into their branch. A PR allows you to compare the content on two branches, and all the changes or diffs (differences) are highlighted in green and red.
As soon as you make a change, you can open a Pull Request. People use Pull Requests to start a discussion about commits (code review) even before the code is finished. This way you can get feedback as you go or help from other developers/team members!
It's good practice to even make a Pull Request for branches in your own repository and merge it yourself to get more comfortable with PRs!
Many OSS projects request that you create pull requests from a non-master branch.
- Fork and Clone https://github.com/ga-wdi-exercises/git-tricks.
- Create and switch to a branch called
<your_name>_suggestion. - Add your own "trick" aka git command/functionality you just learned (or researched) about.
- Commit, and then checkout to master
- Merge changes from your feature branch back into master
- Push your master branch to your remote called 'origin' (your fork)
- Create a pull request from your master to the upstream (ga-wdi-exercises) master branch
PLEASE NOTE: Merging does not always go smoothly, but don't be scared!
Auto-merging <file_name>
CONFLICT (content): Merge conflict in <file_name>
Automatic merge failed; fix conflicts and then commit the result.
When we try to merge two branches (or commits from the same branch from a remote), changes may conflict. In this case, git will stop and ask us to fix the issues manually.
A ‘conflict’ occurs when the commit that has to be merged has some change in the same place as the current commit.
To do so:
- Locate which files contain conflicts using
git status - Open those files and fix the conflicts. (Look for the '<<<<', '====', and '>>>>' which will guide you to the conflict)
- Commit the fixes.
<<<<<<< HEAD:file.txt
This is the original text in your current branch
=======
This is the modified text
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
The HEAD is a reference to the last commit in your current checked out branch. Anything between <<<<< HEAD and ===== is the original code from your checked out branch, while anything beneath from ===== to >>>>>> are the changes introduced by the commit you are trying to merge
- Pair up with someone.
- Pick someone as the 'primary', and the 'secondary'.
- Create a New Repo
Primary Student Instructions:
- In your
~wdi/sandboxdirectory, create a new directory namedmerge-conflicts. - Initialize merge-conflicts as a git repository and create an
index.htmlfile - Work with the Secondary student to fill out the basic structure for the
index.htmlfile. -Include in theindex.htmlfile anh1tag with the content "Merge Conflicts", and aptag with something new you learned about today. - Create a New Repo on Github called
merge-conflictsand add this repo locally as a remote repo for your merge-conflicts directory. - Make sure to save and commit local changes and push up to the Remote Repo
- Add the Secondary student as a Collaborator (search github for how to do this)
Secondary Students Instructions:
- After they are added as a Collaborator, they should clone the same repo. Do not fork the Repo.
- Both the Primary and Secondary should make changes locally on the same "master" branch
- Modify the
index.html, including both changing theh1andpelements - Add and Commit Changes Locally.
- Merging commits:
- The Primary Student should push up their changes first
- Then, the Secondary Student should do the same and try pushing up their changes
- Merge conflicts:
- When the Secondary Student tries to push their commits, there should be merge conflicts.
- The Secondary Student should work locally (with the Primary) to resolve the merge conflicts.
- Once completed, commit and push up changes to the remote repo
- Pulling Changes:
- Now, the Primary student should pull down the changes from the remote repo and work to resolve any merge conflicts
Review Learning Objectives:
- Explain what a branch is in git
- Create, merge and delete branches on local and remote repositories
- Describe how branching and merging allows for collaboration during development
- Describe Github Workflows using issues, branches, and pull-requests
- Resolve a merge conflict
Quiz Questions:
- What is a feature branch in Git?
- How can you check what branch your are currently working in?
- How can you bring a new feature in the main branch?
- What is a conflict in git? How can a conflict be resolved?
From this point on, all homework submissions should be a pull request from a feature (or 'topic') branch, named <your_name>_solution.