I am new to DVCS's so please bear with me...
I am the author of a software library, currently hosted as a private repository on BitBucket. I would like to release the source code of my library to the public, but with the following setup:
I would like to maintain two repositories on BitBucket, a private one and a public one.
I would like the initial contents of the public repository to be the current contents of the private repository, without any history.
I would like to continue making commmits to the private repository without touching the public repository. Then, once in a while, I would like to take a whole bunch of commits to the private repository, and push them to the public repository, as a single changeset, and with its own commit message.
How can I pull this off? If it helps, my private repo only has one branch (the main one).
Concatenating changesets
Well, concatenating changesets can be achieved with one of these technics or with rebase extension with --collapse.
Branch structure
To do what you want you must have a development branch with the detailed commits and a publish branch with the concatenated ones. As long as the publish branch doesn't have any node from the development branch as ancestor, you can push only the publish branch. That means you would have to use one of the options above, you can't merge development branch into publish branch because that would set development branch nodes as ancestors of public branch and you would have to push those nodes.
Controversy
Although this is possible, I agree with #Ringding, it shoudn't be the routine workflow. Here are two good reasons for not doing that:
You are adding unnecessary complexity to your workflow, things should be simpler.
Those development changesets are the evolutive steps that led to the final version, they are part of the history, hiding that is like lying. That's why history editing tools are extensions and not core commands, they shouldn't be part of a normal workflow.
This is easy to do. I would create a "publish" branch and merge into that whenever you want to push to the public repo. Then use the convert extension to extract only this one branch.
However, it is almost never a good idea to work like this. Potential contributors usually don't want to put up with development behind closed doors. For open source work, it's usually best to open up everything – bug tracker, source repo, wiki, mailing list, reviews, …
Related
We have three developers working on a microsoft visual studio project that is being hosted on Github but we are using the VS Github extension tool.
We are a little confused about how many branches are necessary for our project.... This is what we have right now.
Master Branch -> Development Branch.
The idea that we are currently working with, is that we will each individually make changes, and then push up to the Development Branch to test with. When Coder 1 makes a change, Coder 2 and 3 will see the change and can merge their projects with the Dev branch and vice versa- so we stay in sync.... Then when we are comfortable with the changes, we merge Development Branch into Master Branch.
We are wondering if we need more branches, or if more branches would be userful....
For example what if we had:
Master Branch -> Development Branch -> Coder1 Branch, Coder2 Branch, Coder3 Branch.
Is there any benefit to adding more branches? We only have three coders and are wondering what the setup should look like.
Thanks!
With only three programmers, I believe everyone can work on the development branch at the same time as long as there's proper communication on what parts each are working on. Everyone can work on the development branch and when it's time to push their own changes, I advise:
git stash, which will put your changes into a temporary stash and revert back to HEAD, pretending like you did not change anything
git pull, which will pull the others' changes
git stash pop, which will bring back your own changes. This way, you can build "on top" of other people's changes. If there's a merge conflict, "local" will be the other person's changes and "remote" will be your own changes.
But if you really want to be safe and formal, separate branches for each person can work, and using GitHub's page, it's easy to implement a pull request and do code review.
All in all, it just depends on how formal you want it to be.
Do we have any way to Gate-Keep our organisation's GitHub Commits? I want to ensure none of our developer's GitHub commits to public repository is exposing any specific strings/Keys.
So a Gatekeeper scripts which parses through the Commits made by our developers and forbids a commit in case it exposes a particular string. I am aware Private repository is the obvious solution but we should have restriction on public repository
too.
You might consider putting in place a GitHub Action workflow, similar to this repository in order to scan the content of a pushed commit (using one of the security scanners).
And, as an action, you could reset the branch to the previous commit, effectively cancelling what has just been pushed.
If the action does not detect any sensitive data, you can in turn push the commit to a protected branch, which acts as the blessed content from which developers can pull.
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
Is there a way to collapse a few sequential Mercurial changesets into a tree view with a single description while maintaining full history? Kind of like rebasing, but displayed so that no history is altered.
These "fixed", "really fixed" and "really really fixed" changesets are driving me nuts.
Update: I found the Collapse Extension and the Histedit Extension, but both rewrite history like rebase. I wish there was a way of adding 'collapse' information with a commit message as a purely visual layer, without throwing away any changeset information.
No, there's no way to do this in mercurial. But what about having the extra changesets is bothering you? Your past code is always buggy, slow, and low-featured: that's why you kept developing it. There's no harm in having changesets that weren't quite right.
You can't control your repo's entire history; you can only change its current state. And if its current state has the bug fixed, there's no problem. Let the past be.
collapse a few sequential Mercurial changesets into a tree view with a single description while maintaining full history?
How you see it? One changeset with history of more-than-one?!
Short answer: No, you can't - or you have single collapsed changeset or you have rangeset
Longer answer: Not in single place, but at least in two it can be reached, if your repository wasn't published yet (because you can't edit history of already pushed repository - shared repository isn't under your exclusive control).
If repository with rangeset in question met the above requirements, you can try
Have one repo with unmodified history for development (hereinafter DEV)
Have one repo (clone of DEV) with collapsed history to sharing to public (hereinafter PUBLIC)
Suggested workflow:
Clone DEV (existing now) to PUBLIC
Collapse rangeset in PUBLIC by any preferred way (thus - rewrite it's history)
Publish PUBLIC
Continue your work on DEV
When needed, transfer changes to PUBLIC (you'll get anonymous branch with history, diverged at collapsed rangeset)
Linearize history on PUBLIC with rebase
Publish PUBLIC
Repeat 4 latest points in cycle during development