Skip to content

Instantly share code, notes, and snippets.

@DomiR
Last active June 27, 2017 11:50
Show Gist options
  • Select an option

  • Save DomiR/9125581 to your computer and use it in GitHub Desktop.

Select an option

Save DomiR/9125581 to your computer and use it in GitHub Desktop.
Git helpers

Git: how to merge my local, working changes into another branch

Since your files are not yet committed in branch1:

git stash
git checkout branch2
git stash pop

or

git stash
git checkout branch2
git stash list       # to check the various stash made in different branch
git stash apply x    # to select the right one

Move existing, uncommited work to a new branch in Git

Use the following:

git checkout -b <new-branch>

This will leave your current branch as is, create and checkout a new branch and keep all your changes. You can then make a commit with:

git add <files>

and commit to your new branch with:

git commit

The changes in the working directory and changes staged in index do not belong to any branch yet. This changes where those changes would end in.

You don't reset your original branch, it stays as it is. The last commit on will still be the same. Therefore you checkout -b and then commit.

How to update GitHub forked repository?

In your local clone of your forked repository, you can add the original GitHub repository as a "remote". ("Remotes" are like nicknames for the URLs of repositories - origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In terms of commands that might look like:

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

If you don't want to rewrite the history of your master branch, (for example because other people may have cloned it) then you should replace the last command with git merge upstream/master. However, for making further pull requests that are as clean as possible, it's probably better to rebase.

Update: If you've rebased your branch onto upstream/master you may need to force the push in order to push it to your own forked repository on GitHub. You'd do that with:

git push -f origin master
You only need to use the -f the first time after you've rebased.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment