At first I hated Git, I tried to use it and lost an entire day of work. But after learning the basics and work on my own projects I did the opposite: saved my project thanks to Git. Still, I'm scared of working on it on a big corporate project. It's like you read part of my mind with this video. Thank you so much. 👏👏👏
Inspired by Travis journey and started learning DevOps. I completed 1.Liux Administration (20hrs) 2.Bash Scripting (17hrs) Right now learning Git (22hrs) Next will b AWS. (Will prepare at the level of Solutions Associate Architect)
Thank you for this video. Always appreciate such videos where people sharing knowledge. In a large team, tracking commits that comes from merging is not a trivial thing. The history shows like circuit diagram. While rebasing might be hard as you have to go throw every conflict in those commits and resolve them, but the outcome is a clean git history as rebasing will create new commits hashes.
Coming from other VCS systems, I have to admit that I found GIT a bit frustrating to learn. Git has more commands, and they work differently. I suppose it's partly because GIT maintains a local repository on the local machine so you can work off-line--including pull, commit, etc. So, I think my learning curve was more about making sure I understand the terminology...that is, exactly what commands do what. This is a great video to help understand that. And I love explanations that say WHEN or WHY you would use the different commands--something that's not always clear in the docs. Also, the tip about using VS Code to do ALL git functions is great. I suspected that was true, but I wasn't sure. Thanks for making this video!
CLI vs UI has been a rivalry since graphical user interfaces exist... there is no right or wrong, no work flow optimized way of doing, there is your preferred way and that's it. Do it however it comes natural to you.
These tips are awesome, would have been helpful when I started my job earlier this year that first dipped my toes into DevOps but it's still helpful to me now!
Here is another one: You forked an opensource proj, after your change is been accepted and merged, your forked repo is still saying that "you are N commits ahead," to sync it with the upstream you can run: git checkout master git reset --hard upstream/master git push --force
"Don't work about Git rebase, especially if you are working on a large project with lots of developers." Great advice, unless those in control of that large project dictate that everyone shall always use `rebase`, never `merge`. 😉 That was the case for my last major client. #fwiw
For the tip#1, when you want to make sure you fetch all the changes happening in the remote master you can just do "git pull origin master" in the branch you are working. This is straightforward and does not involve more steps. Is there any disadvantage of doing this?
exactly what I was thinking bro. I was about to ask the same thing, good thing I saw your comment first. But still curious as to the pros and cons of both workflows.
Everywhere I go , I see version control. I'm fine with everuthing else but, that thing scares me especially when you involve pipelines for continuous integration and development.Every second feels like I might screw up. Thanks for the video.
Any one use Tower to manage git? It is a GUI app that allows robust git management. Anyone use it before? I like it but I am looking for additional thoughts.
@@TravisMedia question was If, as the first step, a merge from the remote/main would be possible. So Like: 1. merge from remote/main into branch 2. push branch to remote Negative would be that at this point my local main is not updated.
Nay... you simply can't beat keyboard centric (touch type) workflow with pointing your mouse at 598 different buttons just to do simple actions. And imagine... there are custom programmable keyboards out there to bake in entire macros. So... don't talk about GUI superioty in 21st century. And your RSI will thank you later about avoiding mouse.
![Coheed and Cambria - Searching for Tomorrow [Official Video]](http://i.ytimg.com/vi/hDsYGLbmadg/mqdefault.jpg)
At first I hated Git, I tried to use it and lost an entire day of work. But after learning the basics and work on my own projects I did the opposite: saved my project thanks to Git. Still, I'm scared of working on it on a big corporate project. It's like you read part of my mind with this video. Thank you so much. 👏👏👏
Inspired by Travis journey and started learning DevOps. I completed
1.Liux Administration (20hrs)
2.Bash Scripting (17hrs)
Right now learning Git (22hrs)
Next will b AWS. (Will prepare at the level of Solutions Associate Architect)
Your channel is a gold mine. You have helped and motivated me to learn. Thank you ❤
This has helped me a lot. Git used to be my personal horror I even wanted to quit my studies just for this reason many times
Thank you for this video. Always appreciate such videos where people sharing knowledge. In a large team, tracking commits that comes from merging is not a trivial thing. The history shows like circuit diagram. While rebasing might be hard as you have to go throw every conflict in those commits and resolve them, but the outcome is a clean git history as rebasing will create new commits hashes.
Not great when others are working on the branch.
Coming from other VCS systems, I have to admit that I found GIT a bit frustrating to learn. Git has more commands, and they work differently. I suppose it's partly because GIT maintains a local repository on the local machine so you can work off-line--including pull, commit, etc. So, I think my learning curve was more about making sure I understand the terminology...that is, exactly what commands do what. This is a great video to help understand that. And I love explanations that say WHEN or WHY you would use the different commands--something that's not always clear in the docs. Also, the tip about using VS Code to do ALL git functions is great. I suspected that was true, but I wasn't sure.
Thanks for making this video!
CLI vs UI has been a rivalry since graphical user interfaces exist... there is no right or wrong, no work flow optimized way of doing, there is your preferred way and that's it. Do it however it comes natural to you.
I like git graph too
These tips are awesome, would have been helpful when I started my job earlier this year that first dipped my toes into DevOps but it's still helpful to me now!
Thanks for the tips Tavis. Those encouraged me to keep exploring.
Here is another one:
You forked an opensource proj, after your change is been accepted and merged, your forked repo is still saying that "you are N commits ahead,"
to sync it with the upstream you can run:
git checkout master
git reset --hard upstream/master
git push --force
Is that copilot completing your commands on the terminal? That's pretty neat!
this really interested use Cases , thank you for sharing
please please please make a detailed video of merge conflict
Thank you for sharing! That was a great video!
Straight to the point 👍
Another great video, thanks Travis!
"Don't work about Git rebase, especially if you are working on a large project with lots of developers."
Great advice, unless those in control of that large project dictate that everyone shall always use `rebase`, never `merge`. 😉
That was the case for my last major client. #fwiw
For the tip#1, when you want to make sure you fetch all the changes happening in the remote master you can just do "git pull origin master" in the branch you are working. This is straightforward and does not involve more steps. Is there any disadvantage of doing this?
I've done it before. It was fine.
exactly what I was thinking bro. I was about to ask the same thing, good thing I saw your comment first. But still curious as to the pros and cons of both workflows.
Everywhere I go , I see version control. I'm fine with everuthing else but, that thing scares me especially when you involve pipelines for continuous integration and development.Every second feels like I might screw up. Thanks for the video.
great job , keep doing !
Any one use Tower to manage git? It is a GUI app that allows robust git management. Anyone use it before? I like it but I am looking for additional thoughts.
To Tip1: why not merge from remote/main? any difference beside that my local main is not up to date?
That would be the next step. 1 pull down main changes. 2 merge main into branch. 3 merge branch into main (this would take place via a PR)
@@TravisMedia Won't the PR include the "changes" from the merged master too?
@@TravisMedia question was If, as the first step, a merge from the remote/main would be possible.
So Like:
1. merge from remote/main into branch
2. push branch to remote
Negative would be that at this point my local main is not updated.
It was helpful
Love it 😊
AWESOME
If you work at any reasonably sized organisation, they probably stopped using "master" for "main" more than a year ago.
That's correct
I worke in sores tree that will be easy to worke withe git
Nay... you simply can't beat keyboard centric (touch type) workflow with pointing your mouse at 598 different buttons just to do simple actions. And imagine... there are custom programmable keyboards out there to bake in entire macros. So... don't talk about GUI superioty in 21st century. And your RSI will thank you later about avoiding mouse.
Im offended by you using the word “master”
Why?
@@TravisMedia becasue im a special snowflake
it's going to change to main
Main is the word now. If you work in any large organisation, that's been the reality for a while.