![]() (There are other conventions which are sometimes enforced, but in my opinion those two are the most important.You can wrap the body, but not the subject line. Keep all lines to less than 72 characters.Have a single subject line, followed optionally by a blank line and any extra info in paragraphs or bullet points.Try to keep functional changes separate from formatting changes or rewrites/refactoring.If you want to move code and modify it, move it in one commit then modify in another.Try to make each commit represent a single, easily-describable change. Personally I find putting in at least a little effort makes it much easier when someone is looking back and trying to figure out when/why something changed. ![]() Some teams don’t care at all about the history, and some are super strict. Unfortunately, knowing technically how to use Git isn’t enough! Each team often has its own conventions too, because they care different amounts about what the Git history looks like. There is also the GitHub Desktop app, but I would only use it for very simple tasks-from what I’ve seen it’s a little too oversimplified.įor an in-depth guide to Git, try the Pro Git web-book. lazygit: a terminal UI for more advanced users (free Windows, Mac, Linux).gitui: a simple “terminal UI” (free Windows, Mac, Linux).Git has some semi-official GUIs git gui and gitk, which can be installed as extra packages on Linux distros and via Homebrew for Mac.If you’re new to Git, the main thing I recommend is using a GUI: Here’s an overview of my main recommendations. I’ve been using Git for many years and maintain a project which uses it. It’s powerful, but unfortunately it doesn’t guide you much in how to use it. Using Git effectively is as much an art as it is a science. This started as part of a contributing guide for one my projects, but I realised that it was generic enough to be more widely useful.
0 Comments
Leave a Reply. |