3

I've been reading this popular document over and over to try and draft my own git workflow.

I think I have got it down, but I am still a little lost. Here is my current understanding...



We have two branches that will always remain active.

  • Master: This is where I will push code that will actually be deployed to my production server and be used by my users.
  • Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.


We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:

  • Topic Branch 1: feature-ajaxify-shoping-cart
  • Topic Branch 2: bugfix-navbar-font-overlapping


Prepare The Release

  • We have 1 release branch at a time that will be branched from the feature branch.
  • Now we pull/merge all the features, bug fixes etc we want to push into the next release.
  • We can leave some features we have been working on that wont be in the next release (I think).


Creating The Release

  • Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.
  • We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.


Side notes I have learned

The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).

Please let me know where I have messed up or misinterpreted something etc. Thanks!



Rich
  • 109
  • 1
  • 9
  • What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases https://stackoverflow.com/questions/40892485/how-to-work-wit-git-correctly/40895729#40895729 –  Nov 21 '18 at 06:40

1 Answers1

10

Your summary is accurate: you can find illustrated in this cheatsheet.

Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).
There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)

The difference is:

  • with git flow:
    • multiple feature branches are merged in devel (where they discover if they can work together or not)
    • then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).
  • with gitworkflow:
    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)
    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.
    • then a sub-subset of feature branches are merged to master, to prepare the next release.

The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.

tama
  • 142
  • 2
  • 9
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right? – Rich Nov 21 '18 at 10:39
  • 1
    @Rich All the details are in https://github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb?gi=4d0eda0d38ba. – VonC Nov 21 '18 at 12:45
  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other." – VonC Nov 21 '18 at 12:45
  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol. – Rich Nov 22 '18 at 05:55
  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release. – VonC Nov 22 '18 at 05:57
  • @Rich the first merges are done in the ephemeral branch next (which is never merged to master: key difference with gitflow). The second merge (of the ones deemed compatible, for the next release) are done in master, to prepare the next release. – VonC Nov 22 '18 at 06:04
  • So the transistent branch as you state would be the next branch? Say I'm done working on my topic/feature branch, I merge that into the next branch. My question now is where does it go after the next branch? And what if I have to rework on that topic, what's the process there? Really sorry having a hard time following, thank you for taking the time to help however! – Rich Nov 22 '18 at 08:15
  • @Rich on the rework side, That is what https://github.com/rocketraman/gitworkflow#make-your-topics-great describes – VonC Nov 22 '18 at 08:58
  • @Rich this is illustrated in https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb: "Now that the topic has graduated to next, it can be part of a beta, or acceptance release. So every topic on next can now undergo a second round of stabilization, which is exactly the purpose of a beta release / acceptance testing environment. However, note that with gitworkflow, we still have not committed (no pun intended!) to having this topic as part of our next release to production — it still has not been merged to master." – VonC Nov 22 '18 at 08:59
  • @Rich "What if topic branches continue to evolve with new commits after merging and testing on next? The branch is simply merged to next again, as is necessary." – VonC Nov 22 '18 at 08:59
  • @Rich "And lastly, once a topic is judged stable enough to release, the topic graduates again and is merged to master (or perhaps maint), again with --no-ff to preserve the complete history of the topic branch." – VonC Nov 22 '18 at 09:00
  • @Rich This is very different from gitflow, where the lifecycle branches are merged (feature to dev to master). Here a "topic" (feature branch) is merged as many time as necessary to an ephemeral branch pu or next (one which is recreated for each new release). And *then*, once ready, merged to master. pu or next are never merged to master. – VonC Nov 22 '18 at 09:01
  • I think I got it now. We start off merging our feature1 branch into next branch. We work on feature 2 branch, then we merge that into next branch. We realise we need to update feature 1 with some additional functionality, so we go back to our feature1 branch, make the changes, then merge that branch back into next? Now we are happy with both feature1 and feature 2, so we finally push the next branch to master, then safely delete the branch. – Rich Nov 22 '18 at 10:48
  • Did some more learning. We can also rebase the merge commits so that we dont have a long list of merges, just a list of actual commits that were undertaken to provide that functionality? – Rich Nov 22 '18 at 11:38
  • @Rich Wait..."so we finally push the next branch to master"? No: that is the all point of that workflow: you never merge an ephemeral branch to master: you only merge the feature/topic branches you are happy with to master. And you reset next to master in order to go on integrating other feature branches. – VonC Nov 22 '18 at 12:04
  • @Rich That is what I meant by "pu or next are never merged to master.". – VonC Nov 22 '18 at 12:05
  • Ah huh! So next, like you said, is just there for us to test a combination of features. and see if they work well together / any conflicts. It makes a lot of sense now thank you so much! – Rich Nov 22 '18 at 12:19
  • You got it. The pu branch is alpha (does it compile together), the next branch is beta (selected features to try together for the next release) – VonC Nov 22 '18 at 12:25
  • @Rich I have summarized our exchange in those comments in the answer. Please tell me if that summary makes sense. – VonC Nov 22 '18 at 17:02
  • Yes your answer is spot on, I understand everything. Just one side question in regard to the merging of features into the master branch. Would the master branch commit history just consist of, for example, 'Added new feature 1', 'fixed bug1', 'updated customer controller'. Then at the top of those commits, a release. So its feature, feature feature, release, feature feature feature, release. If that makes sense. – Rich Nov 23 '18 at 00:46
  • @Rich Yes, that is the idea. You can see that idea in action in the Git repo itself: https://github.com/git/git – VonC Nov 23 '18 at 08:38
  • Great discussion guys, thanks for the clarifications. I am missing something regarding next. Next could be an integration branch for 3 feature branches, but then we choose to merge only 2 to master. Master ends being different from what was tested on next, maybe feature 1 and 2 don't work as intended without feature 3 that was in next. Am I missing something? – iBobb Feb 24 '22 at 15:18
  • 1
    @iBobb "Master ends being different from what was tested on next": if that is a problem, delete the branch `next` first (since it is a *transient* branch), merge the feature branches you intent to go to production (you intent to merge to `master` eventually), re-validate your tests, then merge those same branches to `master`. Destroy `next` (again), reset it to the new `master`, and the next integration/validation cycle begins anew. – VonC Feb 24 '22 at 17:24
  • Do you mean that if feature 3 was not planned to continue, then I simply delete `next` and I only merge feature 1 and 2 to a new clean `next` to test them alone before I merge them finally into `master`? I guess that makes sense...if feature 3 was not going to make it it is not needed in `next` so I can re-create a `next` branch that has only the stuff I need. – iBobb Feb 24 '22 at 17:41
  • 1
    @iBobb Yes, that would be the idea. The main point is not to merge integrations branches like `dev` to `next`, or `next` to `master`, but to merge only feature branches to said integration branches. – VonC Feb 24 '22 at 18:03