Tag Archives: Git

Git: Move accidental commit to new branch

Sometimes I forget to create a new feature branch, and accidentally commit to master. Keep having to look up how to fix it…

# From master, create new branch, which will include the accidental commits
git branch feature/foobar

# Move master HEAD back, which will remove the commits from there
git reset --hard HEAD~1

# Checkout feature branch, where the commits should still exist
git checkout feature/foobar

Heroku deploy sub-directory

Going through a couple of Udemy courses, and figured it was nice to keep all the code I wrote while doing them in a single github repository.

Was working nicely until I started the Node with React where part of the course is to deploy the app to Heroku which wants a full repository pushed to a certain git repo it creates for deployment. But in my case the app I want to deploy is of course a sub-directory…

Turns out there’s a git command called subtree one can use here:

# Setup
heroku login
heroku create

git remote add heroku/some-name https://git.heroku.com/{created-heroku-app-id}.git

# Deploy
git subtree push --force --prefix path/to/app heroku/some-name master

The subtree command needs to be run from the top-level directory of the git repository, but one can add a script command to the apps package.json, for example like this:

{
  "scripts": {
    "deploy": "cd ../../.. && git subtree push --prefix path/to/app heroku/some-name master"
  }
}

Unfortunately, subtree push doesn’t support --force, but a workaround for that is running it nested like this:

git push heroku/some-name `git subtree split --prefix path/to/app master`:master --force

Which unfortunately doesn’t work on Windows… but you can do it in two steps instead:

git subtree split --prefix path/to/app master
git push heroku/some-name {id-from-previous-command}:master --force

Stop Git from messing with my newlines

I’m sorry, but I just hate when Git is messing with my files… That’s just not its job!

warning: CRLF will be replaced by LF in …
The file will have its original line endings in your working directory.

Local fix

To fix it on your computer, set core.autocrlf to `false.

# This shows what it's set to now, and where
> git config --show-origin core.autocrlf

Then either edit the file manually, or do one of the following:

# System level (might disappear with git upgrades?)
> git config --system core.autocrlf false

# User level (probably preferred)
> git config --global core.autocrlf false

# Repo level (no point, use .gitattributes instead)
> git config --local core.autocrlf false

Shared repository fix

For shared projects, others might not have set this or even want to set this, so to prevent issues there, creating a .gitattributes file at the root of the repo with the following contents should fix things:

* -text

Source: How to express core.autocrlf = false with .gitattributes

Renormalization

For already messed up repos or working-copies, after changing core.autocrlf, you might be able to renormalize the files one of the methods described in this answer on StackOverflow.