Problems with source tree branches

[anon37455979]

In my earlier topic, I managed to remove previous branches because discard and merge could be used. I just filed a complaint to the developers at atlassian to create a branch for every single item so we don’t waste time. My screenshot is here. If anyone knows how to delete without wasting too much time, a helping hand would be useful.

[topdog]

I don’t know why you would want/choose to create a branch for every commit - what is that gaining you?

It’s reasonable for a git repository to have several hundred commits (if not several thousand). It was not intended to have anywhere near that many branches.

[topdog]

As a suggestion, if you need to create references in the commit history for going back to later (and with something other than the commit message), look into using tags instead.

Like branches, a tag is basically a “label on a commit”, but whereas the branch represents the head of the commits relating to it, a tag can exist on any one without carrying that significance.

[anon37455979]

I understand your points. What i meant was both commit and push so that we can easily keep track of every change. Let me know if there are limitations to sourcetree so I can understand it better. In this case, does it mean i cannot remove the records where there are no branches created as a record? Is this what you mean?

[topdog]

You can still commit and push to the current branch you are on without creating a new branch each time. Adding a branch for every commit does not aid in tracking changes - the opposite in fact.

A branch represents some deviation from the main line of code, and that deviation should be temporary for some time.

For example, maybe you need to implement a new feature and that feature could take 5, 10, or 20 commits to complete (it’s not yet known). The “main” branch can remain unbroken from unfinished code if you create a new branch to do this work on, and only when it all works as expected would you then merge it back into the main branch.

That way if you mess up part way through you can also roll back your changes whilst on this other feature branch, and it’s easy to know how far back to go before you’re at the beginning of the changes for this item.

This isn’t about sourcetree or its limits, it’s fundamentals of source control (and to some extent git).

Here’s my analogy that I use. Every commit you do automatically knows which previous commit it was based off of, so each commit is like a train station and there is a train line from that station to the previous one.

A branch is only a label, it’s like a train on those tracks, parked at a station. It knows based on that station all of the other ones it took on its journey to get to that point, but it’s still free to move on to new stations (commits) and leave this one behind, or even be sent back to one of those earlier stations again if needed (forgetting the journey “ahead” of it, in some sense).

You don’t need a new train at every new station, to just sit there going nowhere.

Back to the commit and push functionality, pushing is always allowed to the branch you are on, and whether there is a branch (train) present at a commit (station) doesn’t protect or allow that commit from being discarded any more than it can be already.

To keep track of every change, the tools you are given are:

1. Every commit knows its parent and can form its own tracks back to them without there being a branch label present.
2. Every commit has a message, an author, and a time.
3. The first line of the commit message should represent the information you need to at-a-glance determine what the change is for (the branch label actually should not, at least it should not be commit specific but rather feature or purpose specific).

I think you are getting some familiarity with how source control works, but git is almost too open and too flexible at how you can do things that you can end up in a workflow that doesn’t really use it correctly.

There are workflows out there (git flow, github flow, and others) that get you using it correctly, but I think the best thing for you would be to look at GameDev.tv’s git course since it’s designed entirely around getting up and going with a workflow for game dev editing (Unity targeted specifically but not exclusively). It will show you the best practices for both making your changes and reconciling differences and recovering from mistakes, the way that these could (and should if no better way is being used) be done.

Also take a look at and follow some repositories in github - there are many public ones for the development of popular projects and tools, and you can get a look at how they are structured. They can all be developed using best practices that don’t need branches on every commit.