At the start of every project, most managers generally ask the same basic setup question, "how should we establish the git workflow?" At most large...
For further actions, you may consider blocking this person and/or reporting abuse
This filled in some gaps in my git knowledge. Especially thanks for sharing
git stashandgit fetch!! Losing everything is my number one reason I don't go past the most basic git commands on my personal projects. Since you're always technically the "lead" LOL. Fire stuff, thanks! 🔥Haha! I'm glad my article helped you out!
It too took me awhile to understand the subtle nuances within Git. I would recommend checkout the following for a deeper dive into the command lines:
git stash:
git-scm.com/docs/git-stash
git-scm.com/book/en/v2/Git-Tools-S...
git fetch:
git-scm.com/docs/git-fetch
atlassian.com/git/tutorials/syncin...
Yeah, I know a lot of people tend to pass on being so strict on themselves when it comes to personal projects. But I see it as good practice for when you actually do work with a larger team, you're better equipped at not messing up.
Thanks for the resources! Will do ✌️
"one should not work on master as a general practice" - did someone tell you this nonsense or you just read it somewhere?
For people who are just starting with Git: don't blindly believe everything you find on internets. Before you continue to blindly follow some so called "best practices" I highly recommend you to learn what alternatives are. And in this specific case I recommend to read about Trunk Based Development.
A master branch should not be committed to. The master branch should be merged to after other branches have been through a formal approval process. Writing directly to the master branch is sloppy and unprofessional. That is a fact. Your code should be rigorously reviewed before it is ever merged into a master branch.
On a personal project is what my article is referred too. But yes, you are right. In a professional setting there usually is a team lead or dev manager who monitors this particular task of merging pieces together. In my experience I was never the one to merge things to production.
Isn't it a norm/best practice to have a dev branch where all the development goes down and a clean empty branch (master/main for example) where the finished product get merged to ?
Yes, from my past experience the master branch is the clean branch. Everything gets merged into that branch before it is pushed up to staging or production.
I only say "one should not work on master", if you are not team lead. I was never team lead. I was always one memeber out of 2-15 other people. So, unless I am working on personal projects, then of course, you can push stuff from master after you have merged your separate branch changes. Because no one else will do it for you.
I think this is where the confusion lies.
I totally agree with you James. I have a similar workflow when working in a team
thanks
Commit messages should always have a body detailing changes. It is therefore preferable to use "git commit -a". This will launch the default editor and allow the engineer to write a well formed commit message.
Oh didn't see know about the "-a" feature. I'll have to look into that. Thanks!
You should call it your “git workflow”. Git Flow is an actual git workflow that many development teams follow.
Acknowledged and changed. Thanks!