Trying To Understand/Determine A Basic Git Workflow












0















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!










git github merge version-control







share|improve this question

























  • 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 stackoverflow.com/questions/40892485/…

    – user7154703
    Nov 21 '18 at 6:40
















0















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!










git github merge version-control







share|improve this question

























  • 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 stackoverflow.com/questions/40892485/…

    – user7154703
    Nov 21 '18 at 6:40














0












0








0


1






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!










git github merge version-control







share|improve this question
















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!










git github merge version-control




git github merge version-control






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 '18 at 4:43







Rich

















asked Nov 21 '18 at 3:00









RichRich

225




225













  • 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 stackoverflow.com/questions/40892485/…

    – user7154703
    Nov 21 '18 at 6:40



















  • 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 stackoverflow.com/questions/40892485/…

    – user7154703
    Nov 21 '18 at 6:40

















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 stackoverflow.com/questions/40892485/…

– user7154703
Nov 21 '18 at 6:40





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 stackoverflow.com/questions/40892485/…

– user7154703
Nov 21 '18 at 6:40












1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer


























  • 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













  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

    – 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 5: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 5:57













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404684%2ftrying-to-understand-determine-a-basic-git-workflow%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














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.






share|improve this answer


























  • 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













  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

    – 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 5: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 5:57


















0














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.






share|improve this answer


























  • 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













  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

    – 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 5: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 5:57
















0












0








0







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 22 '18 at 17:01

























answered Nov 21 '18 at 5:43









VonCVonC

845k29426783233




845k29426783233













  • 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













  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

    – 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 5: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 5:57





















  • 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













  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

    – 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 5: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 5:57



















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







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















@Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

– VonC
Nov 21 '18 at 12:45





@Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….

– 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





@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 5:55







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 5: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 5:57







@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 5:57






















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404684%2ftrying-to-understand-determine-a-basic-git-workflow%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Image
3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question
Read more

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Image
up vote 5 down vote favorite 2 I would like to make it so that the vertical space below the title of each chapter is the same when using the Bjornstrup package (i.e. so that the descenders do not affect the spacing - as shown by the red arrow in the picture below). I think I'm fairly happy with the spacing around "A chapter", so I'd really like titles without descenders (e.g. "Contents") to have the same vertical spacing as "A chapter" below the title. I would also like to remove the large "0" in the contents title. Any help appreciated, as always. documentclass[11pt,a4paper]{book} % Packages[![enter image description here][1]][1] usepackage[left=3.5cm, right=3.5cm, top=4.3cm, bottom=4.25cm]{geometry} usepackage[utf8]{inputenc} usepackage{libertine} usepackage[libertine]{newtx
Read more

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Image
0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"
Read more