Skip to content

Git Workflows

Jump to bottom
StephenChan edited this page Apr 6, 2013 · 13 revisions

The procedures/workflows on this page are merely suggested workflows for working with Git; there are many different Git workflows that are popular, so feel free to use whatever kind of workflow you like. Also, most of these workflows talk about working with Git from a command line interface. However, graphical user interfaces (such as the GitHub native app, or Git GUI) can accomplish mostly the same things.

Contents

Checking status

At any time, if you're not sure of the status of changed files, branches, etc., you can and should check the status of things with the following commands:

Updating your local repository

  • Update origin, which is your local copy of the remote/upstream repo: git fetch origin. If you get any output on this command, then there's something new from the upstream master branch, and you should proceed with the rest of these steps.
  • If you currently have any changes that you don't want to commit yet:
    • Stash your changes for now: git stash
  • If you currently have any changes that you just want to get rid of:
    • Revert those changes: git checkout -- <path to file>
    • Revert all of your changes (careful, make sure you really don't have any changes you want to keep): git checkout -- .
  • Say that the origin just got some updates on the master branch. We'll want to update the local master branch to get those changes, too. First, switch to the local master branch: git checkout master
  • Update that branch to origin/master: git rebase origin/master
  • If you were working in a different branch, say feature-1, and you want feature-1 to get the master branch's changes:
    • Change to branch feature-1: git checkout feature-1
    • Rebase that branch to master, so feature-1's commits get re-applied on top of the newest master branch: git rebase master
      • If a conflict arises between the upstream changes and your changes, git will say so. See the "Handling Conflicts" procedure.
  • If you stashed some changes earlier:
    • Get those changes back: git stash pop

Starting work on the code

  • First, follow the procedure on Updating. If you don't have any changes yet or you aren't working in another branch yet, then disregard those parts of the procedure.

  • Typically, it's a good idea to commit your work in a branch other than the master branch. Working in a branch other than master makes it much easier to merge your changes with origin/master changes from upstream. It's recommended to create a branch named after whatever you're working on, like "language-change-form". Here's how to create that branch, and simultaneously switch to that branch to start work: git checkout -b language-change-form.

  • Whenever you want to commit some changes, see the Committing procedure.

Committing

It's highly recommended to use an IDE (such as PyCharm) or a similar tool for committing changes. It will make reviewing changes much easier. However, you can also commit via git commands:

  • To pick files to commit: git add <path to file>
    • To undo a mistaken git add: git reset <path to file>
  • Make sure that your current branch is the branch that you want to commit to. For example, maybe you intend to commit to a branch called feature-2, instead of committing to master directly. In that case, git checkout feature-2 to switch to that branch.
  • To do the commit: git commit -m "Commit message here"
  • If you want to undo a commit, see here.

In general, it's a good idea to commit early and often instead of saving up for one massive commit. This can make it easier to merge your changes with any changes from the upstream, particularly if there are any conflicts.

Pushing

  • Check your status to make sure you don't have any indexed, uncommitted changes. If you do, commit, stash, or revert those changes, whatever is applicable.

  • Follow the procedure on Updating, first. You need to make sure you merge with any upstream changes (by someone else) before pushing your own changes.

  • Now, say your changes have been committed to a branch called feature-2, and you ultimately want to push the changes to the remote master branch, origin/master. You would first need to get your local master branch up to date with feature-2: git checkout master and then git rebase feature-2.

  • Now, your local master branch should have the changes you've made, and you can push them upstream: git push origin master

  • You can check that the push succeeded by going on github.com and visiting the repository that you pushed to.

Handling Conflicts

When you do a rebase to merge changes you made with changes someone else made, and the changes are in the same files, a conflict may occur. Git will tell you if there are conflicts during the rebase. Then, to resolve the conflicts:

  • Run a git status and see what's under "Unmerged paths."
  • Open each file under "Unmerged paths" to find which files are conflicted. Then, you have a few options:
    • a) Edit the file to resolve the conflict: Git will have automatically added symbols like <<<< ==== >>>> to indicate where the conflicts are, so find these symbols. Edit the file to incorporate both the changes you made and the changes the other person made (this may not be easy; contact the person who made the other changes if you're not sure). Once you've done editing, remove the conflict symbols and save the file (and test that your new code works, if possible; if not, then test after the rebase is done).
    • b) Just drop your changes and accept the other person's version: git checkout --theirs <path to file>.
    • c) Just drop the other person's changes and go with your version: git checkout --ours <path to file>. Obviously, check with the other person if you're not sure.
  • When there are no more files under "Unmerged paths," run git rebase --continue to resume the rebase. If more conflicts happen, then resolve them in the same way.

Deleting a Branch

Creating branches is useful for keeping your changes organized without working directly in the master branch. However, it's a good idea to delete branches that you've finished working on and have already merged into master, or branches that you no longer need for some other reason. That way, whenever you want to see a list of all the branches (either local or remote), you don't see a bunch of really old branches that you don't care about anymore.

To remove a local branch that you no longer need: git branch -d branchName

To remove a remote (i.e. pushed) branch that you no longer need, you can use: git push origin --delete branchName

  • The --delete option only works in Git v1.7.0 or later. Another syntax is git push origin :branchName, which works in Git v1.5.0 or later. Source

If you remove a branch that's not merged into the master "line", then you'll delete the unmerged commits. Before you do this, you should really make sure that the unmerged commits either:

  • consist of changes that are already incorporated into the master branch, or
  • consist of changes that you really don't need anymore.

To see the current branches that aren't merged into master, go here. Note that next to each branch, it says how many commits the branch is "ahead" of master. That's the number of unmerged commits in that branch.

Clone this wiki locally