How to use git namespace to hide branches

前端 未结 3 1101
夕颜
夕颜 2021-01-03 06:23

Background

I\'m working with a large team using git for version control. The normal flow is:

  • People selecting a ticket from the \"backlog queue\".
相关标签:
3条回答
  • 2021-01-03 06:53

    The first answers are good. If you can fork repositories and use pull-requests or just keep the branches for yourself, do it.

    I will however put my 2 cents in case you are in my situation : a lot of WIP branches that you have to push to a single repository since you work on multiple workstations, don't have fork possibilities, and don't want to annoy your fellow developers.

    Make branches starting with a specific prefix, i.e. wip/myuser/, fetch from / push to a custom refspec, i.e. refs/x-wip/myuser/*.

    Here is a standard remote configuration after a clone:

    [remote "origin"]
            url = file:///c/temp/remote.git
            fetch = +refs/heads/*:refs/remotes/origin/*
    

    To push branches starting with wip/myuser/ to refs/x-wip/myuser/, you will add:

    push = refs/heads/wip/myuser/*:refs/x-wip/myuser/*
    

    This will however override the default push rule for the normal branches. To restore it, you will add:

    push = refs/heads/*:refs/heads/*
    

    Finally, to fetch you WIP branches that are now outside the conventional refs/heads/* refspec, you will add:

    fetch = +refs/x-wip/myuser/*:refs/remotes/origin/wip/myuser/*
    

    You will end up with this 2nd remote configuration:

    [remote "origin"]
            url = file:///c/temp/remote.git
            fetch = +refs/x-wip/myuser/*:refs/remotes/origin/wip/myuser/*
            fetch = +refs/heads/*:refs/remotes/origin/*
            push = refs/heads/wip/myuser/*:refs/x-wip/myuser/*
            push = refs/heads/*:refs/heads/*
    

    (Git evaluates fetch / push rules from the top to the bottom, and stops as soon as one matches; this means you want to order your rules from the most to the less specific rule.)

    People using the standard remote configuration will only fetch branches from refs/heads/*, while you will fetch branches from both refs/heads/* and refs/x-wip/myuser/* with the 2nd configuration.

    When your branch is ready to be "public", remove the wip/myuser/ prefix.

    The refspec internal documentation was useful to make it.


    Please note that once you have push rules in your remote configuration, running the command...

    git push
    

    ... with no arguments will no longer only push your current branch, nor use any strategy defined with the push.default configuration. It will push everything according to your remote push rules.

    You will either need to always specify the remote and the branch you want to push, or use an alias as suggested in this answer.

    0 讨论(0)
  • 2021-01-03 07:09

    Long story short: you can - but it may be a bit tricky.

    You should use the namespace concept (give a look here: gitnamespaces)

    Quoting from the docs:

    Git supports dividing the refs of a single repository into multiple namespaces, each of which has its own branches, tags, and HEAD. Git can expose each namespace as an independent repository to pull from and push to, while sharing the object store

    and

    Storing multiple repositories as namespaces of a single repository avoids storing duplicate copies of the same objects, such as when storing multiple branches of the same source.


    To activate a namespace you can simply:

    export GIT_NAMESPACE=foo

    or

    git --namespace=foo clone/pull/push

    When a namespace is active, through git remote show origin you can see only the remote branches created in the current namespace. If you deactivate it (unset GIT_NAMESPACE), you will see again the main remote branches.


    A possible workflow in your situation may be:

    Create a feature branch and work on it

    export GIT_NAMESPACE=foo
    git checkout -b feature_branch
    # ... do the work ...
    git commit -a -m "Fixed my ticket from backlog"
    git push origin feature_branch # (will push into the namespace and create the branch there)
    

    Merging upstream

    unset GIT_NAMESPACE
    git checkout master
    git pull (just to have the latest version)
    git merge --squash --allow-unrelated-histories feature_branch
    git commit -a -m "Merged feature from backlog"
    git push # (will push into the main refs)
    

    The tricky part

    Namespace provides a complete isolation of branches, but you need to activate and to deactivate namespace each time

    Pay attention

    Pay attention when pushing. Git will push in the current namespace. If you are working in the feature branch and you forgot to activate the namespace, when pushing, you will create the feature branch in the main refs.

    0 讨论(0)
  • 2021-01-03 07:15

    It seems as if the simplest solution here, since you're using GitHub and a pull-request workflow, is that developers should be pushing to their own fork of the repository rather than to a shared repository. This way their remote feature branches aren't visible to anybody else, so any "clutter" they see will be entirely their own responsibility.


    If everything lives in a single repository, another option would be to set up a simple web service that receives notifications from github when you close a pull request (responding to the PullRequest event). You could then have the service delete the source branch corresponding to the pull request.

    This is substantially less simple than the previous solution, because it involves (a) writing code and (b) running a persistent service that is (c) accessible to github webooks and that (d) has appropriate permissions on the remote repository.

    0 讨论(0)
提交回复
热议问题