Git Workflow guide: Centralized workflow

Reprint: http://blog.jobbole.com/76847/

This article by Bole Online-liding translation. without permission, no reprint!
English Source: Atlassian. Welcome to join the translation team.

Going to a distributed version control system looks like a daunting task, but you can also use the benefits without changing the used workflow Git . Teams can Subversion develop projects in a completely unchanging way.

But using Git the enhanced development workflow, there Git are SVN有 several advantages. First, each development can have a local copy of the entire project that belongs to it. The isolated environment allows individual developers to separate their work from other parts of the project-that is, to submit to their own local repositories, completely ignoring upstream development, until it is convenient to back up the changes.

Second, Git strong branching and merging models are provided. Unlike SVN , Git the branch is designed to be a "fail safe" mechanism for integrating code between warehouses and sharing changes.

Working style

Like Subversion , the centralized workflow takes a central warehouse as a single point entity for all modifications to the project. Compared to the SVN default development Branch trunk , Git called master , all modifications are submitted to this branch. This workflow only uses master this one branch.

The developer starts by cloning the central repository first. In their own copy of the project, like SVN the same edit file and commit the changes, but the changes are local, and the central warehouse is completely isolated. Developers can postpone synchronization with upstream to a convenient point in time.

To publish the changes to a formal project, the developer will master "push" the local branch's modifications to the central repository. This is equivalent svn commit to an operation, but the push operation pushes all local commits that are not yet in the central repository.

Conflict resolution

The central warehouse represents a formal project, so the submission history should be respected and stable. If the developer's local commit history and the central warehouse are divided, the submission will be Git rejected push or will overwrite the official submissions already in the central repository.

Before developers can submit their own functionality changes to the central repository, they need to submit their own submissions to the central repository submission history before they are added to the central repository fetch rebase . The idea is to say, "I'm going to add my own changes to the changes that someone else has already done." "The end result is a perfect linear history, just like in the previous SVN workflow.

If there is a conflict between the local modification and the upstream commit, the Git process is paused rebase , giving you the opportunity to resolve the conflict manually. Gitresolving merge conflicts, using and generating commits git status and git add commands, is consistent and convenient. Also, if you're having trouble resolving a conflict, Git you can simply abort the entire rebase operation and do it again (or let someone else help).

Example

Let's split up and see how a common small team works with this workflow. There are two developers, Xiao Ming and Xiao Red, to see how they develop their own features and submit them to the central warehouse.

Someone first initialized the central warehouse.

In the first step, someone creates a central repository on the server. If it's a new project, you can initialize an empty warehouse, or you'll import an existing one Git or a SVN warehouse.

The central warehouse should be a bare repository ( bare repository ), i.e. a warehouse without a working directory ( working directory ). You can create it with the following command:

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

Make sure to write a valid user ( SSH username), host (the server's domain name or IP address), /path/to/repo.git (where you want to store the warehouse). Note that in order to represent a bare repository, add the .git extension to the warehouse name by convention.

Everyone, clone the central warehouse.

Next, each developer creates a local copy of the entire project. git cloneComplete by command:

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

Based on the assumption that you will continue to interact with the cloned repository, the Git remote alias is automatically added to origin the "parent" repository when the repository is cloned.

Xiao Ming Development function

In Xiaoming's local repository, he uses standard Git process development features: Edit, Staging ( Stage ), and submit. If you are unfamiliar with staging area ( Staging Area ), here is a description: Staging Area is used to prepare a submission, but it is not necessary to include all the modifications in the working directory. This allows you to create a highly focused commit, although you modify a lot of content locally.

git status # 查看本地仓库的修改状态
git add # 暂存文件
git commit # 提交文件

Keep in mind that because these commands generate local commits, xiaoming can repeatedly operate on his or her own needs without worrying about what is on the central warehouse. This is useful for large functions that require multiple simpler and more atomic chunking.

Little Red Development function

At the same time, Little red in its own local warehouse with the same editing, staging and submission process development features. Like Xiaoming, she doesn't care if the central warehouse has any new submissions; Of course, I don't care about Xiaoming's operations in his local warehouse, because all the local warehouses are private.

Xiao Ming Publishing features

Once Xiaoming has completed his functional development, he will post his local submission to the central repository so that other team members can see his changes. He can use the following git push command:

git push origin master

Note that origin this is the Git Remote central warehouse alias that was created when Xiaoming cloned the repository. masterparameter tells Git the push branch. Since the central warehouse has not been updated since Xiaoming was cloned, there push will be no conflict and successful completion of the operation.

Little Red try to publish the function

Take a look at Xiao Ming after the release of the changes, Little red push changes will be what? She uses exactly the same push command:

git push origin master

But her local history has been divided with the central repository, Git refusing to operate and giving the following very long error messages:

error: failed to push some refs to ‘/path/to/repo.git‘
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. ‘git pull‘)
hint: before pushing again.
hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.

This avoids the small red overlay to write formal submissions. She wants to start pull with Xiao Ming's update to her local warehouse after merging her local modifications, try again.

Little red on the submission of xiaoming rebase

Red uses the git pull merged upstream modifications into its own warehouse. This command is similar svn update --pull all the upstream commit commands to the Red local repository and try to merge with her local modifications:

git pull --rebase origin master

--rebaseThe option tells to move the submission of the Git Little Red to the top of the modified branch of the synchronized Central warehouse master , as shown in:

If you forget to add this option, the pull operation can still be completed, but each time the pull action is synchronized with someone else in the central repository, the commit history ends with an extra "merge commit." For a centralized workflow, it is best to use rebase instead of generating a merge submission.

Little Red Resolve Merge conflicts

rebaseThe operation process is to migrate the local commits one at a time to the updated central repository master branch. This means that it is possible to resolve merge conflicts that occur when a commit is migrated, rather than resolving conflicts that occur when a large merge with all commits is involved. This way you keep the focus of each submission and the cleanliness of the project history as much as possible. Conversely, it simplifies the analysis where it is introduced Bug and, if necessary, rolls back the modifications to minimize the impact on the project.

If the function of Xiao Hong and Xiao Ming is related, it is unlikely that there will be conflict in the rebase process. If so, Git pause the process at the submission where the conflict is merged rebase , output the following information and bring the relevant instructions:

CONFLICT (content): Merge conflict in

GitThe great thing is that anyone can solve his own conflict. In this example, Little red can simply run the git status command to see where the problem is. The conflicting files are listed in the Unmerged paths (not merged paths) Section:

Shell

12345

# unmerged paths: # (use "git reset HEAD <some-file> ..." to Unstage) # (use "Git add/rm <some-file> ..." as appropriate to mark resolution) # # Both modified: <some-file>

Then little red edits these files. After the modification is complete, save the files with the old routine and let git rebase the rest of the work be done:

git add
git rebase --continue

That's all we have to do. Gitwill continue to merge the subsequent commits one by one, repeating the process as other commits have conflicts.

If you come across a conflict, but find it uncertain, don't panic. Just execute the following command to get back to what you did git pull --rebase before you executed the command:

git rebase --abort

Little Red successfully released features

After Red completes the synchronization with the central warehouse, she can successfully release her modifications:

git push origin master

Next stop

As you can see, using just Git a few commands allows us to simulate a traditional Subversion development environment. SVNThis is great for teams to migrate from, but does not give the Git benefits of a distributed nature.

If your team adapts to a centralized workflow, but wants a smoother collaboration effect, it's definitely worth exploring the benefits of functional branching workflows. By assigning a dedicated branch to a feature, you can thoroughly discuss new features before integrating them into a formal project.

«Overview features Branch Workflow»

Moqtada
Oneself understand superficial, the source of the GitHub translation is insufficient and the wrong place, welcome suggestion (submit issue) and correct (submit code after fork)!

Git Workflow guide: Centralized workflow