i had to watch the video about 4 times(i am very dumb in terms of git) to understand what was going. Just recently joined a company and git stuff is really daunting especially when the company wants you to do particular things like rebase instead of pull, watching this video helped me a lot ! thanks
You're not dumb! Git is very hard and requires practice. By searching for strategies and tutorials, you're on the right path. Let me know if there are other concepts that require explanation. Btw if you don't know this website, it is also helpful :D ohshitgit.com
Hi Julie, I'd love a thorough deep down into git security (signing commits), versioning, and automatic release notes. You seem to have a very slick system in place. Thanks and keep up the good work!
There's a little bit more detail here ua-cam.com/video/e4lJmgd_4DA/v-deo.html Yeah, I get asked a lot at work for the signing commits and automatic release notes. The latter is simple, check out github.com/conventional-changelog/standard-version. Let me know if that answers most of your questions about the automated changelogs. Signing commits is more challenging for me to explain, because my workflow using a physical FIDO key is a bit paranoid and over the top for most people.
Git just takes practice and the best tip is to slow down and read all the messages line by line. Git tells you what to do :) it took me many months if not years to feel comfortable. But it's doable and you can do it too :)
A typical day is not as interesting as most people think 😜lots of calls and emails. But I can understand why people are curious and I'll add this topic to my list :)
Hey Julie, I just discovered your content. It's sweet. Thanks! I would like to deep dive more on git commands & knowledge, do you know of any good place to start? Thanks!
One of my favorite sites is ohshitgit.com :D It describes most the commands I use regularly. And just using git regularly on the command line is great for mastering git. git gives good error messages and the `-h` flag is always helpful and if needed the longer `--help` flag for the full manual. Over time you'll master it :)
Hey Julie, that 's a great tip on making rebases much faster/easier. Question though: how do you deal with this when you're mid pull request and there have been several changes to main. If you rebase and force push then the Pull Request loses its state does it not?
Hi Ashok, the trick here is to rebase from main often and keep up with those changes. When you force push on GitHub, the Pull Request will lose it's "approved" state - which makes sense. If you expect to need to force push regularly, I suggest mostly using PR for comments and waiting to do approvals until you're ready to merge. This is what the GitHub docs say: "If both required reviews and stale review dismissal are enabled and a code-modifying commit is pushed to the branch of an approved pull request, the approval is dismissed. The pull request must be reviewed and approved again before it can be merged." Source: docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews Does that help?
Can you help me understand your ask? What do you mean by early stages and "different tools"? Like when I'm prototyping, do I just have lots of messy files lying around? (sometimes I do 😜)
@@JulieNgTech have a nice week end, Indeed we will have so many messy files around, as a example till projects core structure and features has at least has some stabilization. I mess around move files, change api, move files, change internal api's... break the system and fix it. then when there is a some type of stablization I strat using braching on git. feature/x ... chore/x very smilar to git commit message's. so I would have an idea about that branch. I was wondering about your approach. My english can get messy also :P
How does one start learning devops, there seems to be alot to learn from testing to building to deploying, what are the tools that are commonly used and why are those chosen, I see that terraform you use terraform as well but I am not quite sure I understand how it should be applied.
Talk to each other. Beforehand talk about who is working on which files, because if you don't touch the same ones, no merge conflicts should arise. Also merge timing is important. Make clear which ones should go in first, for example because you know both features update the readme. Pick one to go first and rebase those merged changes into the 2nd branch (resolve any conflicts there) before it too is merged. Talking to each other is the best thing to do, each team will have its own rhythm and that takes time to figure out. The only way to increase the velocity is to communicate.
i had to watch the video about 4 times(i am very dumb in terms of git) to understand what was going. Just recently joined a company and git stuff is really daunting especially when the company wants you to do particular things like rebase instead of pull, watching this video helped me a lot ! thanks
You're not dumb! Git is very hard and requires practice. By searching for strategies and tutorials, you're on the right path. Let me know if there are other concepts that require explanation.
Btw if you don't know this website, it is also helpful :D ohshitgit.com
Hi Julie, I'd love a thorough deep down into git security (signing commits), versioning, and automatic release notes. You seem to have a very slick system in place. Thanks and keep up the good work!
There's a little bit more detail here ua-cam.com/video/e4lJmgd_4DA/v-deo.html
Yeah, I get asked a lot at work for the signing commits and automatic release notes. The latter is simple, check out github.com/conventional-changelog/standard-version. Let me know if that answers most of your questions about the automated changelogs.
Signing commits is more challenging for me to explain, because my workflow using a physical FIDO key is a bit paranoid and over the top for most people.
This video was super helpful. My git-fu is weak and merge conflicts were daunting to someone not really used to them.
Git just takes practice and the best tip is to slow down and read all the messages line by line. Git tells you what to do :) it took me many months if not years to feel comfortable. But it's doable and you can do it too :)
this is suuch a greaaat video. that is such a cool way to do it. thankyou : )
Thank you Calieee ♥️ I am glad you found it cool :)
How is a typical day working at Microsoft on Germany? Thanks for the great content, explained in a very straight forward way!
A typical day is not as interesting as most people think 😜lots of calls and emails. But I can understand why people are curious and I'll add this topic to my list :)
Hey Julie, I just discovered your content. It's sweet. Thanks!
I would like to deep dive more on git commands & knowledge, do you know of any good place to start?
Thanks!
One of my favorite sites is ohshitgit.com :D
It describes most the commands I use regularly. And just using git regularly on the command line is great for mastering git. git gives good error messages and the `-h` flag is always helpful and if needed the longer `--help` flag for the full manual. Over time you'll master it :)
hey julie, you rock
Thanks Calvin! What did you like most about the video? Anything else you'd like to see?
Hey Julie, that 's a great tip on making rebases much faster/easier. Question though: how do you deal with this when you're mid pull request and there have been several changes to main. If you rebase and force push then the Pull Request loses its state does it not?
Hi Ashok, the trick here is to rebase from main often and keep up with those changes. When you force push on GitHub, the Pull Request will lose it's "approved" state - which makes sense. If you expect to need to force push regularly, I suggest mostly using PR for comments and waiting to do approvals until you're ready to merge.
This is what the GitHub docs say:
"If both required reviews and stale review dismissal are enabled and a code-modifying commit is pushed to the branch of an approved pull request, the approval is dismissed. The pull request must be reviewed and approved again before it can be merged."
Source: docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
Does that help?
I would like to know how you deal with very early stages of the code on different tools.
Can you help me understand your ask? What do you mean by early stages and "different tools"? Like when I'm prototyping, do I just have lots of messy files lying around? (sometimes I do 😜)
@@JulieNgTech have a nice week end,
Indeed we will have so many messy files around, as a example till projects core structure and features has at least has some stabilization. I mess around move files, change api, move files, change internal api's... break the system and fix it. then when there is a some type of stablization I strat using braching on git. feature/x ... chore/x very smilar to git commit message's. so I would have an idea about that branch.
I was wondering about your approach. My english can get messy also :P
THANKS
You're welcome!
How does one start learning devops, there seems to be alot to learn from testing to building to deploying, what are the tools that are commonly used and why are those chosen, I see that terraform you use terraform as well but I am not quite sure I understand how it should be applied.
Hi Charles, what specifically are you unsure about? Like how to structure code? How to separate environments?
How do you recommend I best practice git conflict resolutions without a large team?
Talk to each other. Beforehand talk about who is working on which files, because if you don't touch the same ones, no merge conflicts should arise. Also merge timing is important. Make clear which ones should go in first, for example because you know both features update the readme. Pick one to go first and rebase those merged changes into the 2nd branch (resolve any conflicts there) before it too is merged. Talking to each other is the best thing to do, each team will have its own rhythm and that takes time to figure out. The only way to increase the velocity is to communicate.
git push origin master -f