I often commit to local branches and switch between them without pushing the commits to the remote branches right away. From time to time I want to review all commits which are ahead of the respective remote branches. Based on this I want to push some of the branches to remote.
Particularly I would like to get an overview with TortoiseGit of all branches which are ahead of their remote branches in one list.
I have been used to the overview in SourceTree where all branches with pending commits where highlighted: SourceTree branch overview with highlights I am searching for a similar feature in TortoiseGit.
I have tried the Sync Dialog: As far as I understand I can only see the outgoing commits of one branch at a time. The solution would be acceptable if this list contains the incoming commits as well (distinguishable).
Is there a way to get a list with all branches where outgoing commits are pending? I also want to use this feature in order to check if I forgot to push any commits.
I have seen the "Push all branches" option in the push dialog. This is not what I am searching for as I need to review the commits before pushing them.
Just want to clarify your question:
Does the following figure match the figure you provided?
Related
I have small experience using git repos. So i'm a little bit confusing, trying solve my problem.
I use Xcode installed (not vie terminal) git system and remote github repo.
The problem is for some reasons I've been commiting code for last 2 weeks not inside my master branch (it's the only one), but somewhere else (in source control navigator it seems on project level (high blue folder with project name)). So because of that i coudn't and still cant push changes to github.
if i select master branch, the last commit was 2 weeks ago. However if i select highest blue folder with project name, i see fresh commits.
How can i carry over all commits (or at least the last one) back in my master branch, which is connected with remote github repo and not lose data?
And what actually happened?
From your comments, it appears that somehow you ended up in a detached HEAD state, to which you have made several commits. However, it is easy to get out of this situation. Just checkout a new branch from your detached HEAD state, and then merge this branch back to master:
# from ac4c47c
git checkout -b your_branch
git checkout master
git merge your_branch
Then, you may push master to GitHub. Or, you could push your_branch to GitHub and open a pull request back to the master branch. Note that if you have unfinished work currently in your working directory and/or stage, you should finish it and then commit before creating your_branch.
So while this is completely do-able (albeit using some fairly fancy scripting) in Jenkins, I'm just wondering if it's do-able in VSTS.
I'm not too familiar with capabilities of VSTS (have read https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-build-git).
I want all changes pushed from a feature branch to master to be automatically merged into all other active feature branches. So basically, I want (what I call) true CI.
Is this possible in VSTS, and if so, how would I do it?
EDIT 1:
Read this:
https://learn.microsoft.com/en-us/vsts/build-release/actions/scripts/git-commands#merge-a-feature-branch-to-master
This would work for me by simply switching the merge direction; instead of merging from feature branch to master, merge from master to feature branch.
So the question now becomes:
How to get a list of all active child branches?
Given that I'll be using work items mapped to branches, would this suffice?
https://learn.microsoft.com/en-us/vsts/report/extend-analytics/work-item-links
No, it is not supported in VSTS, with Pull Request it just can merge source branch to a target branch.
The workaround is that you can create the Pull Requests for related branches during the build/release, refer to this thread for detail steps:
How can I create a Pull Request when a release completes in VSTS?
Update:
The other way is calling git command to merge branches: Merge a feature branch to master
Regarding active branch, as we discussed, you can link them to a work item, the work item has the TO DO, In Progress etc... states that can identify different "state" of branches, and you can retrieve the work item through Work Item REST API.
I've looked around the site but I couldn't find an answer that covers mine entirely, so please excuse me in advance if I missed it.
I inherited a VB.NET project that didn't have source control (it started as a pet project of a long-gone dev and nobody ever bothered after that to put it in), and by a friend's suggestion I thought about using Git for source control.
The project is a niche product that is customized and sold according to the customer's specs, so that brings the problem that even if 95% of the code is the same for all the customers, sometimes up to 10% of the code is changed and tailored for each customer, by changing or adding lines to existing functions, sometimes adding whole blocks of code, but there's no commonality in the changes between different customers (a function changed in one might not be changed in another).
To complicate things further, due to maintenance contracts, updates made to the baseline app have to be replicated in the customer's branches should they want them, and sometimes changes we make for a specific customer are good enough that we want to put them in the baseline app and replicate them to the other customers, BUT keeping the customizations for each customer!
So with my little knowledge of Git, I thought it would be like:
(customer 1)
C1-----
(main) /
A------B------D
\
\ (customer 2)
C2-----
\
\ (customer 3)
C3-----
...but I can't see how it's going to work after that:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
Can I "mark" specific lines of code so they are not merged/committed?
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import process to put those folders them into Git?
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done with the console?
Thanks and sorry again if it overlaps with another answer.
I'm relatively new to git and normally use PoshGit for all my operations, so while I may not be able to help you with everything, I hope I can help with some things:
Can I merge SOME changes from the customer's branches into the main trunk WITHOUT merging others that are only useful for that customer?
Can I merge SOME changes from the main trunk into each customer's branches WITHOUT losing the customizations in those branches?
From what I understand, both of these operations can be achieved by using git cherry pick, which allows you to pick a particular commit from one branch, and add it to another without merging the branches together.
For example, assuming you want to add a change made to customer1's repository, to customer2:
First you get the hash ID of the commit from customer 1 that you want to insert into customer2
git checkout customer1Branch
git log
commit 2e8c40025939e8cf41dec70f213da75aa462184b
Author: xxxxxxx
Date: xxxxxx
This made a change that you want...
You then copy the first few characters of the hash you want to cherry pick, change to customer 2's branch and cherry pick it into the branch.
git checkout customer2Branch
git cherry-pick 2e8c40025939e8c
Now, if you do a git log, you'll see your cherry pick at the top. A similar tutorial can be found here (http://nathanhoad.net/how-to-cherry-pick-changes-with-git)
Can I "mark" specific lines of code so they are not merged/committed?
You may find help from a similar question was asked and answered here:
Commit only part of a file in Git
Three or more devs will be working in this, each in his own machine but pushing changes to the company's repository for synchronization. What are the implications for this process?
Since GIT is a fully Distributed VCS, each dev on your team will effectively have a full clone of the central repo on his own machine (complete with full history of that repo.) This means that log history queries and other requests (such as finding out who did what) don't need to go through your central server, but can be done privately and offline by each dev.
Similarly, the changes that each dev makes will become available to all of you (for example, all new branches will be available), but it can sometimes be frustrating to be working on the same features if you're not quite used to git.
As always its a good idea to commit early and often, this will decrease the tension you're likely to face when changes clash. you should also set some structure to when pushes are done, especially if you rely on each other's work to continue.
Another idea you may want to try is having one person in charge of the repo and having him merge changes and patches to help coordinate your efforts.
Right now, every customer has a separate folder and separate project files with all their source code. How would be the import
process to put those folders them into Git?
EDIT
Thanks for clarifying what you meant by this question. You could expand on a similar approach adapted from the answer given here: How do you create a remote Git branch?
Create a new mainline branch for your BASE project and push it to your remote repository.
cd baseProjectDirectory # navigate to your main project directory
git init # git initialize the dir
git add . # recursively add all files in directory to git repo
git remote add <remote-branch-name> <remote-url> # Add the url to your remote directory to your git repo
git commit -m "Initial commit of base project"
git push <remote-branch-name> <local-branch-name>
This will establish your Baseline project on a remote repository called remote-branch-name under a branch called local-branch-name.
You can then navigate to your other projects and repeat these steps putting your repositories under different branches on the same remote, by using new local branch names, i.e. instead of using the local-branch-name when creating a branch, just use a new branch name, such as git checkout -b new-local-branch-name
so if, for example your base project push (the last line of code) was:
git push clientproject base
Where "clientproject" is the name of your remote, and "base" is the name of your local branch, you can just change the line to:
git checkout -b client1 # Creates new branch named client1
git branch -d base # Deletes base branch
git push clientproject client1
Note that while it's not strictly necessary to delete the "base" branch before continuing, it does keep your repository cleaner and is thus considered good practice. Don't worry about losing anything though, your entire git history from base will be copied to client1 on checkout.
Also note: Since your situation requires you to do this from different directories, you'll probably be deleting a branch named "master" and not "base".
Pushing like this will keep client1 on the "clientproject" remote, but will place the project under on a new branch called client1, complete with its own history.
The same steps can be used for the rest of the projects. If I've lost you anywhere along the way, I suggest reading the above link (it's much more concise than I am).
All of this must be done with Visual Studio, with Gitextensions and the Git Source provider for VS. Is it supported, or it has to be done
with the console?
I haven't yet used VS with Git, but I assume most if not all these operations would be supported since they are native git commands.
Hope this helps.
OK, I'm new to Mercurial and version control branching in general, so I may have a fundamental misunderstanding of what's going on here -- please be kind... ;)
We are a small development team (2 developers) working on a project, and we have a need to implement a fairly significant change that may take weeks or months. At the same time, the program is in daily use, so we have a need to make regular patches and fixes.
Because of the long-running nature of the significant change, I created a branch off the default branch (call it dev1). I will want to periodically merge the changes from the default branch into the dev1 branch, for reasons that don't need to be reiterated here. However, I do NOT want the changes from dev1 merged into the default branch until much later in the development.
I have tried several different ways to do this, but it always seems the merge affects both branches. After the merge, if I update to the default I now have changes from dev1 merged into the source.
Can I work on both branches using the same repository? If so, can someone please share the sequence of commands to use? If not, it seems to me I would not be able to push the dev1 branch up to the master repo until it was finished, and that just doesn't seem right.
We are running the latest TortoiseHg for Windows, and for the most part I love the graphical tool. However, I am perfectly willing to drop to the command line to do certain tasks when necessary.
Thanks for any help,
Dave
This depends on what sort of branch you've created.
If you have created a named branch, and are working in a single working directory, then you need to use one workflow, but if you have cloned your production repository, you need to use a different workflow.
Named branch workflow, single repo/working directory
In this case, you are using update to switch between the default branch and the dev1 feature branch.
When you want to work on the default branch, update to it, do your bug fixes, and commit those changes. Do not merge in changes from dev1 branch.
When you want to work on your dev1 branch, update to it, merge in your bug fixes from the default branch, work on your feature and commit when done.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes, merge them in and then resume your work (there are shortcuts you can take here, but this way you can backout the merge if it gets messy)
Note: All of these assume that all of your changes are committed at the point you want to switch between dev1 and default branches.
The important thing to note is that you only get the changes from your dev1 branch in default when you merge them in. If you only merge default into dev1 then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple merge operation.
Unnamed branch workflow using dev1 repo cloned from production repo
This workflow is similar, but allows you to work on the default and dev1 branches simultaneously, without having to update to switch between the two.
When you want to work on the default branch, use the repository where the tip is your production code. Do your bug fixes, and commit those changes just as you would normally.
When you want to work on your dev1 branch, use the repository where the tip is your dev1 feature branch. If there have been fixes in the default repository, pull in the changes and merge them into your clone, but do not push the merge changeset back. Only push your changeset back when you want to deploy you feature to production code. Once the changesets from default have been merged in, you can continue working on the feature.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes from your shared repository into your default production clone, then pull those changes down into your dev1 feature clone, merge them in and then resume your work.
Again, the important thing to note is that you only get the changes from your dev1 branch in default when you push them up to your default production repository. If you only pull/merge default changesets into the dev1 clone then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple push operation.
Yes, you can absolutely do this with Mercurial.
First, in case it isn't clear to you (it wasn't to me for some time), there are 3 types of 'branches' in Mercurial:
clone a repository
a 'named branch' (using the hg branch command)
an anonymous branch, which you can manage with bookmarks or just remembering the changeset
I'm guessing that you used the hg branch method. Be aware that this is often not what you want, because that branch name will live in the repo's history forever (well, there is the --close-branch option, but still...).
The essential workflow is:
update to dev branch with hg up devbranch
commit changes to dev branch
merge with main branch via hg merge default or just hg merge as desired
(repeat as desired)
And for working on the default branch:
update to default branch with hg up default
commit changes
(repeat as desired)
Do NOT do this:
update to default branch with hg up default
merge with dev branch with hg merge
I suspect that you are using the command hg merge without specifying a branch name. That will merge with any other head, which may or may not be what you want.
Edit: The above info is probably not your issue. Your issue is probably running a merge when your current branch is the default one.
You don't want to run hg merge from your default branch.
# bang on dev1
# more banging on dev1
# someone beats on default for a while
# update to dev1
hg up dev1
# bring in the changes from default
hg merge -r default
# validate successful merge
hg commit -m "merging"
The key is committing on dev1 when you bring changes over from default.
Note that I'm using named branches here.
This sentence:
After the merge, if I update to the default I now have changes from dev1 merged into the source.
tells me that you're doing something wrong. It is perfectly doable what you want to do, work on two branches in parallel, and merge from one to the other, without influencing both.
It is important to know that the merge is a directional merge. You merge from one branch to the other, and when you initiate the merge, you should be on the to-branch.
directional in the sense that the direction plays a role in the outcome. For the actual contents of the file, it doesn't matter which direction you merge, but the new merge-changeset you commit will be on the branch you was on when you initiated the merge (unless you override.)
So, update to the head of dev1 first, then merge with default, and after committing, you should have a new changeset on the dev1 branch, but default should be left undisturbed.
This is more of a tip than an answer, but...
I use this workflow a lot. I find the Transplant extension very useful for named branch workflows. TortoiseHg supports it, so you can enable it in the TortoiseHg options. It lets you cherry-pick from other branches, which is very useful - especially if you regularly commit to the wrong branch.
For personal projects I use Git for SCM, but at work we use TFS. One thing that I like about Git is that it allows a person to easily squash all the changes made in a branch when pulling the changes back into the master branch.
The benefit of this is that if their is anything wrong with the changes they can easily be removed be reverting back to the version before the merge even if no tag was created.
Is this. or the equivalent possible in TFS? Is this where shelving changes fits into the equation?
Thanks.
Performing a merge in TFS results in a single commit; all of the changes from the source branch get rolled up into one changeset pended against the target branch. So as far as I understand your question, the answer is "yes".