VS Code Tip: commit part of a file

A cool feature of Git is that you can stage/commit some of the modifcations that were made to a file while leaving the other parts unstaged.

This is nice when you’ve made several changes and need to commit one of them to fix something asap.

You can use this Git feature right from VS Code. Select the changes you want commited by clicking the change indicators in the gutter.

selectChange

Stage the change using the + icon.

stageChange

You can then commit it normally. You will see your other unstaged changes for this file under the CHANGES header.

commitChange

Shell Script to update master

I was tired of always typing in the same commands to update my GitHub forks so I added this small shell script in /usr/local/bin (so it’s accessible from everywhere):


git fetch upstream
git merge upstream/master
git push origin master

So I can update my master branch quickly. I always work in feature branches so the merge from upstream is always a fast forward.

I named it update-master. Don’t forget to chmod 755.

Updating pull request branch with changes from upstream in GitHub

I don’t know if it’s the most efficient way but here’s one way of dealing with updating a pull request from a personal branch after upstream/master has been updated.

I update my origin/master:


git checkout master

git fetch upstream

git merge upstream/master

I switch to my local branch:

git checkout local-branch-name

“Pop” the PR commit back into unstaged:

git reset HEAD^

This will remove the last commit (I usually rebase all my PR commits into one before submitting a PR but you can also specify HEAD~x where x is the number of commits you want to pop back out) and put it back into unstaged.

And then try to merge master into the branch:

git merge master local-branch-name

If it merges cleanly I can proceed with a commit. If it can’t merge cleanly, I stash the unstaged changes, I merge and then pop the stash likewise:

git stash

git merge master local-branch-name

git stash pop

And then take care of the merge conflicts manually. You will get info on which files are in conflict by doing:

git status

After all of this I can commit and push the branch to GitHub which will update the pull request.

Improve your Git experience

With these Git setup tips

Cut down on tedious credentials typing

When you start to push to remote repositories on a frequent basis, typing in you credentials can get tedious. For example, my GitHub user name is gilles-leblanc, which is fourteen characters and my password is around twenty characters. Combine this with two carriage return and that’s a whole lot of typing.

You can cut down on this tedious typing in two ways.

First you can store your username for a remote repository service like GitHub in your .gitconfig file. When this is done, Git will use this username and stop asking you for it altogether. I prefer not to store any passwords this way tough. This could be a security risk in case of accidental commit of the .gitconfig file or someone could get read access to the file.

storing credentials in .gitconfig file

[credential "https://github.com"]
  username = gilles-leblanc

If you really want to store your passwords investigate encrypted .netrc files.

The second thing you can do is caching your credentials. The default cache length is 15 minutes, but you can set it to what you want (mine is five minutes).

setting up credential cache in .gitconfig file

[credential]
  helper = cache --timeout=300

You can edit your .gitconfig by hand or use the git config command to do it for you.

using git config

git config --global credential.https://www.github.com.username "gilles-leblanc"

git config --global credential.helper cache
git config --global credential.helper "cache --timeout=300"

Turn on the colours for more readability

Turning on the colours makes for a big change in readability, particularly when using git diff where you can scan for added and removed lines by colour.

Git output when colours on
git diff command with colour highlighting

Colouring is also applied on other commands like git log . You can turn on the colours either by using git config or by directly editing your .gitconfig file.

using the git config command

git config --global color.ui true

resulting .gitconfig file

[color]
  ui = true

Setup Git to use your favourite editor

Git can be configured to use your favourite text editor. The standard text editor will vary depending on your OS, distribution and installation. Mine was nano. While using Git isn’t a text editor intensive operation, using a familiar editor is great for writing multi-line commit messages and rebase scripts where you have to change several pick commands.

You can configure this in your .gitconfig or in your shell’s configuration files. Here is an example of both (using Bash for the shell).

in the .gitconfig

[core]
  editor = vim

in .bash_profile or .bashrc

export GIT_EDITOR=vim

Use Git and GitHub to store your Git dot files

You use Git and GitHub to track your source files, why not your dot files? Now that you have customised your settings, keep them safe in source control. Keeping your dot files in a Git repo will allow you to easily revert changes when something bad happens or just see when you changed a particular setting.

Hosting that Git repository on a service like GitHub (or BitBucket, Gitorius or others) will allow you to easily share and sync those files across different computers from anywhere.

I use a GitHub repository to store all my dot files. This is particularly useful for Vim files.

In case of emergency break out this link…

This one isn’t related to Git configuration, but I can’t talk about Git without mentioning this page here. On undoing, fixing, or removing commits in git, is a real life-saver when something bad happens. I have used it myself a couple of times when doing my first rebases on pending pull requests. Next time you realize you have just made a big mistake, follow the instructions on the site by following the hyperlinks.