I am working on the same project from two different computers (let's call them PC-1 and PC-2) using VSCode. The project is on github.
For example, usually when I work from PC-1, I make changes to the code, and when I accomplished some working state of the code, I execute git commit and git push to load working code to the github repo. Then when I need to switch to PC-2, I just executing git pull to load all the changes I made on PC-1.
But what should I do, when I working on something new on PC-1 and need to switch to PC-2, but code on PC-1 is not ready to commiting (feature I working on is still in progress, and code is kind of broken).
As far as I know, you should commit and push only "working" code, but not half-done things. If I`ll just do commit when I need to sync - I'll end up with a ton of "trash commits" that are shouldn't be there, and history of commits will be a huge mess.
So, what is best practice to synchronizing between two computers when there is just "work in progress" on the one of them, and you need to pull that "work in progress" to another one? Should I just use branches? I am not sure if it is good idea, because history of the branch commits would be same mess.
Usually I just trying to clean not-ready code quickly to make code look clean, but it is still "trash commit"
Related
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I am pretty new to Git and I am using sourcetree as a client.
I know that in Git two developers work on the same branch at a time since they have local copies of the remote branch.
So here is a scenario :
A and B are working on a branch feature/release1.0
A commits code to local branch.
Now B commits the code and pushes it to the remote branch as well.
Now A will have to push his changes as well as Pull changes made by B.
So what will A do in this case ?
In this case, A should pull B's changes down first, make sure everything works, commit, and push.
Generally we (my team) don't work quite like that.
When we have two developers working closely on a feature, we work on separate branches and merge into a shared feature branch.
Among the advantages of this is that you can commit and push on your own schedule, which means that you can make your code work without worrying about the other developer's changes and your code makes it to the server quicker. That is, it's somewhere other than your own machine, somewhere that's probably backed up.
A must git pull first (some merge may be needed) and than push the code.
If A try to push his code in the first place, git will tell that the remote and local branches have diverged and instruct the developer to pull the code first.
If you pay attention to git commit error messages (and git status messages) you will always know what to do.
As you said, A has to get the changes from B (git pull) before pushing her changes. It is likely she has to deal with some conflicts, which should be resolved locally before pushing the code.
Apart from that, you should probably reconsider your branch scheme to avoid this kind of conflicts. Would it be possible to work in different branches? For instance, by redefining the tasks, to be more fine-grained.
Moreover, it is weird, at least for me, the name or the branch feature/release-1.0. Looks like there are releases by features basis, os something like that. Take a look at http://nvie.com/posts/a-successful-git-branching-model/. See how the release branches are fed from the developing branch, and this one receives the commits from the features branches.
Hope it helps!
This is probably a noob question, as I only started using Eclipse Git a few days ago.
I was wondering if it was, in any way, possible to have multiple people working on different files in a repository but, when ready to commit, only have one commit for all, instead of one commit per person...?
I was also wondering if there was an option to automatically pull modified files, or a way to update the modified files in every person working in the repository, without making a commit per person first?
I'm asking this because I use Jenkins, and every time a commit is made in GitHub, it immediately starts a build, and it would be very annoying to create a commit per person just because of probably some lines of codes.
Best regards
EGit doesn't have a feature for that, but you can work around it by "squashing" the commits in GitHub. Here's how it works:
Step 1) Create a branch
Step 2) Make everyone work on that branch until it's time to commit (in your words)
Step 3) Create a pull request for merging the branch with master or whatever branch that is marked as default
Step 4) Click "Merge pull request" and then do this:
If you can't find the option to squash-merge, go to the repository settings and make sure the checkbox highlighted in this image is full:
Step 5) Confirm squash and merge
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}