Skip to content

Git Commands

Rick Boss edited this page Apr 20, 2016 · 8 revisions

Hopefully this page will help you avoid this:

Drawing

Let's give it a try :)

Using Git and GitHub

We'll be using the branching model (modified a tiny bit) for our project on GitHub. In this model, everyone works within the same repository, but on different branches. Users should NEVER be working on branch "master", only on other branches. This allows users to make their own commits on branches, and all other users easily see it and compare. When it comes time to integrate these changes into master, the user simply goes to their branch on GitHub and clicks "Create Pull Request".

General Usage

Following are some tips for working with Git and GitHub. And by tips, I mean if you don't follow them you'll encounter serious grief when it comes to share your work with the rest of us in the project. It's best to get used to this format as it is what employers will expect to see (I have personal experience with this).

Branches

We've already established that you should be working on your own branch. Traditionally with branches on GitHub, after a branch is merged, it gets deleted. Just as commits represent a logical set of tightly coupled changes, so do branches. Therefore, when a branch is merged through a pull request, it's purpose is served and it should be deleted. So, name branches to describe what you're working on (i.e. user-profiles, create-projects, create-tests, etc).

Committing

As you're working on your own branch, you should be committing often. Generally, you should commit when you've made a significant change that can be encapsulated in one idea. Sort of think of it like a function - you don't want an excessive amount of things in one commit, just like you wouldn't in a function. Regularily committing will make it much easier for you to keep your branch updated with the master branch, and when it comes time to make a pull request to merge your branch, it will be trivial.

Common Use Cases

Following are some typical use cases and explanations of how, why, and when.

Get the repository

Use case: You are just starting out and are setting up the project.

  • git clone [email protected]:uidaho/squireproject.git
    • This will clone squireproject to a folder "squireproject" in your working directory.
    • The branch master is automatically checked out (checked out refers to the active working branch)

Working with branches:

Use case: You are starting work on a new feature, addressing an issue on the issue tracker.

  • Switch branch: git checkout [branch-name]
  • Create new branch: git branch [branch-name]
    • note that this creates the branch starting from the currently active branch
    • Also this doesn't checkout the branch
    • Shortcut: git checkout -b [branch-name] will create and checkout a branch

Pushing Changes

Use case: You have made some commits that you want to push to your remote branch.

  1. First, add all files: git add -u
  2. Next, commit those changes: git commit
  • type in a title, then press enter twice and type the description
  1. Now push your changed branch: git push origin [branch-name]

Pull Request

Use case: You have finished work on a feature, OR you would like an intermediate step to be reviewed by another team member. (This is all done on GitHub). Note: If your branch is not up to date with master, you will not be able to merge the branch and will need to go through the steps to update it (see this section)

  1. With your changes pushed to your branch, navigate to pull requests and click "New Pull Request"
  2. Compare master to your branch.
  3. Click "Create Pull Request".
  4. Fill out the information. Give it a descriptive title, summarize the changes you made in the body, add the appropriate labels, assign someone to review it (not necessary).
  5. When you are done, click "Submit Pull Request".

NO SELF MERGING I don't trust you guys to blindly self merge, sorry :( We'll be performing code review before merges that add non trivial changes!

Update Branch with Changes from Master

Use case: A pull request has been merged into master, and you want to update your branch with those changes! (Hint: this should be done regularly)

  1. If you have changes, stash them: git stash
  2. Checkout master: git checkout master
  3. Fetch to update all references for remote branches: git fetch
  4. Pull remote changes from remote master branch into your master branch: git pull
  5. Move back to your branch: git checkout [your-name-branch]
  6. Update your branch with all changes from master: git rebase origin/master
  • If you get an error saying "Merge Conflict", prepare for some fun. This happens when you've edited a file on your branch, that was also modified on the master branch. You'll need to resolve these conflicts. Here is a great resource on resolving conflicts. Don't hesitate to reach out to @boss2849 if you need help!
  1. Reapply the stashed changes, bringing your branch back to where it was: git stash apply
  • You can also encounter merge conflicts here, same game as in the previous point.

Remove References to Old Branches

Use case: You have been keeping your repository up to date, and as such it has a bunch of references to deleted branches. When a branch is deleted on GitHub and you update your repository, it doesn't remove your local references to those branches. You can see all remote references by doing git branch -a.

  1. Remove references to old branches: git fetch -p