There are plenty of websites about Git and its commands on the internet. This one will be plenty plus one. If you’ve read my previous post you probably know that I’ve switched from Git Flow to GitHub Flow lately. During that switch, I had to create and delete some branches using console commands in Git Bash. They were very simple commands which can be very quickly found on the internet. But I decided to write this post to have this commands archived for me in one place and maybe it would be helpful for someone to see live examples of these commands usage.
Latest versions of Visual Studio and continues integrations tools are quite well integrated with Git, so sometimes I haven’t been opening Git Bash for weeks. But at the moment I’m using it more often. Firstly, because integration of Team Services and GitHub isn’t finished yet and I don’t use any other continues integration tool. Secondly, I simply want to be more familiar with the console because there are still things you can’t do using GUI tools. Git Bush is simply more powerful.
As a quick reminder, when I started working on the GoogleTasksManager project I was implementing GitFlow as a branching strategy model but later I switched to GitHub Flow which is much simpler and more convenient for me. So firstly I had created develop branch according to Git Flow rules and later I had removed it because it wasn’t longer needed after I switched to GitHub Flow strategy. Below are commands I used then.
Creating a new branch and switching to it: git checkout -b <branchname>
(the command will create a new branch with current uncommitted changes)
New branch was created locally and then I had to push it to the remote repository: git push origin <branchname>
After I started following GitHub Flow rules, develop branch was no longer needed, so I deleted it. But before you are able to delete the branch you have to switch to another one.
Switching from one branch to another: git checkout <branchname>
Deleting branch: git branch -d <branchname>
Viewing all existing branches: git branch -a
In the example above the develop branch is still on the list of branches. So let’s remove local reference to deleted branch: git fetch -p
And finally, after the fetch the develop branch isn’t listed any longer.
As you know Git is the most popular version control system nowadays which successfully has superseded its predecessors like SVN, Mercurial and Perforce. Probably you’re also familiar with GitFlow which is a branching model for Git, created by Vincent Driessen. The model is a git branching and release management strategy that helps developers keep track of features, hotfixes and releases in software projects. The workflow needs a lot of commands to type and to remember, so there’s even the git-flow library of git subcommands that helps automate some parts of the flow to make working with it a lot easier.
master branch contains the latest production code that has been deployed, and versioned with appropriate tags for each release.
develop branch that gets branched off master and contains the latest code for the next feature that is being developed. For each new feature there might be lots of feature branches (always branched off the “develop” branch).
Beside the main branches, there are so-called supporting branches:
Beside those, there are supporting branches:
feature branches contain the development state for a single feature of the overall product (i.e. a user story). They are merged off the develop branch.
hotfix branches are branches for quick and severe bugfixes. they are usually branched off the master branch, fixed in the hotfix branch and then merged back in master and develop as well.
release branch is a branch for preparing the next release. No new features will be developed on this branch but rather it contains some last fixes (also bugfixes) and adjustments for going into production.
A picture is worth a thousand words:
I use GitFlow in my daily basis at work and I find it very useful. It really helps to track changes in the repository, especially in the team consisting of many developers.
When I started developing the GoogleTasksManager project I was wondering whether the GitFlow isn’t too complicated for me. Though there’s no team, I’m the only one who’s working on the project. Maybe there’s a better way of managing the repository than GitFlow in that case? After a quick research on the internet, I found that there’s another way, GitHub Flow.
As you can see on the diagram, GitHub Flow approach is much simpler than the previous one. There’s only one important branch master, which should be always stable and ready to deploy to the production at any time. Feature branches are branched directly from the master and merged back to it when the feature is ready. What’s important, the code should be deployed to the production directly from feature branch to check if everything works correctly there, before it has been merged to the master. So there’s no need to have develop and release branches.
I really like an idea of deploying to the production directly from the feature branch and to not have develop and release branches. I think that GitFlow would be over complicated for me at the moment. So, I decided to give GitHub Flow a chance and it’s been working very well for now.
This is how looked my Changes view after I had built the code:
It’s because I didn’t add .gitignore file and with the first commit, .vs folder went to the repository.
According to the documentation:
A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected.
In the .vs folder are stored project specified files which shouldn’t go to the repository, but I committed them and they are already tracked by Git. Now I have to add a .gitignore file to the repository and remove those files from there to not be tracked any longer.
Adding .gitingnore file in Visual Studio
Under Ignore & Attribute Files in Repository Settings click Add Ignore File.
After that .gitignore with predefined content will appear.
Pretty simple, right? As you can see above .vs directory is one of the ignored directories/files defined in the .gitignore file.
Removing files from the repository
Now it’s time to remove previously committed files from the repository but not from the file system, by using a command: git rm --cached -r
After this, I got rid of .vs directory and its content from the repository, and what’s more, it isn’t tracked any longer by Git.
After I have connected GitHub to Team Services it’s time to set up continues integration process. The way how to do that is described in the Microsft documentation. I’ll try to show my experience with it.
First I created a new build definition by choosing ASP.NET Core (PREVIEW) template.
The build consists of five predefined steps: Restore, Build, Test, Publish and Publish Artifact.
In the Repository tab, I choose the connection with GitHub GoogleTasksManagerConnection set up earlier. The default branch was set to Master and I didn’t change that.
You also need the trigger to run the build. It can be set in Triggers tab. I set the trigger to run the build after branch changes.
Finally, I ran the build using Queue new build button in the upper right corner.
After half a minute the build started and I was waiting excited for the result.
But then suddenly build failed…
I triggered the build two more times but without success. The build failed each time. I also tried to build the project locally on my local machine using the same commands as in the log message. Everything was working fine, so the code was fine. I started looking for the solution on the internet and very quickly I found the thread related to the exception from the logs on GitHub https://github.com/Microsoft/vsts-tasks/issues/3311. It turned out that Microsoft screwed up and after they had replaced JSON configuration file by csproj they haven’t updated the build definition on Team Services. Team Services still needs JSON file. According to the thread, there is a work around by creating your own build agent and uploading it to Team Services but I didn’t want to waste more time on it. I’ll be publishing the application directly from Visual Studio until Microsoft has fixed the issue.
When I was establishing the connection between the Team Services and the GitHub I hoped that I will be able to push the code to the Team Services and the Team Services will redirect it to the GitHub. But this doesn’t work this way. After I had pushed the code to the Team Services my GitHub repository was still empty.
My expectations were wrong. In fact, the code has to be pushed directly to the GitHub omitting Team Services. So what do we do now? I can try to simply remove the repository from Team Services and start a new one on the GitHub, or I can move the repository from the Team Services to the GitHub. The second solution seems to be more difficult. So I decided to try the second one.
Importing a Git repository using the command line.
First, create the directory to have a place for the cloned repository. Then go to this directory.
Next, follow the GitHub documentation and make a bare clone of the repository:
On the command line make a “bare” clone of the repository using the external clone URL. This creates a full copy of the data, but without a working directory for editing files, and ensures a clean, fresh export of all the old data.
What it looked like in my case:
Push the repository to the GitHub.
Push the locally cloned repository to GitHub using the “mirror” option, which ensures that all references, such as branches and tags, are copied to the imported repository.
During the push, you will probably be asked for your GitHub login and password.
After this step, you should have your repository on the GitHub.
And finally, last but not the least, clean up the mess.
Remove the temporary local repository.
And remove the repository from the Team Services.
Switching Visual Studio remote repository from the Team Services to the GitHub.
So the repository is on the GitHub but Visual Studio is still connected to the Team Services’ repository.
To change it to the GitHub, go to the Team Explorer Repository Settings and under Remotes click Edit and replace repository address with the one from the GitHub.
The last thing to do is to clone the repository.
Now Visual Studio is connected to the Team Services and to the GitHub repository at the same time. The Team Services is able now to do several things with the code like: build it, run tests, publish etc.
Unfortunately, the code stored on the GitHub isn’t visible in the Team Services.
At the end of my previous post, I mentioned that I’m going to use Visual Studio Team Services and a moment later I realized that I’m using the GitHub as a code repository and obviously these two tools don’t work together. Wait a second… but actually, they do. After I was looking on the Internet for some information about how to connect the GitHub repository on Team Services I’ve found the answer in the Team Services documentation page. What a surprise! Since the documentation differs slightly from how the Team Services currently looks I decided to describe it in detail.
It is possible to connect the Team Services to the GitHub repository in two ways:
using GitHub account
using a personal access token
I’ve chosen the first one (using GitHub account) and I’m going to show you this approach.
Documentation advises you to turn off pop-up blocker first. Of course, I ignored this advice and I got stuck later looking at the screen and waiting for something to happen. So I advise you to turn off pop-ups blocker before you start too. Here is how you can do this in Google Chrome.
After pop-ups are turned on you can start connecting the Team Service to the GitHub using GitHub account.
On the Code tab click Manage repositories link.
Then go to Services.
Click New Service Endpoint and chose GitHub.
In the Add New GitHub Service Connection dialog box, select Grant authorization, and then click Authorize.
In a new browser window, sign in to GitHub and follow the instructions to authorise Visual Studio Team Services to access your GitHub account.
After authorization, you should have new service endpoint added.
Now you should be able to work using the Visual Studio Team Services and the GitHub at the same time.
I’ve decided to write an application for Google tasks management because Google doesn’t allow to display them from different task lists at the same time. If you have only one list it’s not a problem. But if you have more of them like me then managing task using Google calendar is very inconvenient. I have an application installed on my mobile which allows me to see all tasks from different lists on one screen together but I can’t find any web or desktop application to accomplish it on my PC. So the main goal of the application is simple – to display all tasks whatever list they belong at the same time.
To achieve this goal there are some intermediate steps that have to be taken. These steps are:
set up a website in ASP .Net core technology
allows users to log in with Google account – this will be an application to manage Google tasks so Google account is required anyway.
display and manage Google tasks – I have to check if there are some ready .net libraries not to reinventing the wheel.
Sounds easy and it probably is, but I’m not familiar with web technologies. I have great experience in WPF but almost none in the web. That’s why I’ve decided not to set ambitious goals. I will be really happy if I achieve just what I described above.
Moreover, it is important to me that the application is available online from the very beginning. If there is continues deployment feature in Visual Studio Team Service (Visual Studio Online – an old name) <EDIT> I’m going to use it.
It’s my „Hello world” post and I suppose I should write a little about myself and this blog. So.. I like to eat Skittles, reading books especially fantasy ones and in the past I used to play Civilization game when I had time – so very rarely. By the way, I’m a software developer and work with .Net technology.
I’ve decided to write in English because I’m still improving it. I lack time like almost all people nowadays. That’s way I think combining writing a blog and learning English could be a good idea to focus on these two areas at the same time, therefore making better use of my time.
The project I’m going to develop during the contest concerns managing Google tasks. I’m planning to use variety technologies and libraries new to me or which are not well known to me, as possible. I’ll describe the project in more detail in future posts.
I’ve never planed to write a blog but I want to take part in the Get Noticed contest and writing a blog is one of its requirements. So we can say I’m forced to do it. Yep, life is brutal. Writing two posts a week will be the biggest challenge for me during the contest, so I’m curious whether I will be able to fulfill this requirement. I don’t even post anything on Facebook or on any other website. My only activity on social media was to wish someone happy birthday a few times.
Fortunately there is approximately one thousand participants and there is a chance that my blog wouldn’t get noticed. If you somehow got here feel free to write a comment even if you want to correct my English. It would be great and it could be in Polish of course.