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 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:
After all of this I can commit and push the branch to GitHub which will update the pull request.
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.
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.
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
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
editor = vim
in .bash_profile or .bashrc
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.