question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

request for git help

See original GitHub issue

I’ve been merging commits for v1.1 in the v1.1 branch.

But I’m unsure of how to manage the git workflow so that, in the end, when we merge that branch to master, the commit history is correct.

In short, I want the new v1.1 commits to be added after the 1.0.x stuff, when they’re ready, and to end up with correctly tagged v1.0.2 and v1.1 versions.

Related issue is a few in-progess PRs, where master changes during that progress.

You can also see an example of a PR that’s otherwise ready to merge to master at #212.

My earlier assumption was that for the latter cases, the PR branches should merge (or rebase?) master.

Does this have anything to do with why the convention to do work on a develop branch; maybe so one can rebase on it to fix some of these issues?

@dhimmel - any advice?

References:

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:18 (18 by maintainers)

github_iconTop GitHub Comments

1reaction
dhimmelcommented, May 31, 2020

So for PRs that take time to develop, authors should in fact merge from master if they run into conflicts, and we can just squash the history when we merge to master.

Yes.

Unless the merge is for something like v1.1 where you want to keep commits separate. It’s also possible to rebase a branch on master, but a bit more risky if you mess up.

So for PRs that take time to develop, authors should in fact merge from master if they run into conflicts

Note that conflicts are actually pretty rare unless changes are large and sweeping or PRs are kept open for long periods of time. You’re getting more now because of the reorganization, lot’s of whitespace changes, etcetera.

In general, it’s the onus of the PR creator to resolve conflicts, but it’s best for maintainers to be cognizant of what actions will create unnecessary conflicts.

0reactions
denismaiercommented, Jun 11, 2020

Will er really need to keep updating 1.0 once 1.1 is out? I thought 1.1 will be merged into master once it is ready, tagged 1.1.0 and then development takes place there. Any non minor PRs go then in a 1.2 branch.

Read more comments on GitHub >

github_iconTop Results From Across the Web

git-help Documentation - Git
git -help - Display help information about Git ... To get the manual page for the aliased command, use git <command> --help ....
Read more >
Git Help - W3Schools
There are a couple of different ways you can use the help command in command line: git command -help - See all the...
Read more >
Can't sign in, or don't have an account? - GitHub Support
GitHub Support is here to help. Learn about GitHub products, browse our helpful resources, and contact support with your questions.
Read more >
Git on the command line - GitLab Docs
You can now use the upstream as a <remote> to pull new updates from the original repository, and use the origin to push...
Read more >
What is a Pull Request in Git? | Intermediate Git Tutorial
What is a pull request in Git? A pull request is an event in Git where a contributor asks a maintainer of a...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found