My first question after they've confirmed that they have experience with Git would be if they are used to the CLI or a GUI. Some people using a GUI may not know the commands exactly but may be able to describe it well enough.
Thanks dude. Every other popular video is just rote "Command" -> "Answer". Really helpful just having a conversation about the meta of the version control-portion of an interview.
I've met some people who do not know git cli commands, but do know how git works. They're just using their IDE or some GUI thingy to manage their workflow. So not knowing git commands by heart is probably no reason to disqualify a person (which you wouldn't as you've said, but I just wanted to state that point). Edit: beaten by like a dozen people ;D
I do have a question. At the end of my training as a devops engineer, i was told that with no prior experience you are more than likely never to get a job. My question then from the point of an interviewer, who then employs the new grads? I was told to exaggerate my experience on my resume, even though i have none...what do you do? who then gives you a job? Can you share your perspective with me? I need a job but cant figure how to break this yoke. Thanks
I'm curious -- can you talk about your devops training a bit? I've never heard of a specific course, since devops as an idea covers so many different discrete skills and approaches. My view of DevOps gigs has always been that they basically hire experienced multidisciplinary people (solid sysadmin/infra experience with a knack for programming, or the other way around) with several years of professional experience under their belt already. Although lately the demand is so high that I have seen 'interns' hired straight out of school -- usually compsci students with a real interest in networking, linux, distributed systems, etc. My advice would be to start running and automating a bunch of infrastructure yourself, contribute to some open source web projects, and generally try to get production experience as an infrastructure engineer somewhere.
Hey man, I think in a previous video you mentioned that you use Emacs. What do you think is the way to transition through the text-editors? I'm looking to up my productivity with some of the Emacs packages and shortcuts.
Does it fall under "red flag" if I exclusively use git through my IDE of choice? Basically knowing the features but not necessarily the exact git-command for it, but the corresponding action in my chosen IDE.
Yep this is exactly where I am. I did learn all the CLI git commands a few years ago but have since got so comfortable with VS Code's git integration and GitLab on the remote repo end, I no longer even think about it. I guess the trouble is it's not very portable to other IDEs, but I suppose it wouldn't take me too long to brush up. But the other advantage of the GUI (GitLens in VSCode) is that it actively prompts you "hey sleepyhead, it's time to stage, commit and push, or no-one will be able to see your work!"
How not to do it: Branch the last Release, then manually apply changes from master that was directly committed. And only the change sets that were approved. FML
What SCCM client tool do you use? (Trick question. Flavor counts though) Your local copy is corrupted. How do you fix that (heh, yes GIT isn’t as sophisticated as M$ visual studio)? Otherwise, the finger gun is really cool.. for 2019
What if people use GUI tools for all the git commands? I mean i do use gui tools inside IDE for these specific purposes. I know that there are commands for command line but if one works in a DevOps environment, one might as well have IDE installed in which case most of IDEs do have in one form or the other a module / functionality / addon to communicate with a version control?
We use the git command line because the command line can be automated. Part of my work is prying people off their GUI, so that we can automate their process.
@@lambertlum1087 I would like to dig a bit more here: If you automate processes why do you require people to use command line? I thought that these things can be automated no matter if you use command line or gui tools (for example by using webhooks on gitlab)? But i can see why it would be easier if you for example make a cronjob calling a bash script full of git commands?
@@Flankymanga We want to pry people off their GUI because of various reasons. First, the GUI is not authoritative. Only the command line is authoritative. Second, documenting GUI interactions is not as straightforward as documenting command line calls. Third, automating GUI interactions is not as straightforward as automating command line calls. Fourth, they are engineers, not users, so they have no problems switching to command line, unless they are windows people. For windows people, we have to teach them extra lessons on linux, but they get it after a while. There are a few exceptions to using GUI, like graphical display of git branches, but otherwise everything ought to be command line.
@@lambertlum1087 well yeah i see your point. There are ways to automate even gui interactions - i used Autoit script is perfect for Windows environment. Its just that a i find it kind of time wasted learning git commands and their parameters only to be able to make what you already can do using a sufficient gui client investing no time at all to be productive. But i get it for practical automation git commands would be ideal - in which case i would dedicate two people (for the sake of redundancy and contingencies) to learn git commands to make bash scripts for example?
@@Flankymanga You can use Windows for now, but once you add servers, your servers will be Linux. In that case, there is only one lingua franca and that's command line. Linux servers don't have a GUI, so only the command line is available. DevOps is almost entirely command line. To be fair, I can't remember the command line parameters. I just write them down in a text file, and I copy & paste them when I need to start a Docker.
git is "new & hyped-up"? It's 15 years old and, comparing across version control systems, clearly superior. Not to sound elitist, there's just no competition between the systems. Git is king, and has much more advanced tooling possible, especially in the devops world.
Here's a git basics video I made -- I think there's a card in the video and a link at the end screen. I've also just added it to the description. Cheers! ua-cam.com/video/4SD6rWt9wUQ/v-deo.html
Surprised you mentioned gitflow but not trunk-based. It seems many high-performing teams practicing CD are using trunk-based over gitflow and merging straight to master.
My first question after they've confirmed that they have experience with Git would be if they are used to the CLI or a GUI. Some people using a GUI may not know the commands exactly but may be able to describe it well enough.
Thanks dude. Every other popular video is just rote "Command" -> "Answer". Really helpful just having a conversation about the meta of the version control-portion of an interview.
Some Qs: What is a merge conflict and how do you solve it? What are the reasons to use version controll?
love the direction of the channel.
I've met some people who do not know git cli commands, but do know how git works. They're just using their IDE or some GUI thingy to manage their workflow. So not knowing git commands by heart is probably no reason to disqualify a person (which you wouldn't as you've said, but I just wanted to state that point). Edit: beaten by like a dozen people ;D
A question I heard once - describe Git and GitHub relation
I do have a question. At the end of my training as a devops engineer, i was told that with no prior experience you are more than likely never to get a job. My question then from the point of an interviewer, who then employs the new grads? I was told to exaggerate my experience on my resume, even though i have none...what do you do? who then gives you a job? Can you share your perspective with me? I need a job but cant figure how to break this yoke. Thanks
I'm curious -- can you talk about your devops training a bit? I've never heard of a specific course, since devops as an idea covers so many different discrete skills and approaches. My view of DevOps gigs has always been that they basically hire experienced multidisciplinary people (solid sysadmin/infra experience with a knack for programming, or the other way around) with several years of professional experience under their belt already. Although lately the demand is so high that I have seen 'interns' hired straight out of school -- usually compsci students with a real interest in networking, linux, distributed systems, etc. My advice would be to start running and automating a bunch of infrastructure yourself, contribute to some open source web projects, and generally try to get production experience as an infrastructure engineer somewhere.
Question: When (not) to force push.
BTW: My favorite git thing is rerere :)
Hey man, I think in a previous video you mentioned that you use Emacs. What do you think is the way to transition through the text-editors? I'm looking to up my productivity with some of the Emacs packages and shortcuts.
One common question I have encountered is what is the difference between a merge and a rebase.
Does it fall under "red flag" if I exclusively use git through my IDE of choice? Basically knowing the features but not necessarily the exact git-command for it, but the corresponding action in my chosen IDE.
It wouldn't be a red flag for me -- knowing the principles is the important thing with a VCS system.
Yep this is exactly where I am. I did learn all the CLI git commands a few years ago but have since got so comfortable with VS Code's git integration and GitLab on the remote repo end, I no longer even think about it. I guess the trouble is it's not very portable to other IDEs, but I suppose it wouldn't take me too long to brush up. But the other advantage of the GUI (GitLens in VSCode) is that it actively prompts you "hey sleepyhead, it's time to stage, commit and push, or no-one will be able to see your work!"
Yeah when I learned about git first thing in my my was to move all of my project from dropbox to git
can we merge two braches into a master at a time?
which is the keyboard in the background?
comitizen is also sweet for a large developer base
How not to do it: Branch the last Release, then manually apply changes from master that was directly committed. And only the change sets that were approved. FML
What SCCM client tool do you use? (Trick question. Flavor counts though)
Your local copy is corrupted. How do you fix that (heh, yes GIT isn’t as sophisticated as M$ visual studio)?
Otherwise, the finger gun is really cool.. for 2019
What if people use GUI tools for all the git commands? I mean i do use gui tools inside IDE for these specific purposes. I know that there are commands for command line but if one works in a DevOps environment, one might as well have IDE installed in which case most of IDEs do have in one form or the other a module / functionality / addon to communicate with a version control?
We use the git command line because the command line can be automated. Part of my work is prying people off their GUI, so that we can automate their process.
@@lambertlum1087 I would like to dig a bit more here: If you automate processes why do you require people to use command line? I thought that these things can be automated no matter if you use command line or gui tools (for example by using webhooks on gitlab)? But i can see why it would be easier if you for example make a cronjob calling a bash script full of git commands?
@@Flankymanga We want to pry people off their GUI because of various reasons. First, the GUI is not authoritative. Only the command line is authoritative. Second, documenting GUI interactions is not as straightforward as documenting command line calls. Third, automating GUI interactions is not as straightforward as automating command line calls. Fourth, they are engineers, not users, so they have no problems switching to command line, unless they are windows people. For windows people, we have to teach them extra lessons on linux, but they get it after a while.
There are a few exceptions to using GUI, like graphical display of git branches, but otherwise everything ought to be command line.
@@lambertlum1087 well yeah i see your point. There are ways to automate even gui interactions - i used Autoit script is perfect for Windows environment. Its just that a i find it kind of time wasted learning git commands and their parameters only to be able to make what you already can do using a sufficient gui client investing no time at all to be productive. But i get it for practical automation git commands would be ideal - in which case i would dedicate two people (for the sake of redundancy and contingencies) to learn git commands to make bash scripts for example?
@@Flankymanga You can use Windows for now, but once you add servers, your servers will be Linux. In that case, there is only one lingua franca and that's command line. Linux servers don't have a GUI, so only the command line is available. DevOps is almost entirely command line.
To be fair, I can't remember the command line parameters. I just write them down in a text file, and I copy & paste them when I need to start a Docker.
git is "new & hyped-up"? It's 15 years old and, comparing across version control systems, clearly superior. Not to sound elitist, there's just no competition between the systems. Git is king, and has much more advanced tooling possible, especially in the devops world.
any tutorial suggestion on how to start using git?
Here's a git basics video I made -- I think there's a card in the video and a link at the end screen. I've also just added it to the description. Cheers! ua-cam.com/video/4SD6rWt9wUQ/v-deo.html
Surprised you mentioned gitflow but not trunk-based. It seems many high-performing teams practicing CD are using trunk-based over gitflow and merging straight to master.