Here are some important rules to follow when using Git:
Work on a feature branch: This is important because it means you do all your work in a separate branch, not the main one. It lets you submit more than one pull request without any mix-ups. Plus, you can make changes without risking any instability in the master branch with unfinished code.
Always branch out from develop: By doing this, you make sure that the code in the master branch can be used for releases almost always without any problems. (This might not be necessary for some projects.)
Don't push directly into develop or master branch. Instead, make a Pull Request: This lets your team know that you've finished a feature. It also makes it easy for your peers to review your code and provides a space to discuss the feature you're proposing.
Update your local develop branch and do an interactive rebase before pushing your feature and making a Pull Request: This merges in the requested branch (master or develop) and puts the commits you've made locally at the top of the history. This means the history will be neat and tidy.
Solve any conflicts while rebasing and before making a Pull Request. When you rebase your branch before a Pull Request, you're integrating changes from one branch into another. During this process, conflicts may arise if Git can't decide how to merge the changes. It's crucial to resolve these conflicts during the rebase, before creating your Pull Request. This way, you ensure a clean, conflict-free branch that can be smoothly merged into the main codebase. Resolving conflicts early avoids potential issues down the line and facilitates a faster, more efficient review process for your Pull Request.
Delete your local and remote feature branches after they've been merged: This stops your list of branches from getting cluttered with branches you're not using anymore. It also makes sure you only merge the branch back into master or develop once.
Before making a Pull Request, check your feature branch to make sure it's working properly and passes all tests (including style checks): This is because you're about to add your code to a stable branch. If your tests fail, there's a high chance the destination branch will fail too. Also, doing a style check before making a Pull Request helps keep everything readable and makes sure any formatting fixes are separate from the actual changes.
Use .gitignore file: This file already has a list of system files that you shouldn't include in your remote repository. It also excludes certain folders and files for most editors, as well as most common dependency folders.
Protect your develop and master branch: This keeps your ready-to-go branches safe from unexpected changes.
That's it! By following these rules, you can make sure your Git workflow is smooth and efficient.
Top comments (0)