No they shouldn't, if avoidable. It's a problem that in my experience happens far too often. However I believe it is more to do with ignorance of how to use git correctly than somebody wanting to steal credit.
- If they want to modify your change before applying it to their main branch, they can easily create a branch for your change. They can then add their own commit after yours and then merge the branch in.
- If your pull request is not based on the latest version of their main branch, then they can issue a
git rebase master
. If there are conflicts they can either choose to fix the conflicts themselves (without changing author), or give you the chance to fix it.
I think Github could and should look for this kind of accidental credit stealing and educate maintainers on best practices when appropriate.
The problem with the first approach is that features have to go through the developer's develop
branch before they reach the shared repository. This means that if a developer has posted a pull request for a big and important feature that takes lots of discussing, reviews, approvals and changes, it'll clung their's develop
branch and they won't be able to post smaller pull requests while waiting on other people actions/decisions related to that big PR.
Essentially - the local develop
branch becomes a blocking bottleneck for each developer.
The problem with the second approach is that features are tested after they are merged into the shared repo's develop
branch. This means you can have bad code in there that'll ruin the project for everyone until fixed. Also, if you decide to postpone or to abandon a feature because it's too hard to fix or because you can't fix it without ruining the overall design you need to change the shared repo's develop branch's history - which is not a very fun thing to do...
Essentially - the shared(!) develop
branch becomes a blocking bottleneck for the entire team(!!).
So - I suggest a third approach, that avoids these problems:
- Create new branch for feature.
- Implement feature.
- Test feature branch.
- Create pull request onto develop branch.
- Merge pull request.
- Confirm that everything works.
- Merge develop into master.
That way, the blocking pipe is the feature branch - and since you can have as many as you want it's not a bottleneck.
Best Answer
A tag is a named reference to a commit that cannot be moved (without deleting and re-tagging). A branch is a reference to a commit that can be moved forward to track development. So while you can make a local branch off a tagged commit, you can't push a commit to a tag--you have to make a PR to merge into another branch.
You could create a branch in your remote named something like
1.1-backfix
off the1.1
tag, and create a PR to merge into1.1-backfix
. You could delete and re-tag the new commit as1.1
(although I wouldn't recommend it). You should probably tag the merge commit as1.1.1
or some distinct version number when it's released so it can be distinguished from1.1