I am having hard time devising a workflow for github now that we have swtiched over from clearcase ucm to github.
In clearcase ucm, I just had a development stream and an integration stream. all
developers check in under dev stream which finally gets merged to int stream and baselined.
How can the same thing be done in github?
A stream in ClearCase is a akin to a Git branch in order for multiple developers to collaborate to a common development effort (by delivering/rebasing to that stream)
Since Git is a distributed VCS, you can achieve the same collaboration by:
making local commit to a branch (typically dev for development)
pushing those commits to a common remote repo
If others have already pushed their own commits (like a deliver), you would git pull --rebase first (a bit like a rebase), resolve any conflict, and push back.
A true Git workflow would involve feature branches, that you would then combine and merge to a dev branch, then an integration branch, then, for release, master. Like gitworkflow.
The remote repo can be managed by a Git repository hosting service, like GitHub, BitBucket or Gitlab.
Related
My client is using SVN and my company is using Git (central bare Git repo). So I have the task to sync both servers. I can't use SubGit , because I can't do any modification on either server.
I successfully used git-svn to download the SVN to my local Git repo (using TortoiseGit). But I can't figure out how to set up a remote upstream to the central Git Repository (using Egit in Eclipse).
Is it possible to set up a remote branch, so I can check in the SVN stuff from my local Git into the central Git repo? How?
thanks.
If I understand correctly, you can't update hooks in SVN and Git repositories. That complicates the task a lot, because you can't reject pushes Git if someone is committing to SVN at the same moment and vice versa.
I think, that git-svn is not a solution because on sending commits to SVN ("git svn dcommit") it changes Git commit SHA-1 to add git-svn-id: signature. As result when one pushes commit C to your Git repository, you fetch that commit to your git-svn repsository, run "git svn dcommit", it translates it to SVN and adds git-svn-id: signature to commit message thus changing commit SHA-1, so you'll get another commit C' in git-svn repository. After that C' should be sent back to the Git repository, and after that the user that pushed C should download C' and replace C with C' in his working copy. So you won't have easy and transparent synchronization.
With SubGit you can reduce your problem to synchronization of 2 Git repositories by creation of an "intermediate" Git repository with SubGit installed into it. Synchronization of 2 Git repositories is a simpler task (and there's a lot of solutions on the internet) but it's still isn't a piece of cake, because 2 different users can push into both repositories simultaneously (and you can't discard one of the push, because you can't create hooks in the repositories). If these changes are conflicting, you can resolve that only manually, and I'm afraid this is the best you can do: create a repository with 2 remote and using a script constantly fetch changes from one of them and push the changes to another one and vice versa (and notify the administrator and stop synchronization on simultaneous conflicting changes).
Disclaimer: I can be biased because I'm one of SubGit developers.
I've been a great fan of Plastic SCM for a while now, using it locally for my own personal projects. Lately I've decided to contribute to an open source project on github. Since Plastic SCM can be used as a github client I decided to use it as such.
Now this is my first time using github, so I followed the classic github workflow as described in all the tutorials:
Fork the repo to get your own copy
Sync the Plastic SCM repo with the personal github repo
Commit changesets in Plastic SCM
Sync the Plastic SCM repo with github again
So far everything went fine. I contributed my code, uploaded it to github and saw all the changesets and branches appear in the github webui.
Next I put in a pull request to the original repo I forked from. This is where my problems start. The pull request was accepted, and a new changeset appeared in the original repo which contains my pull request. It seems all my intermediate branches did not transfer to the original repo either.
As shown in the network graph above, the original repo (purple) is now no longer in sync with mine. I started with further development in another branch (VEH003) but this one seems to be completely disconnected from the original repo (purple).
In my Plastic SCM client I can see exactly the same network graphs in the branch explorer, with the exception of the purple branch.
I read that to update your fork with the changesets from the original repo this has to be done explicitly, and in your local git repository (github help). Now I don't know how this is done using Plastic SCM.
To sync your local fork with the original repo, as described in the github help, you need to merge the upstream master branch with your local master branch.
The point here is that Plastic SCM does not track or sync the upstream references (the references of the original repo), just your github's repo references.
To be able to update your fork, and continue working with Plastic SCM you should use the command line git client to perform the update following the guide you linked, push the local git changes to your github repository and then sync Plastic SCM with github to get the changes. Step by step:
Use the git client to clone your github repository
git clone your-fork-url
Add the upstream repository.
git remote add upstream original-repo-url
Fetch the upstream references.
git fetch upstream
Merge upstream changes to your master branch.
git checkout master
git merge upstream/master
Push master branch to your github repository.
git push origin master
Sync Plastic SCM with your github repo.
We have a main trunk branch and various other feature and personal branches in a bazaar repostiry. We'd like to keep personal branches in sync with the main trunk but allow each developer to remotely call 'pull' on his remote branch so that the remote is in sync with trunk. The developer then branches his personal branch to his machine, edits, commits (or branches additional branches as needed) and then can push the updates to his personal branch, or if the remote branch has updated - merge it (and thus latest trunk) with his working local branch before he pushes that up.
Later on a gatekeeper can pull the personal branches and merge them into the main trunk.
How can I issue such a remote pull request so that the remote branch pulls from trunk?
I think the step of pulling from the trunk to remote user branches is simply pointless.
In any case the pull operation is defined only for local branches. Triggering a pull in a remote branch would mean ssh server bzr pull -d path/to/branch, in other words you always need shell access (local or remote) to the branch you want to pull to.
Pulling to remote user branches seems pointless because the users could pull directly to their local branches instead. Your setup could be reworked like this:
Have a main trunk branch and various other feature and personal
branches in a bazaar repository. The developer then branches from
trunk to his machine, edits, commits (or branches additional branches
as needed) and then can push the branch to his personal remote branch.
Later on a gatekeeper can pull the personal branches and merge them
into the main trunk.
At any point, the developers could merge from the trunk to get new changes that have been merged by the gatekeeper since they started working in their local branches.
Comment if you think this would not accomplish the same.
If you really want to update remote branches without shell access, push is the only way. You could do an automated push on all remote personal branches triggered by new revisions in the trunk, but as explained above it would be pointless. If the users want to sync from the trunk, they should just sync from the trunk.
I am trying to find out what would be the best way to set up egit repos for mutliple developers.
I found some arguments to set up independant repos for each developer and then the recommendation to merge the files by setting the respective external upstream repo to eg developer B in Eclipse of developer A so A can pull and merge with B. However A then needs to change the repo back to his own all the time. And switching upstream repos in the settings is quite cumbersome.
Alternatively all developers could work off the same repo in different braches - then merging would be easier since noone has to go to settings and change the upstream repo. On the other side this is also kind of "dangerous" since every developer is working on the same repo without restrictions (so I heard)
Which way is better in the long run?
In the long run, having one upstream repository is easier to manage.
Each developer can make their own branches locally.
They should agree on a common branch to push to though. It can be master, or a feature branch (if a few of them are collaborating to a specific feature).
The idea is, before each push, to pull --rebase that branch from the upstream repo in order to replay your local work (the commits you haven't pushed already) on top of upstream/branch (git pull --rebase will fetch and then rebase your local work on top of what has just been fetch).
That way, a developer will only push commits which will be merged on upstream as a fast-forward merge.
In EGit terms, that pull --rebase is configured when you create a tracking branch.
Rebase: When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch
I'm using Egit on Eclipse Mac and PC to sync a project that has three branches:
master
dev
rendersystem
I've created the project on the Mac and when I created the two branches dev and rendersystem I've used revs/heads/master as the Source ref and as Pull strategy I've used Merge.
Now I've switched to my PC and imported the project with Egit incl. all three branches. But if I change to dev or rendersystem branch it tells me that these branches are remotely tracked (in Branches dialog, Remote Tracking /origin/dev and /orginin/rendersystem).
If I check out dev or rendersystem branch and change my code, then commit it and try to push it to Github, it doesn't push the dev or rendersystem branches, only the master it pushed.
My question is now: How do I change the dev and rendersystem branches so that they are in a state where I can push them to Github from my Mac and PC?
Sorry if this question sounds confusing, but Git is one hell of confusing for beginners.
Remote tracking branches are read-only in git, as they represent remote changes. A Fetch will only update these remote tracking branches. A Pull first executes a Fetch, and then merges the changes with a locally editable branch.
On the source computer there was no need to create this branch, as it was initialized locally, and pushing the branch can create the remote branch.
You can create a local branch from the remote branches by Right clicking on the Remote branch in the Git Repositories view, and selecting Create branch... After that, your branch would be writable.