Bitbucket with CommandLine 101

hello everyone today we are going to look at bitbucket for version control for development purpose bitbucket cloud is one of the free offering that is available there is github and get labs another remote repository which has feel free offerings to bitbucket now gives you a private repository where others cannot see your code with five developers for free so I would you can check it out in their website and create an account that's what I did for my personal reasons and also I used git to install it in my machine it is like something that you need to install in your machine you could have a Windows or a Mac or a linacs it doesn't matter you you would install the gate so that it can communicate to a remote repository like a bit packet or a git lab or github so I went ahead and installed get in my machine and I had a cloud offering of bitbucket account setup in get a bit packet so those are the pre requests for this training purpose so I have set it out personally so let's get started before we get started into pushing pulling the code or merging or resolving a conflict I wanted to show you what we I described earlier like in a picture so you have a machine where your gate is installed and then you have this remote repository in the cloud and then you use all these commands that I threw it all over my machine inside that box so if you see there is these orange commands and then there's brown commands I want to kind of differentiate that because some of these commands like when you run it it it commits the code into your local machine it you know it creates a branch in your local machine and some of the commands like talks to the remote repository so you don't have to remember all the commands and get you do have to only remember few commands which I will be going through and it's just handful of commands and I would prefer everyone to learn this command because it doesn't matter then what platform you're in which OS you are in which machine you are in as long as you do have a remote repository and I get installed you you can rock it like you can you know run this command and get the job done and so it's always good to know this and and the fun part is there's only like six seven commands you have to know on top of your head to get this ball rolling so I I would I would recommend you to kind of get used to it or put it in a notepad somewhere and use it once until you get used to it once you get too used to these commands you don't have you know it's a bread and butter of your life as a developer it helps you to you know work everyday using this command so let's dive into looking at this commands let's get started by creating a repository in the big bucket so I'm gonna click on the plus button I'm gonna say I'm gonna create a repository I'm gonna pick the project which is bitbucket demo I created a project already before this session so I'm gonna name this as bit packet with command line you can make it a public or a private repository I'm gonna make this a private repository in this case and I'm going to click on create repository so it created an empty repository you could have created a readme file when you created the repository but I did not and you can use the HTTP or the SSH that Vantage of SSH is if you're going to use this machine or any machine regularly for working I would say set up an SSH key I will have another video put how to do SSH key how to set up an SSH to talk to a bit packet repository but if you use HTTP you may need to type in the password each time which I don't like to whenever I am communicating so I already set it up in our churches SSH in my machine so I'm going to take the SSH command and I'm going into my code directory and this is where I'm gonna have this and also I'm gonna use Visual Studio code in order to do all this demo purpose this is one of the favorite IDE for all open-source developers nowadays one of the favorite at least I am little biased as I'm coming from a Microsoft background but you can use it for Java go no js' basic HTML dotnet Python rails on Ruby our language so any language you're thinking about you could use this and so I'm gonna open the folder into the directory but we didn't yet create the project so one of the cool thing for about the visual studio code is that it has a terminal at the bottom so you can type in all your crazy command line took tool at the bottom while on the top of your coding and this demo for this demo it's very useful because I would be able to show you as I change the code and check in and check out in one screen to walk through this demo so I'm gonna CD into my D Drive I'm gonna CD into my code I'm gonna clear the screen so that it it's on the top now what we are gonna do is like we're gonna clone the directory so we copied already the command as I showed you and then you're gonna paste it so once you paste it you're gonna clone this repository bit packet command line into my machine so I cloned it since I had the get already setup it didn't ask the password if you are doing through the HTTP it will ask the password each time so keep in mind that when you use HTTP it's gonna ask you every time there is a get around to go to get config and not to prompt it the better way is to use this as chess if you're gonna use this machine for a long time for your development purpose and it's much safer too so the next thing I'm gonna do now is that since it is cloned so I'm gonna open this folder now and gonna say it's like folder so just opened my folder and you know that it doesn't have anything in the projects so since we are gonna use the command line let me again open the command line here so now if you say git status it says that it's in a master branch and it has nothing created yet so in order to start this let's create a simple file called demo dot txt now this simple file I'm going to put some words here I like to eat Indian food so now the git status generally checks on the status so if you go to the command prompt again and say git status sorry I missed I did it says that it says that there is a file called demo text which got created and it's not it's been not fact or you know it's unstaged we call it as in order to stage them or track them you may need to add the project files using the git add command so I'm going to clear the screen again and then say git add and since there's only one file you could say git add demo dot txt or you could say demo get add dot which means it adds all the file as a developer you might be adding a multiple files I would encourage use to you you you to use the git add dot so that you can add all the files so I'm going to say get at all and now I am going to say git status now if you see that it turned the red turn cream in a pretty UI and it also says that it's it you know the funny file has been added and it's been staged or tracked the next thing once you're done with that the next thing you need to do is commit this is one of the important commands and gate whether you use any other tool generally the commit is very important as you're committing this code into the get now you are just dealing with get you didn't yet talk to the bit packet yet all you did so far even the commit the commit you are going to do get commit and this command and you're gonna send a message said saying that this is my first check in so all these commands you're still talking to get you didn't get I do anything with the bit packet yet so for example when you do that this gets committed to the get and if you check now the get status let me clear my screen get status it says that there is the key that you know nothing to commit working preteen so it's all committed now if you want to push it you need to push it up because this change that you just adding a demo text file and adding this text to it it's not there yet like if you have make a refresh here it's not here yet so so you still need to do few more steps to get it over there so the commands that we just saw is get status to always check the status where your code is and get add dot or whatever the file names are and the third command that we saw was git commit minus m and put them as agent all of this commits talks to the gate and makes a commit to the gate so now the next big step we are going to do is the demo dot txt file that we just added I'm going to push that in to the remote repository for example so I'm going to say git push and where am I gonna push origin master so what this means is that I'm going to push this gate into the master the origin is kind of the connection and say push it to the master in the remote branch so there's nothing here at so it's going to create a master branch it's going to push that code called demo dot text into the remote branch when we run this command so when you say enter so it's it if you see this it just connected to it and pushed your local master branch all the commits you add or the last commit into the remote master branch so if I go to the browser and now i refresh my screen voila the demo dot text is in the remote branch so we did two things now here if we scroll up through the commands to just reiterate we just checked on the status and then we then we went ahead and added the file so this file was not yet added when we checked the get status and then we added the file using the git add dot command and then the last command was the git commit command saying that we checked in this is my first chicken all these three commands did like a communication between your your code and your git and then to push the code you said get push and you said push it to this branch in in the cloud since it is already you cloned it it knows that it should be pushing this code into this repository in the cloud and it ended up in creating a branch called master and pushing your code this is how you would commit a code and push it to a branch let's now talk about how to create different branches and how to work with branches the reason you would have multiple Jace's when you're working for an enterprise organization there are different kinds of get flows or branches methodology branding modeling methodology that you could use but I'm going to use the most common and the standard practice by most of the enterprise nowadays so we are going to have basically three branches maybe it depends on if there is only one developer there would be a third branch called future one but you would have a master branch which is going to be your production code and then you're gonna have a dev branch which is going to be your development code and some people tend to work with the just two branches but my recommendation is that you would should create a third branch or how much our developers you have let's say you have ten developers you would have ten branches for each developer as a future branch because the bitbucket one of the good thing about bit packet is it has something called as pull requests so if you open this there's a concept called pull request where you can you know whenever you want to merge you know from your development branch from your future branch into your development branch you need to do a pull request so that someone can do a code review and make sure your code is good before it goes into your development branch so that the testing would be done in the development branch and the code would be pushed into the master branch I always recommend everyone to I kind of have that separation out so that it's much cleaner so it doesn't mean that other approach is bad it's just like it's different kind of way of creating branches and the more the developer you have it's better and also if you're using bit packet if you're going to try to use all the bells and whistles that bit packet has to offer you need to have like another branch so that you can do a pull request before you do a merge and ask someone to review the code before the merge happens so if you are more of a code review if your team is more about code review I would recommend to use some of this pull request and and and the code review process around it in most of the room now adays like did have good labs or any offerings that we have in cloud which is free or enterprise but kind of is becoming very basic to have pull requests so so the route we are gonna take as I said it's gonna be a master branch which is going to be a production code then you have a dev branch which is going to be your development code and then each developer has their future branch and then you will do a pull request to merge into the development branch let's get started by creating branches now so the first thing we are going to do here is going to go here I'm gonna clear the screen so that we can go to the top of this so now before we get working with the branches one thing I would like you to see is to see all the branches that you have you generate the command that you need to use is git branch so it says that you have only one branch and that's where it's pointing to now and it is the master branch so git ranch always gives you the list of branches that you have in your system so in order to create a branch generally you could use git branch and a branch name here or are there is another command which will be which I'll be showing little later so in the second example so let's create a develop develop branch like as I said let the master be your production code and let's create a develop branch now we created two branches let's check how many branches we have so it says you have two branches and it's still pointing to the master branch so I'm gonna clear the screen so that's little cleaner so since we are gonna work a lot with branches I'm gonna make this figure so that you can see it need so let's now check out into a branch what do you mean by check out so you don't want to work on a master branch so if you check on your branch you are in the master branch generally there should be no developer city in a master branch unless he is doing a hotfix which you need to create a hotfix branch from it so anyways you should be never on a master branch so in order to me to switch to this you should say get check out and give the branch that you want to go so now it says switch to branch dev now if you check the status of the branch it should now say develop branch because now you are in the develop branch since now you are in the develop branch I'm gonna show another way how to create a branch and check out so in order to do this in two two command so in this case what you did was if I scroll up you just created a branch and then you checked it out using this command so you did two things there's another way you can do so I'm gonna create a future branch as I said as a developer if you're working for an enterprise you should never be working on the development branch you'll be working in a future branch and it depends on where you're working and how you you're branching strategies are but I'm gonna in this example create a future brand but I'm gonna use a different command and I would prefer you to use this command versus the other comment because it does two things at the same time you can say git checkout minus B and then say future test one so that's my future branch that I'm creating what does that command does is it creates a branch and checks out into that branch so it does two things it does whatever you did those two command into one so it's better always to use this command so you see it switched it to this so it created a branch and switched to it if you want to check that what I said is what it is it shows the green one and a star means you're checked out into this branch let me clear my screen now again so that we can move on to the next one so I'm gonna create a dummy branch and I'm going to delete it okay so let's say I say get Brad and I'm gonna say demo delete branch so it should if you check on the branch now it should have created that branch so now I want to delete that branch which is which I did by mistake so the command for deleting a branch would be get branch minus te and give the branch name like like the you know to to delete whatever branch you want to which is demo delete branch so this branch got deleted and if you check the branch you should have only three branches so now if we worked with three branches now we know how how to create a branch delete a branch see the blister branch and also check out into a branch those are the few commands that we learned just now so as of now what we have done so far is that we have created cloned and committed created a branch and checked out into a branch these were the commands some of the commands we went through now we are going to look at fetch pull push which we kind of saw earlier how to push your code from your local machine into the remote thing and you already know what pull means you're pulling the code from the remote branch into your machine and then merge these are the last four important commands that you need to know there are other commands that you know it's good to know but these are the last I mean for commands that you know you know you would be not using the fetch and I will kind of explain at eye level what fetch and pull means fetch is a safe command it doesn't do a merge of the code it just pull if there is already commits made into the remote repository just pulls it down to your local machine it doesn't merge the code the pull is not a safe command it does two things it does get fetch and get merged together that's all what pull does it does too get get commands together so it fetches and also more just pulls all the code down and more just from your remote repository into your local machine if there is a code match that needs to happen so it is not a safe command but what I would do what I would say is that you would end up in using the git pull then git fetch generally I tend to use always the git pull as a developer and then you already learned how what get push means you're just pushing your local changes into your remote branch and get merged by the name it says be in the branch where you need to merge and say git branch into development would pull down all the development code and merge it into your branch where like a future branch that you're sitting on so these are the four important commands that you need to know and let's get into it and it you will better understand if you see walk through some of this with an example then it's very easy for you to understand that so now going back to our example let me clear the screen you get branch so now we are sitting in the branch called git future text one all these branches were created locally and if you go to remote and you try to see the source code now for our command there is only one branch in the remote repository because all we did was creating the branches in your local machine it doesn't mean that those branches are created in the remote repository so it's just one command you can just shake get you know push and then say enter so sorry now you need to get push whatever branch you want to push it up so in this case what I'm gonna do is I'm gonna push each one of the branches into the cloud so let's get started git push I'm gonna say origin future test one it pushed that so now I'm gonna say get checkout ever love inter so I want to clear my screen so that you can see what I'm typing now I am checked out into the develop branch and now I say get push you origin template you pushed what you had in the development to into the bitbucket so now when you go to the bit packet and refresh your screen you should see three branches that you have developed master and future and coming back to your visual studio you're going to work on your future branch so I would say git git branch future test one sorry I need to be checking out into it we already have the branch so I'm gonna just check out into this future branch so now I am checked out I'm gonna say git branch make sure I'm in the right branch yes I'm in the future brand let me clear my screen so I am in my future branch now I would like to make some chord changes as a developer you would be assigned some work making a code change so let's say I'm gonna say I also love eat Italian the end food so you made a change and you know now the routine you need to check on git status there's a change is made I want to say git add and you can now do two commands at one line by using this and operator so I'm gonna say and I'm gonna say git commit same SH Future one force check-in so you added a new future you are in the future brand you're adding and then committing those together at one command and then you can say git push you origin future test one so if you now go into your repository you should be able to see that your future branch has one more extra line of code that says I also allow to eat Italian food so like what next we are going to do is we just learn how to push and how to pull from the repository and I generally tend not used we don't tend to use the the fetch command as I said so let's now do a merge so let's say you're done with the development in your future branch and you're ready to merge into a development branch so you can have the testing started and this is very interesting because as I said one of the benefits of using boot packet is to use the pull request so you are now before even you do a pull request what I would recommend is to come to the screen and see this and there's a way to compare two branches so let's say you have two branches so you're going to compare your development and future and compare when you do that if you see the diff it will say that the a new line you know this line and this line are is the same but then there's a new line that got added which says it also I also love to eat Italian food so that's the demo brand so it kind of shows you what the new line is and kind of highlights you some of that ignore whitespace and you can just do some of these things so since there was white face it didn't show clean but this is much better it it shows you that you know the development branch here has a code of I like to eat Indian food and then if you see the future branch the code change to have this extra line of code so you feel comfortable as a developer you kind of compare that you can use this IDE to do some of these and once you feel comfortable you just come here and say I want to do a pull request so now you need to say from where to where you are doing a pull request from - - so you're going to do a pull request from your future branch you know if you're gonna do a pull request from your future branch try to merge your code in your future branch into your development branch so you need to shade that say that that I'm trying to merge my code from a future branch into my development branch and then you can put whatever you want saying that hello reviewer hello the viewer I would like you to review my code and see if it looks good and then you can pick the list of reviewer in this demo I don't have another user who could review my code I could have tried that but I'm gonna just assume that I'm gonna review my own code which is not when you are working for an enterprise you would not do that but for in this case it doesn't matter so and also you can say that once the pull request is merged you do you want to close this future branch because it's all emerged into the development branch and you have all the history so you do you want that future anyway so I'm not going to close it now because I might want to show a little more demo with this future so I'm going to leave that but generally in enterprise you're going to give and reviewer who on each to review and some mostly you're going to close the future branch if you are done with the development so for now for simplicity sake as I don't want to log in as another user I want to leave this as empty but I'm I'm gonna review my own code which doesn't tend to happen in an enterprise level set up so now it's now created a full request so like hypothetically if I am in the review where I would get let's say an email or you set up something I would log in and I go to this repository I should be able to see that there was if I was the reviewer there it would show one two whatever code you need to review you would click on it and click oh I need to review this court or actually I could have put myself as a reviewer let me see that if you let me do that so I'm gonna say for me you know it doesn't let me put me as a review well so yeah you may need to put someone else as a reviewer and they would be able to see that notification on their end for simplicity sake I'm gonna just say I'm gonna review my own code here so I imagine that another person would come in and I am NOT that been right since I might mean I am able to do everything but they would come in and say oh Praveen wants to okay they want to review this code let me go here and see oh he made some commits here okay that makes sense and then he would see the activities and he would see what he changed and stuff like that overall what he's trying to do and it shows all the code that got changed so I generally tend to say ignore white space so that you know if there's white space it ignores and says that this is the only new line that got added and then I was generally used to see this side-by-side so as a reviewer I feel very comfortable and I go on approve this once the reviewer approves it then I would ask another developer I would again since in this case I'm not doing that but once that is approved when I log out and log back in let's say in this example I log out and then I would log back in I come next day to my work I go in and I say I would see my pull request it would say that it got through so I can now merge the code so once the approval happens I generally don't recommend anyone to merge the code using this IDE because it's not that cleaner and especially if you're having rosal conflict if it gets into a very difficult for you to see the code and see compared to code it's very difficult in a browser in an HTML browser to kind of look and compare the code so I don't tend to merge the code unless it's a very simple merge and you know what you're doing then I would recommend you use this but otherwise I generally once this is done we will go back to our IDE generally to merge the code so let's see which branch we are checked out we are in the future branch and generally before you merge anything what I would recommend you to do is to put guilt always pull all the branches so that you pull everything up to date so when you say git pull all what it does is anyone who made commits into your repository if there are 30 people working on a project it pulls everything down it's like getting the latest from all the branches and I would recommend you to do that just to be safe at least for the branch you want to do if you want to just do it for the branch you are interested in in this case it would be the dev branch because you are the develop if you are the only developer in your future branch you don't have to worry but if you want to just do the pull from the remote on your the command is so at least I would recommend you to do this before you merge with the development branch so that any other commits that happen gets pulled down before you merge so now all you need to do is simple steps you do all you need to do is get merge and then say develop since you are in the Future branch you're merging in the development branch it will take everything in the development branch and merge it into your future branch so I would always recommend you to do this so that you get the latest code from the development branch into your local machine so that you always are up to date with your future branch so so you didn't have anything in the development branch to merge with the git branch with your future branch now because if you go to the repository and you look at the future if you look at the source code and go to your development branch you didn't make any changes so there's nothing to merge you just made a change in your future branch but the development branch has only one line of code so when you do this it's it's going to be fine because you don't have anything changed in the development branch but if you now want to merge your future branch into your development branch what you need to do is to get checkout develop so get branch let me clear my screen let's say get branch now I am in my development branch as I said always pull the or down and also do a merge with the development code like how we did before if you see we were checked out in the future branch and then merged with the development branch because I want all my latest code to be in the future branch before I merge my future branch into my development branch it's kind of like getting latest from the development branch into the future branch and then you are merging the future branch into the development branch since already you did a pull request saying that you want to merge your future branch into the development branch you can just go here and say git merge future test one so it went ahead and merged your future branch into the development branch now so if you go to the repository and check now your development branch it should okay let me go here and now we were in the development branch and then merge into merged our code from the future branch into the development branch oh we also need to push that even though we merge we didn't yet push it that's why we did not see it there so let me do that so origin so I'm gonna push it push my development branch because I just merged my future branch into my development branch now when I see this and get refresh so I mean go to my development branch and I'll go to my see all my changes came over so I know it's kind of a lengthy tutorial which is be important to I'm gonna go back and reiterate some of the important points yeah so we were in the future branch we added this line of code and we checked in and we were good and then what we did is we wanted to do a code merge into the and branch so we did a pull request by going into this and did a pull request saying that I want to merge my core which is in the future branch into the development ranch it went through an approval process someone approved it compared the code and they were fine letting you add this code into the development branch generally it's it's always very important to do a pull request when you go from bottom to top just keep that in your mind and you might have big get confused why are we merging twice so whenever you go from bottom to top right like whenever you go from for example whenever you go from your future branch into your development branch you need to do a pull request because that's a standard practice that someone checks in as a developer you do a code review and do that whenever you're merging the code from the development of future it's safer because you're not hurting the development or the master branch is just making bringing back all the changes in the development branch back into you your future branch which is always safe so that's why I let like when I did before this code if you have seen me what I did is I said git merge develop because I was in my future branch so I was sitting on my future branch and I said merge all the call from the development which is okay because all I'm saying is more all the if there's ten developers who put nuke or you need to get the latest from the development into your future branch so I just got the latest right so it's always okay to do that and one thing I did I should have done this before I did the pull request because it's safer that your code is latest and greatest I would I would recommend that you do this thing before you do the pull request in this example I ended up in doing after which is not a good practice I would say generally what I tend to recommend people is to do this get merge into development branch just before you know ten minutes before you do the pull request so that you know you have the latest in the development merged into your future so it's safe that you know you are very close to the development branch so I would recommend before even you try to click this button the first thing you need to remember is to go ahead and you know merge with development just to be safe to see that if there is any other developer then checked in you would get the latest and I didn't have that you scare that didn't have another developer I didn't ignore to do that in this demo but I would recommend you guys to do this so I'd you get the latest from the development branch before you do the pull request and someone does the code review and then do the merge from the development be in the development branch sitting on the development branch and say that pull all the code in the future branch into the development branch like how we did it like in this example so what we did was we moved all the future code into the development branch after the pull request was approved and the code review was done so that's the cool thing that we went through a whole cycle of almost code review pull requests you know getting latest from the develop you know when you are building working on the development and the future branch let's say take 10 days every morning when you come to office you would say or whenever you work and you feel like you need to be having the latest code you need to merge your you need to pull it down like take it from the dev and push it down to the future branch so that you have the latest code other developers checked in or maybe they might have added a library that you need to use so it's always good to do that every morning and then and especially before you do the pull request and then once you have ready to push your code just commit your code and do a pull request to your supervisor or whoever is reviewing the code the code reviewer and then let them review the code and give you command deny it then you may need to go back and record it and once they approve then you would be able to merge merge in down like in the example how we did like then you would check out into your development branch like what we did and then merge with the future branch so that you take all the code in the future and push it to your development branch so we went one big cycle now and we are pushed the code into the development branch as we are seeing here on on the bit packet a next thing we would be looking at merge with conflict and resource like you know having conflicts so that's an interesting topic that we would be looking next thank you let's move on to the next one next topic we are going to cover is resolve conflict so let's go to the IDE now so we are in the future branch now so let me switch back to the development branch so I'm gonna say git check out develop so now I am in the develop branch and I'm gonna go here and add a new file called let's say sample dot HTML so I'm gonna create an HTML called hello world so I'm gonna say h1 developer so let's say this was something developer one dead and he merged the code lets him merge the code from a future branch to the development branch so let's say someone did this court and they already merged something here right like the developer wrote came here and an added developer one added some added some awesome code it was it was then he did a pull pull request and the code was reviewed and it is in the development branch for the lack of time for the lack of time I'm just not going to do all those because we went through that be for so I'm just going to directly check-in into the development branch which is not advisable but for the simplest city's sake I'm going to just do that so I want to copy this because I might be adding the same code on the future branch with the developer tool so let's say git add I'm gonna know add two commands in the same line so I put an end and sign to do that and say add add new core bye so let me put it this way so developer one did pull request and code review and merge to death that's what happened when e this code comes here so let's assume that and I'm gonna push this change to the development branch in the remote repository so I'm gonna push this so if we want to make sure that it looks correct I'm gonna go to the development branch make sure that the sample dot HTML has whatever we did now step two is like let's i'm developer to i came early in the morning and it is always a good practice to do this so i came in the morning and what i should do is like i would be checked out in my future branch because i'm been developing for many days in this branch now i'm being working so hard for like let's say 10 days so i am in my future branch working on it so the thing is every day you come in the morning you should have to merge your future branch with the development branch because it's always a good practice so let me show this to you that you need to always take all the code that is in the development branch and push it to your future branch so that you have the latest code that other developers did a code review and checked in so it's always a good practice to do that every morning okay so for this use case now we are in this future branch let me create the same this future branch doesn't have anything so let's create the same sample dot HTML I'm gonna say HTML actually what I could do is like I could copy whatever we have here and put it over here and let's say since I'm developer - I will say developer to change change the core so let's say you went and this third line you just changed to something else so you're now your development branch and future branch is out of sync right let's say this is your change you made so you committed and added it future to change one let's say so you did add this to your future branch and make sure you push it so git push to your future branch just make sure that just to confirm that your changes are over there you could always go to your future branch and look at your code it's there so awesome so we have the code that we need now so any remember like as I said the future branch is different from the development branch on the line - now you came in the morning I'm gonna clear this out so you came in the morning you just need to say git pull all branches so that brings down everything that is committed by every developer in all the branches so you're cool now so you have everything there so now you say hey I am in my future branch I want to pull down everything in the development and merge it so you say git merge develop once you do that it would show this and it's so exciting to see this and it's I mean sometimes people think it's harder to resolve it's so easy you just need to understand and once you get used to you know what you're doing so it says that that the current headers which is the current commit is pointing to your future branch right it says head and it says this is what you have the current change but there was an incoming change that came from the development branch that says developer one added code now you could say so what should you do now so you could talk to the other developer one and say you know what I think my code should go or he should say I think my code or if you need to combine the code whatever you know the resolve is so you mean this is the visual studio ide has a lot of fun thing that would let you do lot of these and we aren't gonna get I mean let's say you are using a notepad all you would say is this so what you could do is that you would come here and say yeah that looks right so I'm gonna say I'm gonna take this out I'm gonna take this out and this out I'm gonna leave both the code changes in this so so both the code changes are good to go I added both the code changes and I like what I changed so I like to now check this end so now you say come here and say get status so it looks like both added it says you know you added your made both the changes so now I can go and do whatever I do regularly let me clear my screen so git add dot add git commit I'm gonna put in my message and say development so merged that okay double a merge developer one code with developer to code so so that's what you did you must only say git push and origin future test to so what you did is you just to reiterate what we did you just went ahead and pulled all the code from the development branch and merged into your future branch and and that this works perfectly fine this is how it would work so this is a very basic example of how would you resolve a conflict while you are in the development and I think most of the time this is how you will be like you'll be working on your future branch every morning you will come in the development branch and I mean whenever it is possible I would say not every morning so whenever it is possible pull down the cord from the development branch and merge it into your future branch so your current as your coding adding new code to your future branch so that your current with your development environment and this is the best way to resolve generally so that you are up-to-date in your branch so that when you do a code review or PR request you don't have any conflicts so one more topic I want to cover is the other way around so in this example what we did was we pull down the development branch into a future branch and we had a conflict but that is possible also that let's say you you you checked in all the code and did a PR request full request but the code reviewer did not do anything for a while and then and all of the sudden he reviews the code and he sees a conflict on the page in the bid packets website and he would come to you and say that is conflict resolve it so let's see that use case next though so the last use case is about like little more making it complicated with the Claude McCord merge so what we are gonna do is I already set up the data for here so if you go to the development branch and look at sample to HTML someone added this code did their code review and it's already there okay in the development but you are as a future branch you need a fresh air so in the future branch this is not there this file doesn't exist at all let me go ahead and add this so I'm gonna go here make sure my future branch it's H as the code I think I just added I might have not pushed it so I'm gonna say git status and it's there but see there's one commit which is not yet pushed to the origin future it says and you need to keep an eye on this so I didn't push that so let me go ahead and push it get push and it's a good example to review this once you make your code change and if you don't see it in the cloud it's because you didn't push it so I just let me go ahead and push the score change into the cloud into your remote repository which is bitbucket in our use case so now if you refresh this page it should show that you just added another line of code to the existing code which is little different from the development which has only one line so now let's say you said hey I want to create a pull request I just added another code so you're gonna go ahead and say I want to do a pull request from this to my development branch and that is I'm gonna say sample two dot HTML added one line of code so we just want to do it I'm gonna name it little fancy now future two sample tests to HTML changes so you need a pull request but the fun part was like the person who is supposed to do the pull requires when I'm sorry did the code review went for a vacation so he went for a vacation and what some one did was that someone went into your development branch and started making all sorts of changes right like they just added they just replace this whole thing let's say they did not like anything about this so they said that span developer one new new new changes in code so he just like made that change in the development branch checked it in committed it with a message it's like a future for and he did a pull request and code review done and he checked it in and get you know you pushed off he did the merge and all the fun stuff when it's now in the development branch so when you are when you are your person comes from the vacation and he says okay let me do this code review and he would say oh looks like there's a conflict see there's a conflict here and he's not liking it so he's gonna decline this and this is a good workflow so I'm gonna say I see four conflicts was in a vacation could not review in time please resolve conflict and then send it for reviewing so he just says you know sorry buddy I was supposed to review and you can also see what conflicts and give a command you know develop a one dated and these are the conflicts I seen you can get fancy with that but another day it's going to decline this saying sorry was in vacation vacation developer one changed some code so he's gonna say sorry about that I would like you to you know go and fix it so he ended up in declining it so as a developer you get an email I know it's little frustrating but it means this happens though so you go and see what's in the development branch okay this is the change and you check it out to see what's in your future branch and that's a change and then you say git pull all just make sure everything is pulled down get pull all and then once you have everything you would check out in your future branch and say git develop merge it with my development branch so that you know you resolve your conflict within your future branch before you do another pull request so I'm gonna do that it's gonna say oh you know what like this is what you had the developer is bring the developer one change this to something like this what do you want to do so I would say you know what like I would like to have the span not the head anymore and just I'm gonna you know delete all this fancy stuff that it adds to say what all came from which branches so I'm gonna do that and I resolve my conflict by now so I'm gonna just make sure that get status so it says yeah you did add all the rest you fixed it it looks like it was salted so you could now go ahead and say get mad dad and and get commit resolve conflict with developer developer one on line three shake it push origin future test - so I did push my changes and I did my part and then I go and say again to do another pull request or you could end up in approving the same pull request I mean it depends on what your company is following here so I'm gonna say I want to do this again to the development branch I say work with developer one and fixed all the conflicts so then you put the reviewer name and create the pull it requires and you should not see any more conflicts because we just resolved it so you should not see any icon and he would be able to say oh that looks perfect so this guy he fixed that and this is the one we were working on the second one I will remove ignore whitespace gonna see side-by-side this is a span I moved the span for that and I just added this line everything looked good and you would go ahead and approve it so now you its approved you can go here and again in this case you will check out get pull all and then you should be not checked out in your future branch you are you should be checked out in your develop branch if you if you know if you remember it right get check out develop branch because it branch I'll explain that again because you all be in your development branch now merging everything in future into your development branch so you're gonna say git merge future test - so that your development branch gets that changes that you made in the future branch so that's all you're done you

Channel: Praveen Raj

Views: 4,329

Keywords:

Id: s_tBZg6tGNY

Length: 63min 43sec (3823 seconds)

Published: Fri May 08 2020