Adopt these Git collaboration strategies to make your team work more efficiently.

Git is great for small teams to manage their software development progress, but there are ways you can become more productive. I’ve found a number of best practices that help my team, especially when new people with different Git levels join.

Formalize Git conventions on your team

Everyone should follow the conventions for branch naming, tagging, and encoding. Every organization has its own norms or best practices, and much of the advice is freely available online, but it is important to choose the right norms early and follow them throughout the team.

At the same time, different team members have varying Git levels. You need to create and maintain a basic set of instructions that follow the team’s specifications to perform common Git operations.

Merge changes correctly

Each team member needs to work on a separate functional branch. But even if a separate branch is used, everyone will modify some common files. When changes are merged back into the Master branch, the merge usually does not happen automatically. You may need to manually resolve conflicts between different people on different changes to the same file. This is why you must learn how to handle Git merges.

Modern editors have features to help resolve Git merge conflicts. They offer various options for merging each part of the same file, such as whether to keep your changes, or keep changes from another branch, or keep them all. If your editor doesn’t support these features, it might be time to switch to a code editor.

Base your functional branches often

As you continue to develop your branch of functionality, rebase it frequently. This means performing the following steps frequently:

Git rebase master # May need to resolve merge conflicts on feature-xyzCopy the code

These steps rewrite history on your functional branch (which is not a bad thing). First, it gives your function branch access to all current updates on the Master branch. Second, all your commits on the functional branch are rewritten at the top of the branch history, so they appear in the log in order. You may need to resolve merge conflicts along the way, which can be a challenge. However, this is the best time to resolve conflicts because it only affects your functional branches.

After resolving all conflicts and doing regression testing, if you are ready to merge the functional branches back to master, you can do the merge a few more times after performing the above rebase steps:

git checkout master
git pull
git merge feature-xyz
Copy the code

In the meantime, if someone else pushes conflicting changes to master, Git merges will clash again. You need to resolve them and retest the regression.

There are other merge philosophies (for example, only use merge and not base change to prevent rewriting history), and some of them may even be simpler to use. However, I have found the above approach to be a clean and reliable strategy. The commit history log is arranged in a meaningful sequence of functions.

If a “pure merge” strategy is used (as mentioned above, without regular rebasing), then the history of the Master branch will be punctuated by the submission of all functionality developed at the same time. Such a messy history is hard to look back on. The exact commit time is usually not that important. It is best to have a history log that is easy to view.

Squash the submission before merging

When you’re working on a feature branch, even the smallest change can be committed as a single change. However, if each functional branch produces 50 commits, then the master branch’s commit count will swell unnecessarily as new features are added. In general, each functional branch should only add one or more commits to the master. To do this, you Squash multiple commits into one or more commits with more detailed information. This is usually done using the following command:

Git rebase -i HEAD~20 # see twenty commits that can be squashedCopy the code

When this command is executed, a commit list editor pops up, which you can edit in several ways, including picking pick or squash. To “select” a commit is to keep it. To “squash” a commit is to merge the commit into the previous one. Using these methods, you can combine multiple commits into one, edit and clean it up. This is also an opportunity to clean up unimportant submissions (for example, typos).

In summary, leave all actions related to commit, but merge and edit the information to clarify the intent before merging into the Master branch. Be careful not to accidentally delete the commit during the rebasing process.

After doing something like rebasing, I’ll look at the Git log again and make the final changes:

git commit --amend
Copy the code

Finally, because the branch’s Git commit history has been overwritten, the remote branch must be forcibly updated:

git push -f
Copy the code

Use a label

Create a Git tag when you’ve finished testing and are ready to deploy software online from the Master branch, or when you want to keep the current state as a milestone for some reason. For a branch that has accumulated changes and commits, the label is a snapshot of that branch at that point in time. A label can be thought of as a branch with no history, or as a named pointer that points directly to the submitted label before it was created.

The so-called “configuration control” is to save the state of the code at different milestones. Most projects have a requirement to reproduce the software source code at any milestone so that it can be rebuilt as needed. Git tags provide a unique identifier for each code milestone. Labeling is very simple:

Git tag milestone-id -m "Short message saying what this milestone is about" git push --tags #Copy the code

Consider the case where a version of the software for Git tags has been distributed to a customer who reports a problem. Although the code in the code base may already be under development, it is often necessary to fall back to the code state corresponding to the Git tag in order to accurately reproduce the customer problem for a fix. Sometimes new code may have fixed that problem, but not always. Usually you need to switch to a specific tag and create a branch from that tag:

Git checkout -b new-branch-name # Create a new branch to reproduce the bugCopy the code

Also, if annotated tags and signed tags help your project, consider using them.

Let the software run while printing labels

In most embedded projects, binaries built from code versions have fixed names that make it impossible to infer the corresponding Git tag from their names. “Embedding tags” at build time helps to accurately correlate future problems to a particular build. Tags can be embedded automatically during the build process. Typically, the tag strings generated by Git Describe are inserted into the code before it is compiled so that the generated executable can output the tag strings at startup. When customers report problems, you can instruct them to send you the output at startup.

conclusion

Git is a complex tool that takes time to master. Using these practices can help teams successfully collaborate with Git, regardless of their level of knowledge.

Via: opensource.com/article/20/…

By Ravi Chandran, lujun9972

This article is originally compiled by LCTT and released in Linux China