Hey everyone and welcome back to another blog post. Today’s topic is source control and how does one go about pulling a particular file, or a collection of files within a directory, from a remote branch into your local branch. Thankfully the answer is rather straight forward and not so complex as I thought it would be.
First thing you want to do is make sure there are no uncommitted changes in your repository. Then, even though not necessary, pull the latest changes by running this command.
git fetch
Then let’s say we have the following structure in the remote branch.
root
foldera
file1
file2
folderb
file3
file4
file5
If you’re interested in retrieving folderb and all it’s contents then execute this command.
git checkout origin/master -- folderb
Otherwise if you’re interested in just file3 then execute this command.
git checkout origin/master -- file3
That should do the trick!
For the sake of better SEO ranking I’m going to shamelessly include a couple of internal links, so in case you’re having issues splitting a big pull request into small ones then click here. Alternatively if you want to remove a specific file from a pull request then click here.
So this week I was having a bit of a slow morning, and when creating a new pull request I did not realise that I included an already existing file by mistake. Thankfully, I realised that I was about to merge unwanted changes before the reviewer got a chance to look at my PR, but I was now facing another issue. Is there a way to remove just one file without deleting the whole pull request?
After a quick search I found a solution that suits my problem.😎👌
Check out on the branch that has your PR, replace the file with an unmodified version (of the same file) from a different branch (in my case master branch), commit the changes and finally push to the same PR. Git commands, to be typed in Visual Studio’s Package Manager Console, below.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Git has been integrated in Visual Studio’s Team Explorer for quite a few years now, and personally I think it does the job. Common features have been integrated in a nice user interface and honestly that’s what I tend to use on a daily basis.
Having said that there are still scenarios where I need to type Git commands, such as pulling from a remote branch (if this feature was integrated in Team Explorer I never found it ¯\_(ツ)_/¯ ). That’s when I start up a command line instance from within Visual Studio itself, and I do this from within the Manage Connections screen as below.
It’s great, it works and it does the job, but is it convenient? Not always. I needed a more efficient way and after a bit of research I discovered that the Package Manager Console which is inbuilt in Visual Studio, and which is also used to manage your Nuget packages, can be used as a Git command line. Fantastic, I don’t need to open a separate window each time. I just need to have the Package Manager Console window open at the bottom of Visual Studio along with the Error List and Output windows.
If you want to take it up a notch from here what you can do is install PoshGit. Taken from GitHub “posh-git is a PowerShell module that integrates Git and PowerShell by providing Git status summary information that can be displayed in the PowerShell prompt“. In my own words, an IntelliSense for Git.
Other options include BuiltinCmd and Whack Whack Terminal, extensions which you download from the Marketplace and install in Visual Studio.
Have you ever submitted a pull request(PR) but it got rejected straight away because it’s too big? Well I did and you’ve got to give it to the reviewers, huge PRs are a pain in the ass to review. There are various reasons why PRs should be short and concise but I will not cover that in this blog. Instead I will share with you how I managed to split a big PR (it was some 2500+ new lines of code) into smaller ones (I ended up with some 7 PRs).
Let’s say that the project we’re working on has it’s main branch master, and a new feature branch was created based on that and we’re going to name it feature/cool_new_feature_branch. We then created a new PR, called it some_huge_pr, submitted it and it is now pending and active since you’re told that you need to break it down.
In my particular scenario I was working on an new web service and it also depended on other web services, where I also created some endpoints or done some changes, and therefore for me it was easy to break it down by feature (or web services in my case). Find a sensible way how to break down your work and plan ahead how you are going to split your big PR. Find common grounds and create small groups of code implementations.
Step 1
First thing we want to do is compare the differences between master and feature/cool_new_feature_branch. In your Git terminal type this command.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This command compares all the changes between master and feature/cool_new_feature_branch and creates a new file called huge_pr_patch_file in the root directory of your current Git connection. If you had to actually open this file you’ll find the code you wrote, in my case C#, with added Git syntax.
Step 2
Let’s switch back to master branch and create a new branch that will have just a portion of the new code. This will eventually be the new PR so we need to start thinking per feature here.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Whilst checked in on the new branch run the following Git command to apply all the code changes from feature/cool_new_feature_branch to our new branch feature/first_small_feature_branch.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
You should now be able to see a lot of changes in your new branch. From here stage any files you want, commit and push them. For this particular step I like to use Visual Studio’s Team Explorer tools. It displays all the files in a tree structure, and you can use Visual Studio’s file comparison feature. Then again, this is just my personal preference.
Step 4
After committing the staged files, we can stash all the remaining changes (that we will not commit in this branch) including any untracked files. From here proceed to open a new pull request as you normally would.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Repeat steps 3 and 4 until all the code is committed and submitted into new smaller PRs. When splitting PRs be sure to include any code dependency and/or references so that the code compiles. If, when splitting, you notice that some of your code relies on code that is in another branch then create the new branch from that one. If not create the new branch from master.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In conclusion, I’m not going to lie, I’ve only used this approach once (just last week) and I’m no Git expert. Is it possible that there are more efficient methods or even tools that do the job? Yes, I wouldn’t be surprised but this method worked for me and next time I’ll face the same issue I will try to use this method again.
I hope it’s useful for you too and if you run into any issues feel free to drop me a message to fix this post. The one thing worse than not finding a solution online, is finding a solution that doesn’t work!
It's not a bug, it's a feature 