A
由于下周计划的出差提前，当然不该是个借口，稍微延期一天，周日肯定得把A搞定的，当然那天积累了一些失败的经验，就是这个题，我先去自己理个发，上帝请原谅我吧
R
Comparing Workflows
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently. Git offers a lot of flexibility in how users manage changes. Given Git’s focus on flexibility, there is no standardized process on how to interact with Git. When working with a team on a Git managed project, it’s important to make sure the team is all in agreement on how the flow of changes will be applied. To ensure the team is on the same page, an agreed upon Git workflow should be developed or selected. There are several publicized Git workflows that may be a good fit for your team. Here, we’ll be discussing some of these workflow options.
The array of possible workflows can make it hard to know where to begin when implementing Git in the workplace. This page provides a starting point by surveying the most common Git workflows for software teams.
As you read through, remember that these workflows are designed to be guidelines rather than concrete rules. We want to show you what’s possible, so you can mix and match aspects from different workflows to suit your individual needs.
What is a successful Git workflow
When evaluating a workflow for your team, it’s most important that you consider your team’s culture. You want the workflow to enhance the effectiveness of your team and not be a burden that limits productivity. Some things to consider when evaluating a Git workflow are:
- Does this workflow scale with team size?
- Is it easy to undo mistakes and errors with this workflow?
- Does this workflow impose any new unnecessary cognitive overhead to the team?
Centralized Workflow
The Centralized Workflow is a great Git workflow for teams transitioning from SVN. Like Subversion, the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.
Transitioning to a distributed version control system may seem like a daunting task, but you don’t have to change your existing workflow to take advantage of Git. Your team can develop projects in the exact same way as they do with Subversion.
However, using Git to power your development workflow presents a few advantages over SVN. First, it gives every developer their own local copy of the entire project. This isolated environment lets each developer work independently of all other changes to a project - they can add commits to their local repository and completely forget about upstream developments until it’s convenient for them.
Second, it gives you access to Git’s robust branching and merging model. Unlike SVN, Git branches are designed to be a fail-safe mechanism for integrating code and sharing changes between repositories. The Centralized Workflow is similar to other workflows in its utilization of a remote server-side hosted repository that developers push and pull form. Compared to other workflows, the Centralized Workflow has no defined pull request or forking patterns. A Centralized Workflow is generally better suited for teams migrating from SVN to Git and smaller size teams.
How it works
Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally - they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point.
To publish changes to the official project, developers “push” their local master branch to the central repository. This is the equivalent of svn commit, except that it adds all of the local commits that aren’t already in the central master branch.
Initialize the central repository
First, someone needs to create the central repository on a server. If it’s a new project, you can initialize an empty repository. Otherwise, you’ll need to import an existing Git or SVN repository.
Central repositories should always be bare repositories (they shouldn’t have a working directory), which can be created as follows:
ssh user@host git init —bare /path/to/repo.git
Be sure to use a valid SSH username for user, the domain or IP address of your server for host, and the location where you’d like to store your repo for /path/to/repo.git. Note that the .git extension is conventionally appended to the repository name to indicate that it’s a bare repository.
Hosted central repositories
Central repositories are often created through 3rd party Git hosting services like Bitbucket Cloud or Bitbucket Server. The process of initializing a bare repository discussed above is handled for you by the hosting service. The hosting service will then provide an address for the central repository to access from your local repository.
Clone the central repository
Next, each developer creates a local copy of the entire project. This is accomplished via the git clone command:
git clone ssh://user@host/path/to/repo.git
When you clone a repository, Git automatically adds a shortcut called origin that points back to the “parent” repository, under the assumption that you’ll want to interact with it further on down the road.
Make changes and commit
Once the repository is cloned locally, a developer can make changes using the standard Git commit process: edit, stage, and commit. If you’re not familiar with the staging area, it’s a way to prepare a commit without having to include every change in the working directory. This lets you create highly focused commits, even if you’ve made a lot of local changes.
git status # View the state of the repo git add
# Stage a file git commit # Commit a file Remember that since these commands create local commits, John can repeat this process as many times as he wants without worrying about what’s going on in the central repository. This can be very useful for large features that need to be broken down into simpler, more atomic chunks.
Push new commits to central repository
Once the local repository has new changes committed. These change will need to be pushed to share with other developers on the project.
git push origin master
This command will push the new committed changes to the central repository. When pushing changes to the central repository, it is possible that updates from another developer have been previously pushed that contain code which conflict with the intended push updates. Git will output a message indicating this conflict. In this situation, git pull will first need to be executed. This conflict scenario will be expanded on in the following section.
Managing conflicts
The central repository represents the official project, so its commit history should be treated as sacred and immutable. If a developer’s local commits diverge from the central repository, Git will refuse to push their changes because this would overwrite official commits.
Before the developer can publish their feature, they need to fetch the updated central commits and rebase their changes on top of them. This is like saying, “I want to add my changes to what everyone else has already done.” The result is a perfectly linear history, just like in traditional SVN workflows.
If local changes directly conflict with upstream commits, Git will pause the rebasing process and give you a chance to manually resolve the conflicts. The nice thing about Git is that it uses the same git status and git add commands for both generating commits and resolving merge conflicts. This makes it easy for new developers to manage their own merges. Plus, if they get themselves into trouble, Git makes it very easy to abort the entire rebase and try again (or go find help).
Example
先到此吧，这篇文章感觉结构有问题，头重脚轻？大量的篇幅在 centralized workflow 上；Example往后放下周
T
首先是仅仅type Jump，click不到Jump to Colors and Fonts，而是得多敲几个基本上到Colo肯定就出来了
其次是真没啥用，好像有个idea的更漂亮的插件可以干这个事情，除非你自己懂配色吧
每周一T（吐.槽？）完成…
S
不知道为啥，又想起盛田昭夫的那句话，曾经对我无限影响，一度怀疑过他，但是似乎现在还是渐渐又浮现出来他的意义，出自骚尼的故事这本书，这里应该是个基于学习目的的链接吧，侵删
但是管理方面有一件事值得注意，一个管理者可以连年犯错误，而无人知晓。也就是说，管理可以是一种模糊性的工作
这两句的前一段都是在描述，其他很多得工作，做到顶尖都是需要技能上非常超群的出色
就这样吧，更多的内容其实应该开专题说，也是敏感信息没法展开了说，但除了盛田昭夫说的那个问题很有可能不为人知这点之外，应该注意几点：
- 真正的和管理相关的工作应该在一个更大的时间尺度上来做出评价
- 还不是往前简单的追溯一段时间，而往往是还需要等经过时间沉淀下去一段时间之后
- 甚至…盖棺才能定论，也就是等你要评价的对象在时间尺度上终结了之后才会比较合适
- 有时候其实有些人确实干了很多脏活累活，背锅较多罢了
若有收获，就点个赞吧
0 人点赞
