Git Workflow: Central workflow (translation)

With Git as a version controller, there are a number of possible workflows (Workflow), which makes us new birds unaware of what kind of workflow to choose in their actual work. Here we make a comparison of the most common git workflows, providing a reference for the corporate team.

As you can imagine, the design of these workflows is only a reference, not an absolute rule. We're going to show you what the possible workflows are, so you can get the best of both worlds from a variety of different workflows, combined with the needs of your team. Centralized workflow (centralized Workflow)

Switching to a distributed version control system may seem like a daunting task, but you don't have to take advantage of git by changing your existing workflow. Your team can use the same way as subversion to develop projects.
However, using Git to run your development workflow will still show some of the advantages that SVN does not have. First, Git allows each developer to have a complete copy of the project locally. This environment, which is independent of the central repository, allows each developer and other developers to make changes to the project independently-they can commit on the local repository, and they can not upload their development at all until they think it's time to upload.

Second, Git provides you with a powerful branching and merging model that uses Git. Unlike SVN, the GIT branch is designed to be a fail-safe mechanism to facilitate the integration of GIT code and to share changes between libraries and libraries.

How It Works

Like subversion, a centralized workflow uses a central library as a single point of entry for all code modifications to the project. This discards the trunk concept, the default development branch is called the Master Branch, and all modifications to the project are submitted to this branch. This workflow does not require any other branch other than the master branch.

Developer development starts with the Clone Center library. In their copy of the local project, they can modify the file and commit the modified action as if they were using SVN, but the difference is that the new commits are kept locally -and that the local copy and the Central Library are completely independent. This allows developers to delay uploading local modifications until a suitable point in time to upload all commmits to the Central Library.

In order to publish all local changes to the official project (Central Library), developers need to "push" their local master branch to the Central Library. This is equivalent to SVN's commmit, except that git commits all commits that exist locally and that are not in the central repository.

Conflict management

The Central Library represents the official project, so the submission history of the Central Library needs to be considered solemn and immutable. If a developer's local commits deviates from the (diverge) Central Library, Git will reject his push operation, as this will result in an overwrite of the official submission.

Before the developer can post his features, they need to get the commit in the Central library and reset the local modifications to the base (rebase) on top of the central library. It's like saying, "I want to add my changes to the changes someone else has already done." "As with the traditional SVN workflow, the result of this operation is a perfectly linear history.

If there is a direct conflict between a local modification and a high commit, git pauses the rebase operation and gives you the opportunity to resolve the conflict manually. The good thing is that when resolving conflicts, the way you use git status and git add commands is constant. This facilitates the developer to manage their own conflicts conveniently. In addition, as they approach themselves into the trouble of resolving conflicts, Git provides a convenient way to give up the current rebase, and it is convenient to rebase again (or, of course, to seek help from others).

Example

We'll take a step-by-step look at how a typical small team works with this workflow. We'll see how two developers (Hohn and Mary) work on the same feature and share their contributions on the same central repository.

Initializing the Central Library

First, someone needs to create a central library on a magic couple server. If this is a new project, you can initialize an empty library. Otherwise, you'll need to import from the memory's Git or SVN repository.

Centralized warehouses always start with an empty library (no working directory) and are created in the following ways:

SSH [email protected] git init--bare/path/to/repo.git

Make sure you provide a legitimate SSH username, host with a server domain name or IP address instead, and finally choose a path where you want to store the library.

Everyone clones from the Central Library

After cloning from the Central Library, each developer creates a local copy of the complete project. This is done through the git clone command:

1 ssh://[email protected]/path/to/repo.git

When you finish cloning a central library, Git automatically adds a shortcut called Origin, which points to the "Father" repository. Creating this shortcut is based on the assumption that you will interact with the "Father" warehouse.

John developed his features.

In John's local repository, John wants to use the standard git commit process (edit,stage, and commit) to develop his features. If you are unfamiliar with the stage, remember that he is a submission that does not need to include all the modifications to the working directory. This allows you to make highly centralized submissions even if you make a lot of local changes.

1 git status # VIew The state of the repo 2 file 3 file </some-file>

Remember that because these commands create a local commit operation, John can repeat the process many times without worrying about what is happening on the Central library. This is useful for the development of a large feature, since large features need to be decomposed into many simpler, more atomized blocks.

Mary is developing her features.

At the same time, Mary also developed her features on her local repository, using the same edit/stage/commit process. Like John, she doesn't need to care about the central repository, and she doesn't have to worry about what John is doing because all the local repositories are private.

John publishes his features.

Once John has completed his feature development, he needs to publish his local commits to the Central Library so that other members of the team can access his work. He can do this through the git push operation:

1 git push Origin master

This is a remote connection between origin and the Central Library, which was created at the time of the John Clone Center library. Parameter master tells Git to try to make the master branch of the Central Library the same as John's local master branch. Since the Central Library was cloned from John and has not yet been updated, this will not cause any conflicts, and the push operation will be executed successfully as expected.

Mary tries to publish her features

Let's see what happens if Mary tries to push her feature after John has successfully released his changes to the Central library. She uses the same command to push:

1 git push Origin master

However, because his local history deviates from the central repository, Git rejects her request and returns the following complex error message:

 error:failed to push some refs to  " /path/to/ Repo.git   " hint:updates were rejected Because the tip of your current branch is behindhint:its remote counterpart. Merge the remote changes (e.g.   " git pull   " ) Hint:before pushing Again.hint:See The   "  '  

This error prevented Mary from overwriting the official commit. She needs to synchronize John's update (pull) to her local repository, inherit her own local modifications, and then push. Mary on John's commit rebase Mary can use Git pull to mix the upper changes into her local repository. This command is somewhat similar to the update in SVN:

1 git pull--rebase Origin master

The--rebase option here tells Git to move all of Mary's commits to the end of the master branch after synchronizing with the changes in the central Library, as shown in:

Pull also works without the--rebase option, but the result is that each time someone wants to synchronize with the central repository, it creates an unnecessary merge commit. For this workflow, replacing merge commit with Rebase is the best choice.

Mary resolves a merge conflict

The rebase process transfers all local commits one after another (one at a time) to the updated Master branch. This means that the conflict you get is based on commit-by-commit, not on the whole modification. This ensures that the work is as focused as possible on your submission, thus guaranteeing a clean project history. Accordingly, this makes it easier to find out where a bug is passing parameters. If necessary, the rollback operation can be performed with minimal impact to the project.

If Mary and John are developing unrelated de features, then there is little likelihood of conflict in the rebase process. But if it does, git pauses rebase at the current commit that generated the conflict and outputs the following message, along with the relevant recommendations:

1  in <some-file>

The great thing about git is that anyone can solve the conflicts they encounter in their own merge. In our example, Mary will see where the problem occurs with the git status command. The file that generated the conflict is displayed in the unmerged path section:

1 # unmerged paths: 2 " git reset HEAD <some-file> " To Unstage) 3 " git add/rm <some-file> " As appropriate to mark resolution) 4 # 5 # both modified: <some-file>

She then modifies the conflicting document to the way she wishes it to be. Once she is satisfied with the results, she can resubmit the conflicting files and let git rebase continue to work:

1 git add <some-file>2 git rebase--continue

This is all the process of resolving the conflict. Git will continue with the process of repeating the next commit, using the same process for other conflicting commits.

If in this process, you feel no way to deal with, do not be afraid. Just point to the following command, and you can go back to before you run git Pullo--rebae:

Git rebase--abort

This is all the process of resolving the conflict. Git will continue with the process of repeating the next commit, using the same process for other conflicting commits.

If in this process, you feel no way to deal with, do not be afraid. Just point to the following command, and you can go back to before you run Git pull--rebae:

Git rebase--abort

Marry successfully released her features

After she has finished synchronizing with the Central Library, Mary can successfully release his changes to the project:

Git push Origin Master

From here, where can we go?

As you can see, with a simple git command, you can reuse the traditional subversion development environment. This is great for teams that have moved from SVN, but it's not taking full advantage of Git's distributed features.

If your team is happy to use a centralized workflow, but then you want to simplify teamwork, then you can explore the feature branching workflow (Feature Branch Workflow). By focusing on a separate branch to develop a feature, you can move these new things into the discussion before they are integrated into the official project.

Git Workflow: Central workflow (translation)