Disclaimer: This was adapted from a guide written internally for our Bits of Good organization to help newbies get their footing when joining a pro...
For further actions, you may consider blocking this person and/or reporting abuse
Great stuff! I might add that if you're tracking issues it's great to include that ticket number (or equivalent) in your branch name. When you make your PR it is a 1-1 mapping for reviewers to look at the requirements your code should fulfill.
Definitely. In gitlab (I'm guessing it works in github too) it will pop in the history of the ticket, and it can even automatically close tickets by accepting merge requests if the commit message include a keyword like "fix" or "close" in front of the ticket number.
Definitely. Oftentimes tickets can be in different systems though. So that number is especially important.
Totally agree! To be honest, I have limited industry exposure from internships as a college student, so I haven't worked much with ticketing, backlogs, or other more robust systems.
Should probably add a clarification of my own experience to the post for some context.
You wouldn't have been able to tell! It's applicable at all levels.
So I'm a self-taught developer who hasn't worked on a team before. This is super useful to me. When you're making commit messages to yourself, it's almost a joke. I try to put a few keywords that let me remember what I was working on at the time. I don't commit nearly enough, I don't think.
Also, you sent me down the rabbit whole of looking into Agile. Thanks! It was a nice introduction.
Wow, love hearing when people how actually get something out of my posts. Keep crushing it man!
Also cool to see your journey trying out Gatsby and Netlify. I'm planning on using both for a club homepage, so its nice to learn some of the pitfalls to watch out for when using them 😊
"merged the remote branch into yours" - why don't "rebased your branch onto remote one"?
Fair point! Stems from my bad habit of merging the remote even when it's not the best choice.
Basic explanation to those unaware: rebasing will shift all of your commits to after the last commit of the remote, making your branch look like it's building off of the
master/developyou want to merge in. Just merging will not fix up the commit history like this, even though it yields the same resulting code in your editor. This article gives a nice visual.I'll make an edit shortly :)
I forgot to add that some projects have specific rule that states something like "rebase your changes on top of upstream before creating pull request".
Found example.
"Note that it is highly recommended to keep your pull requests up-to-date. If you do not know how to do this, take a look on manpage of git-rebase."
github.com/termux/termux-packages#...
Commit messages are a whole topic of themselves. I don't think you should do anything more than point to this article: chris.beams.io/posts/git-commit/
The example you give is actually encouraging bad practice by providing commit messages without explanations.
Regarding branch names, similarly I think it is bad practice to start them with the date. It makes them very cumbersome to use, whereas by starting with descriptive words you get easy autocomplete.
Recently, we've been facing issues where certain code merges were reverted from the develop branch. This led to other feature branches that were rebased from the develop branch contain code that isn't in the develope branch anymore. So when you try to merge that rebased feature branch to develop, the reverted code goes back in.
Is there any smart way to handle this? We're currently resorting to manually remove the reverted changes from our feature branches, which is prone to mistakes.
Yeesh, that sounds like you'd have to walk through the commits within the child branches and peel out the commits that were reverted. Really haven't been in this situation tbh so I don't have a great answer other than to always use revert sparingly.
Any readers have suggestions?