Git Command Cycle for Central Repo With Multiple Developers-CodePudding

One way to collaborate using git is for each developer to hold their own branch (

I (developer 1) thought of the following command cycle, starting at the Developer-1 branch (purposefully avoiding git pull):

 1. $ (Developer-1) git fetch --all
 2. $ (Developer-1) git merge origin/Developer-1
 3. $ (Developer-1) git merge origin/dev
 4. Do some work on `Developer-1` over time, during which it is likely that other devs push to remote
 5. $ (Developer-1) git fetch --all
 6. $ (Developer-1) git merge origin/Developer-1
 7. $ (Developer-1) git merge origin/dev
 8. $ (Developer-1) git push Developer-1:Developer-1
 9. $ (Developer-1) git push Developer-1:dev
10. Restart cycle from (1)

Here is a shorter version, using git pull and git's built-in name resolution (in case helpful to someone else):

 1. $ (Developer-1) git pull
 2. $ (Developer-1) git merge origin/dev
 3. Do some work on `Developer-1` over time, during which it is likely that other devs push to remote
 4. $ (Developer-1) git pull
 5. $ (Developer-1) git merge origin/dev
 6. $ (Developer-1) git push Developer-1:Developer-1
 7. $ (Developer-1) git push Developer-1:dev
 8. Restart cycle from (1)

When I want to test the dev branch:

 1. $ (Developer-1) git switch dev
 2. $ (dev) git fetch --all
 3. $ (dev) git merge origin/dev

When I want to push to production:

 1. $ (dev) git switch master
 2. $ (master) git fetch --all
 3. $ (master) git merge origin/dev
 2. $ (master) git push master:master

Resources

Workflow 4 here, is the same as above
The Distributed Workflows chapter from the git book are also illustrating a centralized workflow, but not exactly the approach above

Questions

Is my command cycles the right way to implement the above workflow?
Is the above workflow a common way to collaborate, when you have a small team with a centralized repo?

CodePudding user response：

If you search the web for "git workflow", you will find dozens, or probably hundreds, of articles discussing particular workflows, their pros and cons, and details of how to implement them.

There is one common piece of advice, though: in git, branches are cheap: most workflows involve creating and deleting several branches a week, maybe several a day. The actual history mechanisms in git are all based around commits, with branches just as convenient, and mostly temporary, labels.

If you limit yourself to one branch per developer, you can't leave a branch unmerged while it is tested or code reviewed, or pause work to work on something higher priority; and you can't take over someone else's task if they're off sick or on leave. That's why you'll generally see workflows using branches to represent individual units of work.

There may be some advantage to treating those branches as "owned by" a particular developer, so that they are free to rewrite history (amend commits, rebase onto a new starting point, etc).

The other thing that's unusual in your proposed workflow (although not strictly "wrong", since it will result in a usable history) is that you push the developer branch directly to "dev". It would be more common to switch to "dev", merge the developer (or task) branch into that, and then push the result.

The other thing I advise you to read up on are the advantages of central tools like Gitlab, Bitbucket, Github, or Gerrit, which facilitate and enforce peer review of code, rather than letting all users push directly to the main long-running branches. The merge into "dev" then happens on the server, controlled by the review tool, and developers only need to work on their own branches.

CodePudding user response：

Below is a more git-like implementation of the workflow in question. It does not push from one local branch to a remote branch with a different name.

Hope it is helpful to someone else as well.

 1. $ (Developer-1) git pull #merge in remote changes to current branch (in case developer moved between computers). Most likely FF merge.
 2. Do some work on `Developer-1` branch over time, during which it is likely that other devs push to remote
 3. $ (Developer-1) git push
 4. $ (Developer-1) git switch dev
 5. $ (dev) git pull #merge in remote changes to current branch.
 6. $ (dev) git merge Developer-1 #merge in local branch Developer-1 into local branch dev.
 7. $ (dev) git push #push the newly updated dev branch to remote
 8. $ (dev) git branch -f Developer-1 #move local Developer-1 branch pointer from the pre-merge commit, to wherever dev now points to (which will be a new merge commit if a "true merge" happened).
 9. $ (dev) git switch Developer-1
10. $ (Developer-1) git push
11. Restart from 1

Results

Developer-1 is updated and pushed to remote
dev receives changes from Developer-1
dev is pushed to remote
Developer-1 pointer is moved to dev. This is an important step, to make this workflow function correctly. Since Developer-1 was merged into dev, moving the Developer-1 pointer will not result in any conflict with Developer-1 on the remote server. It will simply be ahead of its remote version, so the remote version is updated next time you push Developer-1.
In other words, if you accidentally try to pull from Developer-1 on remote to Developer-1 locally, after moving the pointer, you will just be told that Developer-1 is up to date. Again, because the remote version is now an ancestor of your local copy, in the commit chain.
It is also good to know that git will not allow you to push anything to remote, if you have not first merged changes from remote into the local branch. So, you don't have to worry about forgetting one of the pull commands above, before pushing. Git will keep you in line and avoid errors.

Alternative

As @torek pointed out in the comments to the other answer, merging with ff-only, is the same as just moving the pointer. So this works too:

 1. $ (Developer-1) git pull #merge in remote changes to current branch (in case developer moved between computers). Most likely FF merge.
 2. Do some work on `Developer-1` branch over time, during which it is likely that other devs push to remote
 3. $ (Developer-1) git push
 4. $ (Developer-1) git switch dev
 5. $ (dev) git pull #merge in remote changes to current branch.
 6. $ (dev) git merge Developer-1 #merge in local branch Developer-1 into local branch dev.
 7. $ (dev) git push #push the newly updated dev branch to remote
 8. $ (dev) git switch Developer-1
 9. $ (Developer-1) git merge dev --ff-only #merge dev branch back into Developer-1 branch, via ff-only (flag should not be needed, but just in case)
10. $ (Developer-1) git push
11. Restart from 1