Reputation: 77
I have doubts how to use git flow locally and do i need to do this at all. With remote git flow i guess all seems clear:
1)Create remote repository, this makes one master branch 2)Make devel branch from master 3)All developers clone remote repo to their local computers and make some staffs: add, commit changes, and the push to the remote devel branch, then "repository owner" merges remote develop branch to the master time after time
But what about local repository? Do i need to create locally some sort of git flow? make my own develop and master branch, where i will commit changes to my local develop branch then merge it to local master, and only after that make push to remote develop branch.
What would be the right queue of actions to working with locally - remote repositories?
Cause I think if I would clone remote repo I would have master and develop branches like remote repo already has.
Thanks
Upvotes: 0
Views: 1228
Reputation: 45659
Your description of git flow leaves out some very important details; you might want to review documentation of why it works the way it does.
In any case, in gitflow the master branch is the master branch across all repos. The most important thing it does is to consist only of release versions. At any given moment the HEAD of master should match your current production release; which is why you don't do work directly on master. The develop branch is branched from master, as are any hotfix branches. The important thing about merges to master isn't so much WHO does them as WHAT merges should be done: Only finished release and hotfix branches should merge into master, reflecting a new release version.
The develop branch is the develop branch across all repos. It reflects the cumulative releasable (but not necessarily released) work on the project. You might create central development and/or qa environments that track the HEAD of the develop branch. At any time develop should contain a clean build, so just like master you don't do work directly on the develop branch. Release branches are branched from develop, as are feature branches.
When you want to develop a feature, you create a feature branch. This branch might never be pushed to the team's origin repo; it's up to the team to decide whether these branches are to be shared, not to be shared, or it's up to the developer on a case-by-case basis. This branch contains work in progress. When you get it to a clean build state that fully implements the feature for which it was created, you merge it back into develop (and can then delete it).
Etc, etc.
The point is - if you're using gitflow, you're using gitflow. The branches in your local repo (except maybe feature branches) should be tracking the corresponding branches in the origin.
You seem to be wondering about an approach where you clone the origin develop branch as your local master, and should you then replicate gitflow locally around that new master (that's really develop)? Well, I suppose you could invent a workflow like that, but why? It just seems like needless complexity, and in fact by failing to replicate the gitflow structure already present at origin it takes useful tools away from the developer.
Is it so that sub-teams can collaborate in the local repo, and then those teams can act as individual developers in how they relate to the origin repo? Well, ok, but (1) in that case the "local" should probably be an intermediate, cloned from the "true" origin but from which individual developers still clone; and (2) there's no way you actually need to do this.
If you and another developer are collaborating on a feature branch by a means other than pair programming, and if you're sure that's not because you should do something different (like decompose the feature into two features, or just pair program), then you can share the feature branch (at least among you two even if not through origin), create local branches for individual work, and coordinate merges (or rebases) onto the feature branch. But that won't require the formality of a "sub-gitflow".
Upvotes: 2
Reputation: 38619
git flow
is not about remote repository. With git you don't even need a remote repository, you can do it all in your local repository alone. But git flow
is valid for all repositories of a project. Feature branches on which you usually develop a new feature e. g. are not necessarily ever pushed to a central repository, but only present locally, or maybe shared by some of the developers directly between their repositories.
Upvotes: 0