git tag -l
git tag -d 0.1.0
git push origin :refs/tags/0.1.0
git tag -a 0.1.0 -m"0.1.0"
git push -u origin --tags
git tag -d 0.1.0 && git push origin :refs/tags/0.1.0 && git tag -a 0.1.0 -m"0.1.0" && git push -u origin --tags
I recently had to setup multiple SSH profiles for Github. The reason why I had this requirement as my work required me to have a Github account outside of my personal account. The machine I am using is used for both work and personal development. I needed both SSH keys to work. I had never ran into this before as I never had two Github accounts. Since you are not able to use the same ssh key between multiple accounts in Github I had to come up with a way for both to work together. This makes sense for security purposes that the key should only be identified with one account. The process to set this up was pretty simple overall but that is after you understand what you need to do. Understanding exactly what is needed can be tricky at least from the documentation I found online.
The first thing you need to do is create a SSH key pair for both your personal account and work account. They should be using different email addresses.
$ ssh-keygen -t rsa -C "your_personal_email@youremail.com" # follow prompts use defaults if you want $ ssh-keygen -t rsa -C "your_work_email@youremail.com" # specify new name for key
After that is done you should have a couple of keys. For example you could have id_rsa and id_rsa_work or whatever you called them. Add the proper SSH keys to your Github accounts following Generating SSH Keys – Github. The documentation there is really well done so no further explanation is needed.
So now you should be able to use each SSH account by adding it. Everything will work at this point but you will have to keep adding the ssh-add when you switch between accounts. If you don’t switch often this may be fine but it’s a really pain if you switch often. Also you tend to forget overtime why it’s broken all the sudden.
ssh-add ~/.ssh/id_rsa
The next step is you need to create an SSH config to handle the multiple accounts.
sudo vim ~/.ssh/config # add in the hosts
# Inside the file add the following
Host github.com-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa
Host github.com-work
HostName: github.com
User git
IdentityFile ~/.ssh/id_rsa_work
Save and close it out and that part should be all set. The next part is the most critical. If you have an existing repo go and modify your SSH string to add in the -work or -personal. This is whatever you named your host. Here is an example for my personal project.
git@github.com:[host-name]:[repo-name]/[repo-name]
If you are adding a new clone or new remote continue to use the same host name you set in your SSH profile. After you run the process it all makes sense it looks at the ssh config to determine which key to use.
One command that I find important when doing a Git rebase is.
git reset HEAD\^
This will reset your commit back during an interactive rebase and then you can do an add -p or whatever you want with the files. It really allows you to start with a fresh change set on that given commit. If you are not using ZSH you should but you don’t need to escape the carrot so it would look like this.
git reset HEAD^
I made a post a while back about Github Reliability and how I thought it wasn’t so great. Since that post I don’t think Github has been down. If it has been down it has been down very little and not noticeable in the everyday work environment. I have been very impressed by this. The reason why this post is coming up as over the last year I noticed Github being down often enough to notice. It seemed to happen right in the middle of the work day to.
I believe they have made great effort to improve their reliability. This could be a sign that they turned the corner and are now able to keep their service up and running at all times. Which is very impressive to me. See that they were having so many issues over the summer they have really turned it around. I feel it’s only right to post the good as I did post about the bad some time ago.
I was recently working on a Gem I created called Toolshed. The purpose of this tool is to turn everyday tasks into automated ones. At least to a certain degree. This will allow you more time to do the heavy lifting tasks. For example some of the functionality that this tool provides is creating a Github pull request, updating Pivotal ticket status as well as many Git more tasks. All of this would normally require you to go up into the sites interface click around and enter the data. As we all know that takes time and time is valuable. So down to the part that I had trouble with when I was creating tests for this tool.
I first started to create all of the tests locally and verify that they worked there. I had no trouble with this and everything appeared to be working. I was not getting any test failures. After creating a couple of them I wanted to see if I could get it working up on Travis CI. Travis works well with a ruby project plus since the Gem is open source it’s free. So I setup Travis and everything seemed to be working right. The first couple of runs seemed to pass without issue. Over the next few days I noticed that Travis was failing randomly. I would push up a small change and it would fail. I would run it again and it would pass using the same code base. It seemed random and a CI that has random failures is useless. The theory behind that is if errors happening randomly there they will also happen within your application. So I needed to investigate this further. Since I was unable to recreate the issues on my local machine I decided to try it out on a different machine. I created an ubuntu environment and started fresh. Once I got to that environment I was able to reproduce the problems I was having on Travis pretty easily. I was able to debug real time which helps instead of pushing new commits up to Travis.
What I noticed was that my Git commands were not finishing before it started the next one. So it would be doing a git remote update and then the next command would run before that finished. This would cause it to fail because it depend on remote update finishing first. So I had to create a solution for this and here is that solution.
until (system("git remote update"))
sleep 1
end
This will sleep and wait until it hears a response. This will now wait for each command to run in it’s specific order. I have now tested it out several times on Travis and am no longer having this issue.