Skip to content

Instantly share code, notes, and snippets.

@StevenACoffman
Last active May 3, 2023 05:40
Show Gist options
  • Save StevenACoffman/15b760426182499138a6ebba7074d9e2 to your computer and use it in GitHub Desktop.
Save StevenACoffman/15b760426182499138a6ebba7074d9e2 to your computer and use it in GitHub Desktop.
Git Me Out of This

Repo Rinse

This will blow away anything that is not committed.

git reset --hard
git submodule foreach --recursive 'git reset HEAD . || :'
git submodule foreach --recursive 'git checkout -- . || :'
git submodule update --init --recursive
git clean -d -f -f -x
git submodule foreach --recursive git clean -d -f -f -x

Keeping your master up to date

First off all, we need to know how to keep our master up to date. Do not use the standard Github workflow. Do not use the word merge ever. Do this instead:

git checkout master
git fetch origin
git reset --hard origin/master

Working on a feature branch

It doesn’t matter what name you choose for your branch but I recommend using the JIRA identifier since it makes it easier to keep track.

git checkout -b ARROW-1234

Go ahead and push commits to this branch. When you are ready to create a PR it is quite likely that other commits have been merged to master, so it’s a good idea to rebase to make sure there are no conflicts. I recommend reading this article about git rebase.

Run the following commands to rebase your feature branch. First we get our master up to date …

git checkout master
git fetch origin
git reset --hard origin/master

… and then we can rebase our feature branch and force push …

git checkout ARROW-1234
git rebase -Xtheirs origin/master

Note that force pushing a branch does not send a notification to people watching the PR so you will need to write a comment on the PR to alert reviewers.

Who's On First (re)Base?

If you rebase a branch feature_x against master (i.e. running git rebase master while on branch feature_x), during rebasing ours refers to master and theirs to feature_x.

As pointed out in the git-rebase docs:

Note that a rebase merge works by replaying each commit from the working branch on top of the branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.

For further details read this thread.

Conflict Resolution

Resolve easy/obvious conflicts At this point you may review each files. If solution is to accept local/our version, run:

git checkout --ours PATH/FILE

If solution is to accept remote/other-branch version, run:

git checkout --theirs PATH/FILE

If you have multiple files and you want to accept local/our version, run:

grep -lr '<<<<<<<' . | xargs git checkout --ours

If you have multiple files and you want to accept remote/other-branch version, run:

grep -lr '<<<<<<<' . | xargs git checkout --theirs

Recovering from an accidental merge

If, like me, you use git merge all day long in your day job, it is inevitable that you will do this when working on Arrow (thanks, muscle memory). It is possible to recover using this set of commands:

git checkout -b ARROW-1234-squash
git fetch origin master
git reset --hard origin/master
git merge --squash ARROW-1234
git commit -m "commit message here"
git checkout ARROW-1234
git reset --hard ARROW-1234-squash
git push -f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment