I am new to git command line and as such there’s a greater chance of me fragging things unintentionally. I would like to discuss the commands I plan to use during the last stage of transitioning the wiki to the new format.
For transitioning to the new wiki format I am using a new branch named master-new.
The last stage of the wiki transition would require me to rename the current master branch to master-old and the master-new branch to master without losing history and doing so in a way that would be easiest for all those who have clones of the wiki.
The commands I intend to use and the order I intend to use…
git checkout -b master-new
# make changes, push to origin
git push origin master-new
git checkout master
# rename the branch "master" to "master-old"
git branch -m master master-old
# rename "master-new" to "master"
git branch -m master-new master
# push "master-old"
git push origin master-old
Then in the web interface I would change the default branch to master-old. Then delete master and push new master.
I don’t understand why you’d want to hide the transaction.
Without knowing the source or the motivation for the advice you received, I can’t say for sure why it was given. If you tag the tip of the current master branch then you can get back to that commit at any time, branch it into something else, etc… I don’t know why anyone would want to preserve “the branch”… especially since you are already renaming it. Branches are already almost only their names anyway.
What is the reason you wouldn’t just finish what you are doing on master-new (now poorly named), tag the head of master, then merge master-new into master?
I am new to this so I am not sure why. My goal is to do this in a way that will make it easiest for everyone so all they need to do is a pr and they are done.
So by tag master do you cut a branch like master-old and issue a tag for that branch?
I don’t see any reason to make an old branch. Just tag master before you merge the new branch into it.
To create an annotated tag (one with a message, who did it, etc.):
git checkout master
git tag -a old-master -m “Preserving the old master branch for posterity.”
…at any point in the future, anyone who wants to can go back to master as it looks right now just by checking out the ‘old-master’ tag. (They could have done it before if they knew the last commit, this just makes it easier.) (You will probably be happier with the name ‘old-master’ so that it doesn’t show up every time some types ‘master’ in UIs.)
Then merge your new branch: (with master still checked out)
git merge master-new
…make sure things look like you want and then git push.
Well, you can always make a branch instead and just never use it.
git checkout master
git checkout -b old-master
git push -u origin old-master
git checkout master
Being a branch just means some chucklehead can add new things to it.
If you make a branch and tag that branch, can that branch be edited? Yes.
Whats confusing me is this paragraph,
Tags provide many of the same benefits of branches. You can compare different instances of a file and the repository only stores what’s changed since the previous tag point.
The downside of tags is that, once released, you can’t update them (unlike branches). So if you find a typo, or need to add an example, you can’t edit the content in a released tag. You’ll need to release a new tag, or use another versioning method in combination with tags, in order to publish your updates.
If you do decide to take this approach, we recommend having separate tags for documentation that can be created after the tag for the software release is made (or else release the software very frequently).
I take that to mean tagging head like you mentioned here. I was planning on just cutting branches for versions so we can edit them if needed.
Up to this point, the wiki has not used branches, all commits go to master, no tags.
I was planning on all commits go to master, when a engine stable release is made, just cut a branch for that release after updating it to reflect the engine release changes. No tags.
Tagging is just like a symbolic name for a version. A branch is a branch. It means I can edit some file and commit it on the branch and now the tip of the branch points to a different commit. I’d have to move the tag to get it to point to that commit.
Branches are for forking development. Tags are for marking things… like releases.
And even if someday you decide you do want to go back and “edit” some tag, you can always checkout the tag and then make a branch from it.
If that doesn’t answer your confusion then I’d need a better explanation of what confuses… because I wasn’t sure.
I can see how tags and branching works for software releases where you just dont go back and edit a previous release, even though you can do that on github releases.
Very helpful, thanks Paul. I am going to adopt that for my personal projects.
Branch release looks to be best for this because the wiki-ui adds a edit-page link to previous version branches. This will make it very simple for anyone to edit previous version without having to know git. They will be taken to the branch and can just commit the changes and the workflow will handle the rest.
We can cherry pick the changes into other branches if we need from what I am reading.