You can tag a revision right after your commit or later (after a push). Then, you can push your tag with: git push origin [tagname]. So, yes, your sequence is ok. Take a look at this, for more details: https://git-scm.com/book/en/v2/Git-Basics-Tagging.
What worked well for me (worked with GitHub, self hosted BitBucket, most likely will work on GitLab too). Pre-requisites Note, that despite the name, password here is your access token generated by GitHub and NOT your GitHub password. from git import Repo full_local_path = “/path/to/repo/” username = “your-username” password = “your-password” remote = f”https://{username}:{password}@github.com/some-account/some-repo.git” Clone … Read more
You have to either set requireForce to false in your .gitconfig or use the -f or -i flag with this command. git clean -f will force to clean the untracked files even if clean.requireForce is set to true which is default. git clean -i will give you an interactive way for cleaning each file git … Read more
(Annotated) tags won’t make Git sluggish, only harder to use in that you will have an harder time to find relevant tags amongst all the intermediate ones. Worst case, it can make your web interface (like GitHub) sluggish if it has to display thousands of tags. Maybe all those tags don’t need to be pushed, … Read more
You could do a rebase interactive: git checkout new_feature git rebase –interactive old_feature and drop B1: you simply delete the line with B1: # If you remove a line here THAT COMMIT WILL BE LOST
I’m coming late to the party but I got a little scared after thinking I lost this morning’s work due to an IntelliJ Smart Checkout. So I looked to see if there was a fix and this question came up first. Sadly, my git stash list was empty (probably because I tried merging the conflicting … Read more
Nothing would happen, but your next push would be not accepted. Unless you would force push. This would not break remote repository also, so it is also not that bad. Things go bad when you have more people using this repo. Rewriting history can cause a bit of chaos for others who will pull new … Read more
Christopher is right, tagging will help you do this. I recommend deleting the branch name too to make it a little harder for someone to checkout the branch and make edits. First, merge the branch into develop git checkout develop git merge –no-ff feature_1 Then checkout the branch git checkout feature_1 Then create a tag, … Read more
To get a git history without any pull request merge commits I can use the merge button (Pull request page) and perform a rebase and merge:
One config setting that might help here is core.sharedRepository, presented in the blog post “Preserving Group Write on Git Objects in a Collaborative Repository”: The solution turned out to be fairly straightforward. In the file .git/config, I added a line that read: “sharedRepository = group“, like so: [core] repositoryformatversion = 0 filemode = true bare … Read more